Re: Imports / inclusion of s.el into Emacs

[Philippe Vaucher <philippe.vaucher@gmail.com>]

> > You understand that substring completion fails as soon as the term is
> > too generic? e.g "string", "regexp" or "list", the list is just a lot
> > of noise.
>
> Have you actually tried Drew's suggestion? Starts an Emacs -Q and (setq
> completion-styles '(flex)), or just M-x fido-mode.  Then C-h f for
> "string".  You get a _little_ noise but it's not "a lot", by far.  And
> the little noise you _do_ get from internal functions in other packages
> is pretty easy to remove if you boost things by their mentions in the
> manual.  In fact there's a patch at the end of this message.

I must admit I'm a bit of an extremist here, because even when trying
this the little noise annoys me. Also the noise is bigger with
"regexp". But I understand this solution seems good enough from your
perspective.

> > Also it doesn't quite work when the order is "reversed", e.g> C-h f
> > "string TAB multibyte" would not return the desired function
> > because it has to be "multibyte TAB string".
>
> But that's never going to work either way, unless you alias all the
> multi-word symbols to all their possible permutations.  You'll always
> get a group of people that really expected it to be multibyte-string and
> group of people that expect string-multibyte.

I think "all in string-" or "all in string- or multibyte-" would work
for me. Sure, the first time you try to find "multibyte" in in
"string-" you fail but you rapidly know that from now only multibyte
starts with multibyte. For example your list I'd do:

multibyte-string-p -> multibyte-string-p
string-to-multibyte -> multibyte-from-string
string-as-multibyte -> multibyte-from-string-unsafe
set-buffer-multibyte -> buffer-set-multibyte
multibyte-char-to-unibyte -> multibyte-char-to-unibyte

> To be clear.  I'm not presenting these examples to be antagonistic.  I'm
> kind of sympathetic to your laziness to read the manuals, I'm lazy
> myself, a reasonably good trait in programmers.  So I really do use
> these tools (and work on them) to get around an imperfect world instead
> of demanding that the world adjust to my rigid way of thinking.

I agree you have a point. But even without renaming as much as I
suggest, I think renaming the functions that does not follow the
"standard" of Emacs Lisp should be done (once it is defined). It's
much easier for the brain to think in terms of patterns, even if they
are not as straight forward as namespaces they should at least be
consistent.


> That said, it is possible to devise a completion style that will take
> two words and match them against candidates in different ways, maybe
> even matching them against other properties besides their names.  I
> haven't found it really useful, yet.  But it's not absurd to think about
> that and writing a smart completion style for Emacs is a much better
> (and more interesting) contribution to it than the renaming
> sledgehammer.

Yes, personally I'd be more enclined toward the proposal of grouping
functions according to
https://www.gnu.org/software/emacs/manual/html_node/elisp/index.html,
this should be fairly easy to implement.