[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs
From: |
João Távora |
Subject: |
bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs |
Date: |
Sat, 02 Oct 2021 12:54:13 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (gnu/linux) |
João Távora <joaotavora@gmail.com> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>> Would it be possible to see if the current buffer (from which the
>> minibuffer was entered) has shorthands, and if so, apply them to
>> minibuffer input?
>
> Yes, much like it is done with C-M-i, basically.
Let me improve on that. That it _can_ be done doesn't mean that it
_should_ be done, but we can decide on that. There are various levels
to this integration:
0. no integration
1. This is the current integration. I.e. when C-h o is pressed on the
symbol the global name is discovered and used as the default. This
is how SLIME work with CL's namespacing system. SLIME is a very well
tested and widely appreciated Common Lisp IDE for Emcas.
2. The shorthands from the buffer where the minibuffer was entered are
_not_ in the completions list, but typing one of them interns the
symbol with those shorthands present, so you get the desired result.
This would fix Phil's visually-copy-and-type scenario.
3. (Eli's suggestion): the completion list would be augmented with the
shorthands from the buffer where the minibuffer was entered from.
In levels 2 and 3 the user might be surprised that what once worked for
one 'C-h o' session no longer works for another 'C-h o' session. The
only way I can see this being acceptable is if the user is somehow made
aware -- visually or otherwise -- that the list she is seeing is somehow
connected to the origin buffer.
In contrast, C-M-i (where level 3 happens) never really leaves the
buffer: its results are connected to it because they will be inserted
there.
João
- bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs, Phil Sainty, 2021/10/02
- bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs, Eli Zaretskii, 2021/10/02
- bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs, João Távora, 2021/10/02
- bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs, Eli Zaretskii, 2021/10/02
- bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs, João Távora, 2021/10/02
- bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs,
João Távora <=
- bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs, Eli Zaretskii, 2021/10/02
- bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs, João Távora, 2021/10/02
- bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs, Eli Zaretskii, 2021/10/02
- bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs, João Távora, 2021/10/02
- bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs, Eli Zaretskii, 2021/10/02
- bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs, João Távora, 2021/10/02
- bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs, Eli Zaretskii, 2021/10/02
- bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs, João Távora, 2021/10/02
- bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs, Eli Zaretskii, 2021/10/02
- bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs, João Távora, 2021/10/02