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

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

[MON KEY]

Is this a bug, or am I missing something?

`buffer-local-value' docstring says:

"Return the value of variable in buffer.
If variable does not have a buffer-local binding in buffer, the value
is the ***default binding*** of the variable."  [asterisks mine]

Is this the default binding of buffers local variable or the default
binding of the Global Variable?
---------------
With a fresh emacs "(buffer-local-value longlines-mode (current-buffer))"
With a fresh Emacs, if a mode hasn't been called interactively e.g.
M-x fundamental-mode
then evaluating:

(buffer-local-value fundamental-mode (current-buffer))

throws an error, even though evaluating:

mode-name => "Fundamental"

and:

major-mode => fundamental-mode

This behavior happens with minor and major modes.

For example (still in a fresh emacs):
(buffer-local-value longlines-mode (current-buffer))

-----------------
Debugger entered--Lisp error: (void-variable longlines-mode)
  (buffer-local-value longlines-mode (current-buffer))
  (and (buffer-local-value longlines-mode (current-buffer)))
  eval((and (buffer-local-value longlines-mode (current-buffer))))
  eval-expression((and (buffer-local-value longlines-mode
(current-buffer))) nil)
  call-interactively(eval-expression nil nil)
-----------------
However, after interactively M-x longlines-mode
and/or
(longlines-mode)

(plist-member buffer-file-format 'longlines) = > (longlines)
buffer-file-format => longlines
(local-variable-p 'longlines-mode) => t

_BUT_
(plist-member buffer-file-format (buffer-local-variables)) => nil

Now if:
M-x fundamental-mode
and/or
(fundamental-mode)

Now evaluating:

major-mode => fundamental-mode

(plist-member major-mode (buffer-local-variables)) => fundamental-mode

mode-name => "Fundamental"

(insert (format "%s" (buffer-local-variables))) =>
( {...} (mode-name . Fundamental) (major-mode . fundamental-mode)
(buffer-file-format longlines) {...} ) ;{...Ellided...}

_BUT_
(local-variable-p 'fundamental-mode) => nil

_AND_
(buffer-local-value fundamental-mode (current-buffer))

Still gives an error:
-----
Debugger entered--Lisp error: (void-variable fundamental-mode)
  (buffer-local-value fundamental-mode (current-buffer))
  eval((buffer-local-value fundamental-mode (current-buffer)))
  eval-last-sexp-1(nil)
  eval-last-sexp(nil)
  call-interactively(eval-last-sexp nil nil)
-----

Whereas with longlines-mode having been set per above evaluating:

(buffer-local-value longlines-mode (current-buffer))

No longer drops me into the debugger?


Evaluated on two different emacsen:

GNU Emacs 23.0.91.1 (i386-mingw-nt5.1.2600) of 2009-02-26 on SOFT-MJASON
GNU Emacs 23.0.92.1 (i386-mingw-nt5.1.2600)  of 2009-03-31 on
LENNART-69DE564 (patched)

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

[Jason Rumney]

MON KEY wrote:
> Is this a bug, or am I missing something?
>
> (buffer-local-value fundamental-mode (current-buffer))
>
> throws an error

Not a bug, there is no variable by that name.

> This behavior happens with minor and major modes.
>   

As you observed with longlines-mode, it does not happen with minor-mode 
variables once they have been loaded and the variable is known to Emacs.

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

[MON KEY]

>
> Not a bug, there is no variable by that name.
>

Why not?

(local-variable-if-set-p 'major-mode) => t
(eq major-mode 'fundamental-mode) => t
(equal major-mode 'fundamental-mode) => t
(symbol-value 'major-mode) => fundamental-mode
(assoc-default 'major-mode (buffer-local-variables)) => fundamental-mode



On Wed, Apr 8, 2009 at 6:15 PM, Jason Rumney <jasonr@gnu.org> wrote:
> MON KEY wrote:
>>
>> Is this a bug, or am I missing something?
>>
>> (buffer-local-value fundamental-mode (current-buffer))
>>
>> throws an error
>
> Not a bug, there is no variable by that name.
>
>> This behavior happens with minor and major modes.
>>
>
> As you observed with longlines-mode, it does not happen with minor-mode
> variables once they have been loaded and the variable is known to Emacs.
>
>

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

[Kevin Rodgers]

MON KEY wrote:
>> Not a bug, there is no variable by that name.
> 
> Why not?

The error was not thrown by the buffer-local-value function.  It was
thrown by eval, trying to (recursively) evaluate the fundamental-mode
form, whose result it would then pass as the first argument
buffer-local-value.

> (local-variable-if-set-p 'major-mode) => t
> (eq major-mode 'fundamental-mode) => t
> (equal major-mode 'fundamental-mode) => t
> (symbol-value 'major-mode) => fundamental-mode
> (assoc-default 'major-mode (buffer-local-variables)) => fundamental-mode

You have demonstrated that the major-mode symbol has its value cell set
to the fundamental-mode symbol, and several other facts about the
major-mode symbol.  You have not demonstrated any facts about the
fundamental-mode symbol.

-- 
Kevin Rodgers
Denver, Colorado, USA

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

[Davis Herring]

> (buffer-local-value fundamental-mode (current-buffer))
>
> Still gives an error:
> -----
> Debugger entered--Lisp error: (void-variable fundamental-mode)
>   (buffer-local-value fundamental-mode (current-buffer))
>   eval((buffer-local-value fundamental-mode (current-buffer)))
>   eval-last-sexp-1(nil)
>   eval-last-sexp(nil)
>   call-interactively(eval-last-sexp nil nil)
> -----
>
> Whereas with longlines-mode having been set per above evaluating:
>
> (buffer-local-value longlines-mode (current-buffer))
>
> No longer drops me into the debugger?

First, you need to quote your variable names: (buffer-local-value 'foo
(current-buffer)).

Second, only minor modes are (typically) also variables.  For a major
mode, since there can only be one, you just want

(eq (buffer-local-value 'major-mode [buffer]) [mode])

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.

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

[Davis Herring]

>> First, you need to quote your variable names:
> Prob. but in this case, once the variable is set (evaluated) I don't :P
>
> (longlines-mode)
> (buffer-local-value longlines-mode (current-buffer)) => t
> (longlines-mode)
> (buffer-local-value longlines-mode (current-buffer)) => nil

Because you are only using (current-buffer), you are missing something
rather important.  `buffer-local-value' is a function, so its arguments
are evaluated before it is even called.  What you have done is equivalent
to

(buffer-local-value 't (current-buffer))
(buffer-local-value 'nil (current-buffer))

because t and nil are the values that `longlines-mode' has each time you
check.  (Of course, you do not normally quote t and nil, but this is the
formally equivalent thing.)

Since t and nil are constants that are their own values (which is why you
don't quote them!), their value in any buffer is themselves, so you just
get them back from `buffer-local-value'.  If you try doing something like

(longlines-mode)
(buffer-local-value longlines-mode (get-buffer-create "*other*"))
(longlines-mode)
(buffer-local-value longlines-mode (get-buffer-create "*other*"))

you will _still_ get t and then nil, because the other buffer is entirely
irrelevant to the _value_ of `longlines-mode' (which is implicitly derived
from the current buffer).  If instead you try

(longlines-mode)
(buffer-local-value 'longlines-mode (get-buffer-create "*other*"))
(longlines-mode)
(buffer-local-value 'longlines-mode (get-buffer-create "*other*"))

...you will get nil twice, because calling `longlines-mode' in this buffer
doesn't change its value in *other*.

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.

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.

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

[MON KEY]

> 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

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.

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

[MON KEY]

On Thu, Apr 9, 2009 at 6:42 PM, Davis Herring <herring@lanl.gov> wrote:
> 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)

So, I go in to adjust my code this morning...
And you know man.... this form won't evaluate when longlines-mode is quoted!
GRrrrr!

Once initialzed:

(if (bound-and-true-p longlines-mode) "bubba" "no-bubba") => "bubba"

Whereas (initialized or otherwise):

(if (bound-and-true-p 'longlines-mode) "bubba" "no-bubba")
--------
Debugger entered--Lisp error: (wrong-type-argument symbolp (quote
longlines-mode))
  boundp((quote longlines-mode))
  (and (boundp (quote ...)) (quote longlines-mode))
  (bound-and-true-p (quote longlines-mode))
  (if (bound-and-true-p (quote longlines-mode)) "bubba" "no-bubba")
  eval((if (bound-and-true-p (quote longlines-mode)) "bubba" "no-bubba"))
  eval-last-sexp-1(nil)
  eval-last-sexp(nil)
  call-interactively(eval-last-sexp nil nil)
-------

(boundp longlines-mode) => `t' {once initialized else "VOID variable error"}

(boundp 'longlines-mode) => `t'  {when unitialized _or_ intialized}

(bound-and-true-p longlines-mode) => `nil'|`t'  {when unitialized _or_
intialized}

(bound-and-true-p 'longlines-mode)
=> {...(wrong-type-argument symbolp (quote longlines-mode))...}

Which leads me to suspect that I went down this route at some point in
the past found there were 'issues' with qouting around longlines-mode
with regards symbol vs. variable state and _might_ explain my funky
quoting.

Also, `bound-and-true-p' still won't address situations where
longlines-mode hasn't been initialized because it doesn't tell me if
it's been bound yet.
Per the docstring:
"Return the value of symbol var if it is bound, else nil."

What prob. will work is to test  if symbol both symbol _and_ var are available:

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

which still pretty much bites.

s_P

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

[Chong Yidong]

MON KEY <monkey@sandpframing.com> writes:

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

This should be (bound-and-true-p longlines-mode), because the
bound-and-true-p macro treats its VAR argument like setq; it is a macro,
not an ordinary Lisp function.  Its docstring needs to be
corrected---I'll do this once I when I get the chance.

> Which leads me to suspect that I went down this route at some point in
> the past found there were 'issues' with qouting around longlines-mode
> with regards symbol vs. variable state and _might_ explain my funky
> quoting.

It sounds like you have some confusions about the difference between a
symbol and a variable.  I suggest reading the first few chapters of the
Emacs Lisp reference manual, which explains this topic carefully.

> What prob. will work is to test if symbol both symbol _and_ var are
> available:
>
> (and (boundp 'longlines-mode) (bound-and-true-p longlines-mode))

It's not necessary to use bound-and-true-p here.

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

is _exactly_ the same as

  (and (boundp 'longlines-mode) longlines-mode)

(That's simply how the bound-and-true-p macro is defined.)

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

[Stefan Monnier]

>>> 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)
> This should be (bound-and-true-p longlines-mode), because the
> bound-and-true-p macro treats its VAR argument like setq; it is a macro,
> not an ordinary Lisp function.  Its docstring needs to be
> corrected---I'll do this once I when I get the chance.

It's too bad: it should have been a function, but it's a bit late to fix
it now.


        Stefan

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

[Davis Herring]

>> This should be (bound-and-true-p longlines-mode), because the
>> bound-and-true-p macro treats its VAR argument like setq; it is a macro,
>> not an ordinary Lisp function.  Its docstring needs to be
>> corrected---I'll do this once I when I get the chance.
>
> It's too bad: it should have been a function, but it's a bit late to fix
> it now.

My apologies for, in a message meant to educate about the vagaries of
quoting, not noticing that it was a macro.  On the subject of having it be
a function, it wouldn't be too horrible to provide a function also: I
would suggest the name `symbol-value-safe' (in line with `car-safe').  I
have this function defined as

(defun symbol-value-safe (symbol &optional def)
  "Return SYMBOL's value, or DEF if that is void."
  (if (boundp symbol) (symbol-value symbol) def))

One use of the default is for cross-version compatibility:

(symbol-value-safe 'eval-expression-print-length 12) ; for Emacs 20

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.