bug#52973: Adding a few context-menu-mode commands

bug#52973: Adding a few context-menu-mode commands

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 511 bytes --]


Tags: patch


Hi,

I am attaching a few patches adding a few features for
context-menu-mode, that I mentioned and explained here:
https://ruzkuku.com/texts/emacs-mouse.html.

Would it be OK to add these to Emacs itself?

In GNU Emacs 29.0.50 (build 5, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.16.0)
 of 2021-12-25 built on viero
Repository revision: f9d518bc2f333e03d5e7c4e935b08fbe19f33c5b
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Implement-context-menu-mode-support-for-man-pages.patch --]
[-- Type: text/x-patch, Size: 1496 bytes --]

From 17cd2634df3f71155efa5b9e534850f473b5b05e Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 31 Dec 2021 12:37:50 +0100
Subject: [PATCH 1/3] Implement context-menu-mode support for man pages

* man.el (Man-at-mouse): Add new command
(Man-context-menu): Add new function
---
 lisp/man.el | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/lisp/man.el b/lisp/man.el
index fff31baa5f..2f956525d3 100644
--- a/lisp/man.el
+++ b/lisp/man.el
@@ -1976,6 +1976,29 @@ Man-bookmark-jump
     (bookmark-default-handler
      `("" (buffer . ,buf) . ,(bookmark-get-bookmark-record bookmark)))))
 
+;;; Mouse support
+(defun Man-at-mouse (e)
+  "Open man manual at point."
+  (interactive "e")
+  (save-excursion
+    (mouse-set-point e)
+    (man (Man-default-man-entry))))
+
+(defun Man-context-menu (menu click)
+  "Populate MENU with commands that open a man page at point."
+  (save-excursion
+    (mouse-set-point click)
+    (when (save-excursion
+            (skip-syntax-backward "^ ")
+            (and (looking-at
+                  "[[:space:]]*\\([[:alnum:]_-]+([[:alnum:]]+)\\)")
+                  (match-string 1)))
+      (define-key-after menu [man-separator] menu-bar-separator)
+      (define-key-after menu [man-at-mouse]
+    '(menu-item "Open man page" man-at-mouse
+            :help "Open man page around mouse click"))))
+  menu)
+
 \f
 ;; Init the man package variables, if not already done.
 (Man-init-defvars)
-- 
2.34.0


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-Implement-context-menu-mode-support-for-hi-lock.patch --]
[-- Type: text/x-patch, Size: 1342 bytes --]

From d08f6ef980b1e6464af112f692cfdaed1a6d7256 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 31 Dec 2021 12:45:52 +0100
Subject: [PATCH 2/3] Implement context-menu-mode support for hi-lock

* hi-lock.el (hi-lock-symbol-at-mouse): Add new command
(hi-lock-context-menu): Add new function
---
 lisp/hi-lock.el | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/lisp/hi-lock.el b/lisp/hi-lock.el
index 7d126cb558..5d99fb5288 100644
--- a/lisp/hi-lock.el
+++ b/lisp/hi-lock.el
@@ -854,6 +854,25 @@ hi-lock-unload-function
   ;; continue standard unloading
   nil)
 
+;;; Mouse support
+(defun hi-lock-symbol-at-mouse (event)
+  "Highlight symbol at mouse click EVENT."
+  (interactive "e")
+  (save-excursion
+    (mouse-set-point event)
+    (highlight-symbol-at-point)))
+
+(defun hi-lock-context-menu (menu click)
+  "Populate MENU with a menu item to highlight symbol at CLICK."
+  (save-excursion
+    (mouse-set-point click)
+    (when (symbol-at-point)
+      (define-key-after menu [highlight-search-separator] menu-bar-separator)
+      (define-key-after menu [highlight-search-mouse]
+        '(menu-item "Highlight Symbol" highlight-symbol-at-mouse
+                    :help "Highlight symbol at point"))))
+  menu)
+
 (provide 'hi-lock)
 
 ;;; hi-lock.el ends here
-- 
2.34.0


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: 0003-Add-command-to-invoke-a-search-engine.patch --]
[-- Type: text/x-patch, Size: 2295 bytes --]

From c5fbec3e04c5e4ef641ff8f99d9c2a58f3c8a770 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 31 Dec 2021 15:21:13 +0100
Subject: [PATCH 3/3] Add command to invoke a search engine

* mouse.el (context-menu-online-search): Add new function
(eww-search-prefix): Declare variable from eww.el
(mouse-online-search-at-point): Add new command
---
 lisp/mouse.el | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/lisp/mouse.el b/lisp/mouse.el
index 11fdd3f639..edf4504bdd 100644
--- a/lisp/mouse.el
+++ b/lisp/mouse.el
@@ -523,6 +523,16 @@ context-menu-ffap
                     :help "Find file or URL from text around mouse click"))))
   menu)
 
+(defun context-menu-online-search (menu click)
+  "Populate MENU with command to search online."
+  (save-excursion
+    (mouse-set-point click)
+    (define-key-after menu [online-search-separator] menu-bar-separator)
+    (define-key-after menu [online-search-at-mouse]
+      '(menu-item "Online search" mouse-online-search-at-point
+                  :help "Search for region or word online")))
+  menu)
+
 (defvar context-menu-entry
   `(menu-item ,(purecopy "Context Menu") ,(make-sparse-keymap)
               :filter ,(lambda (_) (context-menu-map)))
@@ -3209,6 +3219,26 @@ mouse-drag-and-drop-region
         (with-current-buffer (window-buffer window)
           (setq cursor-type (nth 3 state)))))))
 
+(defvar eww-search-prefix)
+(defun mouse-online-search-at-point (event)
+  "Query an online search engine at EVENT.
+If a region is active, the entire region will be sent, otherwise
+the symbol at point will be used.  This command uses EWW's
+default search engine, as configured by `eww-search-prefix'."
+  (interactive "e")
+  (require 'eww)
+  (let ((query (if (use-region-p)
+                   (buffer-substring (region-beginning)
+                                     (region-end))
+                 (save-excursion
+                   (mouse-set-point event)
+                   (thing-at-point 'symbol)))))
+    (unless query
+      (user-error "Nothing to search for"))
+    (browse-url (concat
+                 eww-search-prefix
+                 (mapconcat #'url-hexify-string (split-string query) "+")))))
+
 \f
 ;;; Bindings for mouse commands.
 
-- 
2.34.0


[-- Attachment #5: Type: text/plain, Size: 24 bytes --]


-- 
	Philip Kaludercic

bug#52973: Adding a few context-menu-mode commands

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Date: Mon, 03 Jan 2022 08:34:18 +0000
> 
> I am attaching a few patches adding a few features for
> context-menu-mode, that I mentioned and explained here:
> https://ruzkuku.com/texts/emacs-mouse.html.
> 
> Would it be OK to add these to Emacs itself?

Maybe I'm missing something, but I don't see the actual integration
with context-menu-mode?

bug#52973: Adding a few context-menu-mode commands

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Date: Mon, 03 Jan 2022 08:34:18 +0000
>> 
>> I am attaching a few patches adding a few features for
>> context-menu-mode, that I mentioned and explained here:
>> https://ruzkuku.com/texts/emacs-mouse.html.
>> 
>> Would it be OK to add these to Emacs itself?
>
> Maybe I'm missing something, but I don't see the actual integration
> with context-menu-mode?

Each commit adds a function that can be added to context-menu-functions.

-- 
	Philip Kaludercic

bug#52973: Adding a few context-menu-mode commands

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: 52973@debbugs.gnu.org
> Date: Mon, 03 Jan 2022 13:52:50 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Philip Kaludercic <philipk@posteo.net>
> >> Date: Mon, 03 Jan 2022 08:34:18 +0000
> >> 
> >> I am attaching a few patches adding a few features for
> >> context-menu-mode, that I mentioned and explained here:
> >> https://ruzkuku.com/texts/emacs-mouse.html.
> >> 
> >> Would it be OK to add these to Emacs itself?
> >
> > Maybe I'm missing something, but I don't see the actual integration
> > with context-menu-mode?
> 
> Each commit adds a function that can be added to context-menu-functions.

That was my guess, but without having those additions, not even as a
user option, or (better) automagically when context-menu-mode is
turned on, those functions are just dead ballast, aren't they?

bug#52973: Adding a few context-menu-mode commands

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: 52973@debbugs.gnu.org
>> Date: Mon, 03 Jan 2022 13:52:50 +0000
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: Philip Kaludercic <philipk@posteo.net>
>> >> Date: Mon, 03 Jan 2022 08:34:18 +0000
>> >> 
>> >> I am attaching a few patches adding a few features for
>> >> context-menu-mode, that I mentioned and explained here:
>> >> https://ruzkuku.com/texts/emacs-mouse.html.
>> >> 
>> >> Would it be OK to add these to Emacs itself?
>> >
>> > Maybe I'm missing something, but I don't see the actual integration
>> > with context-menu-mode?
>> 
>> Each commit adds a function that can be added to context-menu-functions.
>
> That was my guess, but without having those additions, not even as a
> user option, or (better) automagically when context-menu-mode is
> turned on, those functions are just dead ballast, aren't they?

From my understanding of bug#50552, this was preferred.

-- 
	Philip Kaludercic

bug#52973: Adding a few context-menu-mode commands

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: 52973@debbugs.gnu.org
> Date: Mon, 03 Jan 2022 17:23:45 +0000
> 
> >> Each commit adds a function that can be added to context-menu-functions.
> >
> > That was my guess, but without having those additions, not even as a
> > user option, or (better) automagically when context-menu-mode is
> > turned on, those functions are just dead ballast, aren't they?
> 
> >From my understanding of bug#50552, this was preferred.

Which part of it?

bug#52973: Adding a few context-menu-mode commands

[Juri Linkov]

>>> > Maybe I'm missing something, but I don't see the actual integration
>>> > with context-menu-mode?
>>>
>>> Each commit adds a function that can be added to context-menu-functions.
>>
>> That was my guess, but without having those additions, not even as a
>> user option, or (better) automagically when context-menu-mode is
>> turned on, those functions are just dead ballast, aren't they?
>
> From my understanding of bug#50552, this was preferred.

bug#50552 proposed to add to every package such lines:

  (custom-add-choice 'context-menu-functions
                     '(function-item :tag "Dictionary menu" context-menu-dictionary))

but 'custom-add-choice' fails on the current structure of
'context-menu-functions', so either a new function 'custom-add-repeat-choice'
should be created, or better would be to improve the existing
'custom-add-choice' to handle the choices inside 'repeat'.

bug#52973: Adding a few context-menu-mode commands

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  52973@debbugs.gnu.org
> Date: Mon, 03 Jan 2022 23:17:18 +0200
> 
> >>> > Maybe I'm missing something, but I don't see the actual integration
> >>> > with context-menu-mode?
> >>>
> >>> Each commit adds a function that can be added to context-menu-functions.
> >>
> >> That was my guess, but without having those additions, not even as a
> >> user option, or (better) automagically when context-menu-mode is
> >> turned on, those functions are just dead ballast, aren't they?
> >
> > From my understanding of bug#50552, this was preferred.
> 
> bug#50552 proposed to add to every package such lines:
> 
>   (custom-add-choice 'context-menu-functions
>                      '(function-item :tag "Dictionary menu" context-menu-dictionary))
> 
> but 'custom-add-choice' fails on the current structure of
> 'context-menu-functions', so either a new function 'custom-add-repeat-choice'
> should be created, or better would be to improve the existing
> 'custom-add-choice' to handle the choices inside 'repeat'.

How about add-context-menu-items, or something to that effect?  We are
talking about quite a different feature to "add", IMO, so a new API
would be better, I think.  And it doesn't have to have anything to do
with custom.el.

But in any case, we need to do this soon, because adding functions
that are not used unless the user plays with hooks is not clean,
definitely not for a feature such as this one, because it's supposed
to be very easy, ideally seamless, to activate.  Otherwise it would be
against the raisons d'être of the feature.

bug#52973: Adding a few context-menu-mode commands

[Juri Linkov]

>> bug#50552 proposed to add to every package such lines:
>>
>>   (custom-add-choice 'context-menu-functions
>>                      '(function-item :tag "Dictionary menu" context-menu-dictionary))
>>
>> but 'custom-add-choice' fails on the current structure of
>> 'context-menu-functions', so either a new function 'custom-add-repeat-choice'
>> should be created, or better would be to improve the existing
>> 'custom-add-choice' to handle the choices inside 'repeat'.
>
> How about add-context-menu-items, or something to that effect?  We are
> talking about quite a different feature to "add", IMO, so a new API
> would be better, I think.  And it doesn't have to have anything to do
> with custom.el.

'custom-add-repeat-choice' can help to add more choices to the
customizable variable 'context-menu-functions', so it would be
easier for users to add a function from the package that the user
is really using.

> But in any case, we need to do this soon, because adding functions
> that are not used unless the user plays with hooks is not clean,
> definitely not for a feature such as this one, because it's supposed
> to be very easy, ideally seamless, to activate.  Otherwise it would be
> against the raisons d'être of the feature.

The main customization point is

  'M-x customize-variable RET context-menu-functions'

that will provide more choices with the help of
'custom-add-repeat-choice'.

bug#52973: Adding a few context-menu-mode commands

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: philipk@posteo.net,  52973@debbugs.gnu.org
> Date: Tue, 04 Jan 2022 19:46:31 +0200
> 
> > But in any case, we need to do this soon, because adding functions
> > that are not used unless the user plays with hooks is not clean,
> > definitely not for a feature such as this one, because it's supposed
> > to be very easy, ideally seamless, to activate.  Otherwise it would be
> > against the raisons d'être of the feature.
> 
> The main customization point is
> 
>   'M-x customize-variable RET context-menu-functions'
> 
> that will provide more choices with the help of
> 'custom-add-repeat-choice'.

I think once the user turns on context-menu-mode, all the modes that
defined their context menus should automatically activate them.  There
should be no need for any user customizations except turning on this
mode.

bug#52973: Adding a few context-menu-mode commands

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Juri Linkov <juri@linkov.net>
>> Cc: philipk@posteo.net,  52973@debbugs.gnu.org
>> Date: Tue, 04 Jan 2022 19:46:31 +0200
>> 
>> > But in any case, we need to do this soon, because adding functions
>> > that are not used unless the user plays with hooks is not clean,
>> > definitely not for a feature such as this one, because it's supposed
>> > to be very easy, ideally seamless, to activate.  Otherwise it would be
>> > against the raisons d'être of the feature.
>> 
>> The main customization point is
>> 
>>   'M-x customize-variable RET context-menu-functions'
>> 
>> that will provide more choices with the help of
>> 'custom-add-repeat-choice'.
>
> I think once the user turns on context-menu-mode, all the modes that
> defined their context menus should automatically activate them.  There
> should be no need for any user customizations except turning on this
> mode.

I would disagree, neither do I necessarily want all mode, nor do I
necessarily want to have the entries listed the default order.  In my
case I fix this by manually setting context-menu-functions to the
functions I want to use.

-- 
	Philip Kaludercic

bug#52973: Adding a few context-menu-mode commands

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: Juri Linkov <juri@linkov.net>,  52973@debbugs.gnu.org
> Date: Tue, 04 Jan 2022 20:08:03 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I think once the user turns on context-menu-mode, all the modes that
> > defined their context menus should automatically activate them.  There
> > should be no need for any user customizations except turning on this
> > mode.
> 
> I would disagree, neither do I necessarily want all mode, nor do I
> necessarily want to have the entries listed the default order.  In my
> case I fix this by manually setting context-menu-functions to the
> functions I want to use.

Then we should allow users to opt out of the automatic activation of
the context menus.  But the default should IMO be that they are
activated in all modes.  After all, this mode wants to mimic "other
applications", and those don't let you choose at all.  So I think
users, especially newcomers, would expect that default.

bug#52973: Adding a few context-menu-mode commands

[Juri Linkov]

>> > I think once the user turns on context-menu-mode, all the modes that
>> > defined their context menus should automatically activate them.  There
>> > should be no need for any user customizations except turning on this
>> > mode.
>>
>> I would disagree, neither do I necessarily want all mode, nor do I
>> necessarily want to have the entries listed the default order.  In my
>> case I fix this by manually setting context-menu-functions to the
>> functions I want to use.
>
> Then we should allow users to opt out of the automatic activation of
> the context menus.  But the default should IMO be that they are
> activated in all modes.  After all, this mode wants to mimic "other
> applications", and those don't let you choose at all.  So I think
> users, especially newcomers, would expect that default.

The menu bar doesn't contain all available commands not to overwhelm the
users.  For the same reason, the context menu should stay reasonably short.
Otherwise, it might grow to 28-foot long, and everyone will be mocking
us for this.

bug#52973: Adding a few context-menu-mode commands

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Philip Kaludercic <philipk@posteo.net>,  52973@debbugs.gnu.org
> Date: Wed, 05 Jan 2022 21:09:31 +0200
> 
> >> > I think once the user turns on context-menu-mode, all the modes that
> >> > defined their context menus should automatically activate them.  There
> >> > should be no need for any user customizations except turning on this
> >> > mode.
> >>
> >> I would disagree, neither do I necessarily want all mode, nor do I
> >> necessarily want to have the entries listed the default order.  In my
> >> case I fix this by manually setting context-menu-functions to the
> >> functions I want to use.
> >
> > Then we should allow users to opt out of the automatic activation of
> > the context menus.  But the default should IMO be that they are
> > activated in all modes.  After all, this mode wants to mimic "other
> > applications", and those don't let you choose at all.  So I think
> > users, especially newcomers, would expect that default.
> 
> The menu bar doesn't contain all available commands not to overwhelm the
> users.  For the same reason, the context menu should stay reasonably short.
> Otherwise, it might grow to 28-foot long, and everyone will be mocking
> us for this.

I agree, but is that a real danger?  How much context that gets into
context menu can there be for a single spot in a buffer?

And if indeed there's a lot of useful context, we should produce
multi-level context menus, like we do with buffer-menu.

Once again: this feature makes no sense whatsoever if turning on the
context-menu-mode doesn't activate the context menus.

bug#52973: Adding a few context-menu-mode commands

[Juri Linkov]

> I agree, but is that a real danger?  How much context that gets into
> context menu can there be for a single spot in a buffer?

I've never seen a context menu longer than about 10 items with short submenus.

> And if indeed there's a lot of useful context, we should produce
> multi-level context menus, like we do with buffer-menu.
>
> Once again: this feature makes no sense whatsoever if turning on the
> context-menu-mode doesn't activate the context menus.

More context functions have the same discoverability
as all user options with multiple choices.

bug#52973: Adding a few context-menu-mode commands

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: philipk@posteo.net,  52973@debbugs.gnu.org
> Date: Wed, 05 Jan 2022 22:57:29 +0200
> 
> > I agree, but is that a real danger?  How much context that gets into
> > context menu can there be for a single spot in a buffer?
> 
> I've never seen a context menu longer than about 10 items with short submenus.

So then this is not a real problem, and we shouldn't be worried about
it, right?

> > And if indeed there's a lot of useful context, we should produce
> > multi-level context menus, like we do with buffer-menu.
> >
> > Once again: this feature makes no sense whatsoever if turning on the
> > context-menu-mode doesn't activate the context menus.
> 
> More context functions have the same discoverability
> as all user options with multiple choices.

I don't see what discoverability has to do with this.  The issue is
not discoverability, the issue is to show reasonably useful context
menus when the user turns on context-menu-mode and right-clicks some
part of the Emacs display.  Telling the user to do more customizations
_after_ turning on context-menu-mode makes little sense to me.

bug#52973: Adding a few context-menu-mode commands

[Juri Linkov]

>> > I agree, but is that a real danger?  How much context that gets into
>> > context menu can there be for a single spot in a buffer?
>>
>> I've never seen a context menu longer than about 10 items with short submenus.
>
> So then this is not a real problem, and we shouldn't be worried about
> it, right?

Menus are usually short because long menus is a real problem.

>> > And if indeed there's a lot of useful context, we should produce
>> > multi-level context menus, like we do with buffer-menu.
>> >
>> > Once again: this feature makes no sense whatsoever if turning on the
>> > context-menu-mode doesn't activate the context menus.
>>
>> More context functions have the same discoverability
>> as all user options with multiple choices.
>
> I don't see what discoverability has to do with this.  The issue is
> not discoverability, the issue is to show reasonably useful context
> menus when the user turns on context-menu-mode and right-clicks some
> part of the Emacs display.

If "useful" here means a long menu with all possible items,
then in this case “useful” is the enemy of “usable”.

> Telling the user to do more customizations _after_ turning on
> context-menu-mode makes little sense to me.

There are hundreds of user variables for customization,
and the context menu variable is not different.

bug#52973: Adding a few context-menu-mode commands

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: philipk@posteo.net,  52973@debbugs.gnu.org
> Date: Thu, 06 Jan 2022 10:20:10 +0200
> 
> > Telling the user to do more customizations _after_ turning on
> > context-menu-mode makes little sense to me.
> 
> There are hundreds of user variables for customization,
> and the context menu variable is not different.

I couldn't disagree more.

bug#52973: Adding a few context-menu-mode commands

[Juri Linkov]

> I am attaching a few patches adding a few features for
> context-menu-mode, that I mentioned and explained here:
> https://ruzkuku.com/texts/emacs-mouse.html.
>
> Would it be OK to add these to Emacs itself?

Thanks, it would be beneficial to enrich the packages with the
context-menus.  Man-context-menu is a good addition to the package
man.el, and hi-lock-context-menu to hi-lock.el.  However,
mouse-online-search-at-point looks out of place in mouse.el.
Since it relies on eww, wouldn't the right place for it be
in eww.el?

> +(defun Man-at-mouse (e)
> ...
> +(defun Man-context-menu (menu click)
> +  "Populate MENU with commands that open a man page at point."
> +  (save-excursion
> +    (mouse-set-point click)
> +    (when (save-excursion

It seems the second 'save-excursion' is superfluous?

> +            (skip-syntax-backward "^ ")
> +            (and (looking-at
> +                  "[[:space:]]*\\([[:alnum:]_-]+([[:alnum:]]+)\\)")
> +                  (match-string 1)))
> +      (define-key-after menu [man-separator] menu-bar-separator)
> +      (define-key-after menu [man-at-mouse]
> +    '(menu-item "Open man page" man-at-mouse

Typo: the command name is capitalized 'Man-at-mouse'.

> +    (mouse-set-point click)
> +    (when (symbol-at-point)

This can be simplified to:

       (thing-at-mouse click 'symbol)

bug#52973: Adding a few context-menu-mode commands

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 971 bytes --]

Juri Linkov <juri@linkov.net> writes:

>> I am attaching a few patches adding a few features for
>> context-menu-mode, that I mentioned and explained here:
>> https://ruzkuku.com/texts/emacs-mouse.html.
>>
>> Would it be OK to add these to Emacs itself?
>
> Thanks, it would be beneficial to enrich the packages with the
> context-menus.  Man-context-menu is a good addition to the package
> man.el, and hi-lock-context-menu to hi-lock.el.  However,
> mouse-online-search-at-point looks out of place in mouse.el.
> Since it relies on eww, wouldn't the right place for it be
> in eww.el?

It doesn't really depend on eww in any substantial way, rather eww is
the only place where a search engine is defined.  What I was thinking
about was adding a command like online-search (that could then have both
a keyboard and mouse-oriented command), a online-search-engine
user option.  While one is at it, eww could be updated to use this too,
by deprecating eww-search-prefix:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-search-engine-functionality.patch --]
[-- Type: text/x-patch, Size: 6289 bytes --]

From 1ebb6881aeeb08bf574bdb688cb1e94af8b5609d Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Tue, 4 Jan 2022 20:36:32 +0100
Subject: [PATCH] Add search engine functionality

* lisp/misc.el (online-search): Add command to query an online
search engine.
(online-search-engine-alist): Add user option to configure
`online-search'.
(online-search-engine): Add user option to configure
`online-search'.
(online-search-query): Add internal command to generate a
search engine query, to be used elsewhere.
(online-search-at-point): Add command.
(online-search-at-mouse): Add command.
(online-search-context-menu): Add context menu support.
* lisp/net/eww.el (eww-search-prefix): Mark as obsolete
(eww--dwim-expand-url): Use `online-search-query'.
---
 lisp/misc.el    | 93 +++++++++++++++++++++++++++++++++++++++++++++++++
 lisp/net/eww.el |  7 ++--
 2 files changed, 96 insertions(+), 4 deletions(-)

diff --git a/lisp/misc.el b/lisp/misc.el
index 39ec9497d7..473fcac33f 100644
--- a/lisp/misc.el
+++ b/lisp/misc.el
@@ -27,6 +27,7 @@
 
 (eval-when-compile
   (require 'tabulated-list))
+(require 'cl-lib)
 
 ;;;###autoload
 (defun copy-from-above-command (&optional arg)
@@ -209,6 +210,98 @@ list-dynamic-libraries
   (display-buffer buffer)
   nil)
 
+(defgroup online-search ()
+  "Search engine options."
+  :group 'browse-url)
+
+(defcustom online-search-engine-alist
+  '(("DuckDuckGo" . "https://duckduckgo.com/html/?q=")
+    ("Google" . "https://www.google.com/search?q=")
+    ("Wikipedia" . "https://en.wikipedia.org/w/index.php?search="))
+  "Alist of search engines, mapping strings to queries.
+A query is either a string, interpreted as a URL prefix ending
+with an incomplete query string, onto which the query will be
+concatenated, or a function that accepts one argument and returns
+a URL."
+  :type '(alist :key-type string :value-type string)
+  :group 'online-search)
+
+(defcustom online-search-engine "DuckDuckGo"
+  "Search engine to use for `online-search' and related commands.
+The string should denote a key in `online-search-engine-alist'."
+  :type 'string
+  :group 'online-search)
+
+;;;###autoload
+(defun online-search-query (string &optional engine)
+  "Generate an URL query to search for STRING with ENGINE.
+See `online-search' for more details on ENGINE."
+  (let ((query (alist-get (or engine online-search-engine)
+                          online-search-engine-alist
+                          nil nil #'string=)))
+    (cond
+     ((stringp query)
+      (concat query (mapconcat #'url-hexify-string
+                               (split-string string nil t)
+                               "+")))
+     ((functionp query)
+      (funcall query string))
+     ((error "Unknown query %S" query)))))
+
+;;;###autoload
+(defun online-search (string &optional engine)
+  "Search for STRING using a search engine.
+If the optional argument ENGINE may be used to override
+`online-search-engine', and will be used to look up a query in
+`online-search-engine-alist'."
+  (interactive (list (if (use-region-p)
+                         (buffer-substring (region-beginning) (region-end))
+                       (read-string "Search: "))
+                     (and current-prefix-arg
+                          (completing-read
+                           "Use search engine: "
+                           online-search-engine-alist))))
+  (browse-url (online-search-query string engine)))
+
+;;;###autoload
+(defun online-search-at-point (&optional engine)
+  "Search for symbol at point using ENGINE.
+See `online-search' for more details."
+  (interactive (list (and current-prefix-arg
+                          (completing-read
+                           "Use search engine: "
+                           online-search-engine-alist))))
+  (let ((query (thing-at-point 'symbol)))
+    (unless query
+      (user-error "Nothing to search for"))
+    (online-search query engine)))
+
+;;;###autoload
+(defun online-search-at-mouse (click)
+  "Query an online search engine at CLICK.
+If a region is active, the entire region will be sent, otherwise
+the symbol at point will be used.  See `online-search' for more
+details."
+  (interactive "e")
+  (let ((query (if (use-region-p)
+                   (buffer-substring (region-beginning)
+                                     (region-end))
+                 (thing-at-mouse click 'symbol))))
+    (unless query
+      (user-error "Nothing to search for"))
+    (online-search query)))
+
+;;;###autoload
+(defun online-search-context-menu (menu click)
+  "Populate MENU with command to search online at CLICK."
+  (save-excursion
+    (mouse-set-point click)
+    (define-key-after menu [online-search-separator] menu-bar-separator)
+    (define-key-after menu [online-search-at-mouse]
+      '(menu-item "Online search" online-search-at-mouse
+                  :help "Search for region or word online")))
+  menu)
+
 (provide 'misc)
 
 ;;; misc.el ends here
diff --git a/lisp/net/eww.el b/lisp/net/eww.el
index 8930eb427d..37e84d160b 100644
--- a/lisp/net/eww.el
+++ b/lisp/net/eww.el
@@ -55,6 +55,7 @@ eww-search-prefix
   :version "24.4"
   :group 'eww
   :type 'string)
+(make-obsolete-variable 'eww-search-prefix "online-search-engine" "29.1")
 
 (defcustom eww-use-browse-url "\\`mailto:"
   "EWW will use `browse-url' when following links that match this regexp.
@@ -355,7 +356,7 @@ eww-browse
 (defun eww (url &optional new-buffer buffer)
   "Fetch URL and render the page.
 If the input doesn't look like an URL or a domain name, the
-word(s) will be searched for via `eww-search-prefix'.
+word(s) will be searched for via `online-search'.
 
 If NEW-BUFFER is non-nil (interactively, the prefix arg), use a
 new buffer instead of reusing the default EWW buffer.
@@ -464,9 +465,7 @@ eww--dwim-expand-url
                ;; Some sites do not redirect final /
                (when (string= (url-filename (url-generic-parse-url url)) "")
                  (setq url (concat url "/"))))
-           (setq url (concat eww-search-prefix
-                             (mapconcat
-                              #'url-hexify-string (split-string url) "+"))))))
+           (setq url (online-search-query url)))))
   url)
 
 (defun eww--preprocess-html (start end)
-- 
2.34.0


[-- Attachment #3: Type: text/plain, Size: 990 bytes --]


I added this to misc.el, but it could be added to a separate file as
well.

>> +(defun Man-at-mouse (e)
>> ...
>> +(defun Man-context-menu (menu click)
>> +  "Populate MENU with commands that open a man page at point."
>> +  (save-excursion
>> +    (mouse-set-point click)
>> +    (when (save-excursion
>
> It seems the second 'save-excursion' is superfluous?
>
>> +            (skip-syntax-backward "^ ")
>> +            (and (looking-at
>> +                  "[[:space:]]*\\([[:alnum:]_-]+([[:alnum:]]+)\\)")
>> +                  (match-string 1)))
>> +      (define-key-after menu [man-separator] menu-bar-separator)
>> +      (define-key-after menu [man-at-mouse]
>> +    '(menu-item "Open man page" man-at-mouse
>
> Typo: the command name is capitalized 'Man-at-mouse'.
>
>> +    (mouse-set-point click)
>> +    (when (symbol-at-point)
>
> This can be simplified to:
>
>        (thing-at-mouse click 'symbol)

Thanks for the hints, I have fixed them locally.

-- 
	Philip Kaludercic

bug#52973: Adding a few context-menu-mode commands

[Juri Linkov]

>> However, mouse-online-search-at-point looks out of place in mouse.el.
>> Since it relies on eww, wouldn't the right place for it be in eww.el?
>
> It doesn't really depend on eww in any substantial way, rather eww is
> the only place where a search engine is defined.  What I was thinking
> about was adding a command like online-search (that could then have both
> a keyboard and mouse-oriented command), a online-search-engine
> user option.

Maybe then a better place to add new functions would be in
lisp/net/webjump.el.  webjump is a package created exactly
for this purpose.  Then new functions could share the same
prefix webjump-.

bug#52973: Adding a few context-menu-mode commands

[Philip Kaludercic]

Juri Linkov <juri@linkov.net> writes:

>>> However, mouse-online-search-at-point looks out of place in mouse.el.
>>> Since it relies on eww, wouldn't the right place for it be in eww.el?
>>
>> It doesn't really depend on eww in any substantial way, rather eww is
>> the only place where a search engine is defined.  What I was thinking
>> about was adding a command like online-search (that could then have both
>> a keyboard and mouse-oriented command), a online-search-engine
>> user option.
>
> Maybe then a better place to add new functions would be in
> lisp/net/webjump.el.  webjump is a package created exactly
> for this purpose.  Then new functions could share the same
> prefix webjump-.

I didn't know about webjump, thank you for the hint.  My only fear is
that the prefix would make the functionality harder to discover.

-- 
	Philip Kaludercic

bug#52973: Adding a few context-menu-mode commands

[Juri Linkov]

>> Maybe then a better place to add new functions would be in
>> lisp/net/webjump.el.  webjump is a package created exactly
>> for this purpose.  Then new functions could share the same
>> prefix webjump-.
>
> I didn't know about webjump, thank you for the hint.  My only fear is
> that the prefix would make the functionality harder to discover.

The fact that its name starts with the word "web" improves discoverability.

bug#52973: Adding a few context-menu-mode commands

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 490 bytes --]

Juri Linkov <juri@linkov.net> writes:

>>> Maybe then a better place to add new functions would be in
>>> lisp/net/webjump.el.  webjump is a package created exactly
>>> for this purpose.  Then new functions could share the same
>>> prefix webjump-.
>>
>> I didn't know about webjump, thank you for the hint.  My only fear is
>> that the prefix would make the functionality harder to discover.
>
> The fact that its name starts with the word "web" improves
> discoverability.

How is this?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-search-engine-functionality.patch --]
[-- Type: text/x-patch, Size: 5865 bytes --]

From 2a32d1f7df0b8dfdceb3f63476df150d55215b5d Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Tue, 4 Jan 2022 20:36:32 +0100
Subject: [PATCH] Add search engine functionality

* lisp/net/eww.el (eww-search-prefix): Deprecate user option
(eww): Use webjump-search-query
* lisp/net/webjump.el (webjump-default-search-engine): Add user option
(webjump-choose-search-engine): Add function
(webjump-search-query): Add function
(webjump-search): Add autoloaded command
(webjump-search-at-point): Add autoloaded command
(webjump-search-at-mouse): Add command
(webjump-search-context-menu): Add function for context-menu support.
---
 lisp/misc.el        |  1 +
 lisp/net/eww.el     | 10 +++---
 lisp/net/webjump.el | 80 ++++++++++++++++++++++++++++++++++++++++++++-
 3 files changed, 86 insertions(+), 5 deletions(-)

diff --git a/lisp/misc.el b/lisp/misc.el
index 39ec9497d7..6e5aede789 100644
--- a/lisp/misc.el
+++ b/lisp/misc.el
@@ -27,6 +27,7 @@
 
 (eval-when-compile
   (require 'tabulated-list))
+(require 'cl-lib)
 
 ;;;###autoload
 (defun copy-from-above-command (&optional arg)
diff --git a/lisp/net/eww.el b/lisp/net/eww.el
index 8930eb427d..2ef6b35100 100644
--- a/lisp/net/eww.el
+++ b/lisp/net/eww.el
@@ -33,6 +33,7 @@
 (require 'url)
 (require 'url-queue)
 (require 'xdg)
+(require 'webjump)
 (eval-when-compile (require 'subr-x))
 
 (defgroup eww nil
@@ -55,6 +56,9 @@ eww-search-prefix
   :version "24.4"
   :group 'eww
   :type 'string)
+(make-obsolete-variable 'eww-search-prefix
+                        "webjump-default-search-engine"
+                        "29.1")
 
 (defcustom eww-use-browse-url "\\`mailto:"
   "EWW will use `browse-url' when following links that match this regexp.
@@ -355,7 +359,7 @@ eww-browse
 (defun eww (url &optional new-buffer buffer)
   "Fetch URL and render the page.
 If the input doesn't look like an URL or a domain name, the
-word(s) will be searched for via `eww-search-prefix'.
+word(s) will be searched for via `webjump-search'.
 
 If NEW-BUFFER is non-nil (interactively, the prefix arg), use a
 new buffer instead of reusing the default EWW buffer.
@@ -464,9 +468,7 @@ eww--dwim-expand-url
                ;; Some sites do not redirect final /
                (when (string= (url-filename (url-generic-parse-url url)) "")
                  (setq url (concat url "/"))))
-           (setq url (concat eww-search-prefix
-                             (mapconcat
-                              #'url-hexify-string (split-string url) "+"))))))
+           (setq url (webjump-search-query url)))))
   url)
 
 (defun eww--preprocess-html (start end)
diff --git a/lisp/net/webjump.el b/lisp/net/webjump.el
index 7547f92d7d..17c9312c54 100644
--- a/lisp/net/webjump.el
+++ b/lisp/net/webjump.el
@@ -370,7 +370,85 @@ webjump-url-fix-trailing-slash
       (concat url "/")
     url))
 
-;;-----------------------------------------------------------------------------
+\f
+;;; Search engine functionality
+
+(defcustom webjump-default-search-engine "DuckDuckGo"
+  "Search engine to use for `webjump-search' and related commands.
+The string should denote an entry in `webjump-sites', with a
+`simple-query' entry."
+  :type 'string)
+
+(defun webjump-choose-search-engine ()
+  "Choose a search engine to use from `webjump-sites'.
+If no prefix argument was used, the function will return the
+entry for `webjump-default-search-engine'."
+  (assoc-string
+   (if current-prefix-arg
+       (completing-read
+        (format-prompt "Use search engine"
+                       webjump-default-search-engine)
+        webjump-sites
+        (lambda (ent)
+          (and (vectorp (cdr ent))
+               (eq (aref (cdr ent) 0) 'simple-query)))
+        t nil nil webjump-default-search-engine)
+     webjump-default-search-engine)
+   webjump-sites t))
+
+(defun webjump-search-query (string)
+  "Generate an URL query to search for STRING."
+  (let ((engine (cdr (webjump-choose-search-engine))))
+    (webjump-url-fix
+     (concat (aref engine 2)
+             (webjump-url-encode string)
+             (aref engine 3)))))
+
+;;;###autoload
+(defun webjump-search (string)
+  "Search for STRING using a search engine.
+If the optional argument ENGINE may be used to override
+`webjump-default-search-engine'."
+  (interactive (list (if (use-region-p)
+                         (buffer-substring (region-beginning) (region-end))
+                       (read-string "Search: "))))
+  (browse-url (webjump-search-query string)))
+
+;;;###autoload
+(defun webjump-search-at-point ()
+  "Search for symbol at point online.
+See `webjump-search' for more details."
+  (interactive)
+  (let ((query (thing-at-point 'symbol)))
+    (unless query
+      (user-error "Nothing to search for"))
+    (webjump-search query)))
+
+;;;###autoload
+(defun webjump-search-at-mouse (click)
+  "Query an online search engine at CLICK.
+If a region is active, the entire region will be sent, otherwise
+the symbol at point will be used.  See `webjump-search' for more
+details."
+  (interactive "e")
+  (let ((query (if (use-region-p)
+                   (buffer-substring (region-beginning)
+                                     (region-end))
+                 (thing-at-mouse click 'symbol))))
+    (unless (or query (string-match-p "\\`[[:space:]\n]*\\'" query))
+      (user-error "Nothing to search for"))
+    (webjump-search query)))
+
+;;;###autoload
+(defun webjump-search-context-menu (menu click)
+  "Populate MENU with command to search online at CLICK."
+  (save-excursion
+    (mouse-set-point click)
+    (define-key-after menu [webjump-search-separator] menu-bar-separator)
+    (define-key-after menu [webjump-search-at-mouse]
+      '(menu-item "Online search" webjump-search-at-mouse
+                  :help "Search for region or word online")))
+  menu)
 
 (provide 'webjump)
 
-- 
2.34.0


[-- Attachment #3: Type: text/plain, Size: 167 bytes --]


While I agree that web helps, I think a search-online defalias for
webjump-search would be appreciated when looking for commands via
apropos.

-- 
	Philip Kaludercic

bug#52973: Adding a few context-menu-mode commands

[Juri Linkov]

>>>> Maybe then a better place to add new functions would be in
>>>> lisp/net/webjump.el.  webjump is a package created exactly
>>>> for this purpose.  Then new functions could share the same
>>>> prefix webjump-.
>>>
>>> I didn't know about webjump, thank you for the hint.  My only fear is
>>> that the prefix would make the functionality harder to discover.
>>
>> The fact that its name starts with the word "web" improves
>> discoverability.
>
> How is this?

Thanks, everything looks consistent.  If no one will have more comments
during the next few days, it seems safe to assume it's ok to push.

> While I agree that web helps, I think a search-online defalias for
> webjump-search would be appreciated when looking for commands via
> apropos.

Typing 'M-x search- TAB' shows:

  search-backward
  search-backward-regexp
  search-emacs-glossary
  search-forward
  search-forward-help-for-help
  search-forward-regexp
  search-text-property
  search-unencodable-char

I don't know if 'search-online' could be added here too.
We need more opinions.

bug#52973: Adding a few context-menu-mode commands

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Thu, 06 Jan 2022 22:03:01 +0200
> Cc: 52973@debbugs.gnu.org
> 
> Thanks, everything looks consistent.  If no one will have more comments
> during the next few days, it seems safe to assume it's ok to push.

Yeah, feel free to push and disregard everything I said about this
arrangement of context menus not making sense.

bug#52973: Adding a few context-menu-mode commands

[Juri Linkov]

>> Thanks, everything looks consistent.  If no one will have more comments
>> during the next few days, it seems safe to assume it's ok to push.
>
> Yeah, feel free to push and disregard everything I said about this
> arrangement of context menus not making sense.

The patches from Philip just add new functions.
Whether to include them in the default value
of the context function is a separate discussion.

bug#52973: Adding a few context-menu-mode commands

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: philipk@posteo.net,  52973@debbugs.gnu.org
> Date: Thu, 06 Jan 2022 22:35:57 +0200
> 
> >> Thanks, everything looks consistent.  If no one will have more comments
> >> during the next few days, it seems safe to assume it's ok to push.
> >
> > Yeah, feel free to push and disregard everything I said about this
> > arrangement of context menus not making sense.
> 
> The patches from Philip just add new functions.
> Whether to include them in the default value
> of the context function is a separate discussion.

How does it make sense to add functions that aren't used?

Lars, what is your opinion about these issues?  Am I the only one who
thinks that context-menu-mode should automatically activate context
menus in every mode that has support for it?

bug#52973: Adding a few context-menu-mode commands

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Lars, what is your opinion about these issues?  Am I the only one who
> thinks that context-menu-mode should automatically activate context
> menus in every mode that has support for it?

I agree with you -- I see no reason not to activate context menus where
we have support for it.

(But I've only lightly skimmed this thread, so I may be missing
something (I'm still a bit busy with other stuff, but should be back to
normal next week, hopefully.))

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#52973: Adding a few context-menu-mode commands

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Juri Linkov <juri@linkov.net>,  philipk@posteo.net,  52973@debbugs.gnu.org
> Date: Fri, 07 Jan 2022 07:46:56 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Lars, what is your opinion about these issues?  Am I the only one who
> > thinks that context-menu-mode should automatically activate context
> > menus in every mode that has support for it?
> 
> I agree with you -- I see no reason not to activate context menus where
> we have support for it.
> 
> (But I've only lightly skimmed this thread, so I may be missing
> something (I'm still a bit busy with other stuff, but should be back to
> normal next week, hopefully.))

OK.  Then I think we should wait with these patches until Lars had
time to read the thread more thoroughly and expressed his views.

bug#52973: Adding a few context-menu-mode commands

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Juri Linkov <juri@linkov.net>
>> Cc: philipk@posteo.net,  52973@debbugs.gnu.org
>> Date: Thu, 06 Jan 2022 22:35:57 +0200
>> 
>> >> Thanks, everything looks consistent.  If no one will have more comments
>> >> during the next few days, it seems safe to assume it's ok to push.
>> >
>> > Yeah, feel free to push and disregard everything I said about this
>> > arrangement of context menus not making sense.
>> 
>> The patches from Philip just add new functions.
>> Whether to include them in the default value
>> of the context function is a separate discussion.
>
> How does it make sense to add functions that aren't used?
>
> Lars, what is your opinion about these issues?  Am I the only one who
> thinks that context-menu-mode should automatically activate context
> menus in every mode that has support for it?

Unless I have missed it, do mean that all context menus should be loaded
by default (auto loading all *-context-menu functions and adding all of
them to the default value value of context-menu-functions), or that each
context menu definition should be accompanied by a add-to-list on
context-menu-functions?

-- 
	Philip Kaludercic
n

bug#52973: Adding a few context-menu-mode commands

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: Juri Linkov <juri@linkov.net>,  Lars Ingebrigtsen <larsi@gnus.org>,
>   52973@debbugs.gnu.org
> Date: Fri, 07 Jan 2022 08:29:20 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> The patches from Philip just add new functions.
> >> Whether to include them in the default value
> >> of the context function is a separate discussion.
> >
> > How does it make sense to add functions that aren't used?
> >
> > Lars, what is your opinion about these issues?  Am I the only one who
> > thinks that context-menu-mode should automatically activate context
> > menus in every mode that has support for it?
> 
> Unless I have missed it, do mean that all context menus should be loaded
> by default (auto loading all *-context-menu functions and adding all of
> them to the default value value of context-menu-functions), or that each
> context menu definition should be accompanied by a add-to-list on
> context-menu-functions?

I'm not sure I understand why any of what you say should follow.  I'm
probably missing something.

My mental picture is that context menus are specific to modes.  When a
buffer has certain modes turned on (one major mode and one or more
minor modes), those modes are already loaded, and so any functions
those modes define are already defined.  So when the user right-clicks
some spot on display, and one or more modes have defined context-menu
items for this spot, the code which does that is already loaded, and
calling the functions to produce the menu should not need any
autoloading.

As for add-to-list, if the implementation of context menus requires
adding stuff to some list only when the menu is about to be popped up,
then yes, the add-to-list should be done only when the user clicks.
But if adding to the list is done when a mode is loaded, then again,
since all the relevant modes are already loaded, these functions will
have been added to that list already.

What am I missing?

bug#52973: Adding a few context-menu-mode commands

[Juri Linkov]

>> Unless I have missed it, do mean that all context menus should be loaded
>> by default (auto loading all *-context-menu functions and adding all of
>> them to the default value value of context-menu-functions), or that each
>> context menu definition should be accompanied by a add-to-list on
>> context-menu-functions?
>
> I'm not sure I understand why any of what you say should follow.  I'm
> probably missing something.
>
> My mental picture is that context menus are specific to modes.  When a
> buffer has certain modes turned on (one major mode and one or more
> minor modes), those modes are already loaded, and so any functions
> those modes define are already defined.  So when the user right-clicks
> some spot on display, and one or more modes have defined context-menu
> items for this spot, the code which does that is already loaded, and
> calling the functions to produce the menu should not need any
> autoloading.
>
> As for add-to-list, if the implementation of context menus requires
> adding stuff to some list only when the menu is about to be popped up,
> then yes, the add-to-list should be done only when the user clicks.
> But if adding to the list is done when a mode is loaded, then again,
> since all the relevant modes are already loaded, these functions will
> have been added to that list already.
>
> What am I missing?

None of the proposed functions is specific to a mode.
When the global value of context-menu-functions
contains one of the proposed functions, right-clicking anywhere
will autoload every package where such context functions are defined.

bug#52973: Adding a few context-menu-mode commands

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Philip Kaludercic <philipk@posteo.net>,  larsi@gnus.org,
>   52973@debbugs.gnu.org
> Date: Sat, 08 Jan 2022 20:30:06 +0200
> 
> None of the proposed functions is specific to a mode.

The way I see it, the functions in man.el are for Man-mode, and those
in hi-lock.el are for hi-lock-mode.

> When the global value of context-menu-functions
> contains one of the proposed functions, right-clicking anywhere
> will autoload every package where such context functions are defined.

This is over-engineered, IMO.  There should be no need for such
complexity.

bug#52973: Adding a few context-menu-mode commands

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Juri Linkov <juri@linkov.net>
>> Cc: Philip Kaludercic <philipk@posteo.net>,  larsi@gnus.org,
>>   52973@debbugs.gnu.org
>> Date: Sat, 08 Jan 2022 20:30:06 +0200
>> 
>> None of the proposed functions is specific to a mode.
>
> The way I see it, the functions in man.el are for Man-mode, and those
> in hi-lock.el are for hi-lock-mode.

No, the Man functions can be used anywhere you want to read a man page.
It checks if the user clicked on something like "emacs(1)", then inserts
a entry into the context menu to open the man page at point.

The hi-lock functions can be used to highlight a symbol, just like with
`M-s h .'.  Requiring hi-lock-mode to be enabled beforehand would be
counterproductive.

>> When the global value of context-menu-functions
>> contains one of the proposed functions, right-clicking anywhere
>> will autoload every package where such context functions are defined.
>
> This is over-engineered, IMO.  There should be no need for such
> complexity.

What would you suggest to simplify this?

-- 
	Philip Kaludercic

bug#52973: Adding a few context-menu-mode commands

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: Juri Linkov <juri@linkov.net>,  larsi@gnus.org,  52973@debbugs.gnu.org
> Date: Sat, 08 Jan 2022 19:01:46 +0000
> 
> > The way I see it, the functions in man.el are for Man-mode, and those
> > in hi-lock.el are for hi-lock-mode.
> 
> No, the Man functions can be used anywhere you want to read a man page.
> It checks if the user clicked on something like "emacs(1)", then inserts
> a entry into the context menu to open the man page at point.

So it will suggest to show a man page when text like this one from the
ELisp manual is displayed:

     To conserve memory, Emacs does not hold fixed-length 22-bit numbers
  that are codepoints of text characters within buffers and strings.
  Rather, Emacs uses a variable-length internal representation of
  characters, that stores each character as a sequence of 1 to 5 8-bit
  bytes, depending on the magnitude of its codepoint(1).

When the user displays a man page, the probability that "foo(1)"
references a man page is very high.  In any other major mode, it is
likely to be a false positive.  For example, it could be an array
reference in Fortran or Matlab, or a function call in C or C++.  I
fail to see how this kind of guesswork can be a good idea if it mostly
fails.

> The hi-lock functions can be used to highlight a symbol, just like with
> `M-s h .'.  Requiring hi-lock-mode to be enabled beforehand would be
> counterproductive.

Why is it counterproductive, if you are going to activate it anyway,
the first time the user clicks?

> >> When the global value of context-menu-functions
> >> contains one of the proposed functions, right-clicking anywhere
> >> will autoload every package where such context functions are defined.
> >
> > This is over-engineered, IMO.  There should be no need for such
> > complexity.
> 
> What would you suggest to simplify this?

See above.

bug#52973: Adding a few context-menu-mode commands

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: Juri Linkov <juri@linkov.net>, larsi@gnus.org,
>> 52973@debbugs.gnu.org
>> Date: Sat, 08 Jan 2022 19:01:46 +0000
>> 
>> > The way I see it, the functions in man.el are for Man-mode, and those
>> > in hi-lock.el are for hi-lock-mode.
>> 
>> No, the Man functions can be used anywhere you want to read a man page.
>> It checks if the user clicked on something like "emacs(1)", then inserts
>> a entry into the context menu to open the man page at point.
>
> So it will suggest to show a man page when text like this one from the
> ELisp manual is displayed:
>
>      To conserve memory, Emacs does not hold fixed-length 22-bit numbers
>   that are codepoints of text characters within buffers and strings.
>   Rather, Emacs uses a variable-length internal representation of
>   characters, that stores each character as a sequence of 1 to 5 8-bit
>   bytes, depending on the magnitude of its codepoint(1).
>
> When the user displays a man page, the probability that "foo(1)"
> references a man page is very high.  

Yes, but in that case Man-mode should have already inserted a link that
you can just click on, without the need for a context-menu.

> In any other major mode, it is likely to be a false positive.  For
> example, it could be an array reference in Fortran or Matlab, or a
> function call in C or C++.  I fail to see how this kind of guesswork
> can be a good idea if it mostly fails.

True, that could be improved, either by actually additionally checking
if a man pages exists or by restricting the context menu to only operate
on comments.  Either way, my intention was to provide context menu
entries outside of Man-mode.

>> The hi-lock functions can be used to highlight a symbol, just like with
>> `M-s h .'.  Requiring hi-lock-mode to be enabled beforehand would be
>> counterproductive.
>
> Why is it counterproductive, if you are going to activate it anyway,
> the first time the user clicks?

(It might be that we are misunderstanding one another right now, so I
will be verbose.)

If you have nothing highlighted, hi-lock-mode is disabled.  By clicking
on a symbol, an entry is added to the context menu to highlight the
symbol.  If this were only to be done if hi-lock-mode is enabled, you
couldn't highlight anything, unless you had previously already
highlighted something without use of the context menu.  The reasoning is
basically the same as why highlight-symbol-at-point is bound to the
global map and not to hi-lock-map.

>> >> When the global value of context-menu-functions
>> >> contains one of the proposed functions, right-clicking anywhere
>> >> will autoload every package where such context functions are defined.
>> >
>> > This is over-engineered, IMO.  There should be no need for such
>> > complexity.
>> 
>> What would you suggest to simplify this?
>
> See above.

-- 
	Philip Kaludercic

bug#52973: Adding a few context-menu-mode commands

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: juri@linkov.net,  larsi@gnus.org,  52973@debbugs.gnu.org
> Date: Sat, 08 Jan 2022 19:39:41 +0000
> 
> >> No, the Man functions can be used anywhere you want to read a man page.
> >> It checks if the user clicked on something like "emacs(1)", then inserts
> >> a entry into the context menu to open the man page at point.
> >
> > So it will suggest to show a man page when text like this one from the
> > ELisp manual is displayed:
> >
> >      To conserve memory, Emacs does not hold fixed-length 22-bit numbers
> >   that are codepoints of text characters within buffers and strings.
> >   Rather, Emacs uses a variable-length internal representation of
> >   characters, that stores each character as a sequence of 1 to 5 8-bit
> >   bytes, depending on the magnitude of its codepoint(1).
> >
> > When the user displays a man page, the probability that "foo(1)"
> > references a man page is very high.  
> 
> Yes, but in that case Man-mode should have already inserted a link that
> you can just click on, without the need for a context-menu.

So let me step back a notch and ask: how else can we cause the context
menus to be automatically populated in a given buffer, once
context-menu-mode is turned on?  It must be some buffer-local feature,
because different buffers should in principle show different context
menus.  That's why I thought about modes -- those are always
buffer-local, and mode initialization code runs in every buffer where
the mode is turned on, so we have a place to produce the context
menus.

If you want to have context menus populated regardless of the modes,
what other buffer-specific mechanism can we employ?  IOW, what would
be the trigger for populating the context menus?  It cannot be the
user, because that makes no sense to me: the user already told us
he/she wants those menus when he/she turned on the context-menu-mode.

bug#52973: Adding a few context-menu-mode commands

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> None of the proposed functions is specific to a mode.
> When the global value of context-menu-functions
> contains one of the proposed functions, right-clicking anywhere
> will autoload every package where such context functions are defined.

Ah, I see.  I misunderstood how the context menu machinery works -- I
thought it contained mode-specific stuff, and in addition, things that
are relevant at the point.  That is, if you're over a text like
"foo(1)", then there'd be a predicate to say that this might be a
manual reference, and then you'd get the Man context menu.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#52973: Adding a few context-menu-mode commands

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Philip Kaludercic <philipk@posteo.net>,
>   52973@debbugs.gnu.org
> Date: Wed, 12 Jan 2022 07:16:20 +0100
> 
> Juri Linkov <juri@linkov.net> writes:
> 
> > None of the proposed functions is specific to a mode.
> > When the global value of context-menu-functions
> > contains one of the proposed functions, right-clicking anywhere
> > will autoload every package where such context functions are defined.
> 
> Ah, I see.  I misunderstood how the context menu machinery works -- I
> thought it contained mode-specific stuff, and in addition, things that
> are relevant at the point.  That is, if you're over a text like
> "foo(1)", then there'd be a predicate to say that this might be a
> manual reference, and then you'd get the Man context menu.

How do we make sure stuff like "foo(1)" doesn't cause a lot of false
positives when applied in modes whose idea of what that means is very
different from Man-mode?

More importantly, if this stuff is supposed to be global, how do we
provide the users with a context-menu-mode which seamlessly does TRT
without asking the user to invest too much effort into populating
his/her menus?  I'm not aware of any popular application out there
which expects the users to customize context menus before they work as
expected, i.e. show relevant information in relevant places without
including a lot of irrelevant menu items.

bug#52973: Adding a few context-menu-mode commands

[Juri Linkov]

>> Ah, I see.  I misunderstood how the context menu machinery works -- I
>> thought it contained mode-specific stuff, and in addition, things that
>> are relevant at the point.  That is, if you're over a text like
>> "foo(1)", then there'd be a predicate to say that this might be a
>> manual reference, and then you'd get the Man context menu.
>
> How do we make sure stuff like "foo(1)" doesn't cause a lot of false
> positives when applied in modes whose idea of what that means is very
> different from Man-mode?

For example, today while editing a shell script I needed to consult the
man page about the arguments of the command `zenity` used in the script.
It takes too many keystrokes to type `M-x man RET zenity RET'
or first to move point to this command, then to type `M-x man RET RET'.

With the context menu, it's just one click: press the right mouse button
on the command name, select the item "Open man page", and release the
mouse button.

As you can see, there is no special syntax "foo(1)" used in the script.
The context menu item "Open man page" might be useful on any word
that can show a man page for any command or function.

This means that the item "Open man page" can't be added to the
context menu by default, because it makes no sense most of the time.

But when a user can tolerate this mostly useless menu item,
then the user could customize the context-menu-functions
and add the item that is used occasionally.

bug#52973: Adding a few context-menu-mode commands

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  philipk@posteo.net,
>   52973@debbugs.gnu.org
> Date: Wed, 12 Jan 2022 19:16:22 +0200
> 
> > How do we make sure stuff like "foo(1)" doesn't cause a lot of false
> > positives when applied in modes whose idea of what that means is very
> > different from Man-mode?

I don't think you answered my question above.

> For example, today while editing a shell script I needed to consult the
> man page about the arguments of the command `zenity` used in the script.
> It takes too many keystrokes to type `M-x man RET zenity RET'
> or first to move point to this command, then to type `M-x man RET RET'.
> 
> With the context menu, it's just one click: press the right mouse button
> on the command name, select the item "Open man page", and release the
> mouse button.
> 
> As you can see, there is no special syntax "foo(1)" used in the script.
> The context menu item "Open man page" might be useful on any word
> that can show a man page for any command or function.
> 
> This means that the item "Open man page" can't be added to the
> context menu by default, because it makes no sense most of the time.

I don't get it: is the "Open man page" item in the context menu useful
or is it useless?  The beginning of your description sounds like
saying that it's useful, and I almost wanted to ask: so you assume
that the user will decide when this item makes sense or not, and
therefore we shouldn't be bothered by potential false positives?"

But then you say that this item is mostly useless and shouldn't be in
the context menu by default?  That sounds like a contradiction of the
success story with which you started, where the existence of the menu
item is a win, isn't it?

And then this conclusion:

> But when a user can tolerate this mostly useless menu item,
> then the user could customize the context-menu-functions
> and add the item that is used occasionally.

How would the user decide whether he can tolerate this mostly useless
menu item?  And why should this burden be on the user's shoulders?

bug#52973: Adding a few context-menu-mode commands

[Juri Linkov]

>> > How do we make sure stuff like "foo(1)" doesn't cause a lot of false
>> > positives when applied in modes whose idea of what that means is very
>> > different from Man-mode?
>
> I don't think you answered my question above.

The answer is that we can't make sure stuff like "foo" doesn't cause
false positives.

>> For example, today while editing a shell script I needed to consult the
>> man page about the arguments of the command `zenity` used in the script.
>> It takes too many keystrokes to type `M-x man RET zenity RET'
>> or first to move point to this command, then to type `M-x man RET RET'.
>> 
>> With the context menu, it's just one click: press the right mouse button
>> on the command name, select the item "Open man page", and release the
>> mouse button.
>> 
>> As you can see, there is no special syntax "foo(1)" used in the script.
>> The context menu item "Open man page" might be useful on any word
>> that can show a man page for any command or function.
>> 
>> This means that the item "Open man page" can't be added to the
>> context menu by default, because it makes no sense most of the time.
>
> I don't get it: is the "Open man page" item in the context menu useful
> or is it useless?  The beginning of your description sounds like
> saying that it's useful, and I almost wanted to ask: so you assume
> that the user will decide when this item makes sense or not, and
> therefore we shouldn't be bothered by potential false positives?"
>
> But then you say that this item is mostly useless and shouldn't be in
> the context menu by default?  That sounds like a contradiction of the
> success story with which you started, where the existence of the menu
> item is a win, isn't it?

It's useless for most users, so it's not suitable to be enabled by default.
Only a minority of users might want to customize and add it.

> And then this conclusion:
>
>> But when a user can tolerate this mostly useless menu item,
>> then the user could customize the context-menu-functions
>> and add the item that is used occasionally.
>
> How would the user decide whether he can tolerate this mostly useless
> menu item?  And why should this burden be on the user's shoulders?

This is suitable for users that consult man pages often,
or users can add the "Open man page" item buffer-locally
in some modes.

bug#52973: Adding a few context-menu-mode commands

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: larsi@gnus.org,  philipk@posteo.net,  52973@debbugs.gnu.org
> Date: Wed, 12 Jan 2022 20:03:51 +0200
> 
> > But then you say that this item is mostly useless and shouldn't be in
> > the context menu by default?  That sounds like a contradiction of the
> > success story with which you started, where the existence of the menu
> > item is a win, isn't it?
> 
> It's useless for most users, so it's not suitable to be enabled by default.
> Only a minority of users might want to customize and add it.
> 
> > And then this conclusion:
> >
> >> But when a user can tolerate this mostly useless menu item,
> >> then the user could customize the context-menu-functions
> >> and add the item that is used occasionally.
> >
> > How would the user decide whether he can tolerate this mostly useless
> > menu item?  And why should this burden be on the user's shoulders?
> 
> This is suitable for users that consult man pages often,
> or users can add the "Open man page" item buffer-locally
> in some modes.

A menu item that is not used does no special harm.  So why not have
these items in the menus by default?

Requesting the users to activate those items makes little sense to me,
since these obscure customizations are hardly discoverable.

bug#52973: Adding a few context-menu-mode commands

[Juri Linkov]

>> > But then you say that this item is mostly useless and shouldn't be in
>> > the context menu by default?  That sounds like a contradiction of the
>> > success story with which you started, where the existence of the menu
>> > item is a win, isn't it?
>> 
>> It's useless for most users, so it's not suitable to be enabled by default.
>> Only a minority of users might want to customize and add it.
>> 
>> > And then this conclusion:
>> >
>> >> But when a user can tolerate this mostly useless menu item,
>> >> then the user could customize the context-menu-functions
>> >> and add the item that is used occasionally.
>> >
>> > How would the user decide whether he can tolerate this mostly useless
>> > menu item?  And why should this burden be on the user's shoulders?
>> 
>> This is suitable for users that consult man pages often,
>> or users can add the "Open man page" item buffer-locally
>> in some modes.
>
> A menu item that is not used does no special harm.  So why not have
> these items in the menus by default?

Adding all these items by default will load all these packages by default,
including man.el, hi-lock.el, etc.

bug#52973: Adding a few context-menu-mode commands

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: larsi@gnus.org,  philipk@posteo.net,  52973@debbugs.gnu.org
> Date: Wed, 12 Jan 2022 21:41:04 +0200
> 
> > A menu item that is not used does no special harm.  So why not have
> > these items in the menus by default?
> 
> Adding all these items by default will load all these packages by default,
> including man.el, hi-lock.el, etc.

When will that load these packages?  When context-menu-mode is turned
on, when the menu is actually popped up, or something else?

bug#52973: Adding a few context-menu-mode commands

[Juri Linkov]

>> > A menu item that is not used does no special harm.  So why not have
>> > these items in the menus by default?
>> 
>> Adding all these items by default will load all these packages by default,
>> including man.el, hi-lock.el, etc.
>
> When will that load these packages?  When context-menu-mode is turned
> on, when the menu is actually popped up, or something else?

When the menu is popped up the first time.

bug#52973: Adding a few context-menu-mode commands

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: larsi@gnus.org,  philipk@posteo.net,  52973@debbugs.gnu.org
> Date: Wed, 12 Jan 2022 22:00:37 +0200
> 
> >> > A menu item that is not used does no special harm.  So why not have
> >> > these items in the menus by default?
> >> 
> >> Adding all these items by default will load all these packages by default,
> >> including man.el, hi-lock.el, etc.
> >
> > When will that load these packages?  When context-menu-mode is turned
> > on, when the menu is actually popped up, or something else?
> 
> When the menu is popped up the first time.

Then why is that a problem?

We could alternatively only have these items when the corresponding
package is loaded, but you rejected that possibility, AFAIU.

bug#52973: Adding a few context-menu-mode commands

[Juri Linkov]

>> >> > A menu item that is not used does no special harm.  So why not have
>> >> > these items in the menus by default?
>> >>
>> >> Adding all these items by default will load all these packages by default,
>> >> including man.el, hi-lock.el, etc.
>> >
>> > When will that load these packages?  When context-menu-mode is turned
>> > on, when the menu is actually popped up, or something else?
>>
>> When the menu is popped up the first time.
>
> Then why is that a problem?

The problem is that irrelevant packages will be loaded by default.

> We could alternatively only have these items when the corresponding
> package is loaded, but you rejected that possibility, AFAIU.

This means there are no hi-lock/man items by default.
Then once the user used `M-x man' or `M-x highlight-regexp',
these items will surprisingly appear in the global menu.
This makes no sense, there are no such magic things happened
on the menu bar.

bug#52973: Adding a few context-menu-mode commands

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: larsi@gnus.org,  philipk@posteo.net,  52973@debbugs.gnu.org
> Date: Thu, 13 Jan 2022 10:39:25 +0200
> 
> >> > When will that load these packages?  When context-menu-mode is turned
> >> > on, when the menu is actually popped up, or something else?
> >>
> >> When the menu is popped up the first time.
> >
> > Then why is that a problem?
> 
> The problem is that irrelevant packages will be loaded by default.

They aren't irrelevant: the user wants to use their context-menu
entries.  How is this different from when the user customizes some
option that belongs to a package, or displays its documentation?

> > We could alternatively only have these items when the corresponding
> > package is loaded, but you rejected that possibility, AFAIU.
> 
> This means there are no hi-lock/man items by default.

The same will happen under your suggestion, won't it?

> Then once the user used `M-x man' or `M-x highlight-regexp',
> these items will surprisingly appear in the global menu.

That's no more surprising that having, e.g.,

  M-: (setq FOO- TAB

complete on variables from the package FOO only after it's loaded.

> This makes no sense, there are no such magic things happened
> on the menu bar.

I guess our notions of what makes sense are very different, because
what doesn't make sense to you does for me, and vice versa.  I'm not
sure how to reconcile such opposite opinions.

bug#52973: Adding a few context-menu-mode commands

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> For example, today while editing a shell script I needed to consult the
> man page about the arguments of the command `zenity` used in the script.
> It takes too many keystrokes to type `M-x man RET zenity RET'
> or first to move point to this command, then to type `M-x man RET RET'.
>
> With the context menu, it's just one click: press the right mouse button
> on the command name, select the item "Open man page", and release the
> mouse button.

So it sounds to me like shell-script-mode (and derivatives and other
shell-ish modes) should have the `man' bits of the context menu enabled
by default?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#52973: Adding a few context-menu-mode commands

[Juri Linkov]

>> For example, today while editing a shell script I needed to consult the
>> man page about the arguments of the command `zenity` used in the script.
>> It takes too many keystrokes to type `M-x man RET zenity RET'
>> or first to move point to this command, then to type `M-x man RET RET'.
>>
>> With the context menu, it's just one click: press the right mouse button
>> on the command name, select the item "Open man page", and release the
>> mouse button.
>
> So it sounds to me like shell-script-mode (and derivatives and other
> shell-ish modes) should have the `man' bits of the context menu enabled
> by default?

Nope.  This `man' menu item might be useful everywhere, for example,
in this Gnus Article buffer, to look up the command cited above.

bug#52973: Adding a few context-menu-mode commands

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>> So it sounds to me like shell-script-mode (and derivatives and other
>> shell-ish modes) should have the `man' bits of the context menu enabled
>> by default?
>
> Nope.  This `man' menu item might be useful everywhere, for example,
> in this Gnus Article buffer, to look up the command cited above.

It might be, and I think it's fine to let people customise that, if they
want it.

But it seems to me like that context menu should work by default in
shell-script-modeish buffers -- I think pretty much everybody would like
to have it there.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#52973: Adding a few context-menu-mode commands

[Juri Linkov]

>>> So it sounds to me like shell-script-mode (and derivatives and other
>>> shell-ish modes) should have the `man' bits of the context menu enabled
>>> by default?
>>
>> Nope.  This `man' menu item might be useful everywhere, for example,
>> in this Gnus Article buffer, to look up the command cited above.
>
> It might be, and I think it's fine to let people customise that, if they
> want it.

Agreed, everyone can customize the contents of their context menus.
But Eli wants to reject new functions only because they are not added
to the menu by default.

> But it seems to me like that context menu should work by default in
> shell-script-modeish buffers -- I think pretty much everybody would like
> to have it there.

Actually, the context menu already works by default in all shell related modes.
The problem is that adding the man-menu item by default will load man.el
in every shell-script buffer.

bug#52973: Adding a few context-menu-mode commands

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> Agreed, everyone can customize the contents of their context menus.
> But Eli wants to reject new functions only because they are not added
> to the menu by default.

I think both Eli and I were somewhat confused as to which parts of the
context menu stuff works out of the box and which needs customisation by
the user.  I don't think it'd be a good idea for all context menus to be
added to all modes, but they should be added to some modes, at least.
Probably.

>> But it seems to me like that context menu should work by default in
>> shell-script-modeish buffers -- I think pretty much everybody would like
>> to have it there.
>
> Actually, the context menu already works by default in all shell related modes.
> The problem is that adding the man-menu item by default will load man.el
> in every shell-script buffer.

Is it possible to postpone that loading until the user actually hits
mouse-3?  If so, I think it's fine for mouse-3 in these modes to load
man.el.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#52973: Adding a few context-menu-mode commands

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  philipk@posteo.net,  52973@debbugs.gnu.org
> Date: Thu, 13 Jan 2022 11:10:09 +0200
> 
> Eli wants to reject new functions only because they are not added to
> the menu by default.

No, because there doesn't seem to be _any_ way of having them added by
default.  IOW, AFIU your proposal would _force_ users to customize
context menus before they can have these entries there.  That doesn't
make sense to me.

bug#52973: Adding a few context-menu-mode commands

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  philipk@posteo.net,  52973@debbugs.gnu.org
> Date: Thu, 13 Jan 2022 07:03:33 +0100
> 
> Juri Linkov <juri@linkov.net> writes:
> 
> > For example, today while editing a shell script I needed to consult the
> > man page about the arguments of the command `zenity` used in the script.
> > It takes too many keystrokes to type `M-x man RET zenity RET'
> > or first to move point to this command, then to type `M-x man RET RET'.
> >
> > With the context menu, it's just one click: press the right mouse button
> > on the command name, select the item "Open man page", and release the
> > mouse button.
> 
> So it sounds to me like shell-script-mode (and derivatives and other
> shell-ish modes) should have the `man' bits of the context menu enabled
> by default?

The mode-based approach was what I proposed (and even thought it was
already implemented), but Juri seems to reject it.

bug#52973: Adding a few context-menu-mode commands

[Lars Ingebrigtsen]

Philip Kaludercic <philipk@posteo.net> writes:

> * lisp/net/webjump.el (webjump-default-search-engine): Add user option
> (webjump-choose-search-engine): Add function

I think putting this shared functionality in the webjump package isn't
optimal.  Webjump is "webjump.el --- programmable Web hotlist", and this
doesn't seem related.  

browse-url (or even url-something) would be more natural, I think.

The functionality otherwise looks good to me.

One micro-comment on the code:

> +(make-obsolete-variable 'eww-search-prefix
> +                        "webjump-default-search-engine"

Should be:

> +(make-obsolete-variable 'eww-search-prefix
> +                        'webjump-default-search-engine


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#52973: Adding a few context-menu-mode commands

[Juri Linkov]

>> * lisp/net/webjump.el (webjump-default-search-engine): Add user option
>> (webjump-choose-search-engine): Add function
>
> I think putting this shared functionality in the webjump package isn't
> optimal.  Webjump is "webjump.el --- programmable Web hotlist", and this
> doesn't seem related.  
>
> browse-url (or even url-something) would be more natural, I think.

webjump.el contains a list of search engines,
browse-url.el contains a list or web browsers.

bug#52973: Adding a few context-menu-mode commands

[Philip Kaludercic]

I just wanted to apply this patch, then I noticed that this would also
change the default browser for EWW from html.duckduckgo.com to
duckduckgo.com.  The effect is that every search query it redirected to
the JS-free version.  Any ideas how to fix this?  Should I just remove
the EWW integration, or change the DuckDuckGo URL to the HTML-version?

Philip Kaludercic <philipk@posteo.net> writes:

> Juri Linkov <juri@linkov.net> writes:
>
>>>> Maybe then a better place to add new functions would be in
>>>> lisp/net/webjump.el.  webjump is a package created exactly
>>>> for this purpose.  Then new functions could share the same
>>>> prefix webjump-.
>>>
>>> I didn't know about webjump, thank you for the hint.  My only fear is
>>> that the prefix would make the functionality harder to discover.
>>
>> The fact that its name starts with the word "web" improves
>> discoverability.
>
> How is this?
>
> From 2a32d1f7df0b8dfdceb3f63476df150d55215b5d Mon Sep 17 00:00:00 2001
> From: Philip Kaludercic <philipk@posteo.net>
> Date: Tue, 4 Jan 2022 20:36:32 +0100
> Subject: [PATCH] Add search engine functionality
>
> * lisp/net/eww.el (eww-search-prefix): Deprecate user option
> (eww): Use webjump-search-query
> * lisp/net/webjump.el (webjump-default-search-engine): Add user option
> (webjump-choose-search-engine): Add function
> (webjump-search-query): Add function
> (webjump-search): Add autoloaded command
> (webjump-search-at-point): Add autoloaded command
> (webjump-search-at-mouse): Add command
> (webjump-search-context-menu): Add function for context-menu support.
> ---
>  lisp/misc.el        |  1 +
>  lisp/net/eww.el     | 10 +++---
>  lisp/net/webjump.el | 80 ++++++++++++++++++++++++++++++++++++++++++++-
>  3 files changed, 86 insertions(+), 5 deletions(-)
>
> diff --git a/lisp/misc.el b/lisp/misc.el
> index 39ec9497d7..6e5aede789 100644
> --- a/lisp/misc.el
> +++ b/lisp/misc.el
> @@ -27,6 +27,7 @@
>  
>  (eval-when-compile
>    (require 'tabulated-list))
> +(require 'cl-lib)
>  
>  ;;;###autoload
>  (defun copy-from-above-command (&optional arg)
> diff --git a/lisp/net/eww.el b/lisp/net/eww.el
> index 8930eb427d..2ef6b35100 100644
> --- a/lisp/net/eww.el
> +++ b/lisp/net/eww.el
> @@ -33,6 +33,7 @@
>  (require 'url)
>  (require 'url-queue)
>  (require 'xdg)
> +(require 'webjump)
>  (eval-when-compile (require 'subr-x))
>  
>  (defgroup eww nil
> @@ -55,6 +56,9 @@ eww-search-prefix
>    :version "24.4"
>    :group 'eww
>    :type 'string)
> +(make-obsolete-variable 'eww-search-prefix
> +                        "webjump-default-search-engine"
> +                        "29.1")
>  
>  (defcustom eww-use-browse-url "\\`mailto:"
>    "EWW will use `browse-url' when following links that match this regexp.
> @@ -355,7 +359,7 @@ eww-browse
>  (defun eww (url &optional new-buffer buffer)
>    "Fetch URL and render the page.
>  If the input doesn't look like an URL or a domain name, the
> -word(s) will be searched for via `eww-search-prefix'.
> +word(s) will be searched for via `webjump-search'.
>  
>  If NEW-BUFFER is non-nil (interactively, the prefix arg), use a
>  new buffer instead of reusing the default EWW buffer.
> @@ -464,9 +468,7 @@ eww--dwim-expand-url
>                 ;; Some sites do not redirect final /
>                 (when (string= (url-filename (url-generic-parse-url url)) "")
>                   (setq url (concat url "/"))))
> -           (setq url (concat eww-search-prefix
> -                             (mapconcat
> -                              #'url-hexify-string (split-string url) "+"))))))
> +           (setq url (webjump-search-query url)))))
>    url)
>  
>  (defun eww--preprocess-html (start end)
> diff --git a/lisp/net/webjump.el b/lisp/net/webjump.el
> index 7547f92d7d..17c9312c54 100644
> --- a/lisp/net/webjump.el
> +++ b/lisp/net/webjump.el
> @@ -370,7 +370,85 @@ webjump-url-fix-trailing-slash
>        (concat url "/")
>      url))
>  
> -;;-----------------------------------------------------------------------------
> +\f
> +;;; Search engine functionality
> +
> +(defcustom webjump-default-search-engine "DuckDuckGo"
> +  "Search engine to use for `webjump-search' and related commands.
> +The string should denote an entry in `webjump-sites', with a
> +`simple-query' entry."
> +  :type 'string)
> +
> +(defun webjump-choose-search-engine ()
> +  "Choose a search engine to use from `webjump-sites'.
> +If no prefix argument was used, the function will return the
> +entry for `webjump-default-search-engine'."
> +  (assoc-string
> +   (if current-prefix-arg
> +       (completing-read
> +        (format-prompt "Use search engine"
> +                       webjump-default-search-engine)
> +        webjump-sites
> +        (lambda (ent)
> +          (and (vectorp (cdr ent))
> +               (eq (aref (cdr ent) 0) 'simple-query)))
> +        t nil nil webjump-default-search-engine)
> +     webjump-default-search-engine)
> +   webjump-sites t))
> +
> +(defun webjump-search-query (string)
> +  "Generate an URL query to search for STRING."
> +  (let ((engine (cdr (webjump-choose-search-engine))))
> +    (webjump-url-fix
> +     (concat (aref engine 2)
> +             (webjump-url-encode string)
> +             (aref engine 3)))))
> +
> +;;;###autoload
> +(defun webjump-search (string)
> +  "Search for STRING using a search engine.
> +If the optional argument ENGINE may be used to override
> +`webjump-default-search-engine'."
> +  (interactive (list (if (use-region-p)
> +                         (buffer-substring (region-beginning) (region-end))
> +                       (read-string "Search: "))))
> +  (browse-url (webjump-search-query string)))
> +
> +;;;###autoload
> +(defun webjump-search-at-point ()
> +  "Search for symbol at point online.
> +See `webjump-search' for more details."
> +  (interactive)
> +  (let ((query (thing-at-point 'symbol)))
> +    (unless query
> +      (user-error "Nothing to search for"))
> +    (webjump-search query)))
> +
> +;;;###autoload
> +(defun webjump-search-at-mouse (click)
> +  "Query an online search engine at CLICK.
> +If a region is active, the entire region will be sent, otherwise
> +the symbol at point will be used.  See `webjump-search' for more
> +details."
> +  (interactive "e")
> +  (let ((query (if (use-region-p)
> +                   (buffer-substring (region-beginning)
> +                                     (region-end))
> +                 (thing-at-mouse click 'symbol))))
> +    (unless (or query (string-match-p "\\`[[:space:]\n]*\\'" query))
> +      (user-error "Nothing to search for"))
> +    (webjump-search query)))
> +
> +;;;###autoload
> +(defun webjump-search-context-menu (menu click)
> +  "Populate MENU with command to search online at CLICK."
> +  (save-excursion
> +    (mouse-set-point click)
> +    (define-key-after menu [webjump-search-separator] menu-bar-separator)
> +    (define-key-after menu [webjump-search-at-mouse]
> +      '(menu-item "Online search" webjump-search-at-mouse
> +                  :help "Search for region or word online")))
> +  menu)
>  
>  (provide 'webjump)
>  
> -- 
> 2.34.0
>
>
> While I agree that web helps, I think a search-online defalias for
> webjump-search would be appreciated when looking for commands via
> apropos.

-- 
	Philip Kaludercic

bug#52973: Adding a few context-menu-mode commands

[Juri Linkov]

> I just wanted to apply this patch, then I noticed that this would also
> change the default browser for EWW from html.duckduckgo.com to
> duckduckgo.com.  The effect is that every search query it redirected to
> the JS-free version.  Any ideas how to fix this?  Should I just remove
> the EWW integration, or change the DuckDuckGo URL to the HTML-version?

Another option would be to add a new webjump engine for HTML DuckDuckGo,
and make it default, then it could be used in eww.
Or change the existing DuckDuckGo to HTML, then also add JS DuckDuckGo
for users who prefer JS-based DuckDuckGo.

bug#52973: Adding a few context-menu-mode commands

[Philip Kaludercic]

Juri Linkov <juri@linkov.net> writes:

>> I just wanted to apply this patch, then I noticed that this would
>> also change the default browser for EWW from html.duckduckgo.com to
>> duckduckgo.com.  The effect is that every search query it redirected
>> to the JS-free version.  Any ideas how to fix this?  Should I just
>> remove the EWW integration, or change the DuckDuckGo URL to the
>> HTML-version?
>
> Another option would be to add a new webjump engine for HTML
> DuckDuckGo, and make it default, then it could be used in eww.  Or
> change the existing DuckDuckGo to HTML, then also add JS DuckDuckGo
> for users who prefer JS-based DuckDuckGo.

As the "default search engine" is a new option, changing the default to
HTML DuckDuckGo should be fine.  I personally use it as by default
search engine, but don't know how popular or unpopular it is.

Adding the default DDG (and perhaps the lite version as well) as
alternatives seems sensible too.

-- 
	Philip Kaludercic

bug#52973: Adding a few context-menu-mode commands

[Lars Ingebrigtsen]

Philip Kaludercic <philipk@posteo.net> writes:

> As the "default search engine" is a new option, changing the default to
> HTML DuckDuckGo should be fine.  I personally use it as by default
> search engine, but don't know how popular or unpopular it is.
>
> Adding the default DDG (and perhaps the lite version as well) as
> alternatives seems sensible too.

The default DDG version has more features than the HTML one, so I think
that's what most people would prefer...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#52973: Adding a few context-menu-mode commands

[Philip Kaludercic]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> As the "default search engine" is a new option, changing the default to
>> HTML DuckDuckGo should be fine.  I personally use it as by default
>> search engine, but don't know how popular or unpopular it is.
>>
>> Adding the default DDG (and perhaps the lite version as well) as
>> alternatives seems sensible too.
>
> The default DDG version has more features than the HTML one, so I think
> that's what most people would prefer...

Maybe one should not only configure a general search engine, but a
search engine depending on a context.  Sometimes you might want to use a
specialised search engine (e.g. hoogle when working on Haskell), and
that should be automatically detected as the default.  In the same way,
if EWW would be using a special "context" to designate that it wants a
JS-free search engine (HTML DuckDuckGo).

-- 
	Philip Kaludercic

bug#52973: Adding a few context-menu-mode commands

[Juri Linkov]

>>> As the "default search engine" is a new option, changing the default to
>>> HTML DuckDuckGo should be fine.  I personally use it as by default
>>> search engine, but don't know how popular or unpopular it is.
>>>
>>> Adding the default DDG (and perhaps the lite version as well) as
>>> alternatives seems sensible too.
>>
>> The default DDG version has more features than the HTML one, so I think
>> that's what most people would prefer...
>
> Maybe one should not only configure a general search engine, but a
> search engine depending on a context.  Sometimes you might want to use a
> specialised search engine (e.g. hoogle when working on Haskell), and
> that should be automatically detected as the default.  In the same way,
> if EWW would be using a special "context" to designate that it wants a
> JS-free search engine (HTML DuckDuckGo).

This makes sense as well with e.g. webjump-context-search-engine.

bug#52973: Adding a few context-menu-mode commands

[Philip Kaludercic]

Juri Linkov <juri@linkov.net> writes:

>>>> As the "default search engine" is a new option, changing the default to
>>>> HTML DuckDuckGo should be fine.  I personally use it as by default
>>>> search engine, but don't know how popular or unpopular it is.
>>>>
>>>> Adding the default DDG (and perhaps the lite version as well) as
>>>> alternatives seems sensible too.
>>>
>>> The default DDG version has more features than the HTML one, so I think
>>> that's what most people would prefer...
>>
>> Maybe one should not only configure a general search engine, but a
>> search engine depending on a context.  Sometimes you might want to use a
>> specialised search engine (e.g. hoogle when working on Haskell), and
>> that should be automatically detected as the default.  In the same way,
>> if EWW would be using a special "context" to designate that it wants a
>> JS-free search engine (HTML DuckDuckGo).
>
> This makes sense as well with e.g. webjump-context-search-engine.

I am not sure what you mean by webjump-context-search-engine.  Should it
be a separate command or a user option?

-- 
	Philip Kaludercic

bug#52973: Adding a few context-menu-mode commands

[Juri Linkov]

>>>>> As the "default search engine" is a new option, changing the default to
>>>>> HTML DuckDuckGo should be fine.  I personally use it as by default
>>>>> search engine, but don't know how popular or unpopular it is.
>>>>>
>>>>> Adding the default DDG (and perhaps the lite version as well) as
>>>>> alternatives seems sensible too.
>>>>
>>>> The default DDG version has more features than the HTML one, so I think
>>>> that's what most people would prefer...
>>>
>>> Maybe one should not only configure a general search engine, but a
>>> search engine depending on a context.  Sometimes you might want to use a
>>> specialised search engine (e.g. hoogle when working on Haskell), and
>>> that should be automatically detected as the default.  In the same way,
>>> if EWW would be using a special "context" to designate that it wants a
>>> JS-free search engine (HTML DuckDuckGo).
>>
>> This makes sense as well with e.g. webjump-context-search-engine.
>
> I am not sure what you mean by webjump-context-search-engine.  Should it
> be a separate command or a user option?

Probably a user option, since you already named the function
webjump-search-context-menu.  Then maybe a better option name would be
webjump-context-menu-default-search?

bug#52973: Adding a few context-menu-mode commands

[Lars Ingebrigtsen]

Philip Kaludercic <philipk@posteo.net> writes:

> Maybe one should not only configure a general search engine, but a
> search engine depending on a context.  Sometimes you might want to use a
> specialised search engine (e.g. hoogle when working on Haskell), and
> that should be automatically detected as the default.  In the same way,
> if EWW would be using a special "context" to designate that it wants a
> JS-free search engine (HTML DuckDuckGo).

Sure, sounds good (but it's not immediately obvious to me how the user
(and packages) would specify these contexts)...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#52973: Adding a few context-menu-mode commands

[Philip Kaludercic]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Maybe one should not only configure a general search engine, but a
>> search engine depending on a context.  Sometimes you might want to use a
>> specialised search engine (e.g. hoogle when working on Haskell), and
>> that should be automatically detected as the default.  In the same way,
>> if EWW would be using a special "context" to designate that it wants a
>> JS-free search engine (HTML DuckDuckGo).
>
> Sure, sounds good (but it's not immediately obvious to me how the user
> (and packages) would specify these contexts)...

I would suggest a variable like `webjump-search-context' that could be
locally bound in cases like eww or set as a buffer local variable for
things like haskell-mode.

The structure and contents of such a variable are another question that
I will try to experiment with once I have the time to do s.

-- 
	Philip Kaludercic

bug#52973: Adding a few context-menu-mode commands

[Lars Ingebrigtsen]

Philip Kaludercic <philipk@posteo.net> writes:

> I would suggest a variable like `webjump-search-context' that could be
> locally bound in cases like eww or set as a buffer local variable for
> things like haskell-mode.

Sounds reasonable to me.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#52973: Adding a few context-menu-mode commands

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 534 bytes --]

Juri Linkov <juri@linkov.net> writes:

>> I am attaching a few patches adding a few features for
>> context-menu-mode, that I mentioned and explained here:
>> https://ruzkuku.com/texts/emacs-mouse.html.
>>
>> Would it be OK to add these to Emacs itself?
>
> Thanks, it would be beneficial to enrich the packages with the
> context-menus.  Man-context-menu is a good addition to the package
> man.el, and hi-lock-context-menu to hi-lock.el.

Here an extension on my previous hi-lock commit, adding the ability to
remove highlighting:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Implement-context-menu-mode-support-for-hi-lock.patch --]
[-- Type: text/x-patch, Size: 1943 bytes --]

From 76addfdb26b172cf1cea56f868f9f3e3afec1a20 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 31 Dec 2021 12:45:52 +0100
Subject: [PATCH] Implement context-menu-mode support for hi-lock

* hi-lock.el (hi-lock-symbol-at-mouse): Add new command
(hi-lock-context-menu): Add new function
---
 lisp/hi-lock.el | 34 ++++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/lisp/hi-lock.el b/lisp/hi-lock.el
index 7d126cb558..0ed2def24c 100644
--- a/lisp/hi-lock.el
+++ b/lisp/hi-lock.el
@@ -854,6 +854,40 @@ hi-lock-unload-function
   ;; continue standard unloading
   nil)
 
+;;; Mouse support
+(defun hi-lock-symbol-at-mouse (click)
+  "Highlight symbol at mouse CLICK."
+  (interactive "e")
+  (save-excursion
+    (mouse-set-point click)
+    (highlight-symbol-at-point)))
+
+(defun hi-lock-unhighlight-at-mouse (click)
+  "Remove highlighting from all regular expressions at CLICK."
+  (interactive "e")
+  (save-excursion
+    (mouse-set-point click)
+    (unless (mapc #'hi-lock-unface-buffer (hi-lock--regexps-at-point))
+      (message "Nothing highlighted at point."))))
+
+(defun hi-lock-context-menu (menu click)
+  "Populate MENU with a menu item to highlight symbol at CLICK."
+  (save-excursion
+    (mouse-set-point click)
+    (let ((sym (thing-at-point 'symbol))
+          (rap  (hi-lock--regexps-at-point)))
+      (when (or sym rap)
+        (define-key-after menu [hi-lick-separator] menu-bar-separator))
+      (when sym
+        (define-key-after menu [hi-lock-add]
+          '(menu-item "Highlight Symbol" highlight-symbol-at-mouse
+                      :help "Highlight symbol at point")))
+      (when rap
+        (define-key-after menu [hi-lock-remove]
+          '(menu-item "Unhighlight Symbol" hi-lock-unhighlight-at-mouse
+                      :help "Remove highlight at point")))))
+  menu)
+
 (provide 'hi-lock)
 
 ;;; hi-lock.el ends here
-- 
2.34.0


[-- Attachment #3: Type: text/plain, Size: 24 bytes --]


-- 
	Philip Kaludercic

bug#52973: Adding a few context-menu-mode commands

[Juri Linkov]

> Here an extension on my previous hi-lock commit, adding the ability to
> remove highlighting:

Thanks, looks good that "Unhighlight Symbol" is added only on
a highlighted symbol.

bug#52973: Adding a few context-menu-mode commands

[Lars Ingebrigtsen]

Philip Kaludercic <philipk@posteo.net> writes:

> I am attaching a few patches adding a few features for
> context-menu-mode, that I mentioned and explained here:
> https://ruzkuku.com/texts/emacs-mouse.html.
>
> Would it be OK to add these to Emacs itself?

These all look OK to me, so I've applied the patches to Emacs 29, and
expanded the `type' of `context-menu-functions' to list them, so that
people can add them more easily.

The discussion then went on to whether there should be an infrastructure
to make modes add more context functions automatically -- and I think
there should be, but it's unclear what that mechanism would look like.
In any case, it seems beyond the scope of this bug report, so I'm
closing it, and a new report should be opened for discussion about the
more general issue (or perhaps discussed on emacs-devel).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#52973: Adding a few context-menu-mode commands

[Philip Kaludercic]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> I am attaching a few patches adding a few features for
>> context-menu-mode, that I mentioned and explained here:
>> https://ruzkuku.com/texts/emacs-mouse.html.
>>
>> Would it be OK to add these to Emacs itself?
>
> These all look OK to me, so I've applied the patches to Emacs 29, and
> expanded the `type' of `context-menu-functions' to list them, so that
> people can add them more easily.

I think that "Add command to invoke a search engine" should be reverted,
because we replaced that with a few commands in webjump, that did not
rely on eww.

> The discussion then went on to whether there should be an infrastructure
> to make modes add more context functions automatically -- and I think
> there should be, but it's unclear what that mechanism would look like.
> In any case, it seems beyond the scope of this bug report, so I'm
> closing it, and a new report should be opened for discussion about the
> more general issue (or perhaps discussed on emacs-devel).

-- 
	Philip Kaludercic

bug#52973: Adding a few context-menu-mode commands

[Lars Ingebrigtsen]

Philip Kaludercic <philipk@posteo.net> writes:

> I think that "Add command to invoke a search engine" should be reverted,
> because we replaced that with a few commands in webjump, that did not
> rely on eww.

Right; reverted now.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no