* with a fresh emacs "(buffer-local-value fundamental-mode (current-buffer))" error.
@ 2009-04-08 21:58 MON KEY
2009-04-08 22:15 ` Jason Rumney
2009-04-08 22:32 ` Davis Herring
0 siblings, 2 replies; 13+ messages in thread
From: MON KEY @ 2009-04-08 21:58 UTC (permalink / raw)
To: emacs-devel
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)
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: with a fresh emacs "(buffer-local-value fundamental-mode (current-buffer))" error.
2009-04-08 21:58 with a fresh emacs "(buffer-local-value fundamental-mode (current-buffer))" error MON KEY
@ 2009-04-08 22:15 ` Jason Rumney
2009-04-09 2:22 ` MON KEY
2009-04-08 22:32 ` Davis Herring
1 sibling, 1 reply; 13+ messages in thread
From: Jason Rumney @ 2009-04-08 22:15 UTC (permalink / raw)
To: MON KEY; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: with a fresh emacs "(buffer-local-value fundamental-mode (current-buffer))" error.
2009-04-08 21:58 with a fresh emacs "(buffer-local-value fundamental-mode (current-buffer))" error MON KEY
2009-04-08 22:15 ` Jason Rumney
@ 2009-04-08 22:32 ` Davis Herring
[not found] ` <d2afcfda0904081931n1f0d48fbo1253c6af08cd4bbc@mail.gmail.com>
1 sibling, 1 reply; 13+ messages in thread
From: Davis Herring @ 2009-04-08 22:32 UTC (permalink / raw)
To: MON KEY; +Cc: emacs-devel
> (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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: with a fresh emacs "(buffer-local-value fundamental-mode (current-buffer))" error.
2009-04-08 22:15 ` Jason Rumney
@ 2009-04-09 2:22 ` MON KEY
2009-04-09 5:12 ` Kevin Rodgers
0 siblings, 1 reply; 13+ messages in thread
From: MON KEY @ 2009-04-09 2:22 UTC (permalink / raw)
To: Jason Rumney; +Cc: emacs-devel
>
> 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.
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: with a fresh emacs "(buffer-local-value fundamental-mode (current-buffer))" error.
2009-04-09 2:22 ` MON KEY
@ 2009-04-09 5:12 ` Kevin Rodgers
0 siblings, 0 replies; 13+ messages in thread
From: Kevin Rodgers @ 2009-04-09 5:12 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: with a fresh emacs "(buffer-local-value fundamental-mode (current-buffer))" error.
[not found] ` <d2afcfda0904081931n1f0d48fbo1253c6af08cd4bbc@mail.gmail.com>
@ 2009-04-09 15:26 ` Davis Herring
[not found] ` <d2afcfda0904091341j6b1194a1ifb522b99535139f9@mail.gmail.com>
0 siblings, 1 reply; 13+ messages in thread
From: Davis Herring @ 2009-04-09 15:26 UTC (permalink / raw)
To: MON KEY; +Cc: emacs-devel
>> 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: with a fresh emacs "(buffer-local-value fundamental-mode (current-buffer))" error.
[not found] ` <d2afcfda0904091341j6b1194a1ifb522b99535139f9@mail.gmail.com>
@ 2009-04-09 22:42 ` Davis Herring
2009-04-10 3:12 ` MON KEY
2009-04-10 16:53 ` MON KEY
0 siblings, 2 replies; 13+ messages in thread
From: Davis Herring @ 2009-04-09 22:42 UTC (permalink / raw)
To: MON KEY; +Cc: emacs-devel
> (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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: with a fresh emacs "(buffer-local-value fundamental-mode (current-buffer))" error.
2009-04-09 22:42 ` Davis Herring
@ 2009-04-10 3:12 ` MON KEY
2009-04-16 21:49 ` Davis Herring
2009-04-10 16:53 ` MON KEY
1 sibling, 1 reply; 13+ messages in thread
From: MON KEY @ 2009-04-10 3:12 UTC (permalink / raw)
To: herring; +Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: with a fresh emacs "(buffer-local-value fundamental-mode (current-buffer))" error.
2009-04-09 22:42 ` Davis Herring
2009-04-10 3:12 ` MON KEY
@ 2009-04-10 16:53 ` MON KEY
2009-04-10 17:38 ` Chong Yidong
1 sibling, 1 reply; 13+ messages in thread
From: MON KEY @ 2009-04-10 16:53 UTC (permalink / raw)
To: herring; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: with a fresh emacs "(buffer-local-value fundamental-mode (current-buffer))" error.
2009-04-10 16:53 ` MON KEY
@ 2009-04-10 17:38 ` Chong Yidong
2009-04-10 22:10 ` Stefan Monnier
0 siblings, 1 reply; 13+ messages in thread
From: Chong Yidong @ 2009-04-10 17:38 UTC (permalink / raw)
To: MON KEY; +Cc: emacs-devel
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.)
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: with a fresh emacs "(buffer-local-value fundamental-mode (current-buffer))" error.
2009-04-10 17:38 ` Chong Yidong
@ 2009-04-10 22:10 ` Stefan Monnier
2009-04-16 21:29 ` Davis Herring
0 siblings, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 2009-04-10 22:10 UTC (permalink / raw)
To: Chong Yidong; +Cc: MON KEY, emacs-devel
>>> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: with a fresh emacs "(buffer-local-value fundamental-mode (current-buffer))" error.
2009-04-10 22:10 ` Stefan Monnier
@ 2009-04-16 21:29 ` Davis Herring
0 siblings, 0 replies; 13+ messages in thread
From: Davis Herring @ 2009-04-16 21:29 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Chong Yidong, MON KEY, emacs-devel
>> 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: with a fresh emacs "(buffer-local-value fundamental-mode (current-buffer))" error.
2009-04-10 3:12 ` MON KEY
@ 2009-04-16 21:49 ` Davis Herring
0 siblings, 0 replies; 13+ messages in thread
From: Davis Herring @ 2009-04-16 21:49 UTC (permalink / raw)
To: MON KEY; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2009-04-16 21:49 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-04-08 21:58 with a fresh emacs "(buffer-local-value fundamental-mode (current-buffer))" error MON KEY
2009-04-08 22:15 ` Jason Rumney
2009-04-09 2:22 ` MON KEY
2009-04-09 5:12 ` Kevin Rodgers
2009-04-08 22:32 ` Davis Herring
[not found] ` <d2afcfda0904081931n1f0d48fbo1253c6af08cd4bbc@mail.gmail.com>
2009-04-09 15:26 ` Davis Herring
[not found] ` <d2afcfda0904091341j6b1194a1ifb522b99535139f9@mail.gmail.com>
2009-04-09 22:42 ` Davis Herring
2009-04-10 3:12 ` MON KEY
2009-04-16 21:49 ` Davis Herring
2009-04-10 16:53 ` MON KEY
2009-04-10 17:38 ` Chong Yidong
2009-04-10 22:10 ` Stefan Monnier
2009-04-16 21:29 ` Davis Herring
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).