[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-b

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

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

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


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]