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

[MON KEY <monkey@sandpframing.com>]

> Your quoting is still off, in general.

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

> You should be using
> (buffer-local-value 'longlines-mode ...), and there's no reason that I can
> think of for you to use (buffer-local-value 'anything (current-buffer)),
> because buffer-local values for the current buffer are already in force
> without having to call `buffer-local-value' at all.
OK

> Meanwhile, I can't imagine why you're quoting `t', or why you're calling

Maybe I want to change that symbol's value to something else at some point?
Maybe habit? Maybe a lack of understanding syntax? Again, its probably
a testament to Emacs robustosity that the code made it this far
without choking

> `and' with only one argument, or why you're calling `progn' within the
> body of a `let*'.

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.
>
> If you're in a temporary buffer that you created, longlines-mode isn't
> active in it anyway.

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

>  If you're in a user's buffer, you probably don't
> want to do something so heavyweight as disabling and reenabling
> longlines-mode, because it involves changing the text in the buffer.

Ok. but so long as it's _my_ buffer I'll (attempt) disabling it as I
please warts and all :)
Also, LLM doesn't *really* change text FWIU... only EOL representation no?

> If you merely want to prevent longlines-mode (and anything else) from
> responding to changes you're making (in a buffer where it's active), you
> can just bind `inhibit-modification-hooks':
>
> (defun frob-without-mod-hooks (...)
>  (let ((inhibit-modification-hooks t))
>    (frob ...)))

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.

>
> (bound-and-true-p 'longlines-mode)

Thank You. This seems much cleaner and prob. exactly what is needed.

>
> Again, `fundamental-mode' is never a variable.  Nor is any other major
> mode.

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

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

>
> dir-locals are just data on disk that become buffer-local variables when a

??? 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?

> There are indeed some strange corner cases with buffer-locals, like the
> interaction of `let' and `set-buffer' with buffer-local variables.  But
> you haven't found any in this context.

In which context? The contexts at hand are still (in my case) at the
outer layers.
({.... do stuff with SOME ARGS ...})) does exist in various
manifestations and is being put to active use on a _daily_ basis
sloppy quoting or otherwise. 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) :)

Best,
s_P