GNU bug report logs -
#31676
27.0.50; More helpful error message for unescaped character literals
Previous Next
Reported by: Lars Ingebrigtsen <larsi <at> gnus.org>
Date: Fri, 1 Jun 2018 10:19:01 UTC
Severity: wishlist
Found in version 27.0.50
Done: Philipp Stephani <p.stephani2 <at> gmail.com>
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 31676 in the body.
You can then email your comments to 31676 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#31676
; Package
emacs
.
(Fri, 01 Jun 2018 10:19:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Lars Ingebrigtsen <larsi <at> gnus.org>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Fri, 01 Jun 2018 10:19:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
A reddit user noted these messages popping up when starting Emacs
Loading ‘~/.emacs.d/init’: unescaped character literals `?[', `?]' detected!
and wondered what to do about it. Perhaps it would be a good idea to
just say something like
unescaped character literals `?[', `?]' detected, `?\[', `?\]' expected
or something along those lines? For Emacs 26.2.
In GNU Emacs 27.0.50 (build 20, x86_64-pc-linux-gnu, GTK+ Version 3.22.11)
of 2018-05-19 built on stories
Repository revision: f4d9fd3dd45f767eca33fbf1beee40da790fa74e
Windowing system distributor 'The X.Org Foundation', version 11.0.11902000
System Description: Debian GNU/Linux 9 (stretch)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#31676
; Package
emacs
.
(Sat, 02 Jun 2018 10:01:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 31676 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Lars Ingebrigtsen <larsi <at> gnus.org> schrieb am Fr., 1. Juni 2018 um
12:19 Uhr:
>
> A reddit user noted these messages popping up when starting Emacs
>
> Loading ‘~/.emacs.d/init’: unescaped character literals `?[', `?]'
> detected!
>
> and wondered what to do about it. Perhaps it would be a good idea to
> just say something like
>
> unescaped character literals `?[', `?]' detected, `?\[', `?\]' expected
>
> or something along those lines? For Emacs 26.2.
>
>
Sounds reasonable, here's a patch.
[Message part 2 (text/html, inline)]
[0001-Make-warning-about-unescaped-character-literals-more-h.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#31676
; Package
emacs
.
(Fri, 08 Jun 2018 14:52:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 31676 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 2 Jun 2018 12:00:26 +0200
> Cc: 31676 <at> debbugs.gnu.org
>
> Sounds reasonable, here's a patch.
>
> From 4bd8348753980be95dc4bcba47e52f7f79255fb6 Mon Sep 17 00:00:00 2001
> From: Philipp Stephani <phst <at> google.com>
> Date: Sat, 2 Jun 2018 11:59:02 +0200
> Subject: [PATCH] Make warning about unescaped character literals more helpful.
>
> See Bug#31676.
>
> * src/lread.c (Flread_unescaped_character_literals_warning): New
> defun.
> (load_warn_unescaped_character_literals): Use it.
> (syms_of_lread): Define new defun. Unintern internal
> variable, which is not used any more outside of lread.c
>
> * lisp/emacs-lisp/bytecomp.el (byte-compile-from-buffer): Use new
> defun.
>
> * test/src/lread-tests.el (lread-tests--unescaped-char-literals):
> test/lisp/emacs-lisp/bytecomp-tests.el
> (bytecomp-tests--unescaped-char-literals): Adapt unit tests.
Sounds okay, but can you tell why you implemented
lread--unescaped-character-literals in C? If that's because you need
to call it from load_warn_unescaped_character_literals, then C
functions can call Lisp functions with no problems, we have several
examples of that in the sources. AFAICT, the C implementation is just
a "transliteration" of straightforward Lisp code, so it reads strange.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#31676
; Package
emacs
.
(Sat, 09 Jun 2018 17:13:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 31676 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> schrieb am Fr., 8. Juni 2018 um 16:51 Uhr:
> > Date: Sat, 2 Jun 2018 12:00:26 +0200
> > Cc: 31676 <at> debbugs.gnu.org
> >
> > Sounds reasonable, here's a patch.
> >
> > From 4bd8348753980be95dc4bcba47e52f7f79255fb6 Mon Sep 17 00:00:00 2001
> > From: Philipp Stephani <phst <at> google.com>
> > Date: Sat, 2 Jun 2018 11:59:02 +0200
> > Subject: [PATCH] Make warning about unescaped character literals more
> helpful.
> >
> > See Bug#31676.
> >
> > * src/lread.c (Flread_unescaped_character_literals_warning): New
> > defun.
> > (load_warn_unescaped_character_literals): Use it.
> > (syms_of_lread): Define new defun. Unintern internal
> > variable, which is not used any more outside of lread.c
> >
> > * lisp/emacs-lisp/bytecomp.el (byte-compile-from-buffer): Use new
> > defun.
> >
> > * test/src/lread-tests.el (lread-tests--unescaped-char-literals):
> > test/lisp/emacs-lisp/bytecomp-tests.el
> > (bytecomp-tests--unescaped-char-literals): Adapt unit tests.
>
> Sounds okay, but can you tell why you implemented
> lread--unescaped-character-literals in C? If that's because you need
> to call it from load_warn_unescaped_character_literals, then C
> functions can call Lisp functions with no problems, we have several
> examples of that in the sources. AFAICT, the C implementation is just
> a "transliteration" of straightforward Lisp code, so it reads strange.
>
The function uses an uninterned variable, so it has to be in C. I think
that's slightly better than interning the variable and having some Lisp
function access it (the latter would have one additional internal symbol).
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#31676
; Package
emacs
.
(Sat, 09 Jun 2018 17:32:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 31676 <at> debbugs.gnu.org (full text, mbox):
> From: Philipp Stephani <p.stephani2 <at> gmail.com>
> Date: Sat, 9 Jun 2018 19:12:30 +0200
> Cc: larsi <at> gnus.org, 31676 <at> debbugs.gnu.org
>
> Sounds okay, but can you tell why you implemented
> lread--unescaped-character-literals in C? If that's because you need
> to call it from load_warn_unescaped_character_literals, then C
> functions can call Lisp functions with no problems, we have several
> examples of that in the sources. AFAICT, the C implementation is just
> a "transliteration" of straightforward Lisp code, so it reads strange.
>
> The function uses an uninterned variable, so it has to be in C. I think that's slightly better than interning the
> variable and having some Lisp function access it (the latter would have one additional internal symbol).
Why does it need an uninterned variable? And if it does, why cannot
it create a symbol that is not in obarray?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#31676
; Package
emacs
.
(Fri, 19 Apr 2019 09:55:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 31676 <at> debbugs.gnu.org (full text, mbox):
Am Sa., 9. Juni 2018 um 19:31 Uhr schrieb Eli Zaretskii <eliz <at> gnu.org>:
>
> > From: Philipp Stephani <p.stephani2 <at> gmail.com>
> > Date: Sat, 9 Jun 2018 19:12:30 +0200
> > Cc: larsi <at> gnus.org, 31676 <at> debbugs.gnu.org
> >
> > Sounds okay, but can you tell why you implemented
> > lread--unescaped-character-literals in C? If that's because you need
> > to call it from load_warn_unescaped_character_literals, then C
> > functions can call Lisp functions with no problems, we have several
> > examples of that in the sources. AFAICT, the C implementation is just
> > a "transliteration" of straightforward Lisp code, so it reads strange.
> >
> > The function uses an uninterned variable, so it has to be in C. I think that's slightly better than interning the
> > variable and having some Lisp function access it (the latter would have one additional internal symbol).
>
> Why does it need an uninterned variable?
It doesn't need to be uninterned, but it's cleaner that way because no
other code can access the variable.
> And if it does, why cannot
> it create a symbol that is not in obarray?
That's what the patch does.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#31676
; Package
emacs
.
(Fri, 19 Apr 2019 11:44:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 31676 <at> debbugs.gnu.org (full text, mbox):
Philipp Stephani <p.stephani2 <at> gmail.com> writes:
>> > The function uses an uninterned variable, so it has to be in C. I think that's slightly better than interning the
>> > variable and having some Lisp function access it (the latter would have one additional internal symbol).
>> Why does it need an uninterned variable?
>
> It doesn't need to be uninterned, but it's cleaner that way because no
> other code can access the variable.
>
>> And if it does, why cannot
>> it create a symbol that is not in obarray?
>
> That's what the patch does.
The patch uninterns a symbol after it's interned in the obarray. I
think the question is, why put the symbol in the obarray in the first
place? Just a C static variable would do (although this would require
an additional (trivial) C function, to use with record_unwind_protect
instead of specbind). See for example Vloads_in_progress.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#31676
; Package
emacs
.
(Fri, 19 Apr 2019 15:55:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 31676 <at> debbugs.gnu.org (full text, mbox):
Am Fr., 19. Apr. 2019 um 13:43 Uhr schrieb Noam Postavsky <npostavs <at> gmail.com>:
>
> Philipp Stephani <p.stephani2 <at> gmail.com> writes:
>
> >> > The function uses an uninterned variable, so it has to be in C. I think that's slightly better than interning the
> >> > variable and having some Lisp function access it (the latter would have one additional internal symbol).
>
> >> Why does it need an uninterned variable?
> >
> > It doesn't need to be uninterned, but it's cleaner that way because no
> > other code can access the variable.
> >
> >> And if it does, why cannot
> >> it create a symbol that is not in obarray?
> >
> > That's what the patch does.
>
> The patch uninterns a symbol after it's interned in the obarray. I
> think the question is, why put the symbol in the obarray in the first
> place? Just a C static variable would do (although this would require
> an additional (trivial) C function, to use with record_unwind_protect
> instead of specbind). See for example Vloads_in_progress.
>
Ah, I see. There's no specific reason for this specific
implementation, it's just the simplest one.
Since we have a few cases where we need uninterned variables/functions
(I see 6 existing calls to unintern in the C source code), how about
extending DEFVAR/defsubr to allow uninterned symbols? That would make
the implementation of these cases more obvious.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#31676
; Package
emacs
.
(Fri, 19 Apr 2019 16:35:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 31676 <at> debbugs.gnu.org (full text, mbox):
Am Fr., 19. Apr. 2019 um 17:53 Uhr schrieb Philipp Stephani
<p.stephani2 <at> gmail.com>:
>
> Am Fr., 19. Apr. 2019 um 13:43 Uhr schrieb Noam Postavsky <npostavs <at> gmail.com>:
> >
> > Philipp Stephani <p.stephani2 <at> gmail.com> writes:
> >
> > >> > The function uses an uninterned variable, so it has to be in C. I think that's slightly better than interning the
> > >> > variable and having some Lisp function access it (the latter would have one additional internal symbol).
> >
> > >> Why does it need an uninterned variable?
> > >
> > > It doesn't need to be uninterned, but it's cleaner that way because no
> > > other code can access the variable.
> > >
> > >> And if it does, why cannot
> > >> it create a symbol that is not in obarray?
> > >
> > > That's what the patch does.
> >
> > The patch uninterns a symbol after it's interned in the obarray. I
> > think the question is, why put the symbol in the obarray in the first
> > place? Just a C static variable would do (although this would require
> > an additional (trivial) C function, to use with record_unwind_protect
> > instead of specbind). See for example Vloads_in_progress.
> >
>
> Ah, I see. There's no specific reason for this specific
> implementation, it's just the simplest one.
> Since we have a few cases where we need uninterned variables/functions
> (I see 6 existing calls to unintern in the C source code), how about
> extending DEFVAR/defsubr to allow uninterned symbols? That would make
> the implementation of these cases more obvious.
Thinking about this a bit more, I think the overhead of your approach
for most uninterned symbols (a static variable + staticpro) is small
enough to not warrant further complex DEF* macros, so I'll switch the
existing uses to that.
Reply sent
to
Philipp Stephani <p.stephani2 <at> gmail.com>
:
You have taken responsibility.
(Fri, 19 Apr 2019 17:23:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Lars Ingebrigtsen <larsi <at> gnus.org>
:
bug acknowledged by developer.
(Fri, 19 Apr 2019 17:23:01 GMT)
Full text and
rfc822 format available.
Message #34 received at 31676-done <at> debbugs.gnu.org (full text, mbox):
Am Sa., 9. Juni 2018 um 19:12 Uhr schrieb Philipp Stephani
<p.stephani2 <at> gmail.com>:
>
>
>
> Eli Zaretskii <eliz <at> gnu.org> schrieb am Fr., 8. Juni 2018 um 16:51 Uhr:
>>
>> > Date: Sat, 2 Jun 2018 12:00:26 +0200
>> > Cc: 31676 <at> debbugs.gnu.org
>> >
>> > Sounds reasonable, here's a patch.
>> >
>> > From 4bd8348753980be95dc4bcba47e52f7f79255fb6 Mon Sep 17 00:00:00 2001
>> > From: Philipp Stephani <phst <at> google.com>
>> > Date: Sat, 2 Jun 2018 11:59:02 +0200
>> > Subject: [PATCH] Make warning about unescaped character literals more helpful.
>> >
>> > See Bug#31676.
>> >
>> > * src/lread.c (Flread_unescaped_character_literals_warning): New
>> > defun.
>> > (load_warn_unescaped_character_literals): Use it.
>> > (syms_of_lread): Define new defun. Unintern internal
>> > variable, which is not used any more outside of lread.c
>> >
>> > * lisp/emacs-lisp/bytecomp.el (byte-compile-from-buffer): Use new
>> > defun.
>> >
>> > * test/src/lread-tests.el (lread-tests--unescaped-char-literals):
>> > test/lisp/emacs-lisp/bytecomp-tests.el
>> > (bytecomp-tests--unescaped-char-literals): Adapt unit tests.
>>
>> Sounds okay, but can you tell why you implemented
>> lread--unescaped-character-literals in C? If that's because you need
>> to call it from load_warn_unescaped_character_literals, then C
>> functions can call Lisp functions with no problems, we have several
>> examples of that in the sources. AFAICT, the C implementation is just
>> a "transliteration" of straightforward Lisp code, so it reads strange.
>
>
> The function uses an uninterned variable, so it has to be in C. I think that's slightly better than interning the variable and having some Lisp function access it (the latter would have one additional internal symbol).
However, your point about the C function being strange is valid. I've
reimplemented it in Lisp now and pushed commit 0b4b380ce4 to master.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 18 May 2019 11:24:07 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 344 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.