Re: poplife-mode

[charles@aurox.ch (Charles A. Roelli)]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Mon, 13 Nov 2017 02:17:14 +0700
> 
> On Mon, Nov 13, 2017 at 12:47 AM, Stefan Monnier
> <monnier@iro.umontreal.ca> wrote:
> >> Is it a good idea to invent a UI that is unlike anything out there in
> >> any other GUI application, at least AFAIK?  Last time Emacs did that
> >> there was no other app around, but not so nowadays...
> >
> > AFAIK "long click brings up a context menu" was used in macOS some years
> > ago (no idea if it is still used), so it's not a completely new idea.
> 
> Also, on mobile devices (starting at least as far back as Pocket PC
> around 2002), as a poor man’s substitute for secondary mouse button
> click. Inefficient as hell, since instead of just clicking a button
> you have to hold your finger until the timeout elapses and watch the
> little ring around your cursor fill.

Those were the days!  But in contrast, 450 ms is not long to wait for
a context menu, as you can test in Stefan's patch.

> > The only existing standard I know for context menus is to use mouse-3,
> > but that clashes with existing Emacs behavior.  Of course, we could
> > simply drop that existing Emacs behavior.
> 
> Those same applications that show a context menu on the secondary
> mouse button click also select a region on Shift+primary click.
> 
> Emacs as is:
> 
> * <mouse-3> marks region, one more <mouse-3> at the same position kills it
> * <S-mouse-1> pops up buffer appearance menu
> 
> Emacs mimicking other applications could do this:
> 
> * <mouse-3> pops up context menu which includes buffer appearance as
> part or submenu
> * <S-mouse-1> marks region, one more <S-mouse-1> at the same position kills it

Actually, in Emacs under macOS, S-mouse-1 already runs
mouse-save-then-kill, as mouse-3 (and the buffer appearance menu is by
default not accessible, I think).  It was apparently done to maintain
consistency with other macOS apps.