GNU bug report logs -
#15006
24.3; emacs manual comment-start-skip example grouping
Previous Next
Reported by: Kevin Ryde <user42 <at> zip.com.au>
Date: Fri, 2 Aug 2013 00:50:02 UTC
Severity: minor
Found in version 24.3
Fixed in version 28.1
Done: Lars Ingebrigtsen <larsi <at> gnus.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 15006 in the body.
You can then email your comments to 15006 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#15006
; Package
emacs
.
(Fri, 02 Aug 2013 00:50:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Kevin Ryde <user42 <at> zip.com.au>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Fri, 02 Aug 2013 00:50:04 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
In the emacs manual info node "(emacs)Options for Comments" an example
comment-start-skip is given
"\\(//+\\|/\\*+\\)\\s *"
If I understand the comment-start-skip docstring correctly a \(..\)
group is for extra distinguishing text preceding the comment. Should
that example be a shy group, or perhaps expanded out to ungroup like
vera-mode.el has?
"/\\*+ *\\|//+ *"
I also wondered whether the whitespace "\\s *" in the example was a
little too loose since it matches \n and leading whitespace of the next
line too. Does that matter to anything?
In GNU Emacs 24.3.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
of 2013-05-29 on blah.blah, modified by Debian
System Description: Debian GNU/Linux 7.0 (wheezy)
Configured using:
`configure '--build' 'i486-linux-gnu' '--build' 'i486-linux-gnu'
'--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib'
'--localstatedir=/var/lib' '--infodir=/usr/share/info'
'--mandir=/usr/share/man' '--with-pop=yes'
'--enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.3/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.3/site-lisp:/usr/share/emacs/site-lisp'
'--with-crt-dir=/usr/lib/i386-linux-gnu' '--with-x=yes'
'--with-x-toolkit=lucid' '--with-toolkit-scroll-bars' '--without-gconf'
'build_alias=i486-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall'
'LDFLAGS=-Wl,-z,relro -Wl,-znocombreloc'
'CPPFLAGS=-D_FORTIFY_SOURCE=2''
Important settings:
value of $LANG: en_AU
locale-coding-system: iso-latin-1-unix
default enable-multibyte-characters: t
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#15006
; Package
emacs
.
(Fri, 02 Aug 2013 01:36:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 15006 <at> debbugs.gnu.org (full text, mbox):
> If I understand the comment-start-skip docstring correctly a \(..\)
> group is for extra distinguishing text preceding the comment. Should
> that example be a shy group,
Indeed, thank you.
> I also wondered whether the whitespace "\\s *" in the example was a
> little too loose since it matches \n and leading whitespace of the next
> line too. Does that matter to anything?
Yes, I prefer to stay away from "whitepace syntax" for that reason and
would recommend [ \t]* in its stead.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#15006
; Package
emacs
.
(Fri, 02 Aug 2013 01:51:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 15006 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
>> If I understand the comment-start-skip docstring correctly a \(..\)
>> group is for extra distinguishing text preceding the comment. Should
>> that example be a shy group,
>
> Indeed, thank you.
Actually I see the cc-mode code uses it with a group. And js.el too
(perhaps copying cc-mode). Does it have some subtle effect of skipping
the /*, or is it outright wrong?
> Yes, I prefer to stay away from "whitepace syntax" for that reason and
> would recommend [ \t]* in its stead.
I suppose the intention is to pick up non-breaking spaces or whatever
other flavours of whitespace. Unlikely to arise in practice in
programming language stuff. Is there an obvious ill effect?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#15006
; Package
emacs
.
(Fri, 02 Aug 2013 02:32:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 15006 <at> debbugs.gnu.org (full text, mbox):
> Actually I see the cc-mode code uses it with a group. And js.el too
> (perhaps copying cc-mode). Does it have some subtle effect of skipping
> the /*, or is it outright wrong?
It's wrong. But cc-mode likes to reinvent the wheel, so maybe
it doesn't use much of that code anyway.
>> Yes, I prefer to stay away from "whitepace syntax" for that reason and
>> would recommend [ \t]* in its stead.
> I suppose the intention is to pick up non-breaking spaces or whatever
> other flavours of whitespace. Unlikely to arise in practice in
> programming language stuff. Is there an obvious ill effect?
You can get things like (re-search-forward comment-start-skip) and end
up with (match-end 0) past the end of the matched comment (e.g. when
matching "//\n").
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#15006
; Package
emacs
.
(Sat, 21 Aug 2021 14:09:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 15006 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> I suppose the intention is to pick up non-breaking spaces or whatever
>> other flavours of whitespace. Unlikely to arise in practice in
>> programming language stuff. Is there an obvious ill effect?
>
> You can get things like (re-search-forward comment-start-skip) and end
> up with (match-end 0) past the end of the matched comment (e.g. when
> matching "//\n").
I've now updated the example in the manual (as well as rearranged the
\\| to match the order of the description of the regexp) in Emacs 28.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug marked as fixed in version 28.1, send any further explanations to
15006 <at> debbugs.gnu.org and Kevin Ryde <user42 <at> zip.com.au>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sat, 21 Aug 2021 14:09: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
.
(Sun, 19 Sep 2021 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 273 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.