bug#50959: [PATCH] Re: bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs

[João Távora]

João Távora <joaotavora@gmail.com> writes:

> João Távora <joaotavora@gmail.com> writes:
>
>> On Sat, Oct 2, 2021 at 1:30 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
>>> > 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. The completion list would be augmented with the shorthands from
>>> >    the buffer where the minibuffer was entered from.
>
> Hello Eli,
>
> I've implemented a variation on 2 based on the later suggestion you
> gave in emacs-devel:
>
>> 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?
>
> Yes, it is.  <SOME KEY SEQUENCE> is, of course, TAB.  Here is a patch
> for people to try out which I will push in a few days time if there are
> no objections.  Cc-ing completion-style specialist Stefan.
>
> Patch just below,

I've stashed this patch in branch scratch/bug-50959-fix.

The reason is Stefan's strong objections to it.

IIUC, Stefan, who originally designed the completion-style mechanism
would seem to favour a scheme where a new completion table category
'symbol' is linked to a new 'abbrev' style (instead of a 'shorthand'
style).  The 'abbrev' style would then query the table for an
appropriate source of abbreviations, which, in the case of table of the
'symbol' category, would be extracted from 'read-symbol-shorthands'.
Stefan do you confirm this?

If so, the end result would be the same and a functional level, and
Phil's original request would be satisfied.  I don't strongly object to
the above more complex approach, but I don't have much time right now to
implement those extra indirections either (not that they're rocket
science, but they need at least good formats, good names, good
docstrings, etc.), so I'll leave it up to you guys to figure out what to
do here.

João