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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 01 Oct 2021 11:50:14 +1300
> From: Phil Sainty <psainty@orcon.net.nz>
> Cc: acm@muc.de, joaotavora@gmail.com, emacs-devel@gnu.org
> 
> The *negative* impact of shorthands is limited iff the use of
> shorthands is limited to targeting a small number of problem
> libraries.

The intent is to use this only when necessary.  So yes, the use is
supposed to be limited to those few cases, at least in Emacs.

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

And I'm saying that this will be a bad solution, since many features
that identify symbols by name will not work with those "display-only"
names that the user sees.  So using something like that is a net loss
for users: it "fixes" a minor readability issue, but introduces major
usability issues.

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

We cannot control what third-party code is doing.  If you and others
don't want that to happen in third-party packages you use, the onus is
on you and others to complain to the respective developers, just like
you now (prematurely) complain here, and ask them not to abuse the
feature.

In any case, I don't understand what this has to do with Emacs:
nothing can prevent third-party packages from inventing something like
shorthands and starting to use that in their own packages.  The
existence of shorthands in Emacs core is not a sign to anyone that the
feature can be abused.  We in the Emacs project development cannot be
held responsible for irresponsible acts of others, it is highly unfair
for you and others to hold us to such a standard!

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

Sorry, not our problem.  If and when this happens, please take it up
with people responsible for making it happen.  That's not us.

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

Nothing in Emacs is "blessed" unconditionally.  Each feature has its
intended use, and those who attempt to use it outside of the intended
scope are responsible for the consequences.  I can assure you that
nothing like that will ever happen in Emacs, not on our watch.