bug#358: dabbrev-abbrev-char-regexp

bug#358: dabbrev-abbrev-char-regexp

[Otto Maddox]

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@fastmail.fm

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

bug#358: dabbrev-abbrev-char-regexp

[Glenn Morris]

"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.

bug#358: dabbrev-abbrev-char-regexp

[Glenn Morris]

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-/.

bug#358: dabbrev-abbrev-char-regexp

[Lars Magne Ingebrigtsen]

Glenn Morris <rgm@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/

bug#358: dabbrev-abbrev-char-regexp

[Noam Postavsky]

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)

bug#358: dabbrev-abbrev-char-regexp

[Drew Adams]

> +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".)

bug#358: dabbrev-abbrev-char-regexp

[Noam Postavsky]

On Thu, Mar 23, 2017 at 3:42 PM, Drew Adams <drew.adams@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.

bug#358: dabbrev-abbrev-char-regexp

[Drew Adams]

> >> +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.

bug#358: dabbrev-abbrev-char-regexp

[Noam Postavsky]

On Thu, Mar 23, 2017 at 4:24 PM, Drew Adams <drew.adams@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?

bug#358: dabbrev-abbrev-char-regexp

[Drew Adams]

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

bug#358: dabbrev-abbrev-char-regexp

[Noam Postavsky]

On Thu, Mar 23, 2017 at 4:58 PM, Drew Adams <drew.adams@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')."

bug#358: dabbrev-abbrev-char-regexp

[Drew Adams]

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

bug#358: dabbrev-abbrev-char-regexp

[Noam Postavsky]

[-- Attachment #1: Type: text/plain, Size: 195 bytes --]

On Thu, Mar 23, 2017 at 5:49 PM, Drew Adams <drew.adams@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.

[-- Attachment #2: 0001-Fix-docstring-of-dabbrev-abbrev-char-regexp.patch --]
[-- Type: application/octet-stream, Size: 2785 bytes --]

From 1a7a483c36be3e7bdaf71315032782bff356e247 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs@gmail.com>
Date: Fri, 24 Mar 2017 10:47:19 -0400
Subject: [PATCH] Fix docstring of dabbrev-abbrev-char-regexp

* lisp/dabbrev.el (dabbrev-abbrev-char-regexp): Using a value of nil
is equivalent to "\\sw\\|\\s_", and has no special behavior.  If the
previous character doesn't match, we search backwards for one that
does, not throw an error.  Replace Lisp example with C based one to
make it clear that "symbol" means a sequence of word and symbol
constituent characters, not a Lisp symbol (Bug#358).
---
 lisp/dabbrev.el | 32 +++++++++++++++-----------------
 1 file changed, 15 insertions(+), 17 deletions(-)

diff --git a/lisp/dabbrev.el b/lisp/dabbrev.el
index 3550d75..9c9dc8a 100644
--- a/lisp/dabbrev.el
+++ b/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, 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')."
   :type '(choice (const nil)
 		 regexp)
   :group 'dabbrev)
-- 
2.6.2.windows.1

bug#358: dabbrev-abbrev-char-regexp

[npostavs]

tags 358 fixed
close 358 25.2
quit

Noam Postavsky <npostavs@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