Emacs User Friendliness Question/Hope

Emacs User Friendliness Question/Hope

[Jeff Clough]

Right now there seems to be quite a lot of movement for Emacs to "work
like every other application".  There are a number of features and fixes
in the works to accomplish various things to that end.  But can it be
done in such a way as to minimize the amount of work people have to do
to avoid these enhancements?

Can we get a variable like "enable-compatibility-mode" or some such,
that when 't' (the default) gives us the new and friendly Emacs and when
'nil' gives us the Emacs that works how it does today?

Explanation:

As it stands now, there are a number of things I turn off in Emacs (such
as the menu bar and toolbar) and a number of things that I don't enable
that might soon become defaults (like delete-selection-mode).  I know
I'm not the only one that personally finds these features either of no
use, or even annoying at times.

With Emacs 23.x, this takes only a few lines in my .emacs file.  As the
amount of "user friendliness" goes up, the lines in my .emacs will
likely also go up (the change to how kill/yank interacts with the
clipboard is an example).

Making Emacs work like every other application may be fine, and this
isn't a plea for doing otherwise, but *I* at least wish every other
application worked like Emacs.  Please don't make it harder for people
like me to keep things working for them the way they are now.

Jeff

Re: Emacs User Friendliness Question/Hope

[Uday S Reddy]

On 7/16/2010 11:48 AM, Jeff Clough wrote:

> With Emacs 23.x, this takes only a few lines in my .emacs file.  As the
> amount of "user friendliness" goes up, the lines in my .emacs will
> likely also go up (the change to how kill/yank interacts with the
> clipboard is an example).

How does it matter if the .emacs grows?

Don't you think it is worth the trouble if it helps Emacs continue to stay 
popular and thriving with new generations of users?

Cheers,
Uday

Re: Emacs User Friendliness Question/Hope

[Jeff Clough]

On Fri, 2010-07-16 at 15:07 +0100, Uday S Reddy wrote:
> On 7/16/2010 11:48 AM, Jeff Clough wrote:
> 
> > With Emacs 23.x, this takes only a few lines in my .emacs file.  As the
> > amount of "user friendliness" goes up, the lines in my .emacs will
> > likely also go up (the change to how kill/yank interacts with the
> > clipboard is an example).
> 
> How does it matter if the .emacs grows?

It might not matter to you, but it matters to me and likely to some
other people as well.  I'd rather my .emacs contain only things that
extend the software (new bindings, loading my own lisp, etc.) or set
variables necessary for the packages I use (like pointing slime to
sbcl).  The less code needed to do things like turning something off or
tweaking an "internal" setting, the better.

> Don't you think it is worth the trouble if it helps Emacs continue to stay 
> popular and thriving with new generations of users?

I think some people think it's worth the trouble of changing Emacs to
work in a more expected way for new users.  Some people may also think
it's worth adding a few lines to their .emacs files to accommodate this.
I also think some people would like the number of lines to be kept to a
minimum.

There's a way to let Emacs "continue to stay popular and thriving with
new generations of users" that does not also make it more difficult to
work with (or configure) for existing users that are quite happy with
the way it is now.

I don't think it's unreasonable for a new "usability" feature to check a
global setting before doing it's magic.  Or to otherwise be disabled
unless either enabled specifically or enabled via a global "make Emacs
work like Notepad" command.  Make it on by default, but give me a way to
turn it off with one line, as opposed to having one to three lines for
every one of these enhancements.

Jeff

Re: Emacs User Friendliness Question/Hope

[Deniz Dogan]

2010/7/16 Jeff Clough <jeff@chaosphere.com>:
> On Fri, 2010-07-16 at 15:07 +0100, Uday S Reddy wrote:
>> On 7/16/2010 11:48 AM, Jeff Clough wrote:
>>
>> > With Emacs 23.x, this takes only a few lines in my .emacs file.  As the
>> > amount of "user friendliness" goes up, the lines in my .emacs will
>> > likely also go up (the change to how kill/yank interacts with the
>> > clipboard is an example).
>>
>> How does it matter if the .emacs grows?
>
> It might not matter to you, but it matters to me and likely to some
> other people as well.  I'd rather my .emacs contain only things that
> extend the software (new bindings, loading my own lisp, etc.) or set
> variables necessary for the packages I use (like pointing slime to
> sbcl).  The less code needed to do things like turning something off or
> tweaking an "internal" setting, the better.
>
>> Don't you think it is worth the trouble if it helps Emacs continue to stay
>> popular and thriving with new generations of users?
>
> I think some people think it's worth the trouble of changing Emacs to
> work in a more expected way for new users.  Some people may also think
> it's worth adding a few lines to their .emacs files to accommodate this.
> I also think some people would like the number of lines to be kept to a
> minimum.
>
> There's a way to let Emacs "continue to stay popular and thriving with
> new generations of users" that does not also make it more difficult to
> work with (or configure) for existing users that are quite happy with
> the way it is now.
>
> I don't think it's unreasonable for a new "usability" feature to check a
> global setting before doing it's magic.  Or to otherwise be disabled
> unless either enabled specifically or enabled via a global "make Emacs
> work like Notepad" command.  Make it on by default, but give me a way to
> turn it off with one line, as opposed to having one to three lines for
> every one of these enhancements.
>

But that's easier said than done, isn't it? Where should we draw the
line between what's "new" and Notepad-ish and what's "old" and
Emacs-y? To be honest, it sounds like you're looking to add a function
to Emacs which makes it act exactly as the way you want it to. Every
Emacs user has their own taste, which is why the init files exist in
the first place. Let's not start adding what is essentially custom
user configurations to Emacs.

-- 
Deniz Dogan

Re: Emacs User Friendliness Question/Hope

[Jeff Clough]

On Fri, 2010-07-16 at 16:38 +0200, Deniz Dogan wrote:

> > I don't think it's unreasonable for a new "usability" feature to check a
> > global setting before doing it's magic.  Or to otherwise be disabled
> > unless either enabled specifically or enabled via a global "make Emacs
> > work like Notepad" command.  Make it on by default, but give me a way to
> > turn it off with one line, as opposed to having one to three lines for
> > every one of these enhancements.
> >
> 
> But that's easier said than done, isn't it? Where should we draw the
> line between what's "new" and Notepad-ish and what's "old" and
> Emacs-y? To be honest, it sounds like you're looking to add a function
> to Emacs which makes it act exactly as the way you want it to. Every
> Emacs user has their own taste, which is why the init files exist in
> the first place. Let's not start adding what is essentially custom
> user configurations to Emacs.
> 

I think you have over-generalized what I was asking for.

If you look through some of the recent (and not-so-recent) discussions
on emacs-devel, you will see a number of
proposed/implemented/soon-to-be-implemented changes, the primary (if not
*only*) justification for which is making Emacs behave more like a
typical window-based application.

It's my hope that *those* changes can be easily turned off, not on a
per-enhancement basis, but through a convenient variable.  Look at it as
an exercise in bundling these enhancements into something analogous to a
compatibility mode like those that exist for vi in one form or another.
Put the mode on by default, but let the people who want to turn it off.

Your statements concerning "a function which makes emacs act exactly as
I want" and "adding what is essentially custom user configurations to
Emacs" are definitely *not* describing what I am requesting.

Jeff

Re: Emacs User Friendliness Question/Hope

[Chad Brown]

On Jul 16, 2010, at 8:26 AM, Jeff Clough wrote:

> I think you have over-generalized what I was asking for.

While I do feel your pain, and share it to some degree, I expect emacs to continue to offer settings for such things based on features, rather than versions or `some point in time'.  If you find that this takes up too much space in .emacs for you, it shouldn't be hard to put together an elisp package that contains all of those settings that you think should be disabled for `compatibility mode'; at that point, it's just a matter of submitting it to emacs-devel for inclusion (or simply relying on emacswiki.org or the upcoming package system, for example).

*Chad

Re: Emacs User Friendliness Question/Hope

[Phil Hagelberg]

On Fri, Jul 16, 2010 at 7:38 AM, Deniz Dogan <deniz.a.m.dogan@gmail.com> wrote:
> 2010/7/16 Jeff Clough <jeff@chaosphere.com>:
>> On Fri, 2010-07-16 at 15:07 +0100, Uday S Reddy wrote:
>> I don't think it's unreasonable for a new "usability" feature to check a
>> global setting before doing it's magic.  Or to otherwise be disabled
>> unless either enabled specifically or enabled via a global "make Emacs
>> work like Notepad" command.  Make it on by default, but give me a way to
>> turn it off with one line, as opposed to having one to three lines for
>> every one of these enhancements.
>
> But that's easier said than done, isn't it? Where should we draw the
> line between what's "new" and Notepad-ish and what's "old" and
> Emacs-y? To be honest, it sounds like you're looking to add a function
> to Emacs which makes it act exactly as the way you want it to. Every
> Emacs user has their own taste, which is why the init files exist in
> the first place. Let's not start adding what is essentially custom
> user configurations to Emacs.

As the author of the Emacs Starter Kit,
(http://github.com/techomancy/emacs-starter-kit) I feel pretty
qualified to state that there is a demand for a more user-friendly
configuration for Emacs. The Starter Kit is a set of defaults and
bundled libraries (including package.el) that make things a bit more
useful. It includes some improved library support for Ruby, Perl, etc,
enables ido-mode out of the box, and fixes some poor eshell defaults
(most of which have also been fixed in 23). The point is it sidesteps
the politicized process of changing the actual Emacs defaults, and
it's been immensely popular; there are thousands of people using it.

Once package.el stabilizes in Emacs, it's my plan to bundle up as much
as I can from the Starter Kit into just another set of packages. That
way people can simply select and install packages to get a good
out-of-the-box experience, and the old guard can continue undisturbed.
Perhaps another set could be created that target people who are used
to an IDE?

-Phil

Re: Emacs User Friendliness Question/Hope

[Fernando C.V.]

Perhaps this is an opportunity to use custom-themes and include an example
theme distributed with emacs that has some of the most common settings
for the good old emacs users.

--
Fernando

Re: Emacs User Friendliness Question/Hope

[Christoph]

In order to help increasing the "user-friendliness" couldn't we do 
something similar to what viper-mode does? I.e. provide different levels 
of "Emacs-ness".

The lowest level (default?) could enable features that are common among 
other editors/IDEs, e.g. CUA. Increasing levels could "unlock" more and 
more "Emacs-ness" up to the point of where you get what everybody would 
consider the "true" Emacs in all its glory.

I believe that Cream, a Vim clone with a self-proclaimed "modern 
configuration" (http://cream.sourceforge.net/home.html), does something 
similar.

Imho, this could help ease new users into the Emacs world, without 
alienating the existing longtime users.

Christoph

Re: Emacs User Friendliness Question/Hope

[Miles Bader]

Christoph <cschol2112@googlemail.com> writes:
> In order to help increasing the "user-friendliness" couldn't we do
> something similar to what viper-mode does? I.e. provide different levels
> of "Emacs-ness".
>
> The lowest level (default?) could enable features that are common among
> other editors/IDEs, e.g. CUA. Increasing levels could "unlock" more and
> more "Emacs-ness" up to the point of where you get what everybody would
> consider the "true" Emacs in all its glory.

You'd have to be much more specific.

This seems like the sort of idea that's attractive when stated vaguely
with lots of hand-waving, but would be very hard to actually make work
in practice.

What "levels" would there be, exactly?  What bindings would be different
in each level?  How would you avoid conflicts between "traditional"
Emacs bindings and CUA bindings?  How would your scheme work in the
presence of 3rd-party packages?  Would your scheme discourage people
from learning Emacs bindings?

As I mentioned in a previous message on this thread, cua-mode, which has
fairly limited goals, has to use extremely kludgey methods to achieve
them.  Something considerably more elaborate would probably have an even
harder time.

-Miles

-- 
Any man who is a triangle, has thee right, when in Cartesian Space,
to have angles, which when summed, come to know more, nor no less,
than nine score degrees, should he so wish.  [TEMPLE OV THEE LEMUR]

Re: Emacs User Friendliness Question/Hope

[Óscar Fuentes]

Miles Bader <miles@gnu.org> writes:

> Christoph <cschol2112@googlemail.com> writes:
>> In order to help increasing the "user-friendliness" couldn't we do
>> something similar to what viper-mode does? I.e. provide different levels
>> of "Emacs-ness".
>>
>> The lowest level (default?) could enable features that are common among
>> other editors/IDEs, e.g. CUA. Increasing levels could "unlock" more and
>> more "Emacs-ness" up to the point of where you get what everybody would
>> consider the "true" Emacs in all its glory.
>
> You'd have to be much more specific.
>
> This seems like the sort of idea that's attractive when stated vaguely
> with lots of hand-waving, but would be very hard to actually make work
> in practice.
>
> What "levels" would there be, exactly?  What bindings would be different
> in each level?  How would you avoid conflicts between "traditional"
> Emacs bindings and CUA bindings?  How would your scheme work in the
> presence of 3rd-party packages?  Would your scheme discourage people
> from learning Emacs bindings?
>
> As I mentioned in a previous message on this thread, cua-mode, which has
> fairly limited goals, has to use extremely kludgey methods to achieve
> them.  Something considerably more elaborate would probably have an even
> harder time.

I possible solution for this problem is to use `actions'. An action is a
generic concept like `fordward-line', or `undo', or `save', or `yank'
(`paste', if you prefer.)  `universal-argument',
`execute-extended-command' and `C-x' (whatever is officially called on
Emacs jargon) would be actions as well.

Currently a mode defines its keymap relating keys to functions. An
action-aware mode relates actions to functions. At a higher level, there
is a mapping of keys into actions. When a mode is activated for a
buffer, the keymap is constructed looking up the corresponding keys
assigned to the actions the mode implements. A mode inherits the
key->action mapping from its parent mode, but can define its own actions
that overrides its parent's.

The legacy code that defines keymaps keeps working. local-set-key keeps
working as well. There could be a "classic-emacs" key->action mapping, a
"cua" one, etc. Of course those mappings could collide with some keymaps
defined on legacy code, but nothing is perfect, and Emacs could inform
the user about that circumstance when the legacy keymap is activated.

This can be extended to menus and buttons on the toolbar, so a button
that implements an action is useful for all modes that support that
action.

Re: Emacs User Friendliness Question/Hope

[Miles Bader]

Óscar Fuentes <ofv@wanadoo.es> writes:
> I possible solution for this problem is to use `actions'. An action is a
> generic concept like `fordward-line', or `undo', or `save', or `yank'
> (`paste', if you prefer.)  `universal-argument',
> `execute-extended-command' and `C-x' (whatever is officially called on
> Emacs jargon) would be actions as well.

That works for very common commands and simple bindings, but does
nothing to handle the vast number of very specialized bindings.

The basic problem is that Emacs is not an app with a simple central list
of bindings, it's a bunch of cooperating parts, and there are _many_
unstated but significant relationships between these parts.

-Miles

-- 
Liberty, n. One of imagination's most precious possessions.

Re: Emacs User Friendliness Question/Hope

[Stephen J. Turnbull]

Óscar Fuentes writes:

 > I possible solution for this problem is to use `actions'. An action
 > is a generic concept like `fordward-line', or `undo', or `save', or
 > `yank' (`paste', if you prefer.)  `universal-argument',
 > `execute-extended-command' and `C-x' (whatever is officially called
 > on Emacs jargon) would be actions as well.
 > 
 > Currently a mode defines its keymap relating keys to functions.
 >
 > An action-aware mode relates actions to functions.

I hate to tell you this, but since the vast majority of Emacs keys are
bound to *named commands*, we already have one layer of configurable
actions available to the LISP programmer.  Now you're suggesting
another.  This isn't going to help.  (Not to mention that in Emacsen
on X there are already a bunch of other, hidden layers that you can
work with if you want.)

You see, the problem is not that commands aren't flexible enough.
It's that keymaps aren't, and can't be.  Consider the CUA problem.
People talk a lot about the C-x map and how CUA interferes with that.
But that's actually trivial!  C-x is actually bound to a keymap, and
so you can just move the whole thing elsewhere.  It's more annoying,
but almost algorithmic, to move all the mnemonic movement commands
elsewhere.  And almost all editing modes bind very few of the
Ctrl+<key> or Meta+<key> chords, instead using a sparse keymap with
fundamental as the parent.

So why do the long-timers think of this as cleaning the Augean
Stables?  Because there are scores of modes, and they differ widely on
on what the variant keys are, and what they do.

 > This can be extended to menus and buttons on the toolbar, so a button
 > that implements an action is useful for all modes that support that
 > action.

There simply aren't enough keys and toolbar real estate.  (Menus are a
different kettle of fish.)  To give you an idea,
/usr/include/X11/DECkeysym.h defines 1 action,
/usr/include/X11/HPkeysym.h defines 67 actions (perhaps 40 of these
are OSF actions designed to work exactly as you describe), and
/usr/include/X11/keysymdefs.h 289 actions.  As the Motif/OSF folks
found, you are still going to have conflicts across applications, and
adding one more layer of indirection to the hardware->keycode->keysym->
Emacs event->Emacs keysym->command keyboard handler stack just doesn't
help with that.

(Which is what Miles said, of course.  I'm just more long-winded, as
usual.)

Anyway, you or anybody else are welcome to try despite my misgivings.
But I'm convinced; I never liked sweeping slinging horse manure and
rotten hay, and I'm not going to start here.

Re: Emacs User Friendliness Question/Hope

[Deniz Dogan]

2010/7/18 Stephen J. Turnbull <turnbull@sk.tsukuba.ac.jp>:
> Óscar Fuentes writes:
> But that's actually trivial!  C-x is actually bound to a keymap, and
> so you can just move the whole thing elsewhere.

How would I do that? This is what I use today to make C-t my C-x (only
when used as a prefix):

(global-set-key (kbd "C-t") (lookup-key global-map (kbd "C-x")))

Is there a different way?

-- 
Deniz Dogan

Re: Emacs User Friendliness Question/Hope

[Geoff Gole]

> How would I do that? This is what I use today to make C-t my C-x (only
> when used as a prefix):
>
> (global-set-key (kbd "C-t") (lookup-key global-map (kbd "C-x")))
>
> Is there a different way?

See the variable ctl-x-map.

Re: Emacs User Friendliness Question/Hope

[Stephen J. Turnbull]

Geoff Gole writes:

 > > How would I do that? This is what I use today to make C-t my C-x (only
 > > when used as a prefix):
 > >
 > > (global-set-key (kbd "C-t") (lookup-key global-map (kbd "C-x")))
 > >
 > > Is there a different way?
 > 
 > See the variable ctl-x-map.

Which is equivalent to what he uses, of course.  They're just aliases
for the same keymap.

Re: Emacs User Friendliness Question/Hope

[Geoff Gole]

> Which is equivalent to what he uses, of course.  They're just aliases
> for the same keymap.

The variable will still work if he binds C-x to something else and
then reloads .emacs.