Re: A read-based grep-like for symbols (el-search?) (was Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master))

[Adam Porter]

Dmitry Gutov <dgutov@yandex.ru> writes:

> If we moved the declaration of the package prefix from the referring
> file (at the bottom) to the defining file, or just always said that
> the prefix must match the package name, this would make this
> possible. At the cost of some flexibility, of course, but I'm not sure
> who really needs that.
>
> Taking the example from the manual, the clients would be able to write
>
> ;; elisp-shorthands: (("snu" . "some-nice-string-utils"))
>
> but not
>
> ;; elisp-shorthands: (("sn" . "some-nice"))
>
>
> and that doesn't sound like a terrible limitation.

Maybe I misunderstood you, but having packages declare their own symbol
shorthands doesn't seem practical to me.  For example, if
"some-nice-utils.el" declared its shorthand to be "snu-", that would
conflict with a package "snu.el".  It would seem to make the existing
single-namespace problem worse by allowing packages to claim more of the
namespace, similar to "domain squatting."