From: "Davis Herring" <herring@lanl.gov>
To: "MON KEY" <monkey@sandpframing.com>
Cc: emacs-devel@gnu.org
Subject: Re: with a fresh emacs "(buffer-local-value fundamental-mode (current-buffer))" error.
Date: Thu, 9 Apr 2009 15:42:58 -0700 (PDT) [thread overview]
Message-ID: <33849.128.165.123.18.1239316978.squirrel@webmail.lanl.gov> (raw)
In-Reply-To: <d2afcfda0904091341j6b1194a1ifb522b99535139f9@mail.gmail.com>
> (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.
next prev parent reply other threads:[~2009-04-09 22:42 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=33849.128.165.123.18.1239316978.squirrel@webmail.lanl.gov \
--to=herring@lanl.gov \
--cc=emacs-devel@gnu.org \
--cc=monkey@sandpframing.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.