GNU bug report logs - #31676
27.0.50; More helpful error message for unescaped character literals

Previous Next

Package: emacs;

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.

Full log


View this message in rfc822 format

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>, 31676 <at> debbugs.gnu.org
Subject: bug#31676: 27.0.50; More helpful error message for unescaped character literals
Date: Fri, 19 Apr 2019 18:33:47 +0200
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.




This bug report was last modified 6 years and 90 days ago.

Previous Next


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