bug#41532: Why use the mouse in Emacs?

bug#41532: Why use the mouse in Emacs?

[Kevin Vigouroux via Bug reports for GNU Emacs, the Swiss army knife of text editors]

I briefly followed the discussions about the graphical interface on the
developer mailing list. One issue that comes to mind is the role of
the graphical user interface. Comparing Emacs with other GUIs, one
perceives that the Emacs graphical interface is half broken. This would
explain why many users would prefer using the keyboard or why some users
would perceive Emacs as an outdated text editor.

You can use the mouse to click on certain elements but it is difficult
to navigate with the mouse or to organize its work because the interface
is not designed this way. The menu, for example, does not open graphical
windows but usual Emacs windows (minibuffer, echo area, Customize...).

Finally, I think it is necessary to clarify that we use Emacs mainly
with the keyboard because the interface is designed that way otherwise
the user will have false expectations.

Best regards,
Kevin Vigouroux

bug#41532: Why use the mouse in Emacs?

[Drew Adams]

Lots of us use both keyboard and mouse.

The difference from some other applications,
I think, is that some applications pretty
much _require_ you to use a mouse.  There's
often no keyboard shortcut for this or that
operation, and no way to create your own
shortcut in the application.

This seems to be the problem you're reporting:

> the Emacs graphical interface is half broken.
> ... it is difficult to navigate with the mouse
> or to organize its work because the interface
> is not designed this way.

How so?  Specifically, what's the problem?  In
what way can you not navigate with the mouse?

> The menu, for example, does not open graphical
> windows but usual Emacs windows (minibuffer,
> echo area, Customize...).

OK, good; something concrete.  Except ... what
do you mean by "graphical windows"?  The examples
you mention are graphical windows, AFAICT.

Do you perhaps mean window-manager windows, i.e.,
what Emacs calls "frames"?  If so, customize
`pop-up-frames' to `t', and see if Emacs then
does what you want.

> Finally, I think it is necessary to clarify
> that we use Emacs mainly with the keyboard
> because the interface is designed that way
> otherwise the user will have false expectations.

Is not designed what way?  False expectations
of what?

bug#41532: Why use the mouse in Emacs?

[Kevin Vigouroux via Bug reports for GNU Emacs, the Swiss army knife of text editors]

The user experience is quite different when browsing the Emacs and
LibreOffice menus although they seem similar. The Emacs interface is
mainly text-based partly because there are few graphical widgets.

Nonetheless, this difference is not always clearly perceived. It can be
seen in the following two cases:

1. Menu bar> Tools, Merge, Files... opens a window manager window.
2. Menu bar> Tools, Search Files(Grep)... opens the minibuffer.

Moreover, I think people may also confuse a text-based interface having
a good appearance with a graphical user interface.

The issue may be:

- Better describe or explain how to use the mouse in the interface,

- Fix the menu so as not to mislead the user,

- Rebuild at least partially the Emacs graphical user interface.

bug#41532: Why use the mouse in Emacs?

[Drew Adams]

> The user experience is quite different when browsing the Emacs and
> LibreOffice menus although they seem similar. The Emacs interface is
> mainly text-based partly because there are few graphical widgets.
> 
> Nonetheless, this difference is not always clearly perceived. It can be
> seen in the following two cases:
> 
> 1. Menu bar> Tools, Merge, Files... opens a window manager window.
> 2. Menu bar> Tools, Search Files(Grep)... opens the minibuffer.

#1 invites you to submit a `grep' command.
#2 invites you to choose files.

 `C-h v use-dialog-box'
 `C-h v use-file-dialog'

(Emacs users have a choice, for #2.)

`...' at the end of a menu item means that _some_
further user interaction will entail - for example,
you might be prompted for some input (minibuffer),
or to hit a key (`read-char'), or you may be invited
to do any number of other things.

I'm not sure what you're saying - what the problem is.
But it seems that you're sure.  Examples (like the one
you showed here) can likely help get your point across.
But maybe it's clear to others, even if not to me.

You speak in generalities, which doesn't help (me):
"the Emacs graphical interface is half broken."
"it is difficult to navigate with the mouse or to
organize its work".

HTH.

bug#41532: Why use the mouse in Emacs?

[Stefan Kangas]

tags 41532 + moreinfo
thanks

Kevin Vigouroux <ke.vigouroux@laposte.net> writes:

> The user experience is quite different when browsing the Emacs and
> LibreOffice menus although they seem similar. The Emacs interface is
> mainly text-based partly because there are few graphical widgets.
>
> Nonetheless, this difference is not always clearly perceived. It can be
> seen in the following two cases:
>
> 1. Menu bar> Tools, Merge, Files... opens a window manager window.
> 2. Menu bar> Tools, Search Files(Grep)... opens the minibuffer.
>
> Moreover, I think people may also confuse a text-based interface having
> a good appearance with a graphical user interface.
>
> The issue may be:
>
> - Better describe or explain how to use the mouse in the interface,
>
> - Fix the menu so as not to mislead the user,

What do you suggest, more concretely?  I've read the thread but I can't
find anything actionable.

> - Rebuild at least partially the Emacs graphical user interface.

This is a bit too vague to be actionable.  I suggest coming up with
concrete suggestions for what to do, and sending them as separate
feature requests.

bug#41532: Why use the mouse in Emacs?

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

>> - Rebuild at least partially the Emacs graphical user interface.
>
> This is a bit too vague to be actionable.  I suggest coming up with
> concrete suggestions for what to do, and sending them as separate
> feature requests.

I agree, so I'm closing this bug report.

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

bug#41532: Why use the mouse in Emacs?

[Dmitry Alexandrov]

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

Drew Adams <drew.adams@oracle.com> wrote:
> The difference from some other applications, I think, is that some applications pretty much _require_ you to use a mouse.

Yep, and thatʼs partly true even for Emacs.  Especially, when itʼs built with no GTK.  IIRC, Lucid popup menus once were usable without mouse, but they are not anymore for some reason, while --with-x-toolkit=no menus have never been.

There is M-x tmm-menubar, of course, but besides main menu there are also context menus.  I have not done a good research, but at first sight Iʼve failed to figure out how to access them without falling back to mouse.


>> the Emacs graphical interface [in sense of use-dialog-box and use-file-dialog] is half broken.
>
> How so?  Specifically, what's the problem?

One thing that frustrated me once upon a time, was a dialog window I got trying to close the last frame of server-less Emacs (FWIW, no mouse was involved), that asked the usual question about saving buffers, blocking the session, but it had _no_ ‘cancel’ button.

I could try to press ‘close window’ again, but it had not been quite obvious which of two UI design patterns Emacs would follow here:
— closing the dialog window = cancel (this happens to be the case, after all);
— repeating the destructive command twice = force it (like e. g. C-d in Bash when there are background jobs) — definitely not what I wanted.

Perhaps, I was too stupid, but it took me a certain time to came to idea, that toolkit dialogs in Emacs might accept C-g as well (yes, they do).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

bug#41532: Why use the mouse in Emacs?

[Drew Adams]

> > The difference from some other applications, I think, is that some
> applications pretty much _require_ you to use a mouse.

What you say in reply to that statement is apropos.
But just to be clear, I was really talking not - as
you have, about accessing menus, dialog boxes, etc.
by using the keyboard - but just about using the
keyboard the way Emacs usually does when dialoging.
Responding to prompts with text or char choices,
using completion, etc. are alternatives that Emacs
often uses to what other apps might use menus or
dialog boxes for.

> Yep, and thatʼs partly true even for Emacs.  Especially, when itʼs
> built with no GTK.  IIRC, Lucid popup menus once were usable without
> mouse, but they are not anymore for some reason, while --with-x-
> toolkit=no menus have never been.
> 
> There is M-x tmm-menubar, of course, but besides main menu there are
> also context menus.  I have not done a good research, but at first
> sight Iʼve failed to figure out how to access them without falling back
> to mouse.

Indeed, such things are mostly mousy in Emacs.
But as I hint at above, in many (most?) cases a
menu is not such a great interaction device, with
or without a mouse.
___

FYI, since you mention tmm -

With my library lacarte.el [1], just as with tmm,
you use the keyboard to navigate through the menu-bar
forest and choose menu items.

One difference is that you have the entire forest
available at all times - you can access any parts
of it - you can go up and down and all around.  With
tmm-menubar when you've gone down into a menu you
can't get back up to choose a sibling, ancestor, or
cousin branch to go down.

But the main difference is that you can pattern-match
against it, using completion.  So you can go directly
to some node in the forest, as opposed to drilling
down step by step, forced to hit a key for every step.

This pattern-matching is greatly enhanced when
combined with Icicles [2], which lets you use
regexp-matching etc., and which more importantly lets
you chain together multiple patterns in a process of
successive approximation.

(Icicles also lets you act on multiple completion
candidates during the same command (either
sequentially or a set at a time), which makes menu
exploration quite easy with the keyboard.)

Pattern-matching and completion are things you
can't do with a mouse.

You can proceed to a node with multiple steps, e.g.,
completing a step at a time, as you might do when
navigating the file system with completion.  Or you
can use a pattern that directly completes to a node
(terminal or not) deep within the menu structure,
much like you can do with glob patterns when using
Emacs completion on the file system.

> >> the Emacs graphical interface [in sense of
> >> use-dialog-box and use-file-dialog] is half broken.
> >
> > How so?  Specifically, what's the problem?
> 
> One thing that frustrated me once upon a time, was a dialog window I
> got trying to close the last frame of server-less Emacs (FWIW, no mouse
> was involved), that asked the usual question about saving buffers,
> blocking the session, but it had _no_ ‘cancel’ button.

Sounds like a bug, not a fundamental design flaw.
Doesn't sound like anything inherent in Emacs.
But if by half-broken you mean only that there are
bugs, then OK.  That's perhaps partly because the
use of menus hasn't gotten as much love as dialogs
using the keyboard, and that's perhaps because many
Emacs users don't use the menus much, and many
don't use a mouse much.

> I could try to press ‘close window’ again, but it had not been quite
> obvious which of two UI design patterns Emacs would follow here:
> — closing the dialog window = cancel (this happens to be the case,
> after all);
> — repeating the destructive command twice = force it (like e. g. C-d in
> Bash when there are background jobs) — definitely not what I wanted.

Definitely sounds like that particular dialog was
poorly done.

> Perhaps, I was too stupid, but it took me a certain time to came to
> idea, that toolkit dialogs in Emacs might accept C-g as well (yes, they
> do).

And there's no mousy version of C-g. ;-)  At least
not in the general sense of getting you completely
out of whatever you're in, no matter how deep it is.
___

[1] La Carte:

https://www.emacswiki.org/emacs/LaCarte

[2] Icicles:

https://www.emacswiki.org/emacs/Icicles

bug#41532: Why use the mouse in Emacs?

[Colin Baxter]

>>>>> Bug reports for GNU Emacs, the Swiss army knife of text editors <Kevin> writes:

    > You can use the mouse to click on certain elements but it is
    > difficult to navigate with the mouse or to organize its work
    > because the interface is not designed this way. The menu, for
    > example, does not open graphical windows but usual Emacs windows
    > (minibuffer, echo area, Customize...).

    > Finally, I think it is necessary to clarify that we use Emacs
    > mainly with the keyboard because the interface is designed that
    > way otherwise the user will have false expectations.

Well you may do that. I use mainly the keyboard to avoid repetitive stress
injuries to my wrist. And after 40-odd years, I think it's been
successful.

Best wishes,

Colin.

-- 
Colin Baxter
URL: http://www.Colin-Baxter.com

bug#41532: Why use the mouse in Emacs?

[Dmitry Alexandrov]

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

Kevin Vigouroux <ke.vigouroux@laposte.net> wrote:
> I think it is necessary to clarify that we use Emacs mainly with the keyboard because … otherwise the user will have false expectations.

I there really anyone who expects that he can use a _text editor_ without keyboard?  (Voice recognition aside.)

In any case, +1 — novice users better be not exposed to barely used and therefore neglected features, such as toolkit dialogs.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]