From: Luc Teirlinck <teirllm@dms.auburn.edu>
Cc: emacs-devel@gnu.org
Subject: Re: default-fill-column
Date: Sat, 22 Nov 2003 15:23:34 -0600 (CST) [thread overview]
Message-ID: <200311222123.hAMLNYW22498@raven.dms.auburn.edu> (raw)
In-Reply-To: <jwvbrrbvs82.fsf-monnier+emacs/devel@vor.iro.umontreal.ca> (message from Stefan Monnier on 16 Nov 2003 17:58:05 -0500)
First, a reminder of the behavior:
===File ~/nov22ielm=========================================
*** Welcome to IELM *** Type (describe-mode) for help.
ELISP> (emacs-version)
"GNU Emacs 21.3.50.1 (i686-pc-linux-gnu, X toolkit)\n of 2003-11-22 on swt40.swt.com"
ELISP> (local-variable-p 'fill-column)
nil
ELISP> fill-column
70
ELISP> (setq default-fill-column 75)
75
ELISP> fill-column
70
ELISP> (local-variable-p 'fill-column)
nil
ELISP> (default-value 'fill-column)
75
ELISP> (buffer-local-value 'fill-column (current-buffer))
75
ELISP> fill-column
70
ELISP> (setq-default fill-column (default-value 'fill-column))
75
ELISP> fill-column
75
ELISP>
============================================================
`default-fill-column' is just an example. The same holds for other
variables of the same type.
Reminder of Stefan's response:
Looks like a plain bug indeed.
Could we just declare those `default-*' variables obsolete and tell
people to use `setq-default' and `default-value' instead so we can
slowly hope to get rid of those things ?
If Luc's bugs were already present in Emacs-20 and Emacs-21, then we
wouldn't even have to fix them.
That would, according to me, be a satisfactory solution. There could
be one problem, however. Indeed, the functionality of these variables
is not equivalent with `setq-default'. `setq-default' changes the
value in all buffers without buffer-local binding, whereas
(setq default-fill-column 75) only affects the value in newly created
buffers. This is achieved in a very precarious way, however, because
both the preserved value itself and its type (buffer-local versus
default) are ambiguous and unstable. If one wants to make new
defaults for these variables apply only to newly created buffers,
either automatically or as an option, then I see at least three
possibilities:
1. Make all these variables behave like enable-multibyte-characters
and default-enable-multibyte-characters. For those, there is no
problem, because enable-multibyte-characters is always
buffer-local, even if the user never set it, and
kill-local-variable has no effect on it. Thus the default value
always only affects newly created buffers and the problem in the
above *ielm* run never occurs for them.
2. Make setq-default and set-default, for these variables, scan
through the buffer-list and make all current global values
buffer-local before resetting the default.
3. Leave setq-default and set-default alone, but define a new
function set-default-new-buffers (or whatever) that would behave
as described in (2), not just for the variables we are talking
about, but for all variables. It seems to me that this function
could be written in Lisp and that this would not be too difficult.
Could be useful for other variables too.
(2) and (3) still would require making the default-* variables
obsolete (but without loosing their functionality), whereas (1) would
get rid of the problem without a need to slowly get rid of them.
Sincerely,
Luc.
next prev parent reply other threads:[~2003-11-22 21:23 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-15 16:37 default-fill-column Luc Teirlinck
2003-11-16 22:58 ` default-fill-column Stefan Monnier
2003-11-22 21:23 ` Luc Teirlinck [this message]
2003-11-24 16:23 ` default-fill-column Richard Stallman
2003-12-27 4:13 ` default-fill-column Richard Stallman
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=200311222123.hAMLNYW22498@raven.dms.auburn.edu \
--to=teirllm@dms.auburn.edu \
--cc=emacs-devel@gnu.org \
/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.