[Top][All Lists]

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

Re: Context menus and mouse-3 [was: Changes for emacs 28]

From: Corwin Brust
Subject: Re: Context menus and mouse-3 [was: Changes for emacs 28]
Date: Tue, 15 Sep 2020 19:29:49 -0500


On Tue, Sep 15, 2020 at 6:06 PM Ergus via Emacs development
discussions. <emacs-devel@gnu.org> wrote:
> On September 15, 2020 10:33:51 PM GMT+02:00, Drew Adams 
> <drew.adams@oracle.com> wrote:
> >> > read `Mouse Commands' if you haven't
> >> > already, and give it a try.
> >>
> >> Mouse support is poor in Emacs, this is the reason
> >> why I don't use the mouse in Emacs.
> >
> >I disagree that mouse support is poor in Emacs.
> >
> So you are the only one I know so far with that opinion.
> >I use a mouse in several other applications much
> >of the workday, and Emacs mouse support is superior
> >in every respect I'm aware of.  But I'm no expert
> >on the use of mice.  And perhaps the mouse support
> >in the apps I use is not a reference.
> >
> This is the same problem than undo-redo. Maybe the features are actually 
> better technically speaking or to whom knows all the tricks and trains 
> himself for years; but it worth nothing if the users feel uncomfortable or 
> don't values some of the details that justify complexity in others. (Like 
> hiding the context panel with a control or not having a redo button or not 
> deleting the selection) Or just don't need them.

Technically better is a pretty big deal.  Especially when the specific
technical advancement is massive-overkill levels of user-facing
configuration and even more when the subject at hand is how best to
get said technology to users.  (And, to wit, those users' needs are
varied so as to drive us to this type of sophistication/complexity.)

> There are some "standards" in mouse interaction determined/imposed by most of 
> the gui programing interfaces from visual studio or java to qt5 and gtk. The 
> developers of all the aplications have been following them for years and most 
> of the user are used to them.

This isn't really different from veteran coders who have troubled to
become familiar with lots of Emacs bindings, or really any system
expert.  I acknowledge the utility of having Emacs' default bindings
be simple and obvious to new users.   I think that should be weighed
carefully when pitted directly thoughtful existing
practice/behaviours/defaults.  Echoing what Drew said, above: What we
already have may be superior to other more common practices.

> So this is the "dilema". Or we change a bit (1 binding) to ease the user 
> experience and learning curve OR we expect that all the potential users 
> change their expectations, trainings and don't go to any other editor but use 
> emacs because we pretend we offer a better functionality that they are not 
> aware of and most probably don't need or never learn/use because is complex 
> to remember.

I think the "learning curve" is core to the value proposition of
Emacs:  if we invest the time, we are told, Emacs will overall reduce
the efforts associated to our labors.  There is a balance to be struck
here: new users need to under enough of the machine to begin
configuring it.  Meanwhile, complexities hidden for ease of newcomers
need to remain accessible to users who may be Emacs veterans but not
elisp coders.

Neither new nor old Emacs users will thank us for saving them a
learning curve that costs efficiencies in our work-flows and I think
most of us will learn (and relearn) as needed when the carrot is
general efficiencies when writing, etc.   I think it's the "trainings"
you mention that are the biggest opportunity.

> >> > Double-click (`mouse-1') on a word, then click
> >> > `mouse-3' on another word. The selection picks up
> >> > whole words, from the first through the last you
> >> > clicked.
> >>
> >> In other apps, the same is achieved by double-click
> >> (`mouse-1') on a word, then double-click the same
> >> (`mouse-1') on another word while holding down the Shift key.
> >
> >And that's better why?  Having to use both the
> >keyboard and the mouse?
> >
> Usually the other hand is already in the keyboard and close to a shift. 
> Comparing, our approach of moving the mouse to the toolbar to copy after the 
> selection is probably less efficient than anything else or the fact that M-w 
> and C-y dont share any key like C-c/C-v or that we need the two hand to undo 
> instead of C-z. All these are less efficient too but we are used to them.

I've been thinking about this.  Those who play lots of computer games
may know of an alternate position for the left hand   (Ring finger
slides left onto "A", pinky slides down over the "modern" location of
Control, etc.)  For those who know this position, our left-hands are
pretty comfortable sliding around while we're mousing.  It's almost
another sort of touch-typing - I can stretch over and without looking
hit the Eight key on the number-row with my left index finger pretty
consistently.    In any case, my point is that the diversity of
use-cases continues to multiply however the value proposition Emacs is
only strengthened:  An editor I can configure, based on my own ever
more unique behaviors, to access functionality representing decades of
programers' workflows.

> >> > Triple-click a line, then click `mouse-3' on
> >> > another line.  The selection picks up whole lines.
> >>
> >> In other apps, triple-click a line, then again triple-click
> >> on another line while holding down the Shift key.
> >
> >Both keyboard and mouse again.  Better?  Not IMO.
> >
> But just the same button-1 so yes, probably simpler to remember and intuitive 
> for any office (or other modern editor) user.

> Simple is better than complex.
> Complex is better than complicated.

I think I don't understand: I would say a simple solution I can
remember beats a better solution I've forgotten because it is too
unfamiliar or complex.  But only until I understand how to get "on the
fly help".  The better solution is better for me given only that I
understand and actually do use it.

> The emacs approach with mouse is indeed complicated.

Then it needs better training!  A seperate tutorial?  RMS mentioned a
key-binding memorization game awhile back- maybe a "mouse-trainer"
something like?

In any case, thank you (all) for the work you are doing to help make
Emacs more accessible to new users.  I turn a lot of people on to
Emacs and I'm looking forward to the help I expect this will be for

> >We could provide a keyboard + mouse combination
> >for such use cases if that were a common need.
> >
> >> Also in other apps Shift+F10 opens the context menu,
> >> but why not in Emacs?
> >
> >That's orthogonal.  Nothing prevents also having
> >a keyboard key sequence to open a context menu.
> >(Presumably the "location" it refers to would
> >be point.)
> >
> There is the <print> key which many applications use to show the panel from 
> keyboard too.

There is also <apps> (right of the "right-Flag" key, for me).   In OS
context this opens a context window considering the active selection
if any.

According to ~~C-h k~~ it is unbound:

 | user-error: No command is bound to <apps>

I think people come to Emacs expecting (bracing themselves) to learn.
 We need to do a better job of capitalizing on that by welcoming
people with accessible bite-sized introductory material at least as
much as we need to make the "factory defaults" for Emacs sufficient
for people to make it though such materials.  (I'm referencing
on-going topics such as the first-run configuration wizard,
minor-mode/theme, etc. discussed on other threads.  Apart from the
"mouse trainer" I not sure what else to suggest, specifically.)

> >The impetus for this discussion was expectations
> >of new users to get a context menu on `mouse-3'.
> >(But newbies are not the only reason for such a
> >feature.)
> >
> >> > [I'd like to see the double-clicking extended, so
> >> > that if you double-click a paren in Lisp it picks
> >> > up the full sexp, and if you then `mouse-3' another
> >> > sexp it picks up full sexps in the interval.  But
> >> > this is a bit trickier.]
> >>
> >> It would be easier to use this as: double-click a paren to select
> >> a sexp, then double-click another paren to select another sexp
> >> while holding down the Shift key.
> >
> >Another keyboard + mouse mix.
> >
> >[What I described already works for simple cases, BTW.
> >E.g. double-click a paren in Lisp (open or close),
> >then `mouse-3' another paren, to select up the lists
> >and intervening sexps.]

The first message in this thread (Mouse Commands, plugging the manual,
etc.) has meaningfully changed my workflow.  In fact, I was playing
with the feature described above last night.   Double click the
closing paren of a defun.  Now Mouse-3 after the following defun.
Finally, mouse-3 a second time in the same place (that is, right after
the second defun).


This seems great for refactoring, ie. making little ones out of big
ones.  Took me very little getting used to.

> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

PS, can we rename "yank" to "yoink"?  No?  Okay.


reply via email to

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