all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Christopher Schmidt'" <christopher@ristopher.com>,
	<emacs-devel@gnu.org>
Subject: RE: completion.el users?
Date: Sat, 11 May 2013 14:16:05 -0700	[thread overview]
Message-ID: <943243026FFC4D699528918175E0ABDC@us.oracle.com> (raw)
In-Reply-To: <87txm9uxmp@ch.ristopher.com>

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




  reply	other threads:[~2013-05-11 21:16 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-10 19:44 completion.el users? Stefan Monnier
2013-05-10 20:50 ` Drew Adams
2013-05-11 12:10 ` Richard Stallman
2013-05-11 14:11   ` Vibhav Pant
2013-05-11 14:23     ` Drew Adams
2013-05-11 15:15       ` Vibhav Pant
2013-05-11 15:09 ` Christopher Schmidt
2013-05-11 15:16   ` Drew Adams
2013-05-11 16:34     ` Dmitry Gutov
2013-05-11 18:19       ` Drew Adams
2013-05-11 18:31         ` Dmitry Gutov
2013-05-11 19:33           ` Drew Adams
2013-05-11 19:24         ` Christopher Schmidt
2013-05-11 21:16           ` Drew Adams [this message]
2013-05-11 22:05             ` Christopher Schmidt
2013-05-11 22:20               ` Drew Adams
2013-05-12  9:09               ` Vitalie Spinu
2013-05-13 17:57   ` T.V. Raman
2013-05-13 17:54 ` T.V. Raman
2013-05-13 18:09   ` Lluís

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=943243026FFC4D699528918175E0ABDC@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=christopher@ristopher.com \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.