GNU bug report logs - #24982
24.5; way to let Elisp reader ignore unreadable #(...) constructs

Previous Next

Package: emacs;

Reported by: Drew Adams <drew.adams <at> oracle.com>

Date: Mon, 21 Nov 2016 21:49:01 UTC

Severity: wishlist

Tags: wontfix

Found in version 24.5

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 24982 in the body.
You can then email your comments to 24982 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#24982; Package emacs. (Mon, 21 Nov 2016 21:49:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Drew Adams <drew.adams <at> oracle.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Mon, 21 Nov 2016 21:49:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.5; way to let Elisp reader ignore unreadable #(...) constructs
Date: Mon, 21 Nov 2016 13:47:45 -0800 (PST)
Enhancement request:

Provide a Boolean variable or a wrapper macro that has the effect of not
raising an error but just skipping over any unreadable #(...) construct.

(I really wish this were available for older Emacs versions.  Those are
the ones that barf on #(...) constructs that are supported in later
versions.


In GNU Emacs 24.5.1 (i686-pc-mingw32)
 of 2015-04-11 on LEG570
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/usr --host=i686-pc-mingw32'




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#24982; Package emacs. (Mon, 02 Apr 2018 19:56:01 GMT) Full text and rfc822 format available.

Message #8 received at 24982 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 24982 <at> debbugs.gnu.org
Subject: Re: bug#24982: 24.5;
 way to let Elisp reader ignore unreadable #(...) constructs
Date: Mon, 02 Apr 2018 22:32:49 +0300
> Enhancement request:
>
> Provide a Boolean variable or a wrapper macro that has the effect of not
> raising an error but just skipping over any unreadable #(...) construct.

There is such macro called ‘ignore-errors’.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#24982; Package emacs. (Mon, 02 Apr 2018 20:33:03 GMT) Full text and rfc822 format available.

Message #11 received at 24982 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 24982 <at> debbugs.gnu.org
Subject: RE: bug#24982: 24.5; way to let Elisp reader ignore unreadable #(...)
 constructs
Date: Mon, 2 Apr 2018 13:31:54 -0700 (PDT)
> > Enhancement request:
> >
> > Provide a Boolean variable or a wrapper macro that has the effect of not
> > raising an error but just skipping over any unreadable #(...) construct.
> 
> There is such macro called ‘ignore-errors’.

No.  That ignores all errors.

Is there an error handler that covers all and only #(...) read errors?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#24982; Package emacs. (Mon, 02 Apr 2018 20:56:01 GMT) Full text and rfc822 format available.

Message #14 received at 24982 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 24982 <at> debbugs.gnu.org
Subject: Re: bug#24982: 24.5;
 way to let Elisp reader ignore unreadable #(...) constructs
Date: Mon, 02 Apr 2018 23:54:40 +0300
>> > Enhancement request:
>> >
>> > Provide a Boolean variable or a wrapper macro that has the effect of not
>> > raising an error but just skipping over any unreadable #(...) construct.
>> 
>> There is such macro called ‘ignore-errors’.
>
> No.  That ignores all errors.
>
> Is there an error handler that covers all and only #(...) read errors?

Then you can use something like

  (condition-case err
      (read (current-buffer))
    (invalid-read-syntax err))

that for example for unreadable #<marker ...> returns

  (invalid-read-syntax "#")




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#24982; Package emacs. (Mon, 02 Apr 2018 21:33:01 GMT) Full text and rfc822 format available.

Message #17 received at 24982 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 24982 <at> debbugs.gnu.org
Subject: RE: bug#24982: 24.5; way to let Elisp reader ignore unreadable #(...)
 constructs
Date: Mon, 2 Apr 2018 14:32:41 -0700 (PDT)
> >> > Enhancement request:
> >> > Provide a Boolean variable or a wrapper macro that has the effect of
> >> > not raising an error but just skipping over any unreadable #(...)
> >> > construct.
> >>
> >> There is such macro called ‘ignore-errors’.
> >
> > No.  That ignores all errors.
> >
> > Is there an error handler that covers all and only #(...) read errors?
                                              ^^^^^^^^
> Then you can use something like
>   (condition-case err
>       (read (current-buffer))
>     (invalid-read-syntax err))
> that for example for unreadable #<marker ...> returns
>   (invalid-read-syntax "#")

And (read ")((") gives (invalid-read-syntax ")").
So it's not specific to unreadable #(...) or #....




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#24982; Package emacs. (Tue, 03 Apr 2018 20:15:01 GMT) Full text and rfc822 format available.

Message #20 received at 24982 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 24982 <at> debbugs.gnu.org
Subject: Re: bug#24982: 24.5;
 way to let Elisp reader ignore unreadable #(...) constructs
Date: Tue, 03 Apr 2018 23:06:24 +0300
>> >> > Enhancement request:
>> >> > Provide a Boolean variable or a wrapper macro that has the effect of
>> >> > not raising an error but just skipping over any unreadable #(...)
>> >> > construct.
>> >>
>> >> There is such macro called ‘ignore-errors’.
>> >
>> > No.  That ignores all errors.
>> >
>> > Is there an error handler that covers all and only #(...) read errors?
>                                               ^^^^^^^^
>> Then you can use something like
>>   (condition-case err
>>       (read (current-buffer))
>>     (invalid-read-syntax err))
>> that for example for unreadable #<marker ...> returns
>>   (invalid-read-syntax "#")
>
> And (read ")((") gives (invalid-read-syntax ")").
> So it's not specific to unreadable #(...) or #....

You can also use the position in the source buffer
to scan text near the error where reading failed.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#24982; Package emacs. (Sat, 22 Aug 2020 19:14:02 GMT) Full text and rfc822 format available.

Message #23 received at 24982 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 24982 <at> debbugs.gnu.org
Subject: Re: bug#24982: 24.5;
 way to let Elisp reader ignore unreadable #(...) constructs
Date: Sat, 22 Aug 2020 15:13:31 -0400
Drew Adams <drew.adams <at> oracle.com> writes:

> Enhancement request:
>
> Provide a Boolean variable or a wrapper macro that has the effect of not
> raising an error but just skipping over any unreadable #(...) construct.
>
> (I really wish this were available for older Emacs versions.  Those are
> the ones that barf on #(...) constructs that are supported in later
> versions.

What's the use-case here?  Why can't you use `ignore-errors'?

Best regards,
Stefan Kangas




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#24982; Package emacs. (Sat, 22 Aug 2020 19:18:01 GMT) Full text and rfc822 format available.

Message #26 received at 24982 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 24982 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#24982: 24.5; way to let Elisp reader ignore unreadable
 #(...) constructs
Date: Sat, 22 Aug 2020 21:17:40 +0200
Stefan Kangas <stefan <at> marxist.se> writes:

> Drew Adams <drew.adams <at> oracle.com> writes:
>
>> Enhancement request:
>>
>> Provide a Boolean variable or a wrapper macro that has the effect of not
>> raising an error but just skipping over any unreadable #(...) construct.
>>
>> (I really wish this were available for older Emacs versions.  Those are
>> the ones that barf on #(...) constructs that are supported in later
>> versions.
>
> What's the use-case here?  Why can't you use `ignore-errors'?

The problem is when the thing inside the construct is unreadable, not
when there's errors (in a syntactically valid form).  For instance:

(ignore-errors #0)

In Common Lisp, this is the #| ...  |# operator, and it's handy
occasionally.  It's really like a nesting comment thing...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#24982; Package emacs. (Sat, 22 Aug 2020 19:27:01 GMT) Full text and rfc822 format available.

Message #29 received at 24982 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 24982 <at> debbugs.gnu.org
Subject: RE: bug#24982: 24.5; way to let Elisp reader ignore unreadable #(...)
 constructs
Date: Sat, 22 Aug 2020 12:25:57 -0700 (PDT)
> > Enhancement request:
> >
> > Provide a Boolean variable or a wrapper macro that has the effect of not
> > raising an error but just skipping over any unreadable #(...) construct.
> >
> > (I really wish this were available for older Emacs versions.  Those are
> > the ones that barf on #(...) constructs that are supported in later
> > versions.
> 
> What's the use-case here?  Why can't you use `ignore-errors'?

(ignore-errors (read (current-buffer))

doesn't advance over the sexp.

I guess what I mean is a #() construct that raises
an (invalid-read-syntax "#") error.  A situation
where there is, in fact, a #(...) present but that
error gets raised.

It's possible that the request is underspecified;
dunno.

The parenthetical remark in the request is really
the motivation.  For older Emacs the syntax #(...)
didn't exist.  But that error can still be raised,
when the syntax of the `...' isn't valid.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#24982; Package emacs. (Sat, 22 Aug 2020 19:29:02 GMT) Full text and rfc822 format available.

Message #32 received at 24982 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Stefan Kangas <stefan <at> marxist.se>
Cc: 24982 <at> debbugs.gnu.org
Subject: RE: bug#24982: 24.5; way to let Elisp reader ignore unreadable #(...)
 constructs
Date: Sat, 22 Aug 2020 12:28:32 -0700 (PDT)
> The problem is when the thing inside the construct is unreadable, not
> when there's errors (in a syntactically valid form).  For instance:
> 
> (ignore-errors #0)
> 
> In Common Lisp, this is the #| ...  |# operator, and it's handy
> occasionally.  It's really like a nesting comment thing...

Good point.  I was thinking of #(...), but yes,
the situation is more general.  It's about #
syntax that's found to be invalid, but for cases
where # nevertheless can tell where the sexp
parsing should end (and so can advance point there).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#24982; Package emacs. (Sat, 22 Aug 2020 19:55:01 GMT) Full text and rfc822 format available.

Message #35 received at 24982 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 24982 <at> debbugs.gnu.org, Stefan Kangas <stefan <at> marxist.se>
Subject: Re: bug#24982: 24.5; way to let Elisp reader ignore unreadable
 #(...) constructs
Date: Sat, 22 Aug 2020 21:53:50 +0200
Drew Adams <drew.adams <at> oracle.com> writes:

>> In Common Lisp, this is the #| ...  |# operator, and it's handy
>> occasionally.  It's really like a nesting comment thing...
>
> Good point.  I was thinking of #(...), but yes,
> the situation is more general.  It's about #
> syntax that's found to be invalid, but for cases
> where # nevertheless can tell where the sexp
> parsing should end (and so can advance point there).

Yup.

I couldn't quite remember whether the Common Lisp #| |# was balanced,
but it is, which is nice.  That is, you can write

#| foo #| bar |# zot |#

and the first |# doesn't end the first #|.

Digression: While Googling, I was reminded that Common Lisp also has

#+condition
(foo:bar)

which (possibly) ignores the next sexp...  which is handy in Common
Lisp, but Emacs doesn't need it.  Common Lisp needs it because reference
to an unloaded package is a read error, instead of an undefined error.
Which is a really bad design choice.  That is, you can't say
(if (fboundp 'foo:bar) ...) if foo is a package that isn't loaded --
it's a read error.

Digression over!

I'm not an expert on the Emacs Lisp reader, but poking at it at bit, it
seems like adding support for #| |# should be trivial: It's just a new
comment syntax, really, so we just have to count #|'s and discard the
input.

A bigger issue would be in emacs-lisp-mode -- having forward-sexp etc do
the right thing.  However, surely that's handled already in the Common
Lisp modes, so we could just crib code from those, I'd have thought...

So I think it's doable, which only leaves us with the question: What's
the use case?

Well, I think it's handy when developing.  If I'm in the middle of a
function

...
(foo)
(bar)
(and-here-i'm-adding-some-new-stuff-that's-not-finished
  ...
  )
(zot)
...

and I'm testing stuff, and I decide to take out the stuff I'm
writing...  Emacs doesn't really handle that well.  I usually end up
deleting the sexp, and hoping that the kill ring is big enough to hold
it until I need it again, or slapping a (when nil ...) around it, which
is unsatisfactory, because that changes the indentation.

Just being able to do:

...
(foo)
(bar)
#|
(and-here-i'm-adding-some-new-stuff-that's-not-finished
  ...
  )
|#
(zot)
...

would be nice.  And then the stuff I'm working on doesn't even have to
be syntactically correct.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#24982; Package emacs. (Sat, 22 Aug 2020 22:45:01 GMT) Full text and rfc822 format available.

Message #38 received at 24982 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 24982 <at> debbugs.gnu.org, Stefan Kangas <stefan <at> marxist.se>
Subject: RE: bug#24982: 24.5; way to let Elisp reader ignore unreadable #(...)
 constructs
Date: Sat, 22 Aug 2020 15:44:02 -0700 (PDT)
You bring up a few things.  I'll comment only about
commenting. ;-)

> I couldn't quite remember whether the Common Lisp #| |# was balanced,
> but it is, which is nice.  That is, you can write
> #| foo #| bar |# zot |#
> and the first |# doesn't end the first #|.

Yes, CL block commenting is fully nestable and unnestable.

(IMO, that's really the point/advantage of block commenting.)

> I'm not an expert on the Emacs Lisp reader, but poking at it at bit, it
> seems like adding support for #| |# should be trivial: It's just a new
> comment syntax, really, so we just have to count #|'s and discard the
> input.

Possibly; dunno.

[Aside: I think it would be great if Elisp had reader
macros - give Lisp programs control over the Lisp reader.]
 
> So ... What's the use case?  Well, I think it's handy
> when developing.  If I'm in the middle of a function
> (foo)
> (bar)
> (and-here-i'm-adding-some-new-stuff-that's-not-finished
>   ...
>   )
> (zot)
> 
> and I'm testing stuff, and I decide to take out the stuff I'm
> writing...  Emacs doesn't really handle that well.  I usually end up
> deleting the sexp, and hoping that the kill ring is big enough to hold
> it until I need it again, or slapping a (when nil ...) around it, which
> is unsatisfactory, because that changes the indentation.
> 
> Just being able to do:
> (foo)
> (bar)
> #|
> (and-here-i'm-adding-some-new-stuff-that's-not-finished
>   ...
>   )
> |#
> (zot)
> 
> would be nice.  And then the stuff I'm working on doesn't even have to
> be syntactically correct.

Yes.  Well, we do have such a feature, but we don't have
it by just inserting paired delimiters.

We have it with `comment-region' (and similar).  How so?
Plain `C-u' UNcomments/unnests a given comment level.

One difference, besides the paired-delimiter one (but
which follows from it), is that you can't do it with
the same effect in-line.

Another is that because a single `;' comments to eol,
syntactically there's no essential difference among
`;', `;;', `;;;', etc.  And yet the commenting and
UNcommenting of `comment-region' give you the
additional control of how many `;' to work with.

E.g., you can "uncomment" by N `;', which may uncomment
some code and leave other code commented (which had M>N
`;').  But that's also what makes `comment-region' and
its `C-u' give you block-commenting behavior.

That's how I use `comment-region' - for block commenting
and uncommenting - unnesting a block of commented code.

And it's why I use `M-;' (`comment-dwim') ONLY for a
comment after a line of code.  I don't use it to comment
the region as a block comment.  Its behavior when the
region consists only of comments is different from its
region behavior otherwise.  And I don't want that.
___


Actually, instead of `comment-region' for block commenting
I use this, which is the same except it comments/uncomments
whole lines.

(defun comment-region-lines (beg end &optional arg)
  (interactive "*r\nP")
  (when (> beg end) (setq beg  (prog1 end (setq end  beg))))
  (let ((bol  (save-excursion
                (goto-char beg)
                (line-beginning-position)))
        (eol  (save-excursion
                (goto-char end)
                (if (bolp) (point) (line-end-position)))))
    (comment-region bol eol arg)))




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#24982; Package emacs. (Sun, 13 Feb 2022 08:47:02 GMT) Full text and rfc822 format available.

Message #41 received at 24982 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 24982 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#24982: 24.5; way to let Elisp reader ignore unreadable
 #(...) constructs
Date: Sun, 13 Feb 2022 09:46:19 +0100
Drew Adams <drew.adams <at> oracle.com> writes:

> Provide a Boolean variable or a wrapper macro that has the effect of not
> raising an error but just skipping over any unreadable #(...) construct.

I assume you mean #<...> here?

Anyway, there was some discussion about this in the context of the new
readablep function and the `print-unreadable-function' variable.  We
could indeed introduce a new `read-unreadable-function' variable that's
called when we encounter a #< instead of throwing an error (with no
performance impact).

Does anybody see any major downsides to doing that?  We've been wary of
allowing the users to customise the Emacs Lisp reader, but this seems
like a very small thing.  And it'd allow people to implement having

#<marker in no buffer>

read to (make-marker), etc, if they find that useful for some data
structures.

I had an extremely quick peek at this some time back, and it seemed
pretty trivial to implement.

Any opinions?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#24982; Package emacs. (Sun, 13 Feb 2022 17:34:01 GMT) Full text and rfc822 format available.

Message #44 received at 24982 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: "24982 <at> debbugs.gnu.org" <24982 <at> debbugs.gnu.org>,
 Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: RE: [External] : Re: bug#24982: 24.5; way to let Elisp reader ignore
 unreadable #(...) constructs
Date: Sun, 13 Feb 2022 17:33:43 +0000
> > Provide a Boolean variable or a wrapper macro that has the effect of not
> > raising an error but just skipping over any unreadable #(...) construct.
> 
> I assume you mean #<...> here?

No.  I meant #(...).  I wrote that twice.

But if you like you could extend this request
to some other - or to ALL - # reader syntax.
In that case, it would be good to be able to
specify just which syntaxes to ignore - e.g.,
have an option or defvar whose value is a list
that specifies which to ignore (e.g. in a
given context).

E.g. (from `i # TAB' in the Elisp manual):

 ##
 #$
 #'
 #(
 #@COUNT
 #:
 #N#
 #N=
 #^

> Anyway, there was some discussion about this in the context of the new
> readablep function and the `print-unreadable-function' variable.  We
> could indeed introduce a new `read-unreadable-function' variable that's
> called when we encounter a #< instead of throwing an error (with no
> performance impact).
> 
> Does anybody see any major downsides to doing that?  We've been wary of
> allowing the users to customise the Emacs Lisp reader, but this seems
> like a very small thing.  And it'd allow people to implement having
> 
> #<marker in no buffer>
> 
> read to (make-marker), etc, if they find that useful for some data
> structures.
> 
> I had an extremely quick peek at this some time back, and it seemed
> pretty trivial to implement.
> 
> Any opinions?
> 
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog:
> https://urldefense.com/v3/__http://lars.ingebrigtsen.no__;!!ACWV5N9M2RV99hQ!
> ecUUd4A1C-jNt5HVD7l0qY450h_bpEQRCBEBtE78iCT4tITSqr-AY6VKDdpX9cNx$




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#24982; Package emacs. (Sun, 13 Feb 2022 17:54:01 GMT) Full text and rfc822 format available.

Message #47 received at 24982 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: "24982 <at> debbugs.gnu.org" <24982 <at> debbugs.gnu.org>,
 Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: [External] : Re: bug#24982: 24.5; way to let Elisp reader
 ignore unreadable #(...) constructs
Date: Sun, 13 Feb 2022 18:53:41 +0100
Drew Adams <drew.adams <at> oracle.com> writes:

>> > Provide a Boolean variable or a wrapper macro that has the effect of not
>> > raising an error but just skipping over any unreadable #(...) construct.
>> 
>> I assume you mean #<...> here?
>
> No.  I meant #(...).  I wrote that twice.

There's nothing unreadable about #("..."), which is the only thing
that's printed as #(...).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#24982; Package emacs. (Sun, 13 Feb 2022 18:05:02 GMT) Full text and rfc822 format available.

Message #50 received at 24982 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: "24982 <at> debbugs.gnu.org" <24982 <at> debbugs.gnu.org>,
 Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: RE: [External] : Re: bug#24982: 24.5; way to let Elisp reader ignore
 unreadable #(...) constructs
Date: Sun, 13 Feb 2022 18:03:44 +0000
> There's nothing unreadable about #("..."), which is the only thing
> that's printed as #(...).

I agree that this could usefully be generalized.
As I wrote:

  I was thinking of #(...), but yes,
  the situation is more general.  It's about #
  syntax that's found to be invalid, but for cases
  where # nevertheless can tell where the sexp
  parsing should end (and so can advance point there).

The reason I'm interested in #(...) is stated at
the outset - for Emacs releases where that isn't
supported.  If the bug is fixed in Elisp then I
could likely add whatever the fix is (a macro or
whatever) to my code, to handle such older releases.

But sure, let's consider handling # constructs
more generally, as I said in my previous mail.






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#24982; Package emacs. (Mon, 14 Feb 2022 04:17:01 GMT) Full text and rfc822 format available.

Message #53 received at 24982 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 24982 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, drew.adams <at> oracle.com
Subject: Re: bug#24982: 24.5;
 way to let Elisp reader ignore unreadable #(...) constructs
Date: Sun, 13 Feb 2022 23:15:54 -0500
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Anyway, there was some discussion about this in the context of the new
  > readablep function and the `print-unreadable-function' variable.  We
  > could indeed introduce a new `read-unreadable-function' variable that's
  > called when we encounter a #< instead of throwing an error (with no
  > performance impact).

  > Does anybody see any major downsides to doing that?  We've been wary of
  > allowing the users to customise the Emacs Lisp reader, but this seems
  > like a very small thing.  And it'd allow people to implement having

I think it is asking for trouble to make `read' extensible, because
then people will extend it in different, incompatible ways.  That is
asking for trouble.

Uniformity is what we need here.  If we want to handle some additional
read syntax, we should implement it in the C code so that it works the
same for everyone.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#24982; Package emacs. (Sat, 30 Apr 2022 17:02:01 GMT) Full text and rfc822 format available.

Message #56 received at 24982 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Richard Stallman <rms <at> gnu.org>
Cc: 24982 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, drew.adams <at> oracle.com
Subject: Re: bug#24982: 24.5; way to let Elisp reader ignore unreadable
 #(...) constructs
Date: Sat, 30 Apr 2022 19:01:16 +0200
Richard Stallman <rms <at> gnu.org> writes:

> I think it is asking for trouble to make `read' extensible, because
> then people will extend it in different, incompatible ways.  That is
> asking for trouble.
>
> Uniformity is what we need here.  If we want to handle some additional
> read syntax, we should implement it in the C code so that it works the
> same for everyone.

So there doesn't seem to be much enthusiasm for adding this to Emacs,
and I'm therefore closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Added tag(s) wontfix. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Sat, 30 Apr 2022 17:02:02 GMT) Full text and rfc822 format available.

bug closed, send any further explanations to 24982 <at> debbugs.gnu.org and Drew Adams <drew.adams <at> oracle.com> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Sat, 30 Apr 2022 17:02:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#24982; Package emacs. (Sat, 30 Apr 2022 17:27:01 GMT) Full text and rfc822 format available.

Message #63 received at 24982 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Richard Stallman <rms <at> gnu.org>
Cc: "24982 <at> debbugs.gnu.org" <24982 <at> debbugs.gnu.org>,
 "monnier <at> iro.umontreal.ca" <monnier <at> iro.umontreal.ca>
Subject: RE: [External] : Re: bug#24982: 24.5; way to let Elisp reader ignore
 unreadable #(...) constructs
Date: Sat, 30 Apr 2022 17:26:42 +0000
> > I think it is asking for trouble to make `read' extensible, because
> > then people will extend it in different, incompatible ways.  That is
> > asking for trouble.
> >
> > Uniformity is what we need here.  If we want to handle some
> additional
> > read syntax, we should implement it in the C code so that it works
> the
> > same for everyone.
> 
> So there doesn't seem to be much enthusiasm for adding this to Emacs,
> and I'm therefore closing this bug report.

It seems you went off and dreamed up your own
substitute for the actual bug report and request.

Your reply here only to RMS's reply to your
detour shows that.  You're in effect closing your
own imaginary bug report, but with the unfortunate
side effect of closing this request as well.
___

Don't get me wrong; I assume the hijacking was
unintentional, from misunderstanding, not from
any desire to divert.

But coming back to what this request was actually
about, and to where you hijacked it to take the
detour:

>>> Provide a Boolean variable or a wrapper macro
>>> that has the effect of not raising an error
>>> but just skipping over any unreadable #(...)
>>> construct.

That's the request.

>> I assume you mean #<...> here?
>
> No.  I meant #(...).  I wrote that twice.
>
> But if you like you could extend this request
> to some other - or to ALL - # reader syntax.

With that last sentence I guess I unfortunately
encouraged you to ignore the preceding sentence,
where I said NO, that's not what this is about.

The request is _not_ about extending the reader
in any general way, though (unlike RMS) I'm not
against Elisp considering doing that (the devil
would be in the details).

The request is only about what is written above:
give users and code a way to, in effect,
`ignore-errors' for unreadable #(...).  Only that.

[It's not about `ignore-errors'; I mention that
as an analogy: we provide ways to ignore errors,
but not this kind of (reader) error.]




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sun, 29 May 2022 11:24:06 GMT) Full text and rfc822 format available.

This bug report was last modified 1 year and 305 days ago.

Previous Next


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