emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: use-package.el -> Emacs core


From: Drew Adams
Subject: RE: use-package.el -> Emacs core
Date: Tue, 10 Nov 2015 11:24:50 -0800 (PST)

> >> `define-key' is not really an end-user function,
> >> ...
> >> as I've met countless people who have never even heard of it.
> 
> > That means nothing in this regard. There are countless people,
> > including countless Emacs users, who have never heard of plenty
> > of end-user features.  There are probably countless such who
> > have never heard of `M-x' or `C-h f' or even `C-h C-h'...
> 
> It means something to me, Drew, and I'm the one acting on behalf
> of those users.

Sure, but it's not an argument that just _because_ some end users
are unaware of something that is used by other end users (especially
if there is no alternative to using that something) it _follows_
that that thing is not "end-user".  That's a phony argument.

`define-key' is "end-user" because end users sometimes want/need
to use keymaps other than `global-map', and it is their only way
to do that.  It might not be "end-user" enough for you, but that
is something different.

It is only the argument that I find fault with, not the attempt
to come up with something better or more end-userish.

> > But both are "end-user functions" and "user-facing".  (That
> > doesn't mean that something better cannot be found for end
> > users to use.)
> 
> I think that moving define-key to an internal/programmatic mechanism, and
> enriching global-set-key toward an external/user mechanism, with all the
> features of bind-key, is the solution we both want.

That's not a solution that I proposed or necessarily want.
Just as I have no problem with end users using `setq', I have
no problem with them using `define-key'.

That doesn't mean that I oppose giving them something better
as well (for both `setq' and `define-key').  But that does
not imply "moving define-key to an internal/programmatic
mechanism" (whatever you might mean by that).

FWIW, I also object to some kind of definite line, dividing
non-Lisp Emacs users from "internal/programmatic mechanisms"
and Lisp.  There is naturally a spectrum of Emacs usage that
involves different degrees of using Lisp.  And that's a good
thing.  All kinds of Emacs user are welcome.

Attempts to provide non-Lisp ways to do things can be helpful.
(They are not always/necessarily helpful, however.)  But in
general my attitude is that Emacs _is_ Elisp - Emacs is a Lisp
environment.  That is what makes Emacs different and specially
useful.

It is a mistake to draw a hard line between Emacs "end use"
and Lisp.  Lisp vastly increases one's use of Emacs.  Without
some use of Lisp, you are not really taking advantage of Emacs.
You might even say that you are not _really_ using it.

We should, yes, cater to helping novice users who do not
know Lisp.  But we should also encourage the use of Lisp
with Emacs, not discourage it.  You don't need Lisp to
start using Emacs.  But if you really want to use Emacs
then you will want to learn some Lisp.  That should not
be because you _have to_ learn it, but because you can
do so much more with Emacs if you do.

Lack of Lisp knowledge should not be an unnecessary obstacle
to using basic Emacs features.  But we should not hide Lisp
from users, as something that isn't helpful to them or
something they really shouldn't bother with.

The other aspect of not having a dividing line between
internal/programmer and external/end-user is that this is
what free software is about: users can and do dive into
whatever level of the "internals" - the source code - they
feel like.  And they are not discouraged from doing so -
quite the contrary.

Users _are_ developers in this context, even just by
suggesting things that can affect them directly, but also
by, themselves, getting involved with Lisp and coming up
with other ways to do things.  GNU Emacs has a privileged
role to play in this regard.  It is the use-it, customize-it,
fiddle-with-it, extend-it end-user application par excellence.

(Just one opinion.)

> I'm the one acting on behalf of those users.
  ^^^^^^^^^^^

You are not the only one.  Lots of us here keep those
users in mind and try to act on their behalf.  I'm glad
you do too.  Welcome aboard. ;-)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]