[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A short defense of shorthands.el (but CL packages are still better)
From: |
Richard Stallman |
Subject: |
Re: A short defense of shorthands.el (but CL packages are still better) |
Date: |
Tue, 08 Nov 2022 00:02:38 -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. ]]]
> You would see, in the Emacs echo area line, the indication
> xenomorph-foo: (POINT)
> every time point is over a reference to the function x-foo.
Is that behavior bar? What behavior would we prefer ElDoc to
implememt for such cases? Would we want it to show `x-foo' instead of
`xenomorph-foo' in the echo area?,
How does ElDoc know to apply the shorthands for x.el when looking at
the text of x.el? Does ElDoc have code to do this explicitly?
> > Maybe you're right about C-h f, but you have not specified the
> > scenario fully. What does the user actually type, to invoke it?
> Type this:
> C-h f x e n o TAB RET
> This will most likely lead to a *Help* buffer displaying xenomorph-foo's
> docstring.
That seems correct to me. `xenomorph-foo' is a defined function; why
shouldn't C-h f know about it?
> way you invoke the interactive function defined above is
> M-x xenomorph-foo RET
> _not_
> M-x x-foo
That too seems correct to me.
When I consider the case of `string.el', which would rename s-* to
string-*, these all seem like correct behavior (though M-x won't allow
these functions under any name, since they are not interactive).
> And if the function ever signals an error, and you have the debugger
> activated, then this is what shows up in the Backtrace:
> Debugger entered--Lisp error: (error "ohno")
> signal(error ("ohno"))
> error("ohno")
> xenomorph-foo(104)
> funcall-interactively(xenomorph-foo 104)
I think that is correct, too. It might be confusing
if you are looking at the source of x.el and you don't
notice it uses a shorthand. Nonetheless, it is correct.
--
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)
- Re: Help sought understanding shorthands wrt modules/packages, João Távora, 2022/11/02
- Re: Help sought understanding shorthands wrt modules/packages, Gerd Möllmann, 2022/11/03
- A short defense of shorthands.el (but CL packages are still better) (Was: Help sought understanding shorthands wrt modules/packages), João Távora, 2022/11/03
- Re: A short defense of shorthands.el (but CL packages are still better) (Was: Help sought understanding shorthands wrt modules/packages), Richard Stallman, 2022/11/03
- Re: A short defense of shorthands.el (but CL packages are still better), João Távora, 2022/11/04
- Re: A short defense of shorthands.el (but CL packages are still better), Richard Stallman, 2022/11/07
- Re: A short defense of shorthands.el (but CL packages are still better), João Távora, 2022/11/07
- Re: A short defense of shorthands.el (but CL packages are still better),
Richard Stallman <=
- Re: A short defense of shorthands.el (but CL packages are still better), João Távora, 2022/11/08
Re: Help sought understanding shorthands wrt modules/packages, Richard Stallman, 2022/11/04
Re: Help sought understanding shorthands wrt modules/packages, Richard Stallman, 2022/11/08
Re: Help sought understanding shorthands wrt modules/packages, Yuri Khan, 2022/11/09
Re: Help sought understanding shorthands wrt modules/packages, tomas, 2022/11/09
Re: Help sought understanding shorthands wrt modules/packages, Matt Armstrong, 2022/11/09