Abbrevs for the most frequent elisp symbols

Abbrevs for the most frequent elisp symbols

[Tom]

The other day it occurred to me I could use simple abbrevs for
elisp programming, but defining these manually is tiresome, so
I did some automation.

1. I collected all elisp symbols from the manual

2. Generated abbrevs for those which have multiple parts in the
name from the first letters (e.g. goto-char -> gc)

3. There can be collisions (e.g. gc maps to both goto-char and
garbage-collect), so I collected the usage statistics of all
elisp symbols from the emacs lisp sources and in case of a
collision I used that one which occurs more frequently (in the
above case: goto-char).

The result is an automated abbrev table for elisp symbols based
on frequency. So, for example, you can use wcb for
with-current-buffer, bol for beginning-of-line, mb for
match-beginning, etc.

Here's the list of abbrevs, you can try it in a buffer:

http://pastebin.com/D7Lrg3WA


The idea is trivial, so probably somebody has done something like
this already, but I thought I'd share it in case someone else
finds it useful.

Re: Abbrevs for the most frequent elisp symbols

[Andreas Röhler]

On 19.12.2014 20:58, Tom wrote:
> The other day it occurred to me I could use simple abbrevs for
> elisp programming, but defining these manually is tiresome, so
> I did some automation.
>
> 1. I collected all elisp symbols from the manual
>
> 2. Generated abbrevs for those which have multiple parts in the
> name from the first letters (e.g. goto-char -> gc)
>
> 3. There can be collisions (e.g. gc maps to both goto-char and
> garbage-collect), so I collected the usage statistics of all
> elisp symbols from the emacs lisp sources and in case of a
> collision I used that one which occurs more frequently (in the
> above case: goto-char).
>
> The result is an automated abbrev table for elisp symbols based
> on frequency. So, for example, you can use wcb for
> with-current-buffer, bol for beginning-of-line, mb for
> match-beginning, etc.
>
> Here's the list of abbrevs, you can try it in a buffer:
>
> http://pastebin.com/D7Lrg3WA
>
>
> The idea is trivial, so probably somebody has done something like
> this already, but I thought I'd share it in case someone else
> finds it useful.
>
>
>
>

Interesting item, thanks!

The question is: does the occurrence inside the manual or the source provide indication WRT probability of personal usage?

As being a heavy abbrevs-user, here my collection of emacs-lisp abbrevs defined:

https://github.com/andreas-roehler/werkstatt/blob/master/teens-abbrevs.el

Andreas

Re: Abbrevs for the most frequent elisp symbols

[Emanuel Berg]

Tom <adatgyujto@gmail.com> writes:

> The other day it occurred to me I could use simple
> abbrevs for elisp programming, but defining these
> manually is tiresome, so I did some automation ...
> The idea is trivial ...

Not exactly trivial I would say, and certainly not the
implementation.

> so I collected the usage statistics of all elisp
> symbols from the emacs lisp sources

Cool: most likely there isn't a better example for how
to properly use Elisp for real software, than Emacs
and the associated software and libraries.

But even so, what if some guy is the other way around,
e.g., he prefers `garbage-collect' to `goto-char'? Is
that easily rerouted in some automatically generated
(but after that manually editable) abbrev table?

> so probably somebody has done something like this
> already

Yes: I've seen something similar but I think that was
the typing of commands after M-x, and not the whole
Elisp language when typing it in a buffer.

Personally, though I think this an interesting/cool
project, I don't have a problem typing (on the
contrary, I like it very much) and I am actually very
fond of the Elisp verbose style (compare the C style
with very short names, with "undelimited"
abbreviations and often digits and such in between and
all over) - I mean, I like C, and when I do C I do
that as well, but when I do Elisp, I really enjoy
those long this-is-a-function-that-does-something - it
isn't too slow to type as long as it is normal words
and normal chars, not
asymmetric-asynchronous-continuous-anonymous or
anything.

My second concern is that if this is abbrevs, don't
you get crazy from them expanding all the time as you
type?

But anyway, thumbs up for activity and zeal!

-- 
underground experts united

Re: Abbrevs for the most frequent elisp symbols

[Emanuel Berg]

Andreas Röhler <andreas.roehler@easy-emacs.de> writes:

> The question is: does the occurrence inside the
> manual or the source provide indication WRT
> probability of personal usage?

That would have to be done on-the-fly which would be
too slow (?) unless the person doing it could feed it
with a personal Elisp library or some sufficiently
large amount of Elisp in his prefered way to
counterweight the source learning data - it could be a
weighted measure, like if the source says 9 to 1, and
the personal code says the opposite, only in much less
quantity, the personal code would still win because it
is more likely the person who wrote that will write
something similar again.

Also, the program could simply ask at ambiguities
which the prefered one is. Then that would then be
added as a rule.

Or how about, right after expansion, one could iterate
expansions by a keystroke - e.g., like with yanking:
first do C-y (`yank'), then do M-y (`yank-pop`), and
even

    (defun yank-pop-back (&optional arg)
      (interactive "*p")
      (yank-pop (if arg (* arg -1) -1)) )

It also depends how many ambiguities there are. If
they are everywhere, whatever you do it will bite you
hard more often than anyone would like.

(Now I'm only discussing this from your perspective
because I think nothing beats typing.)

-- 
underground experts united

Re: Abbrevs for the most frequent elisp symbols

[Marcin Borkowski]

On 2014-12-19, at 20:58, Tom <adatgyujto@gmail.com> wrote:

> The idea is trivial, so probably somebody has done something like
> this already, but I thought I'd share it in case someone else
> finds it useful.

I guess so.  I would be quite surprised if Icicles (which I'm slowly
learning to use and appreciate!) couldn't do this.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Abbrevs for the most frequent elisp symbols

[Marcin Borkowski]

On 2014-12-29, at 05:21, Emanuel Berg <embe8573@student.uu.se> wrote:

> Tom <adatgyujto@gmail.com> writes:
>
>> The other day it occurred to me I could use simple
>> abbrevs for elisp programming, but defining these
>> manually is tiresome, so I did some automation ...
>> The idea is trivial ...
>
> Not exactly trivial I would say, and certainly not the
> implementation.
>
>> so I collected the usage statistics of all elisp
>> symbols from the emacs lisp sources
>
> Cool: most likely there isn't a better example for how
> to properly use Elisp for real software, than Emacs
> and the associated software and libraries.

False assumption: that Emacs libraries contain good practices only.  I
know you dislike Emacs.SE, but there was a question there about good
Elisp code to read (to learn Elisp), and someone warned about reading
Emacs code (especially older libraries).  Recently, I grepped the Emacs
Lisp sources for occurences of `mapcar', and there is *no* consistency
in e.g. using ' versus #', or quoted lambdas (which I hear are a no-no
unless in special circumstances, like macros).

> But even so, what if some guy is the other way around,
> e.g., he prefers `garbage-collect' to `goto-char'? Is
> that easily rerouted in some automatically generated
> (but after that manually editable) abbrev table?
>
>> so probably somebody has done something like this
>> already
>
> Yes: I've seen something similar but I think that was
> the typing of commands after M-x, and not the whole
> Elisp language when typing it in a buffer.

BTW: what's wrong with Yasnippet?

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Abbrevs for the most frequent elisp symbols

[Robert Thorpe]

There are the dynamic abbrevs facilities, M-\ and C-M-\.  They search
through the open buffers looking for completion candidates.  They're
included by default in hippie-expand's completers.  Personally, I prefer
that style of completion to abbrev.

You could use a similar strategy with normal abbrev though.  Load up a
set of Elisp files that are typical of your personal usage.  You could
then use the code in dabbrev-expand or dabbrev-completion to find the
completions you want.  You could wrap that in a bit of Elisp and run it
once to generate a table, then decide on the abbrevs manually or by
taking a prefix.

Martin mentions that the Emacs sources themselves contain some code
that's frowned upon these days.  That's true, there are many old parts
of Emacs.  The parts that are new are a good guide though.  There are
some peculiarities even there though, Emacs code doesn't use certain
features to avoid loading them when Emacs starts, easymenu for example.

BR,
Robert Thorpe

Re: Abbrevs for the most frequent elisp symbols

[Stefan Monnier]

> Elisp code to read (to learn Elisp), and someone warned about reading
> Emacs code (especially older libraries).

That's one person's opinion.

> Recently, I grepped the Emacs Lisp sources for occurences of `mapcar',
> and there is *no* consistency in e.g. using ' versus #',

Indeed.  But to a large extend, for quoted function names, the
difference between the two is a question of taste.  IOW there are
usually much bigger elephants to deal with before it's worth worrying
about such details.

> or quoted lambdas (which I hear are a no-no unless in special
> circumstances, like macros).

AFAIK there have been no quoted lambdas left in Emacs's own code for
quite a few years now.  There are still some backquoted lambdas which
should be converted to closures, admittedly (usually it's either
because converting those packages to lexical-binding is a bit more
tricky than usual, so it hasn't been done yet, or it's because the
conversion can't be done because the package is also distributed
outside Emacs and needs to work on Emacs<24).

>> Yes: I've seen something similar but I think that was
>> the typing of commands after M-x, and not the whole
>> Elisp language when typing it in a buffer.

That also works in Elisp buffers, actually: type "(g-c" and then M-TAB
and you'll be offered completion on all the
g<something>-c<something> functions.  It's not really the same as the
OP's abbrevs, tho, because there are *many* functions matching "(g-c".


        Stefan

Re: Abbrevs for the most frequent elisp symbols

[Marcin Borkowski]

On 2014-12-29, at 14:26, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>> Elisp code to read (to learn Elisp), and someone warned about reading
>> Emacs code (especially older libraries).
>
> That's one person's opinion.

No offence meant; Emacs is older than many people on this list
(including me), both the language and the libraries did evolve quite a
bit, and then there is the problem of manpower - no surprise some code
in Emacs is rather dated.

>> Recently, I grepped the Emacs Lisp sources for occurences of `mapcar',
>> and there is *no* consistency in e.g. using ' versus #',
>
> Indeed.  But to a large extend, for quoted function names, the
> difference between the two is a question of taste.  IOW there are
> usually much bigger elephants to deal with before it's worth worrying
> about such details.

Maybe - I just wrote about something I noticed, I don't read Emacs
sources on a daily basis (and I'm not competent enough in Elisp to
notice many things).

>> or quoted lambdas (which I hear are a no-no unless in special
>> circumstances, like macros).
>
> AFAIK there have been no quoted lambdas left in Emacs's own code for
> quite a few years now.  There are still some backquoted lambdas which
> should be converted to closures, admittedly (usually it's either
> because converting those packages to lexical-binding is a bit more
> tricky than usual, so it hasn't been done yet, or it's because the
> conversion can't be done because the package is also distributed
> outside Emacs and needs to work on Emacs<24).

I have Emacs 24.3, maybe that's the reason.

>         Stefan

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Abbrevs for the most frequent elisp symbols

[Stefan Monnier]

>> AFAIK there have been no quoted lambdas left in Emacs's own code for
>> quite a few years now.  There are still some backquoted lambdas which
>> should be converted to closures, admittedly (usually it's either
>> because converting those packages to lexical-binding is a bit more
>> tricky than usual, so it hasn't been done yet, or it's because the
>> conversion can't be done because the package is also distributed
>> outside Emacs and needs to work on Emacs<24).
> I have Emacs 24.3, maybe that's the reason.

No: "quite a few years" here means something like since before
Emacs-24.1, IIRC.  If you see a quoted lambda in Emacs's code, report it
as a bug.


        Stefan

RE: Abbrevs for the most frequent elisp symbols

[Drew Adams]

> > The idea is trivial, so probably somebody has done something like
> > this already, but I thought I'd share it in case someone else
> > finds it useful.
> 
> I guess so.  I would be quite surprised if Icicles (which I'm slowly
> learning to use and appreciate!) couldn't do this.

No, Icicles does not do anything for this by default. As Stefan
mentioned, for input to `M-x' you already get a kind of
command-name abbreviation with vanilla Emacs completion (e.g.
partial-completion).  The same holds for Icicles.

Icicles adds an ability to use custom command abbrevs (but none
are defined by default).  With this feature you can:

. treat command abbrevs the same as command names, for input
. define command abbrevs on the fly
. define a list of command abbrevs as user option
  `icicle-command-abbrev-alist'

So for example, you could customize `icicle-command-abbrev-alist'
to what the OP wants, for commands (essentially all commands).

By default, `C-x SPC' in Icicle mode is multi-command
`icicle-command-abbrev'.  It is similar to `M-x' but handles
custom command abbreviations too.  See the Icicles doc, section
"Multi `M-x' with Abbreviations: `icicle-command-abbrev'".
Doc string:

,----
| icicle-command-abbrev is an interactive compiled Lisp function in
| `icicles-cmd1.el'.
| 
| It is bound to C-x SPC.
| 
| (icicle-command-abbrev)
| 
| Read command name or its abbreviation, read command args, call command.
| Read input, then call `icicle-command-abbrev-action' to act on it.
| 
| If `icicle-add-proxy-candidates-flag' is non-nil, then command
| abbreviations, as well as commands, are available as completion
| candidates.  Otherwise, only commands are available.  You can toggle
| `icicle-add-proxy-candidates-flag' using `C-M-_'in the minibuffer.
| 
| When an abbreviation is available, you can treat it just like a
| command.  The rest of this description covers the behavior of choosing
| an abbreviation.
| 
| Completion for an abbreviation is lax.  If you enter a new
| abbreviation then it is added to option `icicle-command-abbrev-alist',
| which is the list of your known abbreviations.  You can also customize
| this list.
| 
| If an abbreviation that you enter matches a single command name then
| that command is invoked.  If it matches more than one, then you can
| use (strict) completion to choose one.
| 
| Hyphens (`-') in command names divide them into parts.  For example,
| `find-file' has two parts: `find' and `file'.  Each character of a
| command abbreviation corresponds to one part of each of the commands
| that match the abbreviation.  For example, abbreviation `ff' matches
| commands `find-file' and `focus-frame', and abbreviation `fg' matches
| `find-grep'.
| 
| If user option `icicle-command-abbrev-match-all-parts-flag' is nil
| then an abbreviation need not match all parts of a command name; it
| need match only a prefix.  For example, if nil then abbreviation `ff'
| also matches `find-file-other-window' and `fg' also matches
| `find-grep-dired'.
| 
| You can use `C-$' to toggle filtering of candidates to those that are
| bound to keys.
| 
| You can use `C-x C-a' to toggle showing key bindings as annotations.
| (Menu bindings are not shown.)
| 
| Read input, then call `icicle-command-abbrev-action'
| to act on it.
| 
| Input-candidate completion and cycling are available.  While cycling,
| these keys with prefix `C-' are active:
| 
| `C-mouse-2', `C-return' - Act on current completion candidate only
| `C-down', `C-wheel-down' - Move to next completion candidate and act
| `C-up', `C-wheel-up' - Move to previous completion candidate and act
| `C-next'  - Move to next apropos-completion candidate and act
| `C-prior' - Move to previous apropos-completion candidate and act
| `C-end'   - Move to next prefix-completion candidate and act
| `C-home'  - Move to previous prefix-completion candidate and act
| `C-!'     - Act on *all* candidates, successively (careful!)
| 
| When candidate action and cycling are combined (e.g. `C-next'), user
| option `icicle-act-before-cycle-flag' determines which occurs first.
| 
| With prefix `C-M-' instead of `C-', the same keys (`C-M-mouse-2',
| `C-M-RET', `C-M-down', and so on) provide help about candidates.
| 
| Use `mouse-2', `RET', or `S-RET' to finally choose a candidate, or
| `C-g' to quit.
| 
| This is an Icicles command - see command `icicle-mode'.
`----

RE: Abbrevs for the most frequent elisp symbols

[Drew Adams]

> There are the dynamic abbrevs facilities, M-\ and C-M-\.  

And the little-known but there-forever and useful `dynamic-completion-mode,
from built-in library `completions.el'.  (The file Commentary is the doc.)
The keys for it are, by default, `C-RET' and `M-RET'.

> They search through the open buffers looking for completion candidates.
> They're included by default in hippie-expand's completers.  Personally,
> I prefer that style of completion to abbrev.

The use is different, but yes, very useful.

> You could use a similar strategy with normal abbrev though.  Load up
> a set of Elisp files that are typical of your personal usage.  You
> could then use the code in dabbrev-expand or dabbrev-completion to find
> the completions you want.  You could wrap that in a bit of Elisp and run
> it once to generate a table, then decide on the abbrevs manually or by
> taking a prefix.

Yes.

> Martin mentions that the Emacs sources themselves contain some code
> that's frowned upon these days.  That's true, there are many old
> parts of Emacs.  The parts that are new are a good guide though.  There
> are some peculiarities even there though, Emacs code doesn't use certain
> features to avoid loading them when Emacs starts, easymenu for
> example.

+1.

Re: Abbrevs for the most frequent elisp symbols

[Tom]

Emanuel Berg <embe8573 <at> student.uu.se> writes:
> 
> Tom <adatgyujto <at> gmail.com> writes:
> 
> But even so, what if some guy is the other way around,
> e.g., he prefers `garbage-collect' to `goto-char'? Is
> that easily rerouted in some automatically generated
> (but after that manually editable) abbrev table?

Something like this could be added, but I don't see
the reason, because I think the elisp sources are
fairly representative of the usage frequency of symbols.

I'm pretty sure most people use goto-char more often
than garbage-collect.

The aim was to provide a very convenient way to type
the most frequent symbols. For the less frequent one
you always have some kind of completion.

I was tired of typing save-exursion, etc. all the time
and while I use completion (company) for elisp symbols
it's still cumbersome to type for the most frequent
symbols while typing simply 'se' is very convenient.

> My second concern is that if this is abbrevs, don't
> you get crazy from them expanding all the time as you
> type?

There was one problematic abbrev I found when I tried
it 'if' which mapped to some lesser used function, don't
remember which, so I deleted it manually.

Otherwise, the abbrevs are surprisingly unique and 
didn't interfere with normal typing, though I haven't
tested it extensively.

Re: Abbrevs for the most frequent elisp symbols

[Tom]

Andreas Röhler <andreas.roehler <at> easy-emacs.de> writes:
> 
> The question is: does the occurrence inside the manual or the source
provide indication WRT probability of
> personal usage?
> 
> As being a heavy abbrevs-user, here my collection of emacs-lisp abbrevs
defined:
> 

Certainly, if you assemble a list manually that is more personal.
My idea was to assemble an abbrev list automatically, because
adding an abbrev for everything manually is cumbersome.

It may be more efficient to start from an automatic list and 
make it more personal, than starting from scratch and adding
everything manually.

Re: Abbrevs for the most frequent elisp symbols

[Robert Thorpe]

Drew Adams <drew.adams@oracle.com> writes:

>> There are the dynamic abbrevs facilities, M-\ and C-M-\.  
>
> And the little-known but there-forever and useful `dynamic-completion-mode,
> from built-in library `completions.el'.  (The file Commentary is the doc.)
> The keys for it are, by default, `C-RET' and `M-RET'.

Thanks.  I didn't know about that, I'll give it a try.

BR,
Robert Thorpe

Re: Abbrevs for the most frequent elisp symbols

[Andreas Röhler]

On 29.12.2014 16:58, Tom wrote:
> Andreas Röhler <andreas.roehler <at> easy-emacs.de> writes:
>>
>> The question is: does the occurrence inside the manual or the source
> provide indication WRT probability of
>> personal usage?
>>
>> As being a heavy abbrevs-user, here my collection of emacs-lisp abbrevs
> defined:
>>
>
> Certainly, if you assemble a list manually that is more personal.
> My idea was to assemble an abbrev list automatically, because
> adding an abbrev for everything manually is cumbersome.
>
> It may be more efficient to start from an automatic list and
> make it more personal, than starting from scratch and adding
> everything manually.
>
>
>
>

Sure, finally it's a matter of personal habits.
As said, your project is interesting and once pondered to realize it in a simialar way.

However, abandoned that path.
Beside the reason given: there is the need remember abbrevs - unless it's useless.
When defining it manually, you will give a mnemonic abbrev, which presents itself maybe.

Apropos cumbersome: there are ways to make that task easier.

See ar-mode-abbrev-propose

https://github.com/andreas-roehler/werkstatt/blob/master/ar-abbrev-extensions.el

Cheers,

Andreas

Re: Abbrevs for the most frequent elisp symbols

[Tom]

Andreas Röhler <andreas.roehler <at> easy-emacs.de> writes:
> 
> Beside the reason given: there is the need remember abbrevs - unless it's
useless.
> When defining it manually, you will give a mnemonic abbrev, which presents
itself maybe.
> 

In the automatic example the abbrevs are generated from the 
first letters, so there is nothing extra to remember, if you know
the function name then you know the abbrev (e.g. with-current-buffer
-> wcb).

Re: Abbrevs for the most frequent elisp symbols

[Artur Malabarba]

I've ben fiddling with something very similar over last months and I'm
loving it. It's really brought my elisp programming to unprecedented
speeds with essentially no effort.
I'll try to polish it into a package now (over the new year) and bring
it here. Then perhaps we could make it into a built-in minor-mode or
something.

2014-12-30 8:19 GMT-02:00 Tom <adatgyujto@gmail.com>:
> Andreas Röhler <andreas.roehler <at> easy-emacs.de> writes:
>>
>> Beside the reason given: there is the need remember abbrevs - unless it's
> useless.
>> When defining it manually, you will give a mnemonic abbrev, which presents
> itself maybe.
>>
>
> In the automatic example the abbrevs are generated from the
> first letters, so there is nothing extra to remember, if you know
> the function name then you know the abbrev (e.g. with-current-buffer
> -> wcb).
>
>
>
>

Re: Abbrevs for the most frequent elisp symbols

[Óscar Fuentes]

Tom <adatgyujto@gmail.com> writes:

> In the automatic example the abbrevs are generated from the 
> first letters, so there is nothing extra to remember, if you know
> the function name then you know the abbrev (e.g. with-current-buffer
> -> wcb).

If you like this, it can be improved by using flx [1] instead of
abbrevs. I use it with Ido for M-x completion and it is very effective
at discovering and executing commands (often with less keypresses than
their associated key bindings.)

1: https://github.com/lewang/flx

Re: Abbrevs for the most frequent elisp symbols

[Stefan Monnier]

> I've been fiddling with something very similar over last months and I'm
> loving it. It's really brought my elisp programming to unprecedented
> speeds with essentially no effort.
> I'll try to polish it into a package now (over the new year) and bring
> it here. Then perhaps we could make it into a built-in minor-mode or
> something.

One way to integrate this kind of feature would be into the
cycling completion (typically controlled by completion-cycle-threshold,
tho in the minibuffer you can also trigger it explicitly via
minibuffer-force-complete and similar command should be provided
alongside completion-at-point).

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.


        Stefan

Re: Abbrevs for the most frequent elisp symbols

[Tom]

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.

Re: Abbrevs for the most frequent elisp symbols

[Artur Malabarba]

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

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

Re: Abbrevs for the most frequent elisp symbols

[Emanuel Berg]

Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:

> False assumption: that Emacs libraries contain good
> practices only. I know you dislike Emacs.SE

No, not really. I supported it from day one (verbally,
I mean). When they do a message-mode/Gnus-like
interface, I might even use it! But only once or twice
for my favorite questions so they perhaps reach a
wider audience... I can't say I like it but I don't
dislike it.

> but there was a question there about good Elisp code
> to read (to learn Elisp), and someone warned about
> reading Emacs code (especially older libraries).

That reading Emacs code in any way should be harmful
of course I don't believe in. I always emphasize
activity rather than consumption but if there is room
for any consumption reading Emacs code is a good
choice for any programmer, no doubt.

> Recently, I grepped the Emacs Lisp sources for
> occurences of `mapcar', and there is *no*
> consistency in e.g. using ' versus #', or quoted
> lambdas (which I hear are a no-no unless in special
> circumstances, like macros).

Yeah, I have no illusions that it is consistent or
perfect in the abstract sense. Of course it isn't as
so many people worked on it. Still, the definition of
good software is what it can do, or, what it enables
you to do. You can't beat that. It is good.

-- 
underground experts united

Re: Abbrevs for the most frequent elisp symbols

[Emanuel Berg]

Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:

> BTW: what's wrong with Yasnippet?

What's wrong with typing? All those expanders are like
ants in a colony. I want it to be a bare mountain and
a clear horizon. I don't want to type less. If you do
it 18 hours a day I can see the point: it could save
your fingers from disintegrating. But I don't do it
all day long so when I do it I think typing is
superior to all those schemes. But the OP is of course
not me: he wants it and he did it, the same goes for
Yasnippet, whoever wrote that, so CRED to them.

-- 
underground experts united

Re: Abbrevs for the most frequent elisp symbols

[Artur Malabarba]

> No, not really. I supported it from day one (verbally,
> I mean). When they do a message-mode/Gnus-like
> interface, I might even use it!

You might like sx.el.
I don't know if I'd call it gnus-like, but it's pretty good.

Re: Abbrevs for the most frequent elisp symbols

[Emanuel Berg]

Artur Malabarba <arturmalabarba@gmail.com> writes:

>> No, not really. I supported it from day one
>> (verbally, I mean). When they do a
>> message-mode/Gnus-like interface, I might even use
>> it!
>
> You might like sx.el. I don't know if I'd call it
> gnus-like, but it's pretty good.

Yes, I found it in melpa ("sx", version
20150105.1006), but it requires "let-alist-1.0.3"
which "is an orphan package" - what does that mean? no
parents as in dependencies up the ladder? - but worse,
the package itself seems to be missing. Here is what
Help says:

    Status: Orphan.
    Archive: n/a
    Summary:

And I can't find it, either.

Anyway, I would really push for sx and other attempts
to access/use the SX sites from Emacs, be included in
Emacs when they reach maturity, if they didn't
already...

Ha! melpa sure is fun. How about this:

    sunny-day-theme ... Emacs24 theme with a light background.

:)

-- 
underground experts united

Re: Abbrevs for the most frequent elisp symbols

[Artur Malabarba]

> Yes, I found it in melpa ("sx", version
> 20150105.1006), but it requires "let-alist-1.0.3"
> which "is an orphan package" - what does that mean? no
> parents as in dependencies up the ladder? - but worse,
> the package itself seems to be missing.

It's on GNU Elpa, do you not have it configured by any chance?