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

[Davis Herring]

> 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
idempotent.

> 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
`unwind-protect'.)

> 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
here.)

> 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
problem.

> [...] 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.

Davis

-- 
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
shipping.