bug-gnu-emacs
[Top][All Lists]
Advanced

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

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


From: Philip Kaludercic
Subject: bug#52973: Adding a few context-menu-mode commands
Date: Sat, 08 Jan 2022 19:39:41 +0000

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





reply via email to

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