GNU bug report logs -
#22238
25.0.50; isearch symbol search can't find ,@symbol
Previous Next
Reported by: Michael Heerdegen <michael_heerdegen <at> web.de>
Date: Fri, 25 Dec 2015 21:30:02 UTC
Severity: minor
Merged with 44418
Found in versions 25.0.50, 28.0.50
Done: Michael Heerdegen <michael_heerdegen <at> web.de>
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 22238 in the body.
You can then email your comments to 22238 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#22238
; Package
emacs
.
(Fri, 25 Dec 2015 21:30:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Michael Heerdegen <michael_heerdegen <at> web.de>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Fri, 25 Dec 2015 21:30:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hello,
isearch's symbol search (M-s _) doesn't find symbols as in
,@symbol
when searching for "symbol". This was already the case in Emacs 24.5.
Regexp searching for "\_<" stops at the "@" char (not at the "s"). At
least, `isearch-forward-symbol' seems to behave as documented, dunno
about the "\_<" regexp.
Anyway, the behavior is not good. People use to replace symbols with
isearch's symbol search when they have renamed a function or variable.
Missing occurrences can introduce bugs.
Thanks for your help,
Michael.
In GNU Emacs 25.0.50.8 (x86_64-pc-linux-gnu, GTK+ Version 3.18.5)
of 2015-12-23
Repository revision: 09053075225fec8a6cf7a72017a6dfc1ec6b6f0c
Windowing system distributor 'The X.Org Foundation', version 11.0.11703000
System Description: Debian GNU/Linux testing (stretch)
Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GSETTINGS NOTIFY
LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11
Important settings:
value of $LC_ALL: de_DE.utf8
value of $LC_COLLATE: C
value of $LC_TIME: C
value of $LANG: de_DE.utf8
locale-coding-system: utf-8-unix
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#22238
; Package
emacs
.
(Fri, 25 Dec 2015 21:51:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 22238 <at> debbugs.gnu.org (full text, mbox):
On 12/25/2015 11:29 PM, Michael Heerdegen wrote:
> Regexp searching for "\_<" stops at the "@" char (not at the "s"). At
> least, `isearch-forward-symbol' seems to behave as documented, dunno
> about the "\_<" regexp.
I'm assuming this is about emacs-lisp-mode.
As you can see, this is not about isearch: re-search-forward behaves the
same in this regard.
This seems to be a regression from the fix for
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17325.
Maybe that should just be reverted. A more proper fix would make Emacs
not consider @ as a symbol constituent when it's the first character.
The "p" in "_ p" apparently tries but fails to do that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#22238
; Package
emacs
.
(Fri, 25 Dec 2015 21:59:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 22238 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> I'm assuming this is about emacs-lisp-mode.
I forgot to tell, but yes.
> This seems to be a regression from the fix for
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17325.
>
> Maybe that should just be reverted. A more proper fix would make Emacs
> not consider @ as a symbol constituent when it's the first
> character. The "p" in "_ p" apparently tries but fails to do that.
Can a similar problem appear with other programming modes/languages?
Thanks,
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#22238
; Package
emacs
.
(Fri, 25 Dec 2015 22:04:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 22238 <at> debbugs.gnu.org (full text, mbox):
On 12/25/2015 11:58 PM, Michael Heerdegen wrote:
> Can a similar problem appear with other programming modes/languages?
A misconfigured syntax table can lead to this and other problems.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#22238
; Package
emacs
.
(Fri, 25 Dec 2015 22:07:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 22238 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> Maybe that should just be reverted. A more proper fix would make Emacs not
> consider @ as a symbol constituent when it's the first character.
But @foo is a valid symbol.
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
bug-gnu-emacs <at> gnu.org
:
bug#22238
; Package
emacs
.
(Fri, 25 Dec 2015 22:10:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 22238 <at> debbugs.gnu.org (full text, mbox):
On 12/26/2015 12:06 AM, Andreas Schwab wrote:
> But @foo is a valid symbol.
Indeed. If you like to implement the syntax-propertize-function that
will distinguish between them, be my guest.
But it's more important to discern "symbol" in ,@symbol than support
symbols with rare names like that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#22238
; Package
emacs
.
(Sat, 26 Dec 2015 10:55:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 22238 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> On 12/26/2015 12:06 AM, Andreas Schwab wrote:
>
>> But @foo is a valid symbol.
>
> Indeed. If you like to implement the syntax-propertize-function that will
> distinguish between them, be my guest.
>
> But it's more important to discern "symbol" in ,@symbol than support
> symbols with rare names like that.
Such symbols are used by Emacs, so they should be properly supported.
There is no point in supporting ,@foo but not @foo, since the method
will be the same.
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
bug-gnu-emacs <at> gnu.org
:
bug#22238
; Package
emacs
.
(Sat, 26 Dec 2015 12:33:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 22238 <at> debbugs.gnu.org (full text, mbox):
On 12/26/2015 12:54 PM, Andreas Schwab wrote:
> Such symbols are used by Emacs, so they should be properly supported.
Example?
> since the method
> will be the same.
Not at all. ,@foo is not a symbol. It's unquote-splicing followed by
symbol foo.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#22238
; Package
emacs
.
(Mon, 05 Dec 2016 13:56:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 22238 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> Maybe that should just be reverted. A more proper fix would make Emacs
> not consider @ as a symbol constituent when it's the first
> character. The "p" in "_ p" apparently tries but fails to do that.
FWIW, there is a similar problem concerning the end of the symbol and
".".
The real-life use case is that I wanted to rename the argument of a
function like this:
(defun el-search--string-matcher (eregexp)
"Return a compiled match predicate for EREGEXP.
That's a predicate returning non-nil when extended regexp EREGEXP ...
with isearch in symbol mode. But symbol search doesn't find the
occurrence of "EREGEXP" at the end of the first sentence of the
docstring. Again, strictly speaking the behavior is as documented I
think ("." is a symbol constituent), but this also again foils the
purpose of symbol matching in "real-life". And again, the situation can
be ambiguous in rare cases.
Michael.
Reply sent
to
Michael Heerdegen <michael_heerdegen <at> web.de>
:
You have taken responsibility.
(Fri, 28 Jul 2023 01:20:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Michael Heerdegen <michael_heerdegen <at> web.de>
:
bug acknowledged by developer.
(Fri, 28 Jul 2023 01:20:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 22238-done <at> debbugs.gnu.org (full text, mbox):
Michael Heerdegen <michael_heerdegen <at> web.de> writes:
> isearch's symbol search (M-s _) doesn't find symbols as in
>
> ,@symbol
>
> when searching for "symbol". This was already the case in Emacs 24.5.
Checking this again and: this seems to be fixed. Closing.
Not sure about the obscure case involving a symbol @foo as mentioned by
Andreas, but searching for such a symbol works using symbol isearch, and
,@foo is read as (,@ foo) by the Lisp reader, not as (, @foo), and
isearch doesn't need to match a symbol @foo here, so I guess everything
works at least relatively well.
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#22238
; Package
emacs
.
(Fri, 28 Jul 2023 08:06:01 GMT)
Full text and
rfc822 format available.
Message #37 received at 22238 <at> debbugs.gnu.org (full text, mbox):
severity 22238 minor
merge 22238 44418
quit
[ Is there a pattern in the bug numbers? 🤔 ]
Michael Heerdegen [2023-07-28 03:19 +0200] wrote:
> Michael Heerdegen <michael_heerdegen <at> web.de> writes:
>> isearch's symbol search (M-s _) doesn't find symbols as in
>> ,@symbol
>> when searching for "symbol". This was already the case in Emacs 24.5.
> Checking this again and: this seems to be fixed. Closing.
Ah, I didn't find this report before submitting the duplicate
https://bugs.gnu.org/44418 (although I claimed to find the behaviour in
Emacs 24.5 as well).
Let's see if merging works without the need for excessive force...
Thanks,
--
Basil
Severity set to 'minor' from 'normal'
Request was from
"Basil L. Contovounesios" <contovob <at> tcd.ie>
to
control <at> debbugs.gnu.org
.
(Fri, 28 Jul 2023 08:06:02 GMT)
Full text and
rfc822 format available.
Merged 22238 44418.
Request was from
"Basil L. Contovounesios" <contovob <at> tcd.ie>
to
control <at> debbugs.gnu.org
.
(Fri, 28 Jul 2023 08:06:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#22238
; Package
emacs
.
(Sat, 29 Jul 2023 02:22:02 GMT)
Full text and
rfc822 format available.
Message #44 received at submit <at> debbugs.gnu.org (full text, mbox):
"Basil L. Contovounesios" via "Bug reports for GNU Emacs, the Swiss army
knife of text editors" <bug-gnu-emacs <at> gnu.org> writes:
> > Checking this again and: this seems to be fixed. Closing.
>
> Ah, I didn't find this report before submitting the duplicate
> https://bugs.gnu.org/44418 (although I claimed to find the behaviour
> in Emacs 24.5 as well).
Oh, and I didn't find the other report although I was sure that I had
read some discussion about this issue during vacations (if I only had
known about the secret pattern...). Thanks for joining.
> Let's see if merging works without the need for excessive force...
The result looks ok to me.
Thx,
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#22238
; Package
emacs
.
(Sat, 29 Jul 2023 02:22:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 26 Aug 2023 11:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 259 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.