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

[Phil Sainty]

On 2021-09-29 08:29, Eli Zaretskii wrote:
> I'm not aware of any plans to use shorthands in Emacs itself.

No doubt; but that doesn't prevent people using them in
libraries which are subsequently proposed for contribution to
Emacs or ELPA.

Personally I think this feature is detrimental to the ecosystem
at large, but even for Emacs itself I think it represents a
problem waiting to happen in one form or another.


Having caught up with the "s.el" issue, I've come to realise
that there are two *radically* different ideas being discussed
here, and I'd love to see the two issues separated.


The first use-case is to do with the "s" library, and finding
a way to rename all of that code with a longer prefix without
requiring other libraries currently requiring "s" to change
much.  I'm still dubious that this is worth doing; but I must
acknowledge that if it *is* to be supported, then it does indeed
mean providing some way to translate "s-" symbols to their
longer names.

This use-case is an extremely limited one, targeted (AFAIU) at
an *extremely* small number of libraries; so the impact is quite
limited.

However I think some people may be expecting that this is also
the *primary* use-case and that the feature probably won't be
used much otherwise, and I'm predicting that this will not turn
out to be the case.


The second use-case, and the one I think will prove to be FAR
more common if this goes ahead, is this: Some people simply want
to read and write shorter symbol names in their code.

João has certainly confirmed that this is an intended personal
use, and I'm confident that many, many other authors will find
the notion of short symbols to be appealing, because long
symbols can be a surface-level irritant.

I suspect that people who are already used to programming in
object-oriented (especially) languages with all manner of
obfuscated and duplicate naming going on will commonly consider
that short names in elisp would be nicer, and will see this as
the officially-blessed way to write code with short names, and
very soon there will be a lot of elisp in the wild which is
(ab)using shorthands just so that the authors of that code can
read and write shorter names.

Alan's examples will probably be real -- people will put all
kinds of shorthand declarations into their third-party code,
including shorthands for core features, just because they can,
and because it's an officially-supported feature.


The first ("s.el") use-case would seem to require something like
the current shorthands feature.

The second absolutely does not, and I wish that shorthands would
not be used for that.

The goal of the second use-case is purely about the authoring
experience -- reading and writing short symbols -- and Emacs
could facilitate that *without* creating discrepancies between
the source code and the actual symbol names.

Instead, we would need two things:

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

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

This gives the author the things they wanted, without the need
for any read-time renaming at all.  The user gets what they
want, and no one else suffers any problems at all.

This feature would be opt-in for anyone who wished to use it,
and could then be controlled in much the same way as the
shorthand feature, with a variable mapping short prefixes to
the associated real prefixes.

The benefits of this approach over shorthand symbols are immense:

1. First and very much foremost it *doesn't break anything else*
   because the actual code contains the real symbol names.

2. Users who enable the feature can retrospectively apply it to
   their code without editing the existing code -- by adding the
   abbreviation spec, any existing code can be redisplayed using
   the new abbreviation without anything being edited.

3. Users could even change which abbreviation they personally
   use/prefer and revert the buffer, and the display would
   change to match.  People could use their own configurations
   which were different to the author's and no one is stepping
   on anyone else's toes.

4. Users could even configure these things globally if they
   wished to -- it's fine, because it doesn't affect the actual
   code, or what other people see.

5. If the abbreviated text is a display-only effect, copying and
   pasting for other people will produce the real working code
   with the actual symbols.

I see one negative: If lines lengths were based on the author's
short symbols, then the actual lines may be longer than 80 cols
even if the author sees them as <= 80.  This would only be an
issue for third-party code, though (I'm sure it's already the
case that someone contributing patches with excessively-long
lines would be asked to reformat that code).  In any case, by
comparison with breaking standard tools, I feel that a few
formatting issues should be fairly inconsequential.


I'm sure there would be fiddly elements in implementing what
I've described, but it's a problem with a confined scope;
whereas making every other tool and feature suddenly know how to
seamlessly cope with shorthand symbols (notwithstanding that I
don't think it's possible to even do so in many cases) is a
problem with a very wide scope and overall likely to be much
more difficult.


-Phil