GNU bug report logs -
#7777
24.0.50; incompatible change for `directory-abbrev-alist' not in NEWS
Previous Next
Reported by: "Drew Adams" <drew.adams <at> oracle.com>
Date: Mon, 3 Jan 2011 19:43:01 UTC
Severity: normal
Found in version 24.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 7777 in the body.
You can then email your comments to 7777 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7777; Package
emacs.
(Mon, 03 Jan 2011 19:43:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Drew Adams" <drew.adams <at> oracle.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Mon, 03 Jan 2011 19:43:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
In Emacs 22, the doc string of `directory-abbrev-alist' says this:
"*Every* FROM string should start with `^'."
Now it says this:
*Every* FROM string should start with "\\`".
That means that *Every* existing customization is broken (or at least
contradicts the "should"). This incompatible change should be
mentioned in the NEWS.
In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
of 2010-12-20 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.4) --no-opt --cflags
-Ic:/imagesupport/include'
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7777; Package
emacs.
(Mon, 03 Jan 2011 19:58:03 GMT)
Full text and
rfc822 format available.
Message #8 received at 7777 <at> debbugs.gnu.org (full text, mbox):
"Drew Adams" <drew.adams <at> oracle.com> writes:
> In Emacs 22, the doc string of `directory-abbrev-alist' says this:
>
> "*Every* FROM string should start with `^'."
>
> Now it says this:
>
> *Every* FROM string should start with "\\`".
>
> That means that *Every* existing customization is broken (or at least
> contradicts the "should").
*Every* existing customization will still work the same as before.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7777; Package
emacs.
(Mon, 03 Jan 2011 20:19:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 7777 <at> debbugs.gnu.org (full text, mbox):
> From: "Drew Adams" <drew.adams <at> oracle.com>
> Date: Mon, 3 Jan 2011 11:49:07 -0800
> Cc:
>
> In Emacs 22, the doc string of `directory-abbrev-alist' says this:
>
> "*Every* FROM string should start with `^'."
>
> Now it says this:
>
> *Every* FROM string should start with "\\`".
>
> That means that *Every* existing customization is broken (or at least
> contradicts the "should").
It isn't and it doesn't. If there are no file names with embedded
newlines, both "^" and "\`" do the same. The "should" is to remind
this issue to those who want their customizations DTRT with newlines
in file names; previously, they needed to figure that by themselves,
or learn it the hard way.
> This incompatible change should be mentioned in the NEWS.
There was no change, except in the doc string (and in the value
suggested during customization). No code changes, and the default
value is still nil.
Can we close this bug, please? (Ts-ts-ts, such a nice bug number.)
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7777; Package
emacs.
(Mon, 03 Jan 2011 21:38:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 7777 <at> debbugs.gnu.org (full text, mbox):
> > That means that *Every* existing customization is broken
> > (or at least contradicts the "should").
>
> It isn't and it doesn't. If there are no file names with embedded
> newlines, both "^" and "\`" do the same.
Yes, I know that.
> The "should" is to remind this issue to those who want their
> customizations DTRT with newlines in file names; previously,
> they needed to figure that by themselves, or learn it the hard way.
"Previously" there was already a similar "should" (for `^').
I have no problem with the "should", in any case.
> > This incompatible change should be mentioned in the NEWS.
>
> There was no change, except in the doc string (and in the value
> suggested during customization). No code changes, and the default
> value is still nil.
There is a change in what we are telling users is the proper form for the option
value. Before, we made a big deal about them needing to use `^'; now we are
making a bid deal about them needing to use `\\`'.
At the very least:
1. We're telling users that _every_ value should be different from what _every_
value was supposed to be before. That's a change for users that they should be
made aware of, even if such a "should" is in fact vacuous wrt the difference.
2. We should tell users, in NEWS, that they do _not_ in fact need to change
existing values that respected the old rule - in spite of the changed rule.
They do _not_ need to swap \\` for ^. That is not necessarily obvious to users.
> Can we close this bug, please?
Sure, after it's fixed.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7777; Package
emacs.
(Mon, 03 Jan 2011 21:39:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 7777 <at> debbugs.gnu.org (full text, mbox):
> > That means that *Every* existing customization is broken
> > (or at least contradicts the "should").
>
> *Every* existing customization will still work the same as before.
Well, that's what I figured, since \\` and ^ act similarly in such contexts.
Which is why I added "(or at least contradicts the "should")".
The NEWS entry should also reassure users that ^ patterns will still work OK -
in spite of the BLARING "*Every*...should" warning/caveat/commandment/rule.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7777; Package
emacs.
(Mon, 03 Jan 2011 21:44:01 GMT)
Full text and
rfc822 format available.
Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
(Ts-ts-ts, such a nice bug number.)
I'm still giggling---you are so funny.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7777; Package
emacs.
(Tue, 04 Jan 2011 03:55:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 7777 <at> debbugs.gnu.org (full text, mbox):
> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <7777 <at> debbugs.gnu.org>
> Date: Mon, 3 Jan 2011 13:44:50 -0800
>
> 1. We're telling users that _every_ value should be different from what _every_
> value was supposed to be before. That's a change for users that they should be
> made aware of, even if such a "should" is in fact vacuous wrt the difference.
It's not a change, it's a doc fix. The doc string is now more
helpful.
> 2. We should tell users, in NEWS, that they do _not_ in fact need to change
> existing values that respected the old rule - in spite of the changed rule.
> They do _not_ need to swap \\` for ^. That is not necessarily obvious to users.
We don't put in NEWS changes that affect only doc strings.
How about if we change the doc string to not sound like a stringent
requirement, but rather as a "note"?
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7777; Package
emacs.
(Tue, 04 Jan 2011 04:07:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 7777 <at> debbugs.gnu.org (full text, mbox):
> How about if we change the doc string to not sound like a stringent
> requirement, but rather as a "note"?
That would be an improvement, thanks (the manual, likewise).
It would also help to explain why. Explaining why helps avoid any
misunderstanding wrt the older "rule", and it helps understand the new "note".
The other part of this bug is the location of the manual entry: Why the Elisp
manual? This is a user option. If we feel it is important to tell users about
this in a manual, why wouldn't the Emacs manual be the right one?
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility.
(Fri, 07 Jan 2011 15:55:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
"Drew Adams" <drew.adams <at> oracle.com>:
bug acknowledged by developer.
(Fri, 07 Jan 2011 15:55:02 GMT)
Full text and
rfc822 format available.
Message #31 received at 7777-done <at> debbugs.gnu.org (full text, mbox):
> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <7777 <at> debbugs.gnu.org>
> Date: Mon, 3 Jan 2011 20:12:33 -0800
>
> > How about if we change the doc string to not sound like a stringent
> > requirement, but rather as a "note"?
>
> That would be an improvement, thanks (the manual, likewise).
I fixed it on the emacs-23 branch (revision 100362).
> It would also help to explain why. Explaining why helps avoid any
> misunderstanding wrt the older "rule", and it helps understand the new "note".
I added a short explanation.
> The other part of this bug is the location of the manual entry: Why the Elisp
> manual? This is a user option. If we feel it is important to tell users about
> this in a manual, why wouldn't the Emacs manual be the right one?
Its description in the ELisp manual is due to the fact that the same
node describes the abbreviate-file-name function, which uses this
variable. As for repeating the description in the user manual, I'm
not sure this variable is important enough. So I left this part out
of the bugfix.
Message #32 received at 7777-done <at> debbugs.gnu.org (full text, mbox):
> I fixed it on the emacs-23 branch (revision 100362).
>
> > It would also help to explain why.
>
> I added a short explanation.
>
> > The other part of this bug is the location of the manual
> > entry: Why the Elisp manual? This is a user option.
>
> Its description in the ELisp manual is due to the fact that the same
> node describes the abbreviate-file-name function, which uses this
> variable. As for repeating the description in the user manual, I'm
> not sure this variable is important enough. So I left this part out
> of the bugfix.
Sounds good to me. Thx.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7777; Package
emacs.
(Sat, 08 Jan 2011 21:55:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 7777 <at> debbugs.gnu.org (full text, mbox):
"Drew Adams" <drew.adams <at> oracle.com> writes:
> The other part of this bug is the location of the manual entry: Why
> the Elisp manual? This is a user option. If we feel it is important
> to tell users about this in a manual, why wouldn't the Emacs manual be
> the right one?
Sounds reasonable; I've done as suggested (and added the anchoring
explanation).
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7777; Package
emacs.
(Sat, 08 Jan 2011 22:29:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 7777 <at> debbugs.gnu.org (full text, mbox):
> > The other part of this bug is the location of the manual entry:
> > Why the Elisp manual? This is a user option. If we feel it is
> > important to tell users about this in a manual, why wouldn't the
> > Emacs manual be the right one?
>
> Sounds reasonable; I've done as suggested (and added the anchoring
> explanation).
Just in case you didn't notice it, Eli gave a reason for it to be where it is
(in the Elisp manual):
ez> Its description in the ELisp manual is due to the fact that the same
ez> node describes the abbreviate-file-name function, which uses this
ez> variable. As for repeating the description in the user manual, I'm
ez> not sure this variable is important enough. So I left this part out
ez> of the bugfix.
FWIW, given Eli's explanation, I'm OK with it being in either manual (or both).
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7777; Package
emacs.
(Sun, 09 Jan 2011 03:55:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 7777 <at> debbugs.gnu.org (full text, mbox):
> From: Chong Yidong <cyd <at> stupidchicken.com>
> Cc: "'Eli Zaretskii'" <eliz <at> gnu.org>, 7777 <at> debbugs.gnu.org
> Date: Sat, 08 Jan 2011 17:01:47 -0500
>
> "Drew Adams" <drew.adams <at> oracle.com> writes:
>
> > The other part of this bug is the location of the manual entry: Why
> > the Elisp manual? This is a user option. If we feel it is important
> > to tell users about this in a manual, why wouldn't the Emacs manual be
> > the right one?
>
> Sounds reasonable; I've done as suggested (and added the anchoring
> explanation).
Didn't you like the change I did (on the emacs-23 branch) in the doc
string? You also threw away the text I added to the ELisp manual, to
explain this. Was it wrong or unclear?
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7777; Package
emacs.
(Thu, 13 Jan 2011 05:14:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 7777 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Chong Yidong <cyd <at> stupidchicken.com>
>> Cc: "'Eli Zaretskii'" <eliz <at> gnu.org>, 7777 <at> debbugs.gnu.org
>> Date: Sat, 08 Jan 2011 17:01:47 -0500
>>
>> "Drew Adams" <drew.adams <at> oracle.com> writes:
>>
>> > The other part of this bug is the location of the manual entry: Why
>> > the Elisp manual? This is a user option. If we feel it is important
>> > to tell users about this in a manual, why wouldn't the Emacs manual be
>> > the right one?
>>
>> Sounds reasonable; I've done as suggested (and added the anchoring
>> explanation).
>
> Didn't you like the change I did (on the emacs-23 branch) in the doc
> string? You also threw away the text I added to the ELisp manual, to
> explain this. Was it wrong or unclear?
Hmm, I didn't realize you already changed it (missed the message),
sorry. I'll double check.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#7777; Package
emacs.
(Fri, 28 Jan 2011 17:23:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 7777 <at> debbugs.gnu.org (full text, mbox):
Chong Yidong <cyd <at> stupidchicken.com> writes:
>>> Sounds reasonable; I've done as suggested (and added the anchoring
>>> explanation).
>>
>> Didn't you like the change I did (on the emacs-23 branch) in the doc
>> string? You also threw away the text I added to the ELisp manual, to
>> explain this. Was it wrong or unclear?
>
> Hmm, I didn't realize you already changed it (missed the message),
> sorry. I'll double check.
Should be fixed now.
I think the material should go in the Emacs manual. Even though it's
not a very important feature, it's still a user feature rather than a
Lisp programming feature. The discussion of abbreviate-file-name in the
Lisp manual now has a cross reference to the Emacs manual node.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 26 Feb 2011 12:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 14 years and 174 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.