GNU bug report logs - #358
dabbrev-abbrev-char-regexp

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 358 in the body.
You can then email your comments to 358 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Otto Maddox" <ottomaddox <at> fastmail.fm>
To: bug-gnu-emacs <at> gnu.org
Subject: dabbrev-abbrev-char-regexp
Date: Wed, 04 Jun 2008 14:30:14 +0100

The default value for dabbrev-abbrev-char-regexp is nil, but its
docstring has this:

    The recommended value is "\\sw\\|\\s_".

If this value is indeed recommended, then it would make sense for it
to be the default value also.

In GNU Emacs 22.2.1 (i386-apple-darwin9.2.2, Carbon Version 1.6.0)
 of 2008-04-16

-- 
  Otto Maddox
  ottomaddox <at> fastmail.fm

-- 
http://www.fastmail.fm - Access all of your messages and folders
                          wherever you are

Message #10 received at 358 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 358 <at> debbugs.gnu.org
Subject: Re: bug#358: dabbrev-abbrev-char-regexp
Date: Mon, 13 Oct 2008 21:07:44 -0400

"Otto Maddox" wrote:

> The default value for dabbrev-abbrev-char-regexp is nil, but its
> docstring has this:
>
>     The recommended value is "\\sw\\|\\s_".
>
> If this value is indeed recommended, then it would make sense for it
> to be the default value also.

As far as I can tell, these two settings are exactly equivalent to one
another, and have been for some time (always?). If no-one disagrees, I
will adjust the documentation to reflect this.

Message #13 received at 358 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 358 <at> debbugs.gnu.org
Subject: Re: bug#358: dabbrev-abbrev-char-regexp
Date: Wed, 22 Oct 2008 21:28:31 -0400

After looking at this again, there's still no difference between nil
and \\sw\\|\\s- AFAICS, but now dabbrev--abbrev-at-point makes little
sense to me:

emacs -Q --eval '(setq dabbrev-abbrev-char-regexp "\\sw")'

in scratch:

yes-or-no---

followed by M-/ gives

"No dynamic expansion for `no---' found". Obviously, "---" are not
word constituents, yet they are included in the abbrev, in flat
contradiction to the doc-string of dabbrev-abbrev-char-regexp:

    if you set this variable to "\\sw", then expanding `yes-or-no-'
    signals an error because `-' is not part of a word

This is caused by dabbrev--abbrev-at-point's:

    ;; If we aren't right after an abbreviation,
    ;; move point back to just after one.
    ;; This is so the user can get successive words
    ;; by typing the punctuation followed by M-/.

View this message in rfc822 format

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 358 <at> debbugs.gnu.org
Subject: bug#358: dabbrev-abbrev-char-regexp
Date: Wed, 06 Jul 2011 19:46:23 +0200

Glenn Morris <rgm <at> gnu.org> writes:

> After looking at this again, there's still no difference between nil
> and \\sw\\|\\s- AFAICS,

I've now changed the doc string to reflect this.

> but now dabbrev--abbrev-at-point makes little
> sense to me:
>
> emacs -Q --eval '(setq dabbrev-abbrev-char-regexp "\\sw")'
>
> in scratch:
>
> yes-or-no---
>
> followed by M-/ gives
>
> "No dynamic expansion for `no---' found". Obviously, "---" are not
> word constituents, yet they are included in the abbrev, in flat
> contradiction to the doc-string of dabbrev-abbrev-char-regexp:
>
>     if you set this variable to "\\sw", then expanding `yes-or-no-'
>     signals an error because `-' is not part of a word
>
> This is caused by dabbrev--abbrev-at-point's:
>
>     ;; If we aren't right after an abbreviation,
>     ;; move point back to just after one.
>     ;; This is so the user can get successive words
>     ;; by typing the punctuation followed by M-/.

I have no idea how dabbrev works, but isn't that a new bug report?  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #20 received at 358 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: 358 <at> debbugs.gnu.org
Subject: Re: bug#358: dabbrev-abbrev-char-regexp
Date: Thu, 23 Mar 2017 14:28:26 -0400

tag 358 patch
quit

I propose the following patch to bring the documentation in line with
the code: (I don't know if the behaviour makes sense, but it seems
nobody complained about it)

--- i/lisp/dabbrev.el
+++ w/lisp/dabbrev.el
@@ -191,23 +191,21 @@ dabbrev-abbrev-char-regexp
 This regexp will be surrounded with \\\\( ... \\\\) when actually used.

 Set this variable to \"\\\\sw\" if you want ordinary words or
-\"\\\\sw\\\\|\\\\s_\" if you want symbols (including characters whose
-syntax is \"symbol\" as well as those whose syntax is \"word\".
-
-The value nil has a special meaning: the abbreviation is from point to
-previous word-start, but the search is for symbols.
-
-For instance, if you are programming in Lisp, `yes-or-no-p' is a symbol,
-while `yes', `or', `no' and `p' are considered words.  If this
-variable is nil, then expanding `yes-or-no-' looks for a symbol
-starting with or containing `no-'.  If you set this variable to
-\"\\\\sw\\\\|\\\\s_\", that expansion looks for a symbol starting with
-`yes-or-no-'.  Finally, if you set this variable to \"\\\\sw\", then
-expanding `yes-or-no-' signals an error because `-' is not part of a word;
-but expanding `yes-or-no' looks for a word starting with `no'.
-
-The recommended value is nil, which will make dabbrev default to
-using \"\\\\sw\\\\|\\\\s_\"."
+\"\\\\sw\\\\|\\\\s_\" if you want symbols (including characters
+whose syntax is \"symbol\" as well as those whose syntax is
+\"word\").  The abbreviation is from point to the start of the
+previous sequence of characters matching this variable.
+
+The default value of nil is equivalent to \"\\\\sw\\\\|\\\\s_\".
+
+For instance, if you are programming in Lisp, `yes-or-no-p' is a
+symbol, while `yes', `or', `no' and `p' are considered words.  If
+this variable is nil or \"\\\\sw\\\\|\\\\s_\", then expanding
+`yes-or-no-' looks for a symbol starting with `yes-or-no-'.  If
+you set this variable to \"\\\\sw\", that expansion looks for a
+word prefixed with `no-' (e.g., it would match `no-problem', but
+not `no-problem-found').  If expanding `yes-or-no' it would look
+for a word starting with `no' (e.g. `normal')."
   :type '(choice (const nil)
          regexp)
   :group 'dabbrev)

Message #25 received at 358 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>, 358 <at> debbugs.gnu.org
Subject: RE: bug#358: dabbrev-abbrev-char-regexp
Date: Thu, 23 Mar 2017 12:42:57 -0700 (PDT)

> +For instance, if you are programming in Lisp, `yes-or-no-p' is a
> +symbol, while `yes', `or', `no' and `p' are considered words.

This text (same as before) is a bit misleading.  It makes it sound
like `yes', `or', `no', and `p' are considered words but not symbols. 
They are also considered symbols.  Each of their characters has word
syntax, but in Lisp those names name symbols.

It is better not to talk about Lisp symbols at all here, I think.
This is about the syntax categories symbol and word.  It is not
about which names can be used for Lisp symbols.  (And there is
no such thing as a Lisp "word".)

Message #28 received at 358 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 358 <at> debbugs.gnu.org
Subject: Re: bug#358: dabbrev-abbrev-char-regexp
Date: Thu, 23 Mar 2017 16:07:27 -0400

On Thu, Mar 23, 2017 at 3:42 PM, Drew Adams <drew.adams <at> oracle.com> wrote:
>> +For instance, if you are programming in Lisp, `yes-or-no-p' is a
>> +symbol, while `yes', `or', `no' and `p' are considered words.
>
> This text (same as before) is a bit misleading.  It makes it sound
> like `yes', `or', `no', and `p' are considered words but not symbols.
> They are also considered symbols.  Each of their characters has word
> syntax, but in Lisp those names name symbols.
>
> It is better not to talk about Lisp symbols at all here, I think.
> This is about the syntax categories symbol and word.  It is not
> about which names can be used for Lisp symbols.  (And there is
> no such thing as a Lisp "word".)

The text is using "symbol" as a shorthand for "text which
`forward-symbol' would move over" or "sequence of characters with word
or symbol constituent syntax", and "word" as short for "text which
`forward-word' would move over" or "sequence of characters with word
constituent syntax". I think it's reasonably clear from context (as
you say, there is no such thing as a Lisp "word" in any other sense),
but I have no problem replacing it with something less ambiguous if
you can come up with something that's not too long.

Message #31 received at 358 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 358 <at> debbugs.gnu.org
Subject: RE: bug#358: dabbrev-abbrev-char-regexp
Date: Thu, 23 Mar 2017 13:24:19 -0700 (PDT)

> >> +For instance, if you are programming in Lisp, `yes-or-no-p' is a
> >> +symbol, while `yes', `or', `no' and `p' are considered words.
> >
> > This text (same as before) is a bit misleading.  It makes it sound
> > like `yes', `or', `no', and `p' are considered words but not symbols.
> > They are also considered symbols.  Each of their characters has word
> > syntax, but in Lisp those names name symbols.
> >
> > It is better not to talk about Lisp symbols at all here, I think.
> > This is about the syntax categories symbol and word.  It is not
> > about which names can be used for Lisp symbols.  (And there is
> > no such thing as a Lisp "word".)
> 
> The text is using "symbol" as a shorthand for "text which
> `forward-symbol' would move over" or "sequence of characters with word
> or symbol constituent syntax", and "word" as short for "text which
> `forward-word' would move over" or "sequence of characters with word
> constituent syntax".

Yes, that's the intended meaning.  Which is why it should not
mention Lisp symbols, which are something else again.

> I think it's reasonably clear from context (as
> you say, there is no such thing as a Lisp "word" in any other sense),
> but I have no problem replacing it with something less ambiguous if
> you can come up with something that's not too long.

I don't think any example is needed.  Essentially we are saying
here that if a letter has word syntax and `-' has symbol syntax
then \"\\\\sw\" matches a word char and \"\\\\sw\\\\|\\\\s_\"
matches a word char or a symbol char.  Not worth saying, IMO.

Message #34 received at 358 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 358 <at> debbugs.gnu.org
Subject: Re: bug#358: dabbrev-abbrev-char-regexp
Date: Thu, 23 Mar 2017 16:50:27 -0400

On Thu, Mar 23, 2017 at 4:24 PM, Drew Adams <drew.adams <at> oracle.com> wrote:
>> >> +For instance, if you are programming in Lisp, `yes-or-no-p' is a
>> >> +symbol, while `yes', `or', `no' and `p' are considered words.
>> >
>> > This text (same as before) is a bit misleading.  It makes it sound
>> > like `yes', `or', `no', and `p' are considered words but not symbols.
>> > They are also considered symbols.  Each of their characters has word
>> > syntax, but in Lisp those names name symbols.
>> >
>> > It is better not to talk about Lisp symbols at all here, I think.
>> > This is about the syntax categories symbol and word.  It is not
>> > about which names can be used for Lisp symbols.  (And there is
>> > no such thing as a Lisp "word".)
>>
>> The text is using "symbol" as a shorthand for "text which
>> `forward-symbol' would move over" or "sequence of characters with word
>> or symbol constituent syntax", and "word" as short for "text which
>> `forward-word' would move over" or "sequence of characters with word
>> constituent syntax".
>
> Yes, that's the intended meaning.  Which is why it should not
> mention Lisp symbols, which are something else again.

Oh, your objection is about mentioning `yes-or-no-p'?

> I don't think any example is needed.  Essentially we are saying
> here that if a letter has word syntax and `-' has symbol syntax
> then \"\\\\sw\" matches a word char and \"\\\\sw\\\\|\\\\s_\"
> matches a word char or a symbol char.  Not worth saying, IMO.

So the last paragraph would be just:

For instance, suppose the current buffer is `emacs-lisp-mode'.
If this variable is nil or \"\\\\sw\\\\|\\\\s_\", then expanding
`yes-or-no-' looks for a symbol starting with `yes-or-no-'.  If
you set this variable to \"\\\\sw\", that expansion looks for a
word prefixed with `no-' (e.g., it would match `no-problem', but
not `no-problem-found').  If expanding `yes-or-no' it would look
for a word starting with `no' (e.g. `normal')."

Or did you mean just drop it entirely?

Message #37 received at 358 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 358 <at> debbugs.gnu.org
Subject: RE: bug#358: dabbrev-abbrev-char-regexp
Date: Thu, 23 Mar 2017 13:58:40 -0700 (PDT)

> > Yes, that's the intended meaning.  Which is why it should not
> > mention Lisp symbols, which are something else again.
> 
> Oh, your objection is about mentioning `yes-or-no-p'?

No.  It's about mentioning Lisp symbols.   Or even mentioning
"symbol" in the context of Lisp, where it has a particular
meaning.  And it's not an objection - just a suggestion.

> > I don't think any example is needed.  Essentially we are saying
> > here that if a letter has word syntax and `-' has symbol syntax
> > then \"\\\\sw\" matches a word char and \"\\\\sw\\\\|\\\\s_\"
> > matches a word char or a symbol char.  Not worth saying, IMO.
> 
> So the last paragraph would be just:
> 
> For instance, suppose the current buffer is `emacs-lisp-mode'.
> If this variable is nil or \"\\\\sw\\\\|\\\\s_\", then expanding
> `yes-or-no-' looks for a symbol starting with `yes-or-no-'.  If
> you set this variable to \"\\\\sw\", that expansion looks for a
> word prefixed with `no-' (e.g., it would match `no-problem', but
> not `no-problem-found').  If expanding `yes-or-no' it would look
> for a word starting with `no' (e.g. `normal')."
> 
> Or did you mean just drop it entirely?

I meant that it could be dropped.  But what you wrote is also OK.

Please use your own judgment; I'm OK with whatever you decide.

My point was not to confuse people by mentioning Lisp symbols.

Of course, the problem here is that we are talking about expanding
`yes-or-no-p', which in Lisp is a Lisp symbol.  It would probably
be better to talk about using dabbrev in another context, besides
Lisp.  Then it would be clearer that we are talking only about
symbol vs word syntax.

Message #40 received at 358 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 358 <at> debbugs.gnu.org
Subject: Re: bug#358: dabbrev-abbrev-char-regexp
Date: Thu, 23 Mar 2017 17:37:55 -0400

On Thu, Mar 23, 2017 at 4:58 PM, Drew Adams <drew.adams <at> oracle.com> wrote:
>
> Of course, the problem here is that we are talking about expanding
> `yes-or-no-p', which in Lisp is a Lisp symbol.  It would probably
> be better to talk about using dabbrev in another context, besides
> Lisp.  Then it would be clearer that we are talking only about
> symbol vs word syntax.

As in, use a C example instead?

For instance, suppose the current buffer is in `c-mode'.  If this
variable is nil or \"\\\\sw\\\\|\\\\s_\", then expanding
`debug_print_in_' looks for a symbol starting with
`debug_print_in_'.  If you set this variable to \"\\\\sw\", that
expansion looks for a word prefixed with `in_' (e.g., it would
match `in_range', but not `in_close_range').  If expanding
`debug_print_in' it would look for a word starting with
`in' (e.g. `integer')."

Message #43 received at 358 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 358 <at> debbugs.gnu.org
Subject: RE: bug#358: dabbrev-abbrev-char-regexp
Date: Thu, 23 Mar 2017 14:49:53 -0700 (PDT)

> > Of course, the problem here is that we are talking about expanding
> > `yes-or-no-p', which in Lisp is a Lisp symbol.  It would probably
> > be better to talk about using dabbrev in another context, besides
> > Lisp.  Then it would be clearer that we are talking only about
> > symbol vs word syntax.
> 
> As in, use a C example instead?
> 
> For instance, suppose the current buffer is in `c-mode'.  If this
> variable is nil or \"\\\\sw\\\\|\\\\s_\", then expanding
> `debug_print_in_' looks for a symbol starting with
> `debug_print_in_'.  If you set this variable to \"\\\\sw\", that
> expansion looks for a word prefixed with `in_' (e.g., it would
> match `in_range', but not `in_close_range').  If expanding
> `debug_print_in' it would look for a word starting with
> `in' (e.g. `integer')."

Yep. Thx.

Message #46 received at 358 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 358 <at> debbugs.gnu.org
Subject: Re: bug#358: dabbrev-abbrev-char-regexp
Date: Fri, 24 Mar 2017 11:19:23 -0400

[Message part 1 (text/plain, inline)]

On Thu, Mar 23, 2017 at 5:49 PM, Drew Adams <drew.adams <at> oracle.com> wrote:
>>
>> As in, use a C example instead?
>
> Yep. Thx.

Here's the final patch, I'll push to emacs-25 in a couple of days.

[0001-Fix-docstring-of-dabbrev-abbrev-char-regexp.patch (application/octet-stream, attachment)]

Message #53 received at 358 <at> debbugs.gnu.org (full text, mbox):

From: npostavs <at> users.sourceforge.net
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 358 <at> debbugs.gnu.org
Subject: Re: bug#358: dabbrev-abbrev-char-regexp
Date: Sun, 26 Mar 2017 09:25:15 -0400

tags 358 fixed
close 358 25.2
quit

Noam Postavsky <npostavs <at> users.sourceforge.net> writes:

>
> Here's the final patch, I'll push to emacs-25 in a couple of days.

Done [1: 9a73707964].

1: 2017-03-26 09:14:15 -0400 9a7370796455b87cebb1177eecc6fa985f61f6a8
  Fix docstring of dabbrev-abbrev-char-regexp

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.