bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#45333: complex command history should not save optional nil paramete


From: Lars Ingebrigtsen
Subject: bug#45333: complex command history should not save optional nil parameters
Date: Thu, 07 Jul 2022 09:29:22 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I can't think of any reason we'd ever want to use that function anywhere
> near performance critical code, so I'd rather keep it in ELisp if
> possible.

I think it'd be nice to have eldoc generate less garbage, though.

> OClosure or not doesn't make much of a difference here, I think (the
> previous version of the code would also be quite hideous in C).
> Why not just call `advice--cd*r`?

Sure, that's possible, but just seems a bit backwards.

Anyway, looking at the functionality in this area, things just seem a
bit messy overall, and I wonder whether there's any scope here for
making things better.

For instance, this code:

(help-function-arglist 'car t)
=> (list)

What it does is call `documentation', find the "(fn LIST)" at the end,
do a `downcase' and `read-from-string' which seems to suggest that
upcasing the arguments in the first place before putting them into
etc/DOC was the wrong thing to do.  Not only do we lose the
capitalisation -- if the argument was really `List', that's lost.
(Perhaps fortunately, some might say -- we don't really use case much in
symbols in Emacs Lisp.)

Moreover, looking at the code in make-docfile, it seems to be upcasing
wrong, so if the argument had been `lïst', we'd put (fn LïST) into
etc/DOC.  (And again, it doesn't really matter that much, because we
don't really use anything but ASCII.)

And even more moreover, if the doc string had (fn [FOO]),
`help-function-arglist' would just ignore that and return (arg1), but if
it has (fn foo bar zot), it'll return (foo bar zot).

(Some of the same issues are with doc strings/arg lists in .elc files.)

So two issues:

1) If we have an advertised calling convention, the original arg list can't
be recoved.  2) We can't recover the original case of the arguments at
all.  (Except for lambda/closure forms.)

For 2), I think we could stop upcasing arguments and adjust callers --
but old .elc files would still have upcased arguments until recompiled.

For 1), we could also stash the actual arglist in addition to the
advertised calling convention into .elc/DOC (i.e., two (fn ...) forms,
for instance).

We could then have

  (function-arglist FUNC &optional ADVERTISED)

that would return either form.

(And there's also `advertised-signature-table', which perhaps we could
then get rid of?)

Of course, I don't really know whether it's worth doing anything about
any of this -- but it just seems a bit messy at the moment, and not very
satisfactory.

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]