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: Eli Zaretskii
Subject: bug#52973: Adding a few context-menu-mode commands
Date: Sat, 08 Jan 2022 21:10:41 +0200

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





reply via email to

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