Re: Abbrevs for the most frequent elisp symbols

[Robert Thorpe]

There are lots of types of completion in Emacs.  It's interesting to
think about them all together.

For minibuffer selections there's Emacs' default completion with TAB.
Then there are all the relations: Ido, Helm, Icomplete, Iswitchb and
probably many more I don't know.  Those use TAB or RET to complete or do
it automatically.  The completion candidates are generally automatically
generated from available options.

For normal buffers there's abbrev which works automatically as the user
types.  That's from a manually choosen set of candidates, unless the
user generates one with elisp as the OP did.

Most of the other systems use a keybinding.  There's dynamic abbrevs
(M-/) which use candidates generated from open buffers.  There's
dynamic-completion-mode (C-RET) which uses the history of the user's
typing (thanks Drew).  Then there's M-TAB (or M-C-i) which uses
knowledge of the language; e.g. parsed data from Semantic, a tags
table or, for text, a spelling database.

Then there's Company.  I've never used that, but I've been meaning to
for ages.  I understand it's a half-way-house, it puts completion
candidates on screen but a key is required to choose one, like
the minibuffer completion systems.  It can use nearly anything to
provide the completion.

Company provides a particular "front-end" and many "back-ends".  The
other systems I mention are both front-end and back-end.  Ideally, for
completion in normal buffers, it would be possible to plug any back-end
into Abbrev.  So, abbrevs could be built from dabbrev's text from other
buffers, Semantic's data from the parse-tree or something else.

(I don't think the same would be useful for the other way around.  It's
not much of a problem having M-/, C-RET and M-TAB.  They could be united
with hippie-expand if anyone wanted to.)

BR,
Robert Thorpe

Artur Malabarba <bruce.connor.am@gmail.com> writes:

> company comes with a backend that matches the initials of defined symbols,
> the only difference is that you have to type the hyphens, so a modification
> of that backend would be a viable approach for this menu that's being
> suggested.
> That seems like a worthy addition to company-mode for me.
>
> Still, I think that should be something separate from this system that's
> being discussed. When there are collisions, I prefer to use the most common
> option than to pop-up a completions menu. That's how my setup works right
> now, it's part of what makes it fast and it feels awesome. :-)
> Besides, I feel Emacs has enough options when it comes to completions, and
> I'd rather this not be Yet Another One.
>
> Maybe SPC could trigger the most common expansion (a la abbrev) and TAB
> could trigger the completions menu (a la company).
>
>
> 2014-12-31 7:50 GMT-02:00 Tom <adatgyujto@gmail.com>:
>
>> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> >
>> > If you use the `initials' completion style, "wcb" will match
>> > "with-current-buffer" (along with various others), so if we add a good
>> > sorting based on known usage frequency (as suggested by the OP), the
>> > cycling completion will behave very similarly to his abbrevs.
>>
>> I wonder if it is possible to combine abbrevs with completion.
>>
>> I feel the most convenient completion is abbrevs, because then you
>> don't have to press anything to complete, it just happens. But
>> if we use initials then there can be collisions.
>>
>> What if we could use initial-abbrevs to type lisp symbols, but when
>> there is more possible completions for the abbrev (e.g. if there is an
>> other  completion for wcb than with-current-buffer) then at
>> abbrev expansion it would pop up a completion menu like company, etc.
>> so right below the  line) with the possible completions sorted by
>> frequency with the most frequent at the top.
>>
>> This would be the most convenient solution, because then you could
>> just type initials and completions would pop up without pressing
>> anything, or if there is no collision then it would expand
>> immediately like any other abbrev.
>>
>>
>>