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

[Stefan Kangas]

Phil Sainty <psainty@orcon.net.nz> writes:

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

This idea strikes me as better than what shorthand provides.  On
paper, at least.

The benefit of nameless is that I don't need to read the package name.
With the above I a) would not need to type the full package name, b)
could do this for any external package I want, c) could configure
which abbreviations are used.  Basically this takes the best of
shorthands and nameless, and combines it in a way that will give us
all benefits of shorthands without affecting 'read' or Emacs Lisp on a
fundamental level.  It removes the main reason to use dash.el or s.el,
which is their short prefixes.

The more we discuss this, the more misgivings I have about shorthands.
Something like what is described above could be a serious contender to
shorthands, but we unfortunately do not have time to explore that or
any other option given that shorthands is already going in so close to
the release of Emacs 28.  For now, it is just an idea of course, but
shorthands was also mostly an idea until this week (at least
publicly).

On a separate note, but related to my misgivings:  If this really is
mostly about s.el, dash.el and f.el, I think it is problem that this
is featured so prominently in the ELisp manual.  To my eyes, what we
have now is basically an implicit recommendation and a statement that
it is unproblematic for general use.  I believe there is a clear risk
that users will use this feature in ways that many of us AFAIU (from
reading this thread) would expressly rather avoid.

Finally, I think the existence of shorthands, and the work it will
cause in all of our tools, workflows, etc. means that people will be
more reluctant to accept proper namespacing later.  "Why do you need
that, just use shorthands", or "shorthands caused X, Y and Z to break
and now you want to break everything all over again".  In other words,
as a person who strongly disagrees with the namespace critics, I worry
that shorthands will stand in the way of something more proper.

Just my two cents.