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

[João Távora]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> 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).

But why?  What bad thing can happen if a specific style is tied to a
specific type of data?

Note _type_, not _source_ of data, which is indeed the table.  The style
can be used on any list of Lisp symbols, regardless of whether they
represent function names, variables names, non-Elisp entities, etc.
That's why this style, as many others, is tied to a category, not a
table.

If there's a mechanism for tables prefer styles via categories, and it's
useful, I don't see why it shouldn't be used.  We need a "backend"
completion style for LSP and SLY, for example, and that doesn't fit
neatly in your delicate frame at all.

> I find the current patch to be a hideous kludge completely subverting
> the design, so I'd rather you fix the code first.

Since we're going for imagery, i think it's this artificial purity which
is a bit malodorous.  

>> But isn't this a bit of overengineering?
> No, it's just trying to keep the abstraction-breakage to a tolerable
> level.

Abstractions should only be kept as long as they're useful to model
behaviour efficiently.  That's not the case with this one.  As we know,
good design is hard to use incorrectly.  So the mere fact that it was
easy to do my patch in an inteligible way and the fact that the
"cleaner" alternative is to do much of the same but with a contrived
mound of indirections is evidence that that particular abstraction that
you're idealizing is relatively weak.

But I agree with Eli, if you want to make the "abbrev" style to replace
"shorthand" (and hopefully with more real use cases than just the
shorthands) on master, I don't object.

João