Re: emacs-26 0643952: Add documentation to ecomplete.el

Re: emacs-26 0643952: Add documentation to ecomplete.el

[Michael Albinus]

larsi@gnus.org (Lars Ingebrigtsen) writes:

> +;; (ecomplete-add-item "larsi@gnus.org" 'mail "Lars Magne Ingebrigtsen <larsi@gnus.org>")
> +;;
> +;; the "larsi@gnus.org" entry will then be updated with that new STRING.
> +
> +;; The interface functions are `ecomplete-add-item' and
> +;; `ecomplete-display-matches', while `ecomplete-setup' should be
> +;; called to read the .ecompleterc file, and `ecomplete-save' are
> +;; called to save the file.

Nice. I will check, whether I could add this to Tramp. Something like

(ecomplete-add-item "remote-host" 'tramp "/ssh:user@remote-host:")

One inconvenience for me is the hard coding of keys in
`overriding-local-map' with lambda functions. I would prefer to have it
customizable, for instance in order to use <up> and <down> instead of
M-n and M-p.

Best regards, Michael.

Re: emacs-26 0643952: Add documentation to ecomplete.el

[Lars Ingebrigtsen]

Michael Albinus <michael.albinus@gmx.de> writes:

> Nice. I will check, whether I could add this to Tramp. Something like
>
> (ecomplete-add-item "remote-host" 'tramp "/ssh:user@remote-host:")
>
> One inconvenience for me is the hard coding of keys in
> `overriding-local-map' with lambda functions. I would prefer to have it
> customizable, for instance in order to use <up> and <down> instead of
> M-n and M-p.

Hm, yes; doing it via a traditional keymap would make more sense.  (And
<up> and <down> should be bound by default, I think.)  I can't recall
why I did it that way (if I was the one that did it).  Hm...  probably
just because it was easier since it defines those lambdas...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: emacs-26 0643952: Add documentation to ecomplete.el

[Michael Albinus]

Lars Ingebrigtsen <larsi@gnus.org> writes:

Hi Lars,

> Hm, yes; doing it via a traditional keymap would make more sense.  (And
> <up> and <down> should be bound by default, I think.)  I can't recall
> why I did it that way (if I was the one that did it).  Hm...  probably
> just because it was easier since it defines those lambdas...

For the time being I would be happy if the lambdas were transferred into
functions, and if <up> and <down> were bound to the functions in
parallel to M-n and M-p.

Still hard-coded, yes. But you could postpone to customize it until
there is further pressure from somebody else :-)

Best regards, Michael.

Re: emacs-26 0643952: Add documentation to ecomplete.el

[Lars Ingebrigtsen]

Michael Albinus <michael.albinus@gmx.de> writes:

> For the time being I would be happy if the lambdas were transferred into
> functions, and if <up> and <down> were bound to the functions in
> parallel to M-n and M-p.

The lambdas work on the locally bound variables, so I've been staring at
that code for a couple of minutes to decide whether there's a trivial
fix here, and I don't quite see it.

> Still hard-coded, yes. But you could postpone to customize it until
> there is further pressure from somebody else :-)

But, yes, I could just bind up/down to the same lambdas, and I think
I'll just do that immediately and further customisation can be left as a
future exercise.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: emacs-26 0643952: Add documentation to ecomplete.el

[Michael Albinus]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> Still hard-coded, yes. But you could postpone to customize it until
>> there is further pressure from somebody else :-)
>
> But, yes, I could just bind up/down to the same lambdas, and I think
> I'll just do that immediately and further customisation can be left as a
> future exercise.  :-)

Thanks!

These key bindings shall also be documented in Info node
"(message) Mail Aliases". As courtesy, I will do it :-)

Midterm, ecomplete.el could get more promotion in the Emacs docs. I, for
example, was unaware of it.

Best regards, Michael.

Re: emacs-26 0643952: Add documentation to ecomplete.el

[Lars Ingebrigtsen]

Michael Albinus <michael.albinus@gmx.de> writes:

> Midterm, ecomplete.el could get more promotion in the Emacs docs. I, for
> example, was unaware of it.

Yes...  It's a generic mechanism, so hiding it in the Message manual is
perhaps not ideal.  :-)  Perhaps making into its own node and referring
to it in the Message manual would be better.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: emacs-26 0643952: Add documentation to ecomplete.el

[Karl Fogel]

Lars Ingebrigtsen <larsi@gnus.org> writes:
>Michael Albinus <michael.albinus@gmx.de> writes:
>> Midterm, ecomplete.el could get more promotion in the Emacs docs. I, for
>> example, was unaware of it.
>
>Yes...  It's a generic mechanism, so hiding it in the Message manual is
>perhaps not ideal.  :-)  Perhaps making into its own node and referring
>to it in the Message manual would be better.

Yes -- had I know about ecomplete, I probably would have extended it instead of writing my own completion system recently.

Best regards,
-Karl

ecomplete and company (was: emacs-26 0643952: Add documentation to ecomplete.el)

[Stefan Monnier]

BTW, talking about ecomplete, I installed a change into `master` which
adds an message-ecomplete-capf function for use on
completion-at-point-function.

I haven't (yet) added it to completion-at-point-function, but if you do,
you get TAB completion using the ecompleterc data, as well as
company-mode support for it.  There's a small problem with this, tho:
if you use company-mode and have added `ecomplete` to
message-mail-alias-type, you get both at the same time, and that doesn't
work very well in my experience.  Not sure yet how best to deal with it.


        Stefan