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

[João Távora]

Eli Zaretskii <eliz@gnu.org> writes:

>> The system is behaving as designed.
> Famous last words ;-)

:-)

> Seriously, though: IME, this is not a popular response to user
> requests.

I understand, I really do.  But it's true: the system is behaving as
designed.

That surely doesn't mean one can't design it differently, or augment it
in the direction of those user requests.

It _is_ possible (I hope I left that clear).  I just don't think it is a
good idea, for the reasons I tried to explain.

My intuition is that people that are making this request aren't
imagining how it would behave if you had two files in your Emacs session
(or even across different sessions).

   read-symbol-shorthands: (("s-" . "magnar-string-"))

And another had:

   read-symbol-shorthands: (("s-" . "joes-system-"))

It is my belief that this would bring some level of confusion.  The user
would have to consider very well the locus of her 'C-h o' request.  I
don't usually do that, not for functions at least (for variables, yes,
to a certain extent).

>> In the sequence C-h o s-foo, the last 5 characters typed are not the
>> name of a symbol, they are the name of a shorthand (a shorthand is _not_
>> a symbol) that you are seeing (in the sense of "with your eyes"") in
>> some buffer.
>
> If it is impossible, or hard, or inappropriate (in your opinion) to
> support s-foo in this use case, would it be possible to have a special
> command that would expand the shorthand in the minibuffer?  That is,
> the user types "C-h o s-foo <SOME KEY SEQUENCE>" and that replaces
> s-foo with the expansion, the "real" symbol.  Is that feasible?

When using some "completion styles" (which see), the completion system
already does that, to a large extent.  The 'flex' completion style, for
example, would do that: it is quite likely that 's-foo' would expand to
'magnar-string-foo'.

Note, however, that that expansion is based on the simple string
relation between 's-foo' and 'magnar-string-foo', where the former is a
subsequence of the latter.  If the shorthand were:

  read-symbol-shorthands: (("x-" . "magnar-string-"))

then, 'x-foo' would _not_ expand to 'magnars-string-foo' using the
'flex' completion style.

If you nevertheless wish that 'x-foo' expand to 'magnars-string-foo'
BECAUSE you invoked 'C-h o' from a buffer where those shorthands are
setup, then you are again creating some locality in the 'C-h o'
interface.  But I presume you are prepared to accept that.

So, it _is_ possible to code that.  Perhaps using a buffer-local
completion-style.  At first sight, this new idea of yours is more
elegant than the first request, because it expresses the true vehicular
nature of shorthands much more accurately.  It also seems simpler to
implement, at first sight.  With heavy emphasis on the two "at first
sight"s ;-).

>> * So, if we follow our first instincts (they were my first instincts,
>>   too!), it means that the exact same Help input in two different
>>   situations could bring about different results.
>
> That already happens in any number of situations, and shouldn't
> prevent us from adding one more.  The most trivial example is
> buffer-local variables; another example is mode-specific commands (a
> recent addition in Emacs 28).  

Interesting, I wasn't aware of mode-specific commands.  Can you give one
example of one or two commands specific to a mode?  Does it mean that
the listing itself, i.e. the collection of completions of given by 'C-h
x' is different according to the buffer?

> And there are many more: a user who expects identical Emacs behaviors
> in different buffers will be extremely disappointed.

In what regards _listing_ of symbols brought about by C-h o, C-h f and
C-h x, etc, I will be one of these "disappointed" users.  I'm OK with
seeing the final product of my C-h v request say that 'foo' 's value is
42 in the buffer 'bar.el', because it's so very clearly spelled out
there.  But I'd find it odd not to see a variable, function or anything
listed there at all.

Anyway "disappointed", doesn't mean "extremely disappointed" because
being a catastrophist about such things isn't really my thing.  If this
is the direction where you and others envision Emacs going, I'm on
board!

João