RE: poplife-mode

[Drew Adams <drew.adams@oracle.com>]

> > I just read up on how Drew's library `mouse3' solves the problem.  If
> > I understood it right, it redefines mouse-save-then-kill (mouse-3's
> > normal binding) to respond differently to either a double-click of
> > mouse-3 or two single-clicks of mouse-3 in the same spot.  A
> > double-click kills the region as it usually does, whereas two
> > single-clicks pop up a contextual menu with menu items based on either
> > the "thing at point" (if no region is selected) or the selected
> > region.  This also seems like o good solution.
> 
> FWIW, I think a better UI is to pop a menu for a "long press".
> I.e. bind it to down-mouse-3 but wait a little and if there's not been
> any "mouse-up" event with 1s or so, then pop up the contextual menu.

That is similar, yes.  But in practice what happens (in my
experience) is that a second click follows, which might or
might not be quick enough to be considered a double-click.

IOW, a "faulty" double-click is handled by `mouse3.el'
as an extension of a successful/true double-click.

Since double-click for `mouse-3' kills the selected text,
if a region is active and the second click is not quick
enough to be the second part of a double-click, you can
still kill the text, by choosing `Kill', which is the
first item in the (default) menu provided by `mouse3.el'.

This is also a good way for users to discover the
possibilities of a mouse-3 contextual menu: stumble
on it by double-clicking too slowly (and choosing `Kill'
to finish it off).  (Someone who clicks slowly or unevenly
might also be a particularly good candidate as someone who
appreciates being able to use the menu.)

Note too that with `mouse3.el' a second click of `mouse-3'
provides different menus, depending on whether the active
region is empty.  If it is empty then the menu applies to
the mouse-click position (it is the same position for both
clicks).  If the region is non-empty then the menu applies
to the region.

(Sure, that two-menu system could be transferred to the
long-mouse-3-press that you suggest instead.)

FWIW, I've never been a fan of of a
longer-press-means-different-behavior UI.  My impression
(but I'm not a user of it) is that this behavior is clunky
in CUA-mode, for example.

Better, I think, to depend on the single timing that users
are alrady used to, which applies to all of their apps
equally, and which they have already configured if they
don't want the default delay: the double-click delay.

What I just said also echoes what Eli said about your
suggestion:

  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...

The double-click delay, on the other hand, is something
that pretty much everyone is used to.

> I think this should actually be provided in core: down-mouse-3 should be
> bound to a command implementing this, with some standardized way to find
> a contextual menu (looking at local char-properties, and if not
> found, buffer-local variable).

I don't think I can agree, here, if only because in some
contexts users/libraries end up defining a behavior for
`down-mouse-3', with an `ignore' behavior of `mouse-3',
and in other contexts (or other users or other libraries)
do the opposite: act upon `mouse-3' and ignore on
`down-mouse-3'.  Even the platform can make a difference
in such a choice, IIRC.

In any case, there must be some way for users to opt out
of any such mouse-3 behavior.  The behavior of `mouse3.el',
which is highly configurable, is 100% optional.