Re: Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master)

[Phil Sainty]

On 2021-10-01 03:12, Eli Zaretskii wrote:
> > This use-case is an extremely limited one, targeted (AFAIU)
> > at an *extremely* small number of libraries; so the impact is
> > quite limited.
>
> The problem is not with the number of libraries, the problem
> is with the libraries that _use_ those few.  They are a lot.

When I say "the impact is quite limited" I mean that the total
number of symbol names which are being obfuscated is not large
if we're only using this to support "s.el" (and maybe a tiny
number of similar cases), because the obfuscated symbols are
always the same limited set.

The *negative* impact of shorthands is limited iff the use of
shorthands is limited to targeting a small number of problem
libraries.


> > 1. A way of displaying long symbols in the desired short
> >     form, such that the buffer contains the actual symbol,
> >     but the user sees the short symbol (i.e. some kind of
> >     replacing display).
>
> I very much doubt that display-time feature can solve this,
> because it will not be supported by Lisp itself.  And then you
> have worse problems.

We are now talking about the second use-case, which has nothing
to do with "s.el" (and which I'm proposing should have nothing
to do with 'shorthands').

In this scenario the files that lisp reads will always contain
the real symbols, so no extra lisp support is required.  The
lisp reader never sees the short names (and nor does any person
who has not opted in), because they don't actually exist in the
file.

This use case is purely about enabling the people who opt in to
type and see their short names when editing the source code, but
with the real/longer names being the actual text.


> > 2. Something analogous to abbrev which recognises when
> >     someone starts typing a symbol with one of the configured
> >     short prefixes, and expands it to be the full name (but
> >     per (1) visually displayed as the short form that they
> >     typed).
>
> Are you thinking about M-/ ?  That already exists, and I'm
> using it all the time, not only in Lisp.  Long identifiers are
> ubiquitous these days, and long words in human-readable text
> are as well.

No, I'm talking about a feature (possibly already implemented by
the "nameless" library; I still need to experiment with this)
whereby people would be able to type their short symbols when
editing their source code and Emacs would recognise the
abbreviation and *automatically* (hence more like abbrev than
dabbrev) change it to the real name.


> I really don't understand why you and Alan (and others) are so
> worried.

I'd be less worried if the release which includes shorthands
(if it's retained) *also* includes "nameless" or something
similar in order to provide for the inevitable second use-case
in a way which doesn't break anything.

We might not allow any shorthand code in Emacs itself, but if
shorthands are understood to be the in-built solution for
reading and writing short names then all kinds of third-party
code is going to start doing exactly that.  A very large
proportion (I would assume a majority) of Emacs users will be
using third-party code in their configs, and hence many of
them/us will inevitably acquire shorthand code in our configs
even if it is not core Emacs code or "s.el"; and the more such
code that emerges, the more problems people will have.

This will affect people debugging their own configs; people
sharing code with other people; people submitting bug reports
or help requests here on the mailing lists and elsewhere.
Whether it's something they can't figure out, or a frustrating
stumbling block that they do figure out, I think it's going
to create a lot of unnecessary problems.

I'm saying that code which does not contain shorthand symbols
is *easier* (on average, for the Emacs user base as a whole)
to deal with than code which does contain shorthand symbols,
and so let's not bless shorthands (even tacitly) as the
standard solution for anything which can be done in other ways.


-Phil