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

[Stefan Monnier]

>> I consider this as an abuse of the notion of completion style (which
>> are supposed to be orthogonal to the actual completion data), so I'd
>> strongly recommend not to use this patch.
>
> What do you mean a style being orthogonal to the completion data?

Completion styles are supposed to work meaningfully with "any"
completion table.  Some completion styles make more sense with some
tables than others, admittely (and some like the `backend` completion
style only do something useful with those completion tables setup to
take advantage of it), but the completion styles should be agnostic to
where the completion candidates come from (that's the job of completion
tables), and so far that's been true of all completion styles.

> A substring style will complete "oo" to "foobar" because it knows that
> "oo" belongs in "foobar" according to the notion of substring, and
> likewise flex will complete "fb" to "foobar" because that belonging is
> also there, according to a certain "flex" notion.

Right.  And your completion style uses `read-symbol-shorthands` as
a "style", but it makes no sense to apply `read-symbol-shorthands` to
something else than symbol names, so it can only ever be used for the
completion table which returns symbol names.

> So the "shorthand" style makes "x-bar" complete to "string-library-foo"
> according to a certain notion of abbreviation based on "shorthands".

Yes, and I can accept this principle, but it should not be tied to
a specific source of candidates (symbol names, in this case).

> How is this not "orthogonal to the data".

Does the above answer the question?

>> I could agree to the use of a new completion-style for it, but then the
>> code of the completion style should not be specific to
>> `read-symbol-shorthands`.  Instead it should offer a generic feature
>> usable by other completion tables (and the part specific to
>> `read-symbol-shorthands` would be in the completion table of `C-x o`
>> rather than in the completion style code).
> In practice, does this change anything in terms of behavior?

I don't think so.

> If not, then I suggest we push that patch and then augment it with this
> generalization, in case we do really come to the conclusion that this
> more generic scheme really is useful.

I find the current patch to be a hideous kludge completely subverting
the design, so I'd rather you fix the code first.  It doesn't have to be
difficult.  A bit like with the `backend` completion, you can just make
the `shorthand` style call the completion-table to do the
actual expansion, and thus move the part of the code specific to
`read-symbol-shorthands` to where it belongs (the completion table).

> Obviously you disagree.  So if your suggestion is to make a an "abbrev"
> completion style which consults the table for the specific source of
> abbreviations (which happens to be read-symbol-shorthands in the case of
> help--symbol-completion-table),

That's right.

> than I have no strong points against, in principle.  It's a question
> of adding something else to the metadata I think.

Indeed you can also put the info in the metadata for the `shorthand`
style to use it (instead of calling the completion table with another
argument).

> But isn't this a bit of overengineering?

No, it's just trying to keep the abstraction-breakage to a tolerable level.

> And can't it be left for 'master', as it's kind of a new feature?

I see no need to push any of this to `emacs-28`, so all my
recommendations are for `master` here.

On my end, I intend to implement what I consider is the "proper"
behavior, presumably making it conditional on some user config since you
seem to consider it strongly undesirable whereas I tend to consider it
strongly "The Right Thing".


        Stefan