[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorth
From: |
Phil Sainty |
Subject: |
Re: Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master) |
Date: |
Fri, 01 Oct 2021 01:23:48 +1300 |
User-agent: |
Orcon Webmail |
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
- Re: Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master), (continued)
- Re: Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master), Alan Mackenzie, 2021/09/28
- Re: Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master), Eli Zaretskii, 2021/09/28
- Re: Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master), Alan Mackenzie, 2021/09/28
- Re: Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master), Eli Zaretskii, 2021/09/28
- Re: Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master),
Phil Sainty <=
- Re: Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master), Gregory Heytings, 2021/09/30
- Re: Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master), Gregory Heytings, 2021/09/30
- Re: Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master), Tomas Hlavaty, 2021/09/30
- Re: Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master), João Távora, 2021/09/30
- Re: Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master), Tomas Hlavaty, 2021/09/30
- Re: Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master), Joost Kremers, 2021/09/30
- Re: Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master), Adam Porter, 2021/09/30
- Re: Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master), Stefan Kangas, 2021/09/30
- Re: Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master), Lars Ingebrigtsen, 2021/09/30
- Re: Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master), João Távora, 2021/09/30