unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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.

  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

  List information: https://www.gnu.org/software/emacs/

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