From: Drew Adams <drew.adams@oracle.com>
To: Dmitry Alexandrov <dag@gnui.org>
Cc: Kevin Vigouroux <ke.vigouroux@laposte.net>, 41532@debbugs.gnu.org
Subject: bug#41532: Why use the mouse in Emacs?
Date: Tue, 26 May 2020 21:57:37 -0700 (PDT) [thread overview]
Message-ID: <e2ff4d2c-2ad4-473f-bf9a-107eeaae8491@default> (raw)
In-Reply-To: <lfle3u95.dag@gnui.org>
> > 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
next prev parent reply other threads:[~2020-05-27 4:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-25 17:37 bug#41532: Why use the mouse in Emacs? Kevin Vigouroux via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-05-25 18:22 ` Drew Adams
2020-05-26 14:58 ` Kevin Vigouroux via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-05-26 15:30 ` Drew Adams
2020-10-18 1:29 ` Stefan Kangas
2020-12-12 13:25 ` Lars Ingebrigtsen
2020-05-27 3:57 ` Dmitry Alexandrov
2020-05-27 4:57 ` Drew Adams [this message]
2020-05-26 15:52 ` Colin Baxter
2020-05-27 3:33 ` Dmitry Alexandrov
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=e2ff4d2c-2ad4-473f-bf9a-107eeaae8491@default \
--to=drew.adams@oracle.com \
--cc=41532@debbugs.gnu.org \
--cc=dag@gnui.org \
--cc=ke.vigouroux@laposte.net \
/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.