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

[Davis Herring]

> (defun do-stuff-when-llm (some args)
>     (let* ((test-llm (and (buffer-local-value longlines-mode
> (current-buffer))))
>          (is-on (and test-llm))
>          (llm-off))
>       (progn
>       (when is-on (longlines-mode 0) (setq llm-off 't))
>       (save-excursion
>       ({.... do stuff with SOME ARGS ...}))
>       (when llm-off
>       (longlines-mode 1) (setq llm-off 'nil)))))

Your quoting is still off, in general.  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.

Meanwhile, I can't imagine why you're quoting `t', or why you're calling
`and' with only one argument, or why you're calling `progn' within the
body of a `let*'.

> In these cases longlines-mode is (typically) already buffer-local per
> my-major modes defaults (a derived mode of my own creation). The
> excursion code usually operate in a vanilla with-temp-buffer  where
> longlines-mode _isn't_ wanted so i turn off the longlines-mode before
> grabbing the region and leaving.  After processing in temp the region
> comes back in and longlines-mode is activated again....

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

> that it hasn't loaded in longlines-mode code (it's autoload stuff) so,
> in _these_ cases the code above breaks.

It breaks in those cases because `longlines-mode' is just a symbol (and
not a variable) until its package is loaded.  This has nothing to do with
`buffer-local-value', except that quoting the variable won't be enough
because `buffer-local-value' will still find it to be void when it looks. 
If you need to detect (and not just suppress) longlines-mode without
having to load it, you can do

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

> but in fact it happens with Fundamental mode as well.  Once Emacs
> becomes aware of longlines-mode the minor-mode buffer-local 'bug'
> disappears. However, it remains for fundamental mode which BTW is
> basically special [...]

Again, `fundamental-mode' is never a variable.  Nor is any other major
mode.  If you want to test a major mode, you use the variable
`major-mode'.

> After looking over subr.el last night I feel that the data structures
> and wrapping functions packing all the buffer-local stuff away is
> kludgy in corner cases and frustratingly inconsistent with regards to
> how variables are created/accessed/unbound - one only wonders what is
> going to happen with the newer dir-locals interaction alongside
> buffer-locals.

dir-locals are just data on disk that become buffer-local variables when a
file under their directory is visited.  They are irrelevant here.  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.

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.