* 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 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. 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
[parent not found: <d2afcfda0904081931n1f0d48fbo1253c6af08cd4bbc@mail.gmail.com>]
* 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
[parent not found: <d2afcfda0904091341j6b1194a1ifb522b99535139f9@mail.gmail.com>]
* 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-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
* 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
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).