[Top][All Lists]

[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: Sat, 02 Oct 2021 01:24:22 +1300
User-agent: Orcon Webmail

On 2021-10-01 19:09, Eli Zaretskii wrote:
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.

Major usability issues caused by things not being what they appear
to be?  Not to put too finer point on it, but that is precisely what
this thread has been about from the beginning.

You can't do any of these things without causing problems.  The notion
of not using real symbol names is a problem by definition.  I'm merely
suggesting that the problems created by the 'nameless' style of "the
code is not what it appears to be" are not nearly as bad as the
problems caused by the 'shorthands' style of "the code is not what it
appears to be".

The particular issue of not being able to identify things using the
names that you see is (amongst the other issues which have been
discussed) precisely what people will face when looking at any code
where shorthands are in effect (at minimum code using s.el).  At least
with the 'nameless' approach every user who sees the short names has
opted in and is aware in advance that things are not how they appear.

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!

I absolutely agree that you are not responsible for irresponsible acts
of others, but I don't think it was at all unreasonable to raise these

I do believe that I've failed to convince you on the subject of
shorthands, however, so I shall hope that documentation dissuading
people from misusing the feature will prove sufficient for avoiding
very many such cases.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]