completion.el users?

completion.el users?

[Stefan Monnier]

I'm wondering what's the status of completion.el.
It's been with us for a long time, but the last non-cosmetic patch for
it was made in 2007, which seems surprisingly long for a 90KB file.

I also have some reservations w.r.t to this file because it uses the
"completion-" prefix which I'd rather use for the meaning of "TAB
completion", and because it is not very namespace-clean (uses various
prefixes plus several non-prefixed functions).

IOW, I'd be happy to declare it obsolete.


        Stefan

RE: completion.el users?

[Drew Adams]

> I'm wondering what's the status of completion.el.
> It's been with us for a long time, but the last non-cosmetic patch for
> it was made in 2007, which seems surprisingly long for a 90KB file.
> 
> I also have some reservations w.r.t to this file because it uses the
> "completion-" prefix which I'd rather use for the meaning of "TAB
> completion", and because it is not very namespace-clean (uses various
> prefixes plus several non-prefixed functions).
> 
> IOW, I'd be happy to declare it obsolete.

The particular kind of dynamic completion it provides is not provided by
anything else, AFAIK, and that feature is useful.

I don't use it anymore, personally, but I used to use it a lot.  (There are
several useful Emacs features - calendar... - that I used to use a lot but no
longer use, for whatever reason.)

Wanting to reuse the `completion-' prefix for something else is not a very good
reason to deprecate.  And any "namespace" cleanup such as you describe is pretty
much a nice-to-have for a library that presumably is not used much.

So my vote would be to (a) to keep completion.el, (b) add a FIXME note, if you
like, with suggested namespace-related changes, and (c) use some other prefix
for the other, unrelated code.  Unless, that is, there is a replacement for
completion.el that does the same thing or more.

Just one opinion.

Re: completion.el users?

[Richard Stallman]

You could make it display a message, when loaded or when first
enabled, asking users to email a special address if they use a
package.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

Re: completion.el users?

[Vibhav Pant]

[-- Attachment #1: Type: text/plain, Size: 588 bytes --]

Wasn't completion.el forked to helm, which obsoleted it?


On Sat, May 11, 2013 at 5:40 PM, Richard Stallman <rms@gnu.org> wrote:

> You could make it display a message, when loaded or when first
> enabled, asking users to email a special address if they use a
> package.
>
> --
> Dr Richard Stallman
> President, Free Software Foundation
> 51 Franklin St
> Boston MA 02110
> USA
> www.fsf.org  www.gnu.org
> Skype: No way! That's nonfree (freedom-denying) software.
>   Use Ekiga or an ordinary phone call
>
>
>


-- 
Vibhav Pant
vibhavp@ubuntu.com
"0x2B | ~ 0x2B (Hamlet, Shakespeare)"

[-- Attachment #2: Type: text/html, Size: 1217 bytes --]

RE: completion.el users?

[Drew Adams]

> Wasn't completion.el forked to helm, which
> obsoleted it?

No.  No relation.  (Helm replaced Anything.)

From the Commentary of completion.el:

-----------8<----------

After you type a few characters, pressing the "complete" key
inserts the rest of the word you are likely to type.

This watches all the words that you type and remembers them.
When typing a new word, pressing "complete" (meta-return)
"completes" the word by inserting the most recently used
word that begins with the same characters.  If you press
meta-return repeatedly, it cycles through all the words it
knows about.

If you like the completion then just continue typing, it is
as if you entered the text by hand.  If you want the
inserted extra characters to go away, type control-w or
delete.  More options are described below.

The guesses are made in the order of the most
recently "used".  Typing in a word and then typing a
separator character (such as a space) "uses" the word.  So
does moving a cursor over the word.  If no words are found,
it uses an extended version of the dabbrev style completion.

You automatically save the completions you use to a file
between sessions.

Completion enables programmers to enter longer, more
descriptive variable names while typing fewer keystrokes
than they normally would.

...

Re: completion.el users?

[Christopher Schmidt]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
> IOW, I'd be happy to declare it obsolete.

There are some people left who enable dynamic-completion-mode in their
init.el.

    https://github.com/search?q=dynamic-completion-mode&type=Code

AFAICT most people use auto-complete-mode, though.

    http://cx4a.org/software/auto-complete/
    https://github.com/search?q=auto-complete-mode&type=Code

I think auto-complete-mode is superior to completion.el.

        Christopher

Re: completion.el users?

[Vibhav Pant]

[-- Attachment #1: Type: text/plain, Size: 1561 bytes --]

Ah. I was confused. Sorry for that.

On Sat, May 11, 2013 at 7:53 PM, Drew Adams <drew.adams@oracle.com> wrote:

> > Wasn't completion.el forked to helm, which
> > obsoleted it?
>
> No.  No relation.  (Helm replaced Anything.)
>
> From the Commentary of completion.el:
>
> -----------8<----------
>
> After you type a few characters, pressing the "complete" key
> inserts the rest of the word you are likely to type.
>
> This watches all the words that you type and remembers them.
> When typing a new word, pressing "complete" (meta-return)
> "completes" the word by inserting the most recently used
> word that begins with the same characters.  If you press
> meta-return repeatedly, it cycles through all the words it
> knows about.
>
> If you like the completion then just continue typing, it is
> as if you entered the text by hand.  If you want the
> inserted extra characters to go away, type control-w or
> delete.  More options are described below.
>
> The guesses are made in the order of the most
> recently "used".  Typing in a word and then typing a
> separator character (such as a space) "uses" the word.  So
> does moving a cursor over the word.  If no words are found,
> it uses an extended version of the dabbrev style completion.
>
> You automatically save the completions you use to a file
> between sessions.
>
> Completion enables programmers to enter longer, more
> descriptive variable names while typing fewer keystrokes
> than they normally would.
>
> ...
>
>


-- 
Vibhav Pant
vibhavp@ubuntu.com
"0x2B | ~ 0x2B (Hamlet, Shakespeare)"

[-- Attachment #2: Type: text/html, Size: 2223 bytes --]

RE: completion.el users?

[Drew Adams]

> I think auto-complete-mode is superior to completion.el.

Does it do what completion.el does (and more)?

Please give reasons _why_ you think one is superior.

Re: completion.el users?

[Dmitry Gutov]

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

>> I think auto-complete-mode is superior to completion.el.
>
> Does it do what completion.el does (and more)?

It has a similar feature:

http://auto-complete.org/doc/manual.html#candidate-suggestion

RE: completion.el users?

[Drew Adams]

> >> I think auto-complete-mode is superior to completion.el.
> >
> > Does it do what completion.el does (and more)?
> 
> It has a similar feature:
> http://auto-complete.org/doc/manual.html#candidate-suggestion

1. Is auto-complete-mode part of Emacs?  I don't think so.  Let's not divert the
thread, if not.  The question is whether Emacs already contains a reasonable
replacement for completion.el.

2. Looking at the auto-complete-mode doc and demo, it's not clear to me that it
is comparable to completion.el.  It certainly does many things that
completion.el does not do.  (It is also quite large - multiple directories and
files.)  But I don't see that a-c-m actually does what completion.el does.  Can
you confirm that it does?

I understand that you can create a dictionary for a-c-m of terms you use.  And I
understand that a-c-m does lots of useful things wrt completing programming
entities that it knows about.  And it records the counts and use times of
_completions_ that you use.

But what about the completion.el use case?  Does a-c-m record ordinary words (as
well as programming constructs) that you type and thus consider them future
completion candidates?  IOW, does simply typing text, or moving the cursor over
text, suffice to turn the words typed or traversed into completion candidates?

That is the feature that completion.el provides.  I did not see that expressed
in the auto-complete-mode doc or demo.

E.g., if you were writing an essay or some documentation, does hitting a key
complete a word that you start typing, based on words you have used previously
(including during past sessions)?  From the doc I couldn't tell.

That is what completion.el does well.  Please read the complete Commentary of
completion.el (which is just a bit more than what I posted).

Re: completion.el users?

[Dmitry Gutov]

On 11.05.2013 22:19, Drew Adams wrote:
>>>> I think auto-complete-mode is superior to completion.el.
>>>
>>> Does it do what completion.el does (and more)?
>>
>> It has a similar feature:
>> http://auto-complete.org/doc/manual.html#candidate-suggestion
>
> 1. Is auto-complete-mode part of Emacs?  I don't think so.  Let's not divert the
> thread, if not.  The question is whether Emacs already contains a reasonable
> replacement for completion.el.

You asked, I answered. Who's diverting what now?

> 2. Looking at the auto-complete-mode doc and demo, it's not clear to me that it
> is comparable to completion.el.  It certainly does many things that
> completion.el does not do.  (It is also quite large - multiple directories and
> files.)  But I don't see that a-c-m actually does what completion.el does.  Can
> you confirm that it does?

Like I said, the feature is similar, not identical.

> I understand that you can create a dictionary for a-c-m of terms you use.  And I
> understand that a-c-m does lots of useful things wrt completing programming
> entities that it knows about.  And it records the counts and use times of
> _completions_ that you use.

Yes.

> But what about the completion.el use case?  Does a-c-m record ordinary words (as
> well as programming constructs) that you type and thus consider them future
> completion candidates?  IOW, does simply typing text, or moving the cursor over
> text, suffice to turn the words typed or traversed into completion candidates?

It allows to use "word in buffer" and "words in buffers in the same 
mode" as sources of completions, so yes, to an extent. Similarly to 
`dabbrev-expand'.

> E.g., if you were writing an essay or some documentation, does hitting a key
> complete a word that you start typing, based on words you have used previously
> (including during past sessions)?  From the doc I couldn't tell.

Past sessions? No.

Re: completion.el users?

[Christopher Schmidt]

"Drew Adams" <drew.adams@oracle.com> writes:
> The question is whether Emacs already contains a reasonable
> replacement for completion.el.

Is it?

There is no replacement for completion.el in vanilla GNU Emacs.  Stefan
does know that.

The questions is whether to deprecate a package that is neither
maintained not exactly used any more and that breaks Elisp coding
conventions big time.

Considering that auto-complete-mode is GPLv3'ed and the de-facto
standard package for text-agnostic auto-completion within Emacs, I think
deprecating is worth a try.

        Christopher

RE: completion.el users?

[Drew Adams]

> > 1. Is auto-complete-mode part of Emacs?  I don't think so.  
> > Let's not divert the thread, if not.  The question is whether
> > Emacs already contains a reasonable replacement for
> > completion.el.
> 
> You asked, I answered. Who's diverting what now?

No one has accused anyone of diverting anything.  Please reread what I wrote.

If auto-complete-mode does what completion.el does, and is better at it, then
certainly we could consider deprecating the latter in favor of the former.  But
for that, a-c-m would need to be added to Emacs first, which is a different, or
at least a broader, topic.

As long as it is not part of Emacs and there is no proposal to add it,
considering a-c-m as a replacement would be a diversion, for this thread.

If someone proposes that a-c-m be added, and its author agrees etc., we can
discuss that.  And if it seems likely to be added then that becomes pertinent to
this topic.

FWIW, from the doc and the demo I looked at, and from comments from others here
and there, a-c-m sounds like something that would be great to add to Emacs.

> > 2. Looking at the auto-complete-mode doc and demo, it's not 
> > clear to me that it is comparable to completion.el.  It certainly
> > does many things that completion.el does not do.  (It is also
> > quite large - multiple directories and files.)  But I don't see
> > that a-c-m actually does what completion.el does.  Can
> > you confirm that it does?
> 
> Like I said, the feature is similar, not identical.

Yes, I understood that.  Nothing wrong with that.  The question I raised is
whether it does what completion.el does.  If not, then perhaps the two
complement each other and both could be useful parts of Emacs.

Or perhaps the functionality of completion.el could be added to a-c-m.  I have
no idea.  But a starting point relative to this discussion about possible
deprecation is to know whether a-c-m already does what completion.el does.

> > I understand that you can create a dictionary for a-c-m of 
> > terms you use.  And I understand that a-c-m does lots of useful
> > things wrt completing programming entities that it knows about.
> > And it records the counts and use times of _completions_ that you use.
> 
> Yes.
> 
> > But what about the completion.el use case?  Does a-c-m record
> > ordinary words (as well as programming constructs) that you
> > type and thus consider them future completion candidates?
> > IOW, does simply typing text, or moving the cursor over
> > text, suffice to turn the words typed or traversed into 
> > completion candidates?
> 
> It allows to use "word in buffer" and "words in buffers in the same 
> mode" as sources of completions, so yes, to an extent. Similarly to 
> `dabbrev-expand'.
> 
> > E.g., if you were writing an essay or some documentation, 
> > does hitting a key complete a word that you start typing, based
> > on words you have used previously (including during past sessions)?
> > From the doc I couldn't tell.
> 
> Past sessions? No.

It sounds to me (not knowledgable about a-c-m) like we should:

1. Try to see if a-c-m can/should be added to Emacs (independently of the
current question).

2. If there is no immediate substitute what completions.el does, leave it in
Emacs until there is.

3. See if a-c-m could be enhanced to provide what completion.el offers.  I agree
that it sounds close already, from your comments.

RE: completion.el users?

[Drew Adams]

> > The question is whether Emacs already contains a reasonable
> > replacement for completion.el.
> 
> Is it?

That was my question, yes.

> There is no replacement for completion.el in vanilla GNU 
> Emacs.  Stefan does know that.

Well I did not know it, and no one has said it until you did just now.

Why remove a perfectly good feature, which has enjoyed lots of Emacs users over
many years, if Emacs offers no replacement for it?

(BTW, try writing your next novel using vanilla Emacs both with and without
completions.el, and you might just see whether you find it useful.)

There are lots of different kinds of Emacs users, with different use cases.  And
even if only a minority of users make use of some library, that does not mean
that the library is useless for those users and should be deprecated without
offering them a reasonable substitute.

> The questions is whether to deprecate a package that is neither
> maintained not exactly used any more and that breaks Elisp coding
> conventions big time.
> 
> Considering that auto-complete-mode is GPLv3'ed and the de-facto
> standard package for text-agnostic auto-completion within 
> Emacs, I think deprecating is worth a try.

I disagree.  If a-c-m is added to Emacs and is made to do what completion.el
does, then I probably would agree.  Until then, completion.el serves a purpose
and deserves to stay.

I see no reason to deprecate completion.el without an Emacs replacement, just
because it supposedly "breaks Elisp coding conventions big time" (which is an
exaggeration, IMO).

Or just because it supposedly is "not exactly used any more" - which is not
demonstrated.  Just googling "dynamic-completion-mode" gives 50K+ hits, some
(other than this thread) as recent as 5 days ago.  No, like your GIT search,
that is admittedly _not_ a good indicator of the use of completion.el.  But it
does not suggest either that it is "not exactly used any more".

What is the real impetus for wanting to deprecate completion.el now?

That the "last non-cosmetic patch for it was made in 2007" is not a strike
against it, IMHO.  Not at all.  And all the less so if that is reinforced with
the "argument" that that "seems surprisingly long for a 90KB file."

Completion.el has been in use for a long time.  And it is not a catch-all file
like simple.el, which would understandably be updated frequently.

And (_not_ surprisingly) there are plenty of other files, of similar size, that
exhibit the same relative non-cosmetic inactivity: calculator.el, arc-mode.el,
filesets.el, image-dired.el, ada-xref.el, ebnf2ps.el,...

I think that ebnf2ps.el, for example, is wonderful, and extremely useful for
anyone who needs what it does, but there have been very few non-cosmetic changes
to it in quite a while.  It just works (well).  Perhaps it has few users
(dunno), but I am sure they are happy users.

"Surprisingly long", indeed.

[BTW, why do people feel the need to pepper their praise or damnation for
something with "astonishingly", "surprisingly", and the like?  Too much hype.
Sounds like a "whiter than white!" laundry commercial (merci, Coluche -
http://www.youtube.com/watch?v=7vVaWFw54ig).]

So far, it sounds like the main reason for wanting to deprecate completion.el
now might just be that it uses prefix `completion-'.  Really, where's the beef?

Re: completion.el users?

[Christopher Schmidt]

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

Hi Drew,

thanks for your massive answer.  I get your argumentation and all the
points you raised.  I do not exactly agree.

> Or just because it supposedly is "not exactly used any more" - which
> is not demonstrated.  Just googling "dynamic-completion-mode" gives
> 50K+ hits, some (other than this thread) as recent as 5 days ago.

There are 80 hits.  Try to go past page eight.

    https://www.google.com/search?q=%22dynamic-completion-mode%22

I went through the result - it does not indicate much usage of
dynamic-completion-mode.

> No, like your GIT search, that is admittedly _not_ a good indicator of
> the use of completion.el.

Why is that?  Considering the massive amount of Emacs configurations
hosted over at github, the ratio of occurrences of auto-complete-mode
vs. dynamic-completion-mode is pretty representative.

> What is the real impetus for wanting to deprecate completion.el now?

Who is responsible for the code?  Who steps up to fix bugs?  Who is
willing to document the feature?[1]

No one is.  Considering the state of GNU Emacs development, most likely
no one ever will.

Why promote usage of dynamic-completion-mode although there are other
free packages such as auto-complete-mode or predictive-mode[2] which are
superior to dynamic-completion-mode?

> That the "last non-cosmetic patch for it was made in 2007" is not a
> strike against it, IMHO.  Not at all.  And all the less so if that is
> reinforced with the "argument" that that "seems surprisingly long for
> a 90KB file."
>
> Completion.el has been in use for a long time.

Ultimately people moved on to other packages.

Why should the dev team keep the cruft?

How about moving the code to a special GNU ELPA branch - the GNU ELPAM
(Emacs Lisp Package Archaeological Museum)?  Move it back to the GNU
ELPA if someone steps up to maintain it...

        Christopher

[1] dynamic-completion-mode is not mentioned in the manual.  The wiki
does not mention it either.  This makes it an implementation detail of
GNU Emacs to me.

[2] http://www.emacswiki.org/emacs/PredictiveMode

RE: completion.el users?

[Drew Adams]

Christopher, you repeat your points:

1. completion.el is not used as much as auto-complete-mode.

2. auto-complete-mode is superior to completion.el.

I repeat mine:

1. auto-complete-mode is not part of Emacs.  I am not against adding it.
Hurrahing a-c-m does not require denigrating completion.el.

2. a-c-m does not yet do what completion.el does, AFAICT.  So far, they appear
to be complementary.

3. completion.el currently serves a purpose, even if the number of users is not
great.

4. completion.el does not require a lot of maintenance to keep it in its present
state.  No one is asking for added doc, or even a code cleanup (both of which
might be welcome).  Just leave it alone and let people use it until Emacs can
offer something better.

5. If a-c-m is enhanced to do what completion.el does (good), and if a-c-m is
added to Emacs (good), then completion.el would effectively be obsolete and
could be deprecated.  Until then it is not obsolete, regardless of how many
users it has relative to a-c-m.

Re: completion.el users?

[Vitalie Spinu]

 >> Christopher Schmidt <christopher@ch.ristopher.com>
 >> on Sat, 11 May 2013 23:05:35 +0100 (BST) wrote:

[...]

 > Why promote usage of dynamic-completion-mode although there are other
 > free packages such as auto-complete-mode or predictive-mode[2] which are
 > superior to dynamic-completion-mode?

This abundance of different completion packages is also very confusing
for the new users.

[...]

 > How about moving the code to a special GNU ELPA branch - the GNU ELPAM
 > (Emacs Lisp Package Archaeological Museum)?  Move it back to the GNU
 > ELPA if someone steps up to maintain it...

Nice :)

    Vitalie

completion.el users?

[T.V. Raman]

The two things that completion.el does that no other package to
my knowledge does:(I still remember it as tmc-completion)which is
what it ws called when I first started using it:

1. Remembers ocmpletions you've used recently.

2. Loads completions from a tags table --

I've not used it heavily recently, but it would be nice to get
that feature in emacs' dabbrev or other packages before we
declare completion.el obsolete.

-- 
Best Regards,
--raman


On 5/10/13, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> I'm wondering what's the status of completion.el.
> It's been with us for a long time, but the last non-cosmetic patch for
> it was made in 2007, which seems surprisingly long for a 90KB file.
>
> I also have some reservations w.r.t to this file because it uses the
> "completion-" prefix which I'd rather use for the meaning of "TAB
> completion", and because it is not very namespace-clean (uses various
> prefixes plus several non-prefixed functions).
>
> IOW, I'd be happy to declare it obsolete.
>
>
>         Stefan
>
>

completion.el users?

[T.V. Raman]

interesting that you mention auto-complete-mode in this context
-- I tried it a few weeks ago (while blissfully unaware of the
relation to dynamic completion) but gave it up as unsuitable --
and went back to completion.el

-- 
Best Regards,
--raman


On 5/11/13, Christopher Schmidt <christopher@ch.ristopher.com> wrote:
> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>> IOW, I'd be happy to declare it obsolete.
>
> There are some people left who enable dynamic-completion-mode in their
> init.el.
>
>     https://github.com/search?q=dynamic-completion-mode&type=Code
>
> AFAICT most people use auto-complete-mode, though.
>
>     http://cx4a.org/software/auto-complete/
>     https://github.com/search?q=auto-complete-mode&type=Code
>
> I think auto-complete-mode is superior to completion.el.
>
>         Christopher
>
>

Re: completion.el users?

[Lluís]

T V Raman writes:

> The two things that completion.el does that no other package to
> my knowledge does:(I still remember it as tmc-completion)which is
> what it ws called when I first started using it:

> 1. Remembers ocmpletions you've used recently.

http://www.emacswiki.org/emacs/PredictiveMode


Lluis

-- 
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth