bug#24982: 24.5; way to let Elisp reader ignore unreadable #(...) constructs

[Drew Adams]

> > 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.]