[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: with a fresh emacs "(buffer-local-value fundamental-mode (current-

From: Davis Herring
Subject: Re: with a fresh emacs "(buffer-local-value fundamental-mode (current-buffer))" error.
Date: Thu, 16 Apr 2009 14:49:58 -0700 (PDT)
User-agent: SquirrelMail/1.4.8-5.3.lanl2

> Thank you. Your right. What knocks my socks off is it generally works
> without trouble...

For variables whose values are always t or nil, evaluating them is

> Maybe i'm paranoid but  ({.... do stuff with SOME ARGS ...}))
> includes nested lets/lets*, catch/throws, save-excursions,
> with-temp-buffer, etc.
> wrapping that in a progn wrapped in a let* seems to ensure that the
> return to the conditional
> (longlines-mode {nil/t}) gets executed as the last form.

The do-stuff will either return a value, in which case let* will continue
evaluating things in order (without a progn), or it will exit non-locally
(via an error or quit or throw), in which case the rest of your progn (and
the rest of the let*, if any) will get skipped.  If you are concerned
about restoring the state after some code runs, even in the case where it
exits abnormally, use `unwind-protect'.  (Note that bindings, or temporary
values, created by let[*] are always undone without the need for

> Obviously, but when shuffling the text between real<->temp buffers
> weird things seem to happen when I *don't* disable lLLM before leaving
> current-buffer
> [..]
> Also, LLM doesn't *really* change text FWIU... only EOL representation no?

That would be because LLM does change the buffer text -- it replaces
certain spaces with newlines when a file is loaded, and does the reverse
when it is saved.  It would not be hard to use part of longlines-mode to
do either of those transformations on the text you want to work with --
but do it outside any user buffers.

> I'll give it a gander but swapping a hook variable (one more poorly
> specified than the
> elisp variable I'm dancing around) doesn't strike me as quite the right
> thing.

Calling `longlines-mode' as a function does much more work than that!

>> (bound-and-true-p 'longlines-mode)
> Thank You. This seems much cleaner and prob. exactly what is needed.

(My apologies, as I said in another email, for the spurious ' I included

> Then fundamental-mode shouldn't masquerade as one behind the
> major-mode elt in buffer-local-variable's alist pair.

It's not -- the _symbol_ `fundamental-mode' is the (buffer-local) _value_
of the _variable_ `major-mode' in certain buffers.  Only the cars of the
elements (or the whole elements if they are symbols) returned by
`buffer-local-variables' are variables: the cdrs can be symbols, or
numbers, or buffers, or...

> Doesn't this generally imply an assumption that one know which mode
> one is testing for?

You only need know whether the mode you're interested in is a major or a
minor mode, which is usually trivial to find out.

> ??? Can't they reside outside of a dir-locals.el bound to a 'class'.
>> They are irrelevant here.
> Is this based on your assumption that dir-locals are _just_ data on disk?

You're right about the classes; I hadn't kept up with that mechanism.  But
it doesn't change the fact that they merely become buffer-local variables
in the end; the directory-locals mechanism is just a way of specifying
variables for more than one file at a time.

> In which context? The contexts at hand are still (in my case) at the
> outer layers.

What I meant by "this context" was the issues you were having with
`buffer-local-value'.  So long as you leave each `let' that binds a
possibly-buffer-local variable (which is nearly anything for which there
is a `defvar') in the same buffer as you entered it, you'll not have this

> [...] I'd be happy to share the details but I
> doubt you'd benefit from pointing out all the deficiencies in my code
> (I'm sure the inverse isn't the case) :)

You're welcome to ask me in particular, but it might also be useful to,
say, post it to the EmacsWiki; I imagine several people there (including
me) might be willing to help out.


This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during

reply via email to

[Prev in Thread] Current Thread [Next in Thread]