poplife-mode

classic Classic list List threaded Threaded
45 messages Options
123
Reply | Threaded
Open this post in threaded view
|

poplife-mode

Tak Kunihiro
With following line, one can cut and paste text using a pop-up menu
triggered by right click.

(define-key global-map [mouse-3] menu-bar-edit-menu)

I noticed that menu-bar items that lead visiting files, buffers,
frames, bookmarks, and recentf can be gathered into a pop-up menu.

I wrote a minor mode `poplife' that provides an integrated pop-up menu
triggered by right click.  Also this minor mode offers contextual
pop-up menus.  When a thing under mouse click is file/directory, word,
and url, this provides pop-up menus of list of files, candidates of
words, and url-opening-menu, respectively.

(require 'poplife)
(setq poplife-word-flag t)
(setq poplife-url-flag t)
(setq poplife-edit-cottager '(:imenu t :buffer t :frame t :bookmark t :recentf t))
(poplife-mode 1)

Contextual pop-up menu by right click is very common interface
nowadays and I propose to include this (or something like this) to
Emacs.


poplife.el (72K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: poplife-mode

Drew Adams
> With following line, one can cut and paste text using a pop-up menu
> triggered by right click.
> (define-key global-map [mouse-3] menu-bar-edit-menu)
>
> I noticed that menu-bar items that lead visiting files, buffers,
> frames, bookmarks, and recentf can be gathered into a pop-up menu.
>
> I wrote a minor mode `poplife' that provides an integrated pop-up menu
> triggered by right click.  Also this minor mode offers contextual
> pop-up menus.  When a thing under mouse click is file/directory, word,
> and url, this provides pop-up menus of list of files, candidates of
> words, and url-opening-menu, respectively.
>
> (require 'poplife)
> (setq poplife-word-flag t)
> (setq poplife-url-flag t)
> (setq poplife-edit-cottager '(:imenu t :buffer t :frame t :bookmark t
> :recentf t))
> (poplife-mode 1)
>
> Contextual pop-up menu by right click is very common interface
> nowadays and I propose to include this (or something like this) to Emacs.


Related:

https://www.emacswiki.org/emacs/Mouse3 (description, screenshots)
https://www.emacswiki.org/emacs/download/mouse3.el (code)

Examples of specialized use:

* `*Completions*' window - actions on candidates and general actions:

  https://www.emacswiki.org/emacs/Icicles_-_Screenshots#CompletionPopupMenu

* Dired - two menus, single file or region of file names:

  https://www.emacswiki.org/emacs/DiredPlus#RegionMenuWithMouse3Library

Reply | Threaded
Open this post in threaded view
|

Re: poplife-mode

Charles A. Roelli
In reply to this post by Tak Kunihiro
> From: Tak Kunihiro <[hidden email]>
> Date: Sun, 5 Nov 2017 10:00:06 +0900
>
> With following line, one can cut and paste text using a pop-up menu
> triggered by right click.
>
> (define-key global-map [mouse-3] menu-bar-edit-menu)
>
> I noticed that menu-bar items that lead visiting files, buffers,
> frames, bookmarks, and recentf can be gathered into a pop-up menu.
>
> I wrote a minor mode `poplife' that provides an integrated pop-up menu
> triggered by right click.  Also this minor mode offers contextual
> pop-up menus.  When a thing under mouse click is file/directory, word,
> and url, this provides pop-up menus of list of files, candidates of
> words, and url-opening-menu, respectively.
>
> (require 'poplife)
> (setq poplife-word-flag t)
> (setq poplife-url-flag t)
> (setq poplife-edit-cottager '(:imenu t :buffer t :frame t :bookmark t :recentf t))
> (poplife-mode 1)
>
> Contextual pop-up menu by right click is very common interface
> nowadays and I propose to include this (or something like this) to
> Emacs.

I also hope we can include something like this in Emacs one day.  But
I would not want to usurp the current binding of mouse-3, which is
handy in its own right.  We could instead trigger the pop-up menu by,
for example, depressing both mouse buttons (mouse-1 and mouse-3) at
the same time.  This feature is apparently already used on the Windows
build to fake a mouse-2 event using a mouse that does not have a third
button:

     The variable ‘w32-mouse-button-tolerance’ specifies the time
  interval, in milliseconds, for faking middle mouse button press on
  2-button mice.  If both mouse buttons are depressed within this time
  interval, Emacs generates a middle mouse button click event instead of a
  double click on one of the buttons.

  from (emacs) Windows Mouse

But maybe it would not be ideal, especially since we don't yet have a
notation for pressing two keys at once.

Also, I would recommend to file a bug for your suggestion so that we
can better keep track of it.  Even if such a feature is not added
right away, the discussion can be useful many years later.

Reply | Threaded
Open this post in threaded view
|

Re: poplife-mode

Stefan Monnier
> I also hope we can include something like this in Emacs one day.  But
> I would not want to usurp the current binding of mouse-3, which is
> handy in its own right.  We could instead trigger the pop-up menu by,

Have you tried C-mouse-3?  It already offers something similar, so it
would make sense to tweak it do what the OP needs.


        Stefan


Reply | Threaded
Open this post in threaded view
|

Re: poplife-mode

Charles A. Roelli
> From: Stefan Monnier <[hidden email]>
> Date: Sat, 11 Nov 2017 10:01:29 -0500
>
> > I also hope we can include something like this in Emacs one day.  But
> > I would not want to usurp the current binding of mouse-3, which is
> > handy in its own right.  We could instead trigger the pop-up menu by,
>
> Have you tried C-mouse-3?  It already offers something similar, so it
> would make sense to tweak it do what the OP needs.

That could work.  I'd still rather not require both a hand on the
keyboard and the mouse to pop up a contextual menu, though.

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.

Reply | Threaded
Open this post in threaded view
|

Re: poplife-mode

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

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


        Stefan


Reply | Threaded
Open this post in threaded view
|

Re: poplife-mode

Eli Zaretskii
> From: Stefan Monnier <[hidden email]>
> Date: Sun, 12 Nov 2017 11:46:50 -0500
>
> 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.

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

Reply | Threaded
Open this post in threaded view
|

Re: poplife-mode

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


        Stefan


Reply | Threaded
Open this post in threaded view
|

Re: poplife-mode

Stefan Monnier
In reply to this post by Stefan Monnier
> 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).

Maybe with something like the patch below.


        Stefan


diff --git a/lisp/mouse.el b/lisp/mouse.el
index 5eeee1ec52..90357806a1 100644
--- a/lisp/mouse.el
+++ b/lisp/mouse.el
@@ -50,10 +49,15 @@ mouse-drag-copy-region
 This affects `mouse-save-then-kill' (\\[mouse-save-then-kill]) in
 addition to mouse drags."
   :type 'boolean
-  :version "24.1"
-  :group 'mouse)
+  :version "24.1")
+
+(defcustom mouse-long-click-time 450
+  "Time after which a click is considered long.")
 
-(defcustom mouse-1-click-follows-link 450
+(defcustom mouse-1-click-follows-link
+  ;; FIXME: Maybe values 1 and -1 should be used to mean
+  ;; "use mouse-long-click-time".
+  mouse-long-click-time
   "Non-nil means that clicking Mouse-1 on a link follows the link.
 
 With the default setting, an ordinary Mouse-1 click on a link
@@ -2455,12 +2451,22 @@ function-key-map
 (if (not (eq system-type 'ms-dos))
     (global-set-key [S-down-mouse-1] 'mouse-appearance-menu))
 ;; C-down-mouse-2 is bound in facemenu.el.
-(global-set-key [C-down-mouse-3]
-  `(menu-item ,(purecopy "Menu Bar") ignore
-    :filter (lambda (_)
-              (if (zerop (or (frame-parameter nil 'menu-bar-lines) 0))
-                  (mouse-menu-bar-map)
-                (mouse-menu-major-mode-map)))))
+(let ((default-context-menu
+        `(menu-item ,(purecopy "Menu Bar") ignore
+          :filter (lambda (_)
+                    (if (zerop (or (frame-parameter nil 'menu-bar-lines) 0))
+                        (mouse-menu-bar-map)
+                      (mouse-menu-major-mode-map))))))
+  (global-set-key [C-down-mouse-3] default-context-menu)
+  (global-set-key [context-menu] default-context-menu))
+
+(global-set-key [down-mouse-3] #'mouse-maybe-context-menu)
+(defun mouse-maybe-context-menu (event)
+  "Bring up a context menu for a long click.
+See `mouse-long-click-time' and `mouse-context-menu-function'."
+  (interactive "@e")
+  (if (sit-for (/ mouse-long-click-time 1000.0))
+      (push (cons 'context-menu (cdr event)) unread-command-events)))
 
 ;; Binding mouse-1 to mouse-select-window when on mode-, header-, or
 ;; vertical-line prevents Emacs from signaling an error when the mouse


Reply | Threaded
Open this post in threaded view
|

Re: poplife-mode

Yuri Khan-2
In reply to this post by Stefan Monnier
On Mon, Nov 13, 2017 at 12:47 AM, Stefan Monnier
<[hidden email]> 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.

> 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

Reply | Threaded
Open this post in threaded view
|

Re: poplife-mode

Charles A. Roelli
In reply to this post by Stefan Monnier
> From: Stefan Monnier <[hidden email]>
> Date: Sun, 12 Nov 2017 13:06:56 -0500
>
> > 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).
>
> Maybe with something like the patch below.

I like it.  We have a lot of existing code that sort of begs for
better mouse integration (find-file-at-point, thing-at-point,
completions buffers, isearch highlights, s-expression/balanced
expression manipulation, dired listings, ...).  I wonder what others
think.

Reply | Threaded
Open this post in threaded view
|

Re: poplife-mode

Charles A. Roelli
In reply to this post by Yuri Khan-2
> From: Yuri Khan <[hidden email]>
> Date: Mon, 13 Nov 2017 02:17:14 +0700
>
> On Mon, Nov 13, 2017 at 12:47 AM, Stefan Monnier
> <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: poplife-mode

Stefan Monnier
In reply to this post by Yuri Khan-2
> * <S-mouse-1> marks region,

Could you explain what that means.  S-mouse-1 is a punctual event, so
I don't see how it can delimit a region.  Or do you mean like current
mouse-3 (i.e. places the mark where you click and activate it)?


        Stefan


Reply | Threaded
Open this post in threaded view
|

RE: poplife-mode

Drew Adams
In reply to this post by Stefan Monnier
> > 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.

Reply | Threaded
Open this post in threaded view
|

RE: poplife-mode

Drew Adams
In reply to this post by Stefan Monnier
> > 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".
                ^^^^^^^^^^^
Why do you think so?

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

The active region is not visible as such until `mouse-3' is
released (the up event).  So even if this could be made to
provide a menu for acting on the region, the region would
not be visible.  A user could try to guess where its other
end is, but why?

The `mouse3.el' code intentionally provides for two menus:

* One for actions on the active region, or actions that
  take it into account in some way.

* One for other actions, unrelated to the region.  This
  includes general actions and actions related to the
  click position - for example, action on a thing-at-point.

Reply | Threaded
Open this post in threaded view
|

Re: poplife-mode

Stefan Monnier
>> 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.
> The active region is not visible as such until `mouse-3' is
> released (the up event).

It doesn't matter, in my UI suggestion.
You can either do:
(short) click => do good ol' mouse-save-then-kill
press-and-hold => pop up a contextual menu

> So even if this could be made to provide a menu for acting on the
> region, the region would not be visible.

It's visible if it was activated by an earlier command, of course.
E.g. "mouse-3" followed by "down-mouse-3".

> The `mouse3.el' code intentionally provides for two menus:

My suggestion doesn't attempt to provide that.  It could provide a menu
whose content depends on whether the region is active (and whether the
click was made in the region), of course, but that's a bit different.


        Stefan

Reply | Threaded
Open this post in threaded view
|

Re: poplife-mode

Yuri Khan-2
In reply to this post by Stefan Monnier
On Mon, Nov 13, 2017 at 3:36 AM, Stefan Monnier
<[hidden email]> wrote:
>> * <S-mouse-1> marks region,
>
> Could you explain what that means.  S-mouse-1 is a punctual event, so
> I don't see how it can delimit a region.  Or do you mean like current
> mouse-3 (i.e. places the mark where you click and activate it)?

Similar to current mouse-3, yes.

More precisely: (1) if there is no region active, put mark where point
is, otherwise leave mark where it is; (2) move point to where you
click; (3) activate mark.

Reply | Threaded
Open this post in threaded view
|

Re: poplife-mode

Tak Kunihiro-3
In reply to this post by Charles A. Roelli
> I like it.  We have a lot of existing code that sort of begs for
> better mouse integration (find-file-at-point, thing-at-point,
> completions buffers, isearch highlights, s-expression/balanced
> expression manipulation, dired listings, ...).  I wonder what others
> think.

I like the long-click too.

I think that a context menu should be created from list of functions
because each person wants to have his own context menu.  I suppose that
the list would look like below.  Each function should return keymap or
nil.  They will be evaluated in the order of the list.  A function
should accept mouse EVENT, and return keymap or nil.  The last candidate
should return valid keymap.

  (defvar poplife-context-candidates
    '(poplife-mouse-file-menu   ; FILE menu
      poplife-mouse-dir-menu    ; DIR menu
      poplife-mouse-word-menu   ; WORD menu
      poplife-mouse-url-menu    ; URL menu
      poplife-mouse-edit-menu)) ; EDIT menu (default)

  (1) FILE menu -- Pop how-to-open-a-file menu.  The file is detected
                   by find-file-at-point.
  (2) DIR menu  -- Pop files in a directory.  The directory is detected
                   by find-file-at-point.
  (3) WORD menu -- Pop words by #'flyspell-correct-word
                   when face of a word under a mouse is flyspell-incorrect.
  (4) URL menu  -- Pop how-to-open-an-url menu.  The url is detected
                   by thing-at-point-url-at-point.
  (5) EDIT menu -- Pop edit-menu with extra commands.  This menu can be
                   gigantic.

Note that this is just an example.

Reply | Threaded
Open this post in threaded view
|

RE: poplife-mode

Drew Adams
In reply to this post by Stefan Monnier
> >> 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.
> >
> > The active region is not visible as such until `mouse-3'
> > is released (the up event).
>
> It doesn't matter, in my UI suggestion. You can either
> do: (short) click => do good ol' mouse-save-then-kill
> press-and-hold => pop up a contextual menu

The point was not about simply killing the region text.
Of course you can kill it using a single, normal click.
That's true of `mouse3.el', as well.  That's nothing new.

The point was about being able to act on the active
region in other ways, with a contextual menu appropriate
to the region being active.

(Being able to.  Nothing _requires_ you to have a menu
that is sensitive to the region being active.)

Again: the region is not highlighted until `mouse-3'
is released (up event).  You should be able to see
the region if you intend to act on it.

> > So even if this could be made to provide a menu for
> > acting on the region, the region would not be visible.
>
> It's visible if it was activated by an earlier command,
> of course.  E.g. "mouse-3" followed by "down-mouse-3".

Pressing and holding down `mouse-3' does _not_ highlight
the region.  That happens only when `mouse-3' is released.

If you mean first click `mouse-3' (press and release)
and then press and hold `mouse-3', then you are talking
about _two_ `mouse-3' clicks (it will be released) -
similar to what `mouse3.el' does.

Besides not highlighting the region that is active and
can be acted on, your approach has the disadvantage of
mistakenly killing the region when an intended long
press happens to be a bit too short.

With the `mouse3.el' approach you can't mistakenly
kill the region.  Instead, the menu is available if
you mistakenly click too slowly, giving you another
chance to kill the region.  IOW, it's the other way
around.

> > The `mouse3.el' code intentionally provides for
> > two menus:
> >  * One for actions on the active region...
> >  * One for other actions...
>
> My suggestion doesn't attempt to provide that.

Right.  Nothing to reflect/distinguish the context
of the region being active.

So again:

>> I think a better UI is to pop a menu for a "long press".
>          ^^^^^^^^^^^
> Why do you think so?

What's better about it?

Reply | Threaded
Open this post in threaded view
|

RE: poplife-mode

Drew Adams
In reply to this post by Tak Kunihiro-3
> I think that a context menu should be created from list of
> functions because each person wants to have his own context
> menu

Did you look at or try mouse3.el?  It makes it very
easy to have your own contextual `mouse-3' menus,
whatever the context (a mode or anything else).

There are even two different ways to do define the
menu - choose whichever you want by a user option.

The default choice is to use keymaps to define the
menu.  The other choice lets you use a definition
specific to `x-popup-menu'.  The default choice is
more flexible.

https://www.emacswiki.org/emacs/Mouse3#LibraryMouse3

123