unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#9054: 24.0.50; show source in other window
@ 2011-07-11 18:31 Florian Beck
  2011-07-12  8:21 ` martin rudalics
  2021-09-07 18:12 ` Lars Ingebrigtsen
  0 siblings, 2 replies; 57+ messages in thread
From: Florian Beck @ 2011-07-11 18:31 UTC (permalink / raw)
  To: 9054


emacs -Q

Two windows. Run `describe-function' on a function: The help buffer pops
up in the other window. `other-window' and click the link to display the
source file: my original buffer is gone. Very annoying.

What I would like: Either a function that displays the source for the
function at point in the other window or for the *Help* buffer to open
the source file in the same window (i.e. the window which displays the
*Help* buffer).

In GNU Emacs 24.0.50.14 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.4)
 of 2011-07-11 on flo-laptop
Windowing system distributor `The X.Org Foundation', version 11.0.11001000
configured using `configure  '--with-x-toolkit=gtk' 'CFLAGS=-march=core2 -msse2 -mssse3 -mcx16 -mfpmath=sse -O2 -pipe''

-- 
Florian Beck





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2011-07-11 18:31 bug#9054: 24.0.50; show source in other window Florian Beck
@ 2011-07-12  8:21 ` martin rudalics
  2011-08-31 16:52   ` Juri Linkov
  2021-09-07 18:12 ` Lars Ingebrigtsen
  1 sibling, 1 reply; 57+ messages in thread
From: martin rudalics @ 2011-07-12  8:21 UTC (permalink / raw)
  To: Florian Beck; +Cc: 9054

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

 > emacs -Q
 >
 > Two windows. Run `describe-function' on a function: The help buffer pops
 > up in the other window. `other-window' and click the link to display the
 > source file: my original buffer is gone. Very annoying.
 >
 > What I would like: Either a function that displays the source for the
 > function at point in the other window or for the *Help* buffer to open
 > the source file in the same window (i.e. the window which displays the
 > *Help* buffer).

I have written some code to do the former which you can find in the
attachement.  I haven't looked into it for some time but I suppose that
the function you want is called `fsap-find-other' there.

The latter should become easy as soon as the label argument for the
corresponding buffer display call is in place.  You then should be able
to choose any window (including the *Help* itself) for displaying the
source buffer.

martin

[-- Attachment #2: fsap.el --]
[-- Type: application/emacs-lisp, Size: 4675 bytes --]

^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2011-07-12  8:21 ` martin rudalics
@ 2011-08-31 16:52   ` Juri Linkov
  2011-09-01  0:26     ` martin rudalics
  0 siblings, 1 reply; 57+ messages in thread
From: Juri Linkov @ 2011-08-31 16:52 UTC (permalink / raw)
  To: martin rudalics; +Cc: Florian Beck, 9054

> The latter should become easy as soon as the label argument for the
> corresponding buffer display call is in place.  You then should be able
> to choose any window (including the *Help* itself) for displaying the
> source buffer.

Could you please elaborate how this is possible to do with a label?
Do you mean a window's label?  So when displaying the *Help* window
you put a label on it, and when displaying a source buffer from it
you match the same label?





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2011-08-31 16:52   ` Juri Linkov
@ 2011-09-01  0:26     ` martin rudalics
  0 siblings, 0 replies; 57+ messages in thread
From: martin rudalics @ 2011-09-01  0:26 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Florian Beck, 9054

 > Could you please elaborate how this is possible to do with a label?
 > Do you mean a window's label?  So when displaying the *Help* window
 > you put a label on it, and when displaying a source buffer from it
 > you match the same label?

Sorry, the mail you refer to apparently was in my outbox for almost two
months and was now sent by error.  I don't remember what I meant then.

martin





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2011-07-11 18:31 bug#9054: 24.0.50; show source in other window Florian Beck
  2011-07-12  8:21 ` martin rudalics
@ 2021-09-07 18:12 ` Lars Ingebrigtsen
  2021-09-07 19:11   ` martin rudalics
  2021-09-09 17:20   ` Juri Linkov
  1 sibling, 2 replies; 57+ messages in thread
From: Lars Ingebrigtsen @ 2021-09-07 18:12 UTC (permalink / raw)
  To: Florian Beck; +Cc: 9054

Florian Beck <abstraktion@t-online.de> writes:

> Two windows. Run `describe-function' on a function: The help buffer pops
> up in the other window. `other-window' and click the link to display the
> source file: my original buffer is gone. Very annoying.
>
> What I would like: Either a function that displays the source for the
> function at point in the other window or for the *Help* buffer to open
> the source file in the same window (i.e. the window which displays the
> *Help* buffer).

Yes, it would be nice to allow displaying the source in the same window
as the *Help* buffer was displayed in.  Martin, can this somehow be done
via `display-buffer-alist', or would we have to add a new user option
for `help-mode' for this?

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





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-07 18:12 ` Lars Ingebrigtsen
@ 2021-09-07 19:11   ` martin rudalics
  2021-09-07 19:17     ` Lars Ingebrigtsen
  2021-09-09 17:20   ` Juri Linkov
  1 sibling, 1 reply; 57+ messages in thread
From: martin rudalics @ 2021-09-07 19:11 UTC (permalink / raw)
  To: Lars Ingebrigtsen, Florian Beck; +Cc: 9054

 >> Two windows. Run `describe-function' on a function: The help buffer pops
 >> up in the other window. `other-window' and click the link to display the
 >> source file: my original buffer is gone. Very annoying.
 >>
 >> What I would like: Either a function that displays the source for the
 >> function at point in the other window or for the *Help* buffer to open
 >> the source file in the same window (i.e. the window which displays the
 >> *Help* buffer).
 >
 > Yes, it would be nice to allow displaying the source in the same window
 > as the *Help* buffer was displayed in.  Martin, can this somehow be done
 > via `display-buffer-alist', or would we have to add a new user option
 > for `help-mode' for this?

See the discussion of Bug#36767.

martin





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-07 19:11   ` martin rudalics
@ 2021-09-07 19:17     ` Lars Ingebrigtsen
  2021-09-08  8:29       ` martin rudalics
  0 siblings, 1 reply; 57+ messages in thread
From: Lars Ingebrigtsen @ 2021-09-07 19:17 UTC (permalink / raw)
  To: martin rudalics; +Cc: Florian Beck, 9054

martin rudalics <rudalics@gmx.at> writes:

>> Yes, it would be nice to allow displaying the source in the same window
>> as the *Help* buffer was displayed in.  Martin, can this somehow be done
>> via `display-buffer-alist', or would we have to add a new user option
>> for `help-mode' for this?
>
> See the discussion of Bug#36767.

Do you mean the help-link-follow patch you proposed there?  I don't
think that's quite what the user wanted here -- we just want to make the
pop-to-buffer in help-function-def--button-function not pop to another
window, but just display in the current window.

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





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-07 19:17     ` Lars Ingebrigtsen
@ 2021-09-08  8:29       ` martin rudalics
  2021-09-08 10:30         ` Lars Ingebrigtsen
  0 siblings, 1 reply; 57+ messages in thread
From: martin rudalics @ 2021-09-08  8:29 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Florian Beck, 9054

 >>> Yes, it would be nice to allow displaying the source in the same window
 >>> as the *Help* buffer was displayed in.  Martin, can this somehow be done
 >>> via `display-buffer-alist', or would we have to add a new user option
 >>> for `help-mode' for this?
 >>
 >> See the discussion of Bug#36767.
 >
 > Do you mean the help-link-follow patch you proposed there?  I don't
 > think that's quite what the user wanted here -- we just want to make the
 > pop-to-buffer in help-function-def--button-function not pop to another
 > window, but just display in the current window.

Both are about displaying the source in the same window.  And since we
cannot use `display-buffer-alist' here (we'd hardly be able to come up
with a suitable regexp for any buffer that is referenced by *Help*) we
do have to provide a suitable function for displaying the source anyway.

But what I'd like to see first are the typical usage patterns (Eli gave
one) that apply here.  [Personally, I'm using a function bound to
M-<return> that tries to go to the source of any symbol or tag around
point and I usually build up an entire chain of such calls to find the
object I am really interested in.  So I never have to follow a link
from *Help* but instead follow the function or variable name cited at
position 1 of the *Help* buffer via M-<return>.]

Are people usually done after they followed the link once or do they dig
further - in that window?  Do they want to return to the *Help* buffer
after they found what they wanted (probably not) and/or do they want to
restore the window configuration that existed before popping up *Help*.
Eli, for example, wants to keep the *Help* window live - for some time
at least, IIRC.

As soon as we've established these patterns, we can provide a solution
that fixes the `pop-to-buffer' in `help-function-def--button-function'
and in a calling convention based on key combinations only.

martin





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-08  8:29       ` martin rudalics
@ 2021-09-08 10:30         ` Lars Ingebrigtsen
  2021-09-09  8:34           ` martin rudalics
  0 siblings, 1 reply; 57+ messages in thread
From: Lars Ingebrigtsen @ 2021-09-08 10:30 UTC (permalink / raw)
  To: martin rudalics; +Cc: Florian Beck, 9054

martin rudalics <rudalics@gmx.at> writes:

> Are people usually done after they followed the link once or do they dig
> further - in that window?  Do they want to return to the *Help* buffer
> after they found what they wanted (probably not) and/or do they want to
> restore the window configuration that existed before popping up *Help*.

My usage pattern is often that I `C-h f' some symbol, hit `s', and then
want to follow a chain of calls, so I normally don't return to the
*Help* buffer -- so I don't care whether it's buried or not in those
cases.

But sometimes I do want to look at what the manual says, in which case I
want to pop back to the *Help* buffer and hit `i'.  So in that case I
don't want the *Help* buffer buried.

I don't want the buffer config to be restored after `s'.

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





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-08 10:30         ` Lars Ingebrigtsen
@ 2021-09-09  8:34           ` martin rudalics
  2021-09-09 13:13             ` Lars Ingebrigtsen
  0 siblings, 1 reply; 57+ messages in thread
From: martin rudalics @ 2021-09-09  8:34 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Florian Beck, 9054

 > My usage pattern is often that I `C-h f' some symbol, hit `s', and then
 > want to follow a chain of calls, so I normally don't return to the
 > *Help* buffer -- so I don't care whether it's buried or not in those
 > cases.

The question here is whether you want to follow that "chain of calls" in
the same window where *Help* appeared or in another one - by default the
one selected when you did C-h f.

 > But sometimes I do want to look at what the manual says, in which case I
 > want to pop back to the *Help* buffer and hit `i'.  So in that case I
 > don't want the *Help* buffer buried.

Since you use the idiom "pop back" it seems that you did manage to use the
former *Help* window for "s".

 > I don't want the buffer config to be restored after `s'.

Does "s" ever do such a thing?  What is a "buffer config"?  A window
configuration?

martin





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-09  8:34           ` martin rudalics
@ 2021-09-09 13:13             ` Lars Ingebrigtsen
  2021-09-10  8:34               ` martin rudalics
  0 siblings, 1 reply; 57+ messages in thread
From: Lars Ingebrigtsen @ 2021-09-09 13:13 UTC (permalink / raw)
  To: martin rudalics; +Cc: Florian Beck, 9054

martin rudalics <rudalics@gmx.at> writes:

> The question here is whether you want to follow that "chain of calls" in
> the same window where *Help* appeared or in another one - by default the
> one selected when you did C-h f.

Yes, that would be my preference.

>> But sometimes I do want to look at what the manual says, in which case I
>> want to pop back to the *Help* buffer and hit `i'.  So in that case I
>> don't want the *Help* buffer buried.
>
> Since you use the idiom "pop back" it seems that you did manage to use the
> former *Help* window for "s".

I'm not sure I understand what you mean here?  I don't mean anything in
particular with "pop back" here other than "change to the buffer".

>> I don't want the buffer config to be restored after `s'.
>
> Does "s" ever do such a thing?  What is a "buffer config"?  A window
> configuration?

Yes, I meant window configuration, and no, but you asked, I think?

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





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-07 18:12 ` Lars Ingebrigtsen
  2021-09-07 19:11   ` martin rudalics
@ 2021-09-09 17:20   ` Juri Linkov
  2021-09-10 10:21     ` Lars Ingebrigtsen
  1 sibling, 1 reply; 57+ messages in thread
From: Juri Linkov @ 2021-09-09 17:20 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Florian Beck, 9054

>> What I would like: Either a function that displays the source for the
>> function at point in the other window or for the *Help* buffer to open
>> the source file in the same window (i.e. the window which displays the
>> *Help* buffer).
>
> Yes, it would be nice to allow displaying the source in the same window
> as the *Help* buffer was displayed in.  Martin, can this somehow be done
> via `display-buffer-alist', or would we have to add a new user option
> for `help-mode' for this?

I use such customization:

* Clicking a link from the =*Help*= buffer opens source code in the same window:

#+begin_src emacs-lisp
(defun display-buffer-from-help-p (_buffer-name _action)
  (unless current-prefix-arg
    (with-current-buffer (window-buffer)
      (derived-mode-p 'help-mode))))

(push '(display-buffer-from-help-p
        display-buffer-same-window
        (inhibit-same-window . nil))
      display-buffer-alist)
#+end_src





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-09 13:13             ` Lars Ingebrigtsen
@ 2021-09-10  8:34               ` martin rudalics
  0 siblings, 0 replies; 57+ messages in thread
From: martin rudalics @ 2021-09-10  8:34 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Florian Beck, 9054

 >> The question here is whether you want to follow that "chain of calls" in
 >> the same window where *Help* appeared or in another one - by default the
 >> one selected when you did C-h f.
 >
 > Yes, that would be my preference.

Did you try Juri's proposal?

 >>> But sometimes I do want to look at what the manual says, in which case I
 >>> want to pop back to the *Help* buffer and hit `i'.  So in that case I
 >>> don't want the *Help* buffer buried.
 >>
 >> Since you use the idiom "pop back" it seems that you did manage to use the
 >> former *Help* window for "s".
 >
 > I'm not sure I understand what you mean here?  I don't mean anything in
 > particular with "pop back" here other than "change to the buffer".

Sorry.  I didn't know about these keybinding like "s" and "i" in
`help-mode'.  I invented similar ones long before and still use them.

 >>> I don't want the buffer config to be restored after `s'.
 >>
 >> Does "s" ever do such a thing?  What is a "buffer config"?  A window
 >> configuration?
 >
 > Yes, I meant window configuration, and no, but you asked, I think?

I did.

martin





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-09 17:20   ` Juri Linkov
@ 2021-09-10 10:21     ` Lars Ingebrigtsen
  2021-09-10 16:15       ` Juri Linkov
  2021-09-11  8:35       ` martin rudalics
  0 siblings, 2 replies; 57+ messages in thread
From: Lars Ingebrigtsen @ 2021-09-10 10:21 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Florian Beck, 9054

Juri Linkov <juri@linkov.net> writes:

> I use such customization:
>
> * Clicking a link from the =*Help*= buffer opens source code in the same window:
>
> #+begin_src emacs-lisp
> (defun display-buffer-from-help-p (_buffer-name _action)
>   (unless current-prefix-arg
>     (with-current-buffer (window-buffer)
>       (derived-mode-p 'help-mode))))
>
> (push '(display-buffer-from-help-p
>         display-buffer-same-window
>         (inhibit-same-window . nil))
>       display-buffer-alist)
> #+end_src
>

Nice.  It's a bit of a mouthful for users, though.

martin rudalics <rudalics@gmx.at> writes:

>>> The question here is whether you want to follow that "chain of calls" in
>>> the same window where *Help* appeared or in another one - by default the
>>> one selected when you did C-h f.
>>
>> Yes, that would be my preference.
>
> Did you try Juri's proposal?

I don't think we can expect users to do all that just to change the
behaviour of these *Help* commands.  Perhaps if we put the
`display-buffer-from-help-p' function into Emacs.

`help-window-select' is (if you squint at it) the kinda-sorta user
option in the opposite direction, so perhaps the way forward here is to
just define a new user option, or all a new value (`both'?) that affects
how windows are selected from the *Help* window.  I guess a new user
option would be the simplest.

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





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-10 10:21     ` Lars Ingebrigtsen
@ 2021-09-10 16:15       ` Juri Linkov
  2021-09-11  8:38         ` martin rudalics
  2021-09-11  8:35       ` martin rudalics
  1 sibling, 1 reply; 57+ messages in thread
From: Juri Linkov @ 2021-09-10 16:15 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Florian Beck, 9054

>> (defun display-buffer-from-help-p (_buffer-name _action)
>>   (unless current-prefix-arg
>>     (with-current-buffer (window-buffer)
>>       (derived-mode-p 'help-mode))))
>>
>> (push '(display-buffer-from-help-p
>>         display-buffer-same-window
>>         (inhibit-same-window . nil))
>>       display-buffer-alist)
>
> Nice.  It's a bit of a mouthful for users, though.
> ...
> I don't think we can expect users to do all that just to change the
> behaviour of these *Help* commands.  Perhaps if we put the
> `display-buffer-from-help-p' function into Emacs.

Or maybe support specifying a mode directly in the condition part
of display-buffer-alist, but this is still too complex.

> `help-window-select' is (if you squint at it) the kinda-sorta user
> option in the opposite direction, so perhaps the way forward here is to
> just define a new user option, or all a new value (`both'?) that affects
> how windows are selected from the *Help* window.  I guess a new user
> option would be the simplest.

A new user option for buffers outgoing from Help would be fine.





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-10 10:21     ` Lars Ingebrigtsen
  2021-09-10 16:15       ` Juri Linkov
@ 2021-09-11  8:35       ` martin rudalics
  2021-09-11 12:43         ` Lars Ingebrigtsen
  1 sibling, 1 reply; 57+ messages in thread
From: martin rudalics @ 2021-09-11  8:35 UTC (permalink / raw)
  To: Lars Ingebrigtsen, Juri Linkov; +Cc: Florian Beck, 9054

 > Nice.  It's a bit of a mouthful for users, though.

It's a bit fragile as well.  We have a `display-buffer' help-args text
property at that position so everything seems in place already.  But I
would have to understand `help-function-def--button-function' first ...

 >> Did you try Juri's proposal?
 >
 > I don't think we can expect users to do all that just to change the
 > behaviour of these *Help* commands.

Agreed.

 > Perhaps if we put the
 > `display-buffer-from-help-p' function into Emacs.

I think we should specify something like a _general_ `display-buffer'
text property that would specify the basic (aka historic) action
(`pop-to-buffer' in the case at hand) here.  Then have `display-buffer',
before it does its `display-buffer-assq-regexp' job, look whether there
"is a `display-buffer' text property around where the user just clicked
or where point is" and perform a corresponding action based on whether
`display-buffer-alist' has a "somehow specified" entry (not a regexp and
not a function) for it and do either that or what the `display-buffer'
text-property says.

 > `help-window-select' is (if you squint at it) the kinda-sorta user
 > option in the opposite direction,

`help-window-select' is for users who want to get rid of the *Help*
window by just typing "q" thus avoiding the "Type \"q\" in help window"
excursion where they have to explicitly select the *Help* window just to
quit it.

 > so perhaps the way forward here is to
 > just define a new user option, or all a new value (`both'?) that affects
 > how windows are selected from the *Help* window.  I guess a new user
 > option would be the simplest.

Agreed.  But we should decide whether we only want it for *Help* windows
and what kind of additional semantics we should support, if any.

martin





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-10 16:15       ` Juri Linkov
@ 2021-09-11  8:38         ` martin rudalics
  2021-09-11 18:51           ` Juri Linkov
  0 siblings, 1 reply; 57+ messages in thread
From: martin rudalics @ 2021-09-11  8:38 UTC (permalink / raw)
  To: Juri Linkov, Lars Ingebrigtsen; +Cc: Florian Beck, 9054

 > Or maybe support specifying a mode directly in the condition part
 > of display-buffer-alist, but this is still too complex.

Could you try with the text property we already have there?

 > A new user option for buffers outgoing from Help would be fine.

I'd prefer text/overlay properties.

martin





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-11  8:35       ` martin rudalics
@ 2021-09-11 12:43         ` Lars Ingebrigtsen
  2021-09-11 16:42           ` martin rudalics
  0 siblings, 1 reply; 57+ messages in thread
From: Lars Ingebrigtsen @ 2021-09-11 12:43 UTC (permalink / raw)
  To: martin rudalics; +Cc: Florian Beck, 9054, Juri Linkov

martin rudalics <rudalics@gmx.at> writes:

> I think we should specify something like a _general_ `display-buffer'
> text property that would specify the basic (aka historic) action
> (`pop-to-buffer' in the case at hand) here.  Then have `display-buffer',
> before it does its `display-buffer-assq-regexp' job, look whether there
> "is a `display-buffer' text property around where the user just clicked
> or where point is" and perform a corresponding action based on whether
> `display-buffer-alist' has a "somehow specified" entry (not a regexp and
> not a function) for it and do either that or what the `display-buffer'
> text-property says.

I'm not sure I understand how that would look in practice.  That is,
what the user would actually put into display-buffer-alist to get the
desired action here.

>> `help-window-select' is (if you squint at it) the kinda-sorta user
>> option in the opposite direction,
>
> `help-window-select' is for users who want to get rid of the *Help*
> window by just typing "q" thus avoiding the "Type \"q\" in help window"
> excursion where they have to explicitly select the *Help* window just to
> quit it.

That's not why I've set it -- I've set it so that I can `C-h foo RET s'
without a `C-x C-o' in the middle.

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





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-11 12:43         ` Lars Ingebrigtsen
@ 2021-09-11 16:42           ` martin rudalics
  2021-09-13  7:50             ` Lars Ingebrigtsen
  0 siblings, 1 reply; 57+ messages in thread
From: martin rudalics @ 2021-09-11 16:42 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Florian Beck, 9054, Juri Linkov

 > I'm not sure I understand how that would look in practice.  That is,
 > what the user would actually put into display-buffer-alist to get the
 > desired action here.

I don't know yet either.  As of now it would have to be a function that
pays attention to a `display-buffer' property at point.  That property
would, by default, act like the action argument of `display-buffer',
that is, specify what clicking at the button would do.  The function
would be used to override that - maybe overriding a regexp based alist
entry as well.  Just that we cannot well expect that a user will write
that function entirely from scratch so we probably should provide some
prespecified alternative here.

 >> `help-window-select' is for users who want to get rid of the *Help*
 >> window by just typing "q" thus avoiding the "Type \"q\" in help window"
 >> excursion where they have to explicitly select the *Help* window just to
 >> quit it.
 >
 > That's not why I've set it -- I've set it so that I can `C-h foo RET s'
 > without a `C-x C-o' in the middle.

I see.  "s" didn't exist at the time `help-window-select' was added.

martin





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-11  8:38         ` martin rudalics
@ 2021-09-11 18:51           ` Juri Linkov
  2021-09-13  8:02             ` martin rudalics
  0 siblings, 1 reply; 57+ messages in thread
From: Juri Linkov @ 2021-09-11 18:51 UTC (permalink / raw)
  To: martin rudalics; +Cc: Lars Ingebrigtsen, Florian Beck, 9054

>> A new user option for buffers outgoing from Help would be fine.
>
> I'd prefer text/overlay properties.

To support a text property or overlay by display-buffer would be nice.
But a new user option is still needed for help-mode, so it could
put the right value on text properties in the Help buffer.





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-11 16:42           ` martin rudalics
@ 2021-09-13  7:50             ` Lars Ingebrigtsen
  2021-09-13  8:10               ` martin rudalics
  0 siblings, 1 reply; 57+ messages in thread
From: Lars Ingebrigtsen @ 2021-09-13  7:50 UTC (permalink / raw)
  To: martin rudalics; +Cc: Florian Beck, 9054, Juri Linkov

martin rudalics <rudalics@gmx.at> writes:

>> That's not why I've set it -- I've set it so that I can `C-h foo RET s'
>> without a `C-x C-o' in the middle.
>
> I see.  "s" didn't exist at the time `help-window-select' was added.

`C-h foo RET s' or `C-h foo RET TAB RET' is pretty much the same thing,
and the latter has existed for a long time...

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





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-11 18:51           ` Juri Linkov
@ 2021-09-13  8:02             ` martin rudalics
  2021-09-13 17:57               ` Juri Linkov
  0 siblings, 1 reply; 57+ messages in thread
From: martin rudalics @ 2021-09-13  8:02 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Lars Ingebrigtsen, Florian Beck, 9054

 > To support a text property or overlay by display-buffer would be nice.

If called `display-buffer', that property's value would appear like a
`display-buffer-alist' entry - a <PROPERTY, ACTION> pair that would be
run by `display-buffer' like an overriding action.

Users could inhibit that by adding to their `display-buffer-alist' a
<PROPERTY, USER-ACTION> entry where USER-ACTION nil would mean to not
run ACTION and USER-ACTION some other action would mean to run that
other action instead of ACTION.

 > But a new user option is still needed for help-mode, so it could
 > put the right value on text properties in the Help buffer.

Lars would like to rewrite help mode from scratch anyway, so I think
that would be a good occasion to do that.  In either case we should be
able to handle mouse clicks, keyboard input like "s" and "i", context
menus and external handling of *Help* navigation from another buffer in
a uniform way.

BTW: IMHO right clicking on a Lisp Object in Elisp mode with
`context-menu-mode' enabled should list

(1) Help for this object

(2) Manual entry of this object

_first_.  And Find Definition should allow to choose whether to do that
in another window/frame in the Context Menu.

martin





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-13  7:50             ` Lars Ingebrigtsen
@ 2021-09-13  8:10               ` martin rudalics
  0 siblings, 0 replies; 57+ messages in thread
From: martin rudalics @ 2021-09-13  8:10 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Florian Beck, 9054, Juri Linkov

 >>> That's not why I've set it -- I've set it so that I can `C-h foo RET s'
 >>> without a `C-x C-o' in the middle.
 >>
 >> I see.  "s" didn't exist at the time `help-window-select' was added.
 >
 > `C-h foo RET s' or `C-h foo RET TAB RET' is pretty much the same thing,
 > and the latter has existed for a long time...

Still that wasn't what I had in mind when I added `help-window-select'.
What bothered me most then was to provide a suitable text to display for
making the help window disappear.  That's still not working in all
cases, especially with multiple frames.  But it's easier with the help
window selected.

martin





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-13  8:02             ` martin rudalics
@ 2021-09-13 17:57               ` Juri Linkov
  2021-09-13 18:43                 ` Juri Linkov
                                   ` (2 more replies)
  0 siblings, 3 replies; 57+ messages in thread
From: Juri Linkov @ 2021-09-13 17:57 UTC (permalink / raw)
  To: martin rudalics; +Cc: Lars Ingebrigtsen, Florian Beck, 9054

>> To support a text property or overlay by display-buffer would be nice.
>
> If called `display-buffer', that property's value would appear like a
> `display-buffer-alist' entry - a <PROPERTY, ACTION> pair that would be
> run by `display-buffer' like an overriding action.
>
> Users could inhibit that by adding to their `display-buffer-alist' a
> <PROPERTY, USER-ACTION> entry where USER-ACTION nil would mean to not
> run ACTION and USER-ACTION some other action would mean to run that
> other action instead of ACTION.

Looks like a good plan.

>> But a new user option is still needed for help-mode, so it could
>> put the right value on text properties in the Help buffer.
>
> Lars would like to rewrite help mode from scratch anyway, so I think
> that would be a good occasion to do that.  In either case we should be
> able to handle mouse clicks, keyboard input like "s" and "i", context
> menus and external handling of *Help* navigation from another buffer in
> a uniform way.

We desperately need to separate the help back-end from its presentation layer.
The back-end should collect information and return it as alists. And
the front-end should display it in the *Help* buffer.

> BTW: IMHO right clicking on a Lisp Object in Elisp mode with
> `context-menu-mode' enabled should list
>
> (1) Help for this object
>
> (2) Manual entry of this object

Good idea.  This should be added to emacs-lisp-mode.

> _first_.  And Find Definition should allow to choose whether to do that
> in another window/frame in the Context Menu.

Wouldn't then the context menu grow too long?  Instead of current 3 items:

  "Find Definition"
  "Find References"
  "Back Definition"

it will show 3x3 items:

  "Find Definition"
  "Find References"
  "Back Definition"
  "Find Definition in another window"
  "Find References in another window"
  "Back Definition in another window"
  "Find Definition in another frame"
  "Find References in another frame"
  "Back Definition in another frame"





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-13 17:57               ` Juri Linkov
@ 2021-09-13 18:43                 ` Juri Linkov
  2021-09-15  9:28                   ` martin rudalics
  2021-09-14 11:07                 ` Lars Ingebrigtsen
  2021-09-15  9:27                 ` martin rudalics
  2 siblings, 1 reply; 57+ messages in thread
From: Juri Linkov @ 2021-09-13 18:43 UTC (permalink / raw)
  To: martin rudalics; +Cc: Lars Ingebrigtsen, 9054

>> BTW: IMHO right clicking on a Lisp Object in Elisp mode with
>> `context-menu-mode' enabled should list
>>
>> (1) Help for this object
>>
>> (2) Manual entry of this object
>
> Good idea.  This should be added to emacs-lisp-mode.

Now added.





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-13 17:57               ` Juri Linkov
  2021-09-13 18:43                 ` Juri Linkov
@ 2021-09-14 11:07                 ` Lars Ingebrigtsen
  2021-09-15  9:28                   ` martin rudalics
  2021-09-15  9:27                 ` martin rudalics
  2 siblings, 1 reply; 57+ messages in thread
From: Lars Ingebrigtsen @ 2021-09-14 11:07 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Florian Beck, 9054

Juri Linkov <juri@linkov.net> writes:

> We desperately need to separate the help back-end from its presentation layer.
> The back-end should collect information and return it as alists. And
> the front-end should display it in the *Help* buffer.

Yup.  Or at least something else than the current nest of confusing
standard-output/current-buffer thing we have, which is just hard to
reason about. 

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





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-13 17:57               ` Juri Linkov
  2021-09-13 18:43                 ` Juri Linkov
  2021-09-14 11:07                 ` Lars Ingebrigtsen
@ 2021-09-15  9:27                 ` martin rudalics
  2021-09-15 16:05                   ` Juri Linkov
  2 siblings, 1 reply; 57+ messages in thread
From: martin rudalics @ 2021-09-15  9:27 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Lars Ingebrigtsen, Florian Beck, 9054

 > We desperately need to separate the help back-end from its presentation layer.
 > The back-end should collect information and return it as alists.

Why as alists?  Who would generate the buffer text?

 > And
 > the front-end should display it in the *Help* buffer.

 >> And Find Definition should allow to choose whether to do that
 >> in another window/frame in the Context Menu.
 >
 > Wouldn't then the context menu grow too long?  Instead of current 3 items:
 >
 >    "Find Definition"
 >    "Find References"
 >    "Back Definition"
 >
 > it will show 3x3 items:
 >
 >    "Find Definition"
 >    "Find References"
 >    "Back Definition"
 >    "Find Definition in another window"
 >    "Find References in another window"
 >    "Back Definition in another window"
 >    "Find Definition in another frame"
 >    "Find References in another frame"
 >    "Back Definition in another frame"

Agreed.  Although "Back Definition" should already know the window it
should act upon.  So maybe use some modifier for the "another" window
click and explain it in the tooltip (which, IIRC we do not always show
on Windows).

martin





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-13 18:43                 ` Juri Linkov
@ 2021-09-15  9:28                   ` martin rudalics
  2021-09-15 16:07                     ` Juri Linkov
  0 siblings, 1 reply; 57+ messages in thread
From: martin rudalics @ 2021-09-15  9:28 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Lars Ingebrigtsen, 9054

 >>> (1) Help for this object
 >>>
 >>> (2) Manual entry of this object
 >>
 >> Good idea.  This should be added to emacs-lisp-mode.
 >
 > Now added.

Thanks.  But to make this really useful for new users we should not talk
about "symbols" and "identifiers" here - maybe using "this" instead
would be better.  And we should provide some feedback when there's no
useful information here.  Consider with

(setq x 3)

clicking on "x" or "3".

martin





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-14 11:07                 ` Lars Ingebrigtsen
@ 2021-09-15  9:28                   ` martin rudalics
  2021-09-15  9:30                     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 57+ messages in thread
From: martin rudalics @ 2021-09-15  9:28 UTC (permalink / raw)
  To: Lars Ingebrigtsen, Juri Linkov; +Cc: Florian Beck, 9054

 > Yup.  Or at least something else than the current nest of confusing
 > standard-output/current-buffer thing we have, which is just hard to
 > reason about.

I'm afraid the `standard-output' thing is carved in stone since `print'
uses it by default.

martin





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-15  9:28                   ` martin rudalics
@ 2021-09-15  9:30                     ` Lars Ingebrigtsen
  2021-09-15  9:42                       ` martin rudalics
  0 siblings, 1 reply; 57+ messages in thread
From: Lars Ingebrigtsen @ 2021-09-15  9:30 UTC (permalink / raw)
  To: martin rudalics; +Cc: Florian Beck, 9054, Juri Linkov

martin rudalics <rudalics@gmx.at> writes:

>> Yup.  Or at least something else than the current nest of confusing
>> standard-output/current-buffer thing we have, which is just hard to
>> reason about.
>
> I'm afraid the `standard-output' thing is carved in stone since `print'
> uses it by default.

If we rearrange our code, then we'd have to adjust the usages of `print'
in this code, of course.

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





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-15  9:30                     ` Lars Ingebrigtsen
@ 2021-09-15  9:42                       ` martin rudalics
  0 siblings, 0 replies; 57+ messages in thread
From: martin rudalics @ 2021-09-15  9:42 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Florian Beck, 9054, Juri Linkov

 > If we rearrange our code, then we'd have to adjust the usages of `print'
 > in this code, of course.

Sure.  But we cannot change `with-help-window' unilaterally - anyone out
there may use it.  So we'd need yet another macro for our purposes ...

martin





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-15  9:27                 ` martin rudalics
@ 2021-09-15 16:05                   ` Juri Linkov
  2021-09-15 18:47                     ` martin rudalics
  0 siblings, 1 reply; 57+ messages in thread
From: Juri Linkov @ 2021-09-15 16:05 UTC (permalink / raw)
  To: martin rudalics; +Cc: Lars Ingebrigtsen, Florian Beck, 9054

>> We desperately need to separate the help back-end from its presentation layer.
>> The back-end should collect information and return it as alists.
>
> Why as alists?  Who would generate the buffer text?

The back-end should return collected data as alist,
and front-end should render data as the buffer text.

>> it will show 3x3 items:
>>
>>    "Find Definition"
>>    "Find References"
>>    "Back Definition"
>>    "Find Definition in another window"
>>    "Find References in another window"
>>    "Back Definition in another window"
>>    "Find Definition in another frame"
>>    "Find References in another frame"
>>    "Back Definition in another frame"
>
> Agreed.  Although "Back Definition" should already know the window it
> should act upon.  So maybe use some modifier for the "another" window
> click and explain it in the tooltip (which, IIRC we do not always show
> on Windows).

Indeed, now there are such modifiers: ‘C-x 4 0’ and ‘C-x 4 4’.





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-15  9:28                   ` martin rudalics
@ 2021-09-15 16:07                     ` Juri Linkov
  2021-09-15 18:48                       ` martin rudalics
  0 siblings, 1 reply; 57+ messages in thread
From: Juri Linkov @ 2021-09-15 16:07 UTC (permalink / raw)
  To: martin rudalics; +Cc: Lars Ingebrigtsen, 9054

>>>> (1) Help for this object
>>>> (2) Manual entry of this object
>>>
>>> Good idea.  This should be added to emacs-lisp-mode.
>>
>> Now added.
>
> Thanks.  But to make this really useful for new users we should not talk
> about "symbols" and "identifiers" here - maybe using "this" instead
> would be better.  And we should provide some feedback when there's no
> useful information here.  Consider with
>
> (setq x 3)
>
> clicking on "x" or "3".

There is already feedback when there is no Manual entry:

  (error "Not documented as a symbol:")





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-15 16:05                   ` Juri Linkov
@ 2021-09-15 18:47                     ` martin rudalics
  2021-09-16 18:53                       ` Juri Linkov
  0 siblings, 1 reply; 57+ messages in thread
From: martin rudalics @ 2021-09-15 18:47 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Lars Ingebrigtsen, 9054

 > The back-end should return collected data as alist,
 > and front-end should render data as the buffer text.

Hmmm...  I still don't get it.

 > Indeed, now there are such modifiers: ‘C-x 4 0’ and ‘C-x 4 4’.

I meant modifiers for mouse-1 clicks on the menu entry.

martin






^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-15 16:07                     ` Juri Linkov
@ 2021-09-15 18:48                       ` martin rudalics
  2021-09-17  7:21                         ` Juri Linkov
  0 siblings, 1 reply; 57+ messages in thread
From: martin rudalics @ 2021-09-15 18:48 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Lars Ingebrigtsen, 9054

 >> Consider with
 >>
 >> (setq x 3)
 >>
 >> clicking on "x" or "3".
 >
 > There is already feedback when there is no Manual entry:
 >
 >    (error "Not documented as a symbol:")

I only see

down-mouse-3 describe-symbol

in the echo area.

martin





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-15 18:47                     ` martin rudalics
@ 2021-09-16 18:53                       ` Juri Linkov
  2021-09-16 19:11                         ` Juri Linkov
  2021-09-17  7:39                         ` martin rudalics
  0 siblings, 2 replies; 57+ messages in thread
From: Juri Linkov @ 2021-09-16 18:53 UTC (permalink / raw)
  To: martin rudalics; +Cc: Lars Ingebrigtsen, 9054

>> The back-end should return collected data as alist,
>> and front-end should render data as the buffer text.
>
> Hmmm...  I still don't get it.

For example, ‘C-h f’ (describe-function) first calls a back-end function
that collects all information about a function and returns it in a such form:

  ((type . function)
   (name . "car")
   (source-file . "src/data.c")
   (Info-node . "(elisp) List Elements")
   (docstring . ...)
   ...)

Then it gives this data to a front-end function that will render it
as buttonized text in the Help buffer, or as html in a eww buffer,
or as Info markup in an Info buffer, etc.

>> Indeed, now there are such modifiers: ‘C-x 4 0’ and ‘C-x 4 4’.
>
> I meant modifiers for mouse-1 clicks on the menu entry.

But ‘C-x 4 0’ and ‘C-x 4 4’ already do what is needed,
and indeed I tested these work fine: ‘C-x 4 0 down-mouse-3’.





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-16 18:53                       ` Juri Linkov
@ 2021-09-16 19:11                         ` Juri Linkov
  2021-09-17  7:39                         ` martin rudalics
  1 sibling, 0 replies; 57+ messages in thread
From: Juri Linkov @ 2021-09-16 19:11 UTC (permalink / raw)
  To: martin rudalics; +Cc: Lars Ingebrigtsen, 9054

>>> The back-end should return collected data as alist,
>>> and front-end should render data as the buffer text.
>>
>> Hmmm...  I still don't get it.
>
> For example, ‘C-h f’ (describe-function) first calls a back-end function
> that collects all information about a function and returns it in a such form:
>
>   ((type . function)
>    (name . "car")
>    (source-file . "src/data.c")
>    (Info-node . "(elisp) List Elements")
>    (docstring . ...)
>    ...)

And when some data collection is too time-consuming
it could return it as lambda for lazy evaluation. e.g.:

  ((type . function)
   (name . "car")
   (references . (lambda () (collect-references "car")))
   ...)





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-15 18:48                       ` martin rudalics
@ 2021-09-17  7:21                         ` Juri Linkov
  2021-09-17  7:39                           ` martin rudalics
  0 siblings, 1 reply; 57+ messages in thread
From: Juri Linkov @ 2021-09-17  7:21 UTC (permalink / raw)
  To: martin rudalics; +Cc: Lars Ingebrigtsen, 9054

>>> Consider with
>>>
>>> (setq x 3)
>>>
>>> clicking on "x" or "3".
>>
>> There is already feedback when there is no Manual entry:
>>
>>    (error "Not documented as a symbol:")
>
> I only see
>
> down-mouse-3 describe-symbol
>
> in the echo area.

Every help command has own unique feedback:

  C-h f xyz C-M-c => error: Symbol’s function definition is void: xyz
  C-h v xyz C-M-c => Help buffer: xyz is void as a variable.
  C-h o xyz C-M-c => no output
  C-h w xyz C-M-c => message: xyz is not on any key
  C-h x xyz C-M-c => error: Symbol is not a command: xyz
  C-h a xyz C-M-c => message: No apropos matches for ‘xyz’





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-16 18:53                       ` Juri Linkov
  2021-09-16 19:11                         ` Juri Linkov
@ 2021-09-17  7:39                         ` martin rudalics
  2021-09-17 16:05                           ` Juri Linkov
  1 sibling, 1 reply; 57+ messages in thread
From: martin rudalics @ 2021-09-17  7:39 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Lars Ingebrigtsen, 9054

  issues.> For example, ‘C-h f’ (describe-function) first calls a back-end function
 > that collects all information about a function and returns it in a such form:
 >
 >    ((type . function)
 >     (name . "car")
 >     (source-file . "src/data.c")
 >     (Info-node . "(elisp) List Elements")
 >     (docstring . ...)
 >     ...)
 >
 > Then it gives this data to a front-end function that will render it
 > as buttonized text in the Help buffer, or as html in a eww buffer,
 > or as Info markup in an Info buffer, etc.

And ‘describe-function-help-front-end’ would peruse that information.
And 'describe-key-help-front-end' would use a 'key' entry.  But what
would you pass to 'view-lossage-help-front-end'?

Anyway I seem to see what you have in mind: Each front end would have
its own rules for how to render the cdr of 'type' or 'name' entries.
And the back end would not be concerned with rendering.

 >>> Indeed, now there are such modifiers: ‘C-x 4 0’ and ‘C-x 4 4’.
 >>
 >> I meant modifiers for mouse-1 clicks on the menu entry.
 >
 > But ‘C-x 4 0’ and ‘C-x 4 4’ already do what is needed,
 > and indeed I tested these work fine: ‘C-x 4 0 down-mouse-3’.

That's not for people who start to explore Emacs via the context menus.
Since you are currently writing them from scratch, they should provide a
simpler interface IMHO.  I'd say C-<mouse-1> should pop up the desired
information in another window, M-<mouse-1> in another frame, ...

martin






^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-17  7:21                         ` Juri Linkov
@ 2021-09-17  7:39                           ` martin rudalics
  2021-09-17 16:04                             ` Juri Linkov
  0 siblings, 1 reply; 57+ messages in thread
From: martin rudalics @ 2021-09-17  7:39 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Lars Ingebrigtsen, 9054

 > Every help command has own unique feedback:
 >
 >    C-h f xyz C-M-c => error: Symbol’s function definition is void: xyz
 >    C-h v xyz C-M-c => Help buffer: xyz is void as a variable.
 >    C-h o xyz C-M-c => no output
 >    C-h w xyz C-M-c => message: xyz is not on any key
 >    C-h x xyz C-M-c => error: Symbol is not a command: xyz
 >    C-h a xyz C-M-c => message: No apropos matches for ‘xyz’

I wasn't talking about C-h ...  I meant the context menu popping up via
mouse-3 when 'context-menu-mode' is enabled.  I think whichever text a
user clicks on in an Elisp buffer should pop up something informative.
But with

(context-menu-mode)
(setq x 3)
(setp x 3)

right clicking on 'setq' and choosing "Describe symbol" from the menu
displays a help buffer for 'setq'.  Doing the same for 'setp' gets me

down-mouse-3 describe-symbol

in the echo area.

martin






^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-17  7:39                           ` martin rudalics
@ 2021-09-17 16:04                             ` Juri Linkov
  2021-09-18  7:36                               ` martin rudalics
  0 siblings, 1 reply; 57+ messages in thread
From: Juri Linkov @ 2021-09-17 16:04 UTC (permalink / raw)
  To: martin rudalics; +Cc: Lars Ingebrigtsen, 9054

>> Every help command has own unique feedback:
>>
>>    C-h f xyz C-M-c => error: Symbol’s function definition is void: xyz
>>    C-h v xyz C-M-c => Help buffer: xyz is void as a variable.
>>    C-h o xyz C-M-c => no output
>>    C-h w xyz C-M-c => message: xyz is not on any key
>>    C-h x xyz C-M-c => error: Symbol is not a command: xyz
>>    C-h a xyz C-M-c => message: No apropos matches for ‘xyz’
>
> I wasn't talking about C-h ...  I meant the context menu popping up via
> mouse-3 when 'context-menu-mode' is enabled.  I think whichever text a
> user clicks on in an Elisp buffer should pop up something informative.
> But with
>
> (context-menu-mode)
> (setq x 3)
> (setp x 3)
>
> right clicking on 'setq' and choosing "Describe symbol" from the menu
> displays a help buffer for 'setq'.  Doing the same for 'setp' gets me
>
> down-mouse-3 describe-symbol
>
> in the echo area.

But the context menu just calls describe-symbol, and describe-symbol
decides whether there is a documentation for the provided argument.
So isn't it the task of describe-symbol to signal an error?

Anyway, now if a symbol doesn't exist, then no menu item is added.
So no error message is needed.





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-17  7:39                         ` martin rudalics
@ 2021-09-17 16:05                           ` Juri Linkov
  2021-09-18  7:35                             ` martin rudalics
  0 siblings, 1 reply; 57+ messages in thread
From: Juri Linkov @ 2021-09-17 16:05 UTC (permalink / raw)
  To: martin rudalics; +Cc: Lars Ingebrigtsen, 9054

>> For example, ‘C-h f’ (describe-function) first calls a back-end function
>> that collects all information about a function and returns it in a such form:
>>
>>    ((type . function)
>>     (name . "car")
>>     (source-file . "src/data.c")
>>     (Info-node . "(elisp) List Elements")
>>     (docstring . ...)
>>     ...)
>>
>> Then it gives this data to a front-end function that will render it
>> as buttonized text in the Help buffer, or as html in a eww buffer,
>> or as Info markup in an Info buffer, etc.
>
> And ‘describe-function-help-front-end’ would peruse that information.

‘describe-function’ is already a front-end function for the help buffers.
But the problem is that it currently also amalgamates back-end code to it.

> And 'describe-key-help-front-end' would use a 'key' entry.
> But what would you pass to 'view-lossage-help-front-end'?

'view-lossage' is already a very simple function, no need
to add a back-end for it.

> Anyway I seem to see what you have in mind: Each front end would have
> its own rules for how to render the cdr of 'type' or 'name' entries.
> And the back end would not be concerned with rendering.

Exactly.

>>>> Indeed, now there are such modifiers: ‘C-x 4 0’ and ‘C-x 4 4’.
>>>
>>> I meant modifiers for mouse-1 clicks on the menu entry.
>>
>> But ‘C-x 4 0’ and ‘C-x 4 4’ already do what is needed,
>> and indeed I tested these work fine: ‘C-x 4 0 down-mouse-3’.
>
> That's not for people who start to explore Emacs via the context menus.
> Since you are currently writing them from scratch, they should provide a
> simpler interface IMHO.  I'd say C-<mouse-1> should pop up the desired
> information in another window, M-<mouse-1> in another frame, ...

But C-<mouse-1> and M-<mouse-1> are already bound.





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-17 16:05                           ` Juri Linkov
@ 2021-09-18  7:35                             ` martin rudalics
  0 siblings, 0 replies; 57+ messages in thread
From: martin rudalics @ 2021-09-18  7:35 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Lars Ingebrigtsen, 9054

 > But C-<mouse-1> and M-<mouse-1> are already bound.

I meant clicking on the menu entry.  But there modifiers have no effect
supposedly, so my proposal was silly.

martin





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-17 16:04                             ` Juri Linkov
@ 2021-09-18  7:36                               ` martin rudalics
  2021-09-18 16:30                                 ` bug#9054: [External] : " Drew Adams
  2021-09-19 16:20                                 ` Juri Linkov
  0 siblings, 2 replies; 57+ messages in thread
From: martin rudalics @ 2021-09-18  7:36 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Lars Ingebrigtsen, 9054

 > But the context menu just calls describe-symbol, and describe-symbol
 > decides whether there is a documentation for the provided argument.
 > So isn't it the task of describe-symbol to signal an error?
 >
 > Anyway, now if a symbol doesn't exist, then no menu item is added.
 > So no error message is needed.

To be useful for beginners, the context menu should not delegate such
tasks to functions like 'describe-symbol'.  As I mentioned before, I'd
even avoid using terms like 'symbol' there.  What I would prefer is that
when I right-click on 'setq' in a form like

(setq x 3)

the context menu proposes

Describe `setq'
Lookup `setq' in Manuals
Show Definition of `setq'
Show References for `setq'

and in addition, if the mouse is say on the 'e' of setq,

Describe character properties of `e'

to run `describe-char' on that `e' so that users are aware of the
granularity of the objects they deal with.

Clicking on "x" OTOH should reveal that the Lisp reader doesn't know
(yet) about "x" while clicking on "3" should reveal that the Lisp reader
considers it an integer.

BTW: Show/Hide in the Options menu should allow to toggle context menu
mode.

martin





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: [External] : bug#9054: 24.0.50; show source in other window
  2021-09-18  7:36                               ` martin rudalics
@ 2021-09-18 16:30                                 ` Drew Adams
  2021-09-19 16:20                                 ` Juri Linkov
  1 sibling, 0 replies; 57+ messages in thread
From: Drew Adams @ 2021-09-18 16:30 UTC (permalink / raw)
  To: martin rudalics, Juri Linkov; +Cc: Lars Ingebrigtsen, 9054

> when I right-click on 'setq' in a form like
> (setq x 3) the context menu proposes
>   Describe `setq'
>   Lookup `setq' in Manuals
>   Show Definition of `setq'
>   Show References for `setq'
> 
> and in addition, if the mouse is say on the 'e' of setq,
>   Describe character properties of `e'
> to run `describe-char' on that `e'

[As I've mentioned, I'm not in favor of the
(relatively hard-coded) approach taken so far
to add a mouse-3 context menu.  I presented the
advantages of the approach taken by mouse3.el.
I've stayed out of the context-menu discussion
since then.]

I'll just mention that by default the mouse3.el
context menu when no region is active has these
menu items that are relevant here.  Enabling of
individual items depends on the type(s) of the
item detected under the mouse pointer (e.g. file,
URL, variable, function, face,...).


Thing at Pointer

  Send Email
  Open URL in Browser
  Visit File
  Visit File in Other Window
  Dired
  Dired in Other Window
  __________________________
  Describe File
  Describe Function
  Show Code Defining Function
  Describe Variable
  Show Code Defining Variable
  Describe Face
  Describe Package
  Describe Text Properties
  __________________________
  Highlight Symbol
  Unhighlight Symbol
  Hi-Lock Symbol
  Un-Hi-Lock Symbol
  __________________________
  Look Up Symbol in Manual
  Search for Symbol
  Eval & Pretty-Print Lisp Sexp

^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-18  7:36                               ` martin rudalics
  2021-09-18 16:30                                 ` bug#9054: [External] : " Drew Adams
@ 2021-09-19 16:20                                 ` Juri Linkov
  2021-09-19 17:27                                   ` Eli Zaretskii
  2021-09-20  8:21                                   ` martin rudalics
  1 sibling, 2 replies; 57+ messages in thread
From: Juri Linkov @ 2021-09-19 16:20 UTC (permalink / raw)
  To: martin rudalics; +Cc: Lars Ingebrigtsen, 9054

> To be useful for beginners, the context menu should not delegate such
> tasks to functions like 'describe-symbol'.  As I mentioned before, I'd
> even avoid using terms like 'symbol' there.  What I would prefer is that
> when I right-click on 'setq' in a form like
>
> (setq x 3)
>
> the context menu proposes
>
> Describe `setq'
> Lookup `setq' in Manuals
> Show Definition of `setq'
> Show References for `setq'

But what to do with long symbols?  For example, this won't fit to any menu:

  Describe `display-fill-column-indicator-character'
  Lookup `display-fill-column-indicator-character' in Manuals
  Show Definition of `display-fill-column-indicator-character'
  Show References for `display-fill-column-indicator-character'

> and in addition, if the mouse is say on the 'e' of setq,
>
> Describe character properties of `e'
>
> to run `describe-char' on that `e' so that users are aware of the
> granularity of the objects they deal with.

There is the menu “Describe” in the submenu “Help” on the manu-bar,
but I don't see “Describe Character” in it.  But there are other
Describe menu items.

> Clicking on "x" OTOH should reveal that the Lisp reader doesn't know
> (yet) about "x" while clicking on "3" should reveal that the Lisp reader
> considers it an integer.

I don't know what to show for an integer.

> BTW: Show/Hide in the Options menu should allow to toggle context menu
> mode.

Maybe in the next version context menu mode will be enabled by default.





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-19 16:20                                 ` Juri Linkov
@ 2021-09-19 17:27                                   ` Eli Zaretskii
  2021-09-19 17:35                                     ` bug#9054: [External] : " Drew Adams
  2021-09-20  8:21                                     ` martin rudalics
  2021-09-20  8:21                                   ` martin rudalics
  1 sibling, 2 replies; 57+ messages in thread
From: Eli Zaretskii @ 2021-09-19 17:27 UTC (permalink / raw)
  To: Juri Linkov; +Cc: larsi, 9054

> From: Juri Linkov <juri@linkov.net>
> Date: Sun, 19 Sep 2021 19:20:18 +0300
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 9054@debbugs.gnu.org
> 
> > Describe `setq'
> > Lookup `setq' in Manuals
> > Show Definition of `setq'
> > Show References for `setq'
> 
> But what to do with long symbols?  For example, this won't fit to any menu:
> 
>   Describe `display-fill-column-indicator-character'
>   Lookup `display-fill-column-indicator-character' in Manuals
>   Show Definition of `display-fill-column-indicator-character'
>   Show References for `display-fill-column-indicator-character'

How about

  Describe symbol at mouse click

etc.?





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: [External] : bug#9054: 24.0.50; show source in other window
  2021-09-19 17:27                                   ` Eli Zaretskii
@ 2021-09-19 17:35                                     ` Drew Adams
  2021-09-19 17:43                                       ` Eli Zaretskii
  2021-09-20  8:21                                     ` martin rudalics
  1 sibling, 1 reply; 57+ messages in thread
From: Drew Adams @ 2021-09-19 17:35 UTC (permalink / raw)
  To: Eli Zaretskii, Juri Linkov; +Cc: larsi, 9054

> How about
>   Describe symbol at mouse click

Yes.

[suggestion] But "at mouse pointer" or
"at mouse" or "under mouse" or some such.

No click action is involved, right?  If
I'm wrong about no click then please
ignore the suggestion.





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: [External] : bug#9054: 24.0.50; show source in other window
  2021-09-19 17:35                                     ` bug#9054: [External] : " Drew Adams
@ 2021-09-19 17:43                                       ` Eli Zaretskii
  0 siblings, 0 replies; 57+ messages in thread
From: Eli Zaretskii @ 2021-09-19 17:43 UTC (permalink / raw)
  To: Drew Adams; +Cc: larsi, 9054, juri

> From: Drew Adams <drew.adams@oracle.com>
> CC: "larsi@gnus.org" <larsi@gnus.org>,
>         "9054@debbugs.gnu.org"
> 	<9054@debbugs.gnu.org>
> Date: Sun, 19 Sep 2021 17:35:09 +0000
> 
> > How about
> >   Describe symbol at mouse click
> 
> Yes.
> 
> [suggestion] But "at mouse pointer" or
> "at mouse" or "under mouse" or some such.
> 
> No click action is involved, right?

Wrong.  We are talking about context menus.





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-19 16:20                                 ` Juri Linkov
  2021-09-19 17:27                                   ` Eli Zaretskii
@ 2021-09-20  8:21                                   ` martin rudalics
  2021-09-20 15:20                                     ` Juri Linkov
  1 sibling, 1 reply; 57+ messages in thread
From: martin rudalics @ 2021-09-20  8:21 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Lars Ingebrigtsen, 9054

 >> Describe `setq'
 >> Lookup `setq' in Manuals
 >> Show Definition of `setq'
 >> Show References for `setq'
 >
 > But what to do with long symbols?  For example, this won't fit to any menu:
 >
 >    Describe `display-fill-column-indicator-character'
 >    Lookup `display-fill-column-indicator-character' in Manuals
 >    Show Definition of `display-fill-column-indicator-character'
 >    Show References for `display-fill-column-indicator-character'

We could abbreviate such monsters in the menu entry and show the full
identifier in the tooltip of the menu entry.

 > There is the menu “Describe” in the submenu “Help” on the manu-bar,
 > but I don't see “Describe Character” in it.

Describe Character makes most sense when the user "is right at that
character".  I think

- the menu at the top of a frame is suited for describing and helping
   with general things (and I think it does that pretty well already),

- the mode line is suitable for describing things around its window and
   the buffer it displays (but it's not very good at that yet),

- the buffer context menu is best suited for describing things around
   the position of the mouse (and we didn't have any of these until you
   started implementing it).

Keybindings (if applicable in this context, like C-h f) should be tied
to the position of the selected window's buffer or the nearest suitable
object near that position.

Thus I'd say that "Select All" has no place in the "Context Menu" but
I'm not very sure where to put it instead: Maybe in a sub-menu where we
offer to select symbol, s-expression, containing function and the entire
buffer around the mouse position.  Then we could also add a search
sub-menu that would allow to search for the symbol near the mouse
cursor.  But the place where "Select All" should really go to is the
mode line.

 > But there are other
 > Describe menu items.
 >
 >> Clicking on "x" OTOH should reveal that the Lisp reader doesn't know
 >> (yet) about "x" while clicking on "3" should reveal that the Lisp reader
 >> considers it an integer.
 >
 > I don't know what to show for an integer.

We could just say that 3 is an integer.  Clicking on any character that
is neither a symbol nor a constant should primarily offer "describe
character" which IMO is a very instructive tool users should get
familiar with early.  I think the context menu is the right place for
that although the *Help* buffer should say on the _first_ line "what it
describes" - namely a character.

 >> BTW: Show/Hide in the Options menu should allow to toggle context menu
 >> mode.
 >
 > Maybe in the next version context menu mode will be enabled by default.

Then we need an entry that allows to toggle it off.

martin






^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-19 17:27                                   ` Eli Zaretskii
  2021-09-19 17:35                                     ` bug#9054: [External] : " Drew Adams
@ 2021-09-20  8:21                                     ` martin rudalics
  2021-09-20 14:11                                       ` bug#9054: [External] : " Drew Adams
  1 sibling, 1 reply; 57+ messages in thread
From: martin rudalics @ 2021-09-20  8:21 UTC (permalink / raw)
  To: Eli Zaretskii, Juri Linkov; +Cc: larsi, 9054

 > How about
 >
 >    Describe symbol at mouse click
 >
 > etc.?

I would try to avoid the term "symbol" in context menus.  Beginners
might not associate "symbol" with some sort of plain code they see.
Juri meanwhile uses "function" and "variable" instead but I'm still
convinced that explicitly writing out the symbol in the menu entry is
the best choice here.

martin





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: [External] : bug#9054: 24.0.50; show source in other window
  2021-09-20  8:21                                     ` martin rudalics
@ 2021-09-20 14:11                                       ` Drew Adams
  2021-09-21  8:32                                         ` martin rudalics
  0 siblings, 1 reply; 57+ messages in thread
From: Drew Adams @ 2021-09-20 14:11 UTC (permalink / raw)
  To: martin rudalics, Eli Zaretskii, Juri Linkov; +Cc: larsi, 9054

>  > How about
>  >    Describe symbol at mouse click
>  > etc.?
> 
> I would try to avoid the term "symbol" in context menus.  Beginners
> might not associate "symbol" with some sort of plain code they see.
> Juri meanwhile uses "function" and "variable" instead but I'm still
> convinced that explicitly writing out the symbol in the menu entry is
> the best choice here.

Your point is reasonable.  On the other hand,
it's not difficult to find out what's meant, I
think.  The first attempt to use such a menu
choice shows users what's meant, by concrete
example.  And that teaches users about the
Emacs notion of "symbol", which is not a bad
thing.
___

I already showed the Thing At Pointer submenu
used in my mouse-3 context menu when there's
no nonempty active region.

My code for menu-bar Help menu similarly has
these items in its Describe submenu.  (It has
others too, but these are things that can be
picked up as a thing-at-point.)

 Command
 Function
 Option
 Variable
 Face
 Key
 File

And even the vanilla Help > Describe has key,
function, variable, and face.
___

FWIW, I don't think writing out the name of
the symbol (or face or whatever) is needed.

In the case of symbols, the symbol name is
being pointed at.  Yes, in the case of a
face or some other thing that's not showing
its name, the name might help, but just
trying the menu item shows a user what's
involved right away.

^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-20  8:21                                   ` martin rudalics
@ 2021-09-20 15:20                                     ` Juri Linkov
  2021-09-21  8:34                                       ` martin rudalics
  0 siblings, 1 reply; 57+ messages in thread
From: Juri Linkov @ 2021-09-20 15:20 UTC (permalink / raw)
  To: martin rudalics; +Cc: Lars Ingebrigtsen, 9054

>> But what to do with long symbols?  For example, this won't fit to any menu:
>>
>>    Describe `display-fill-column-indicator-character'
>>    Lookup `display-fill-column-indicator-character' in Manuals
>>    Show Definition of `display-fill-column-indicator-character'
>>    Show References for `display-fill-column-indicator-character'
>
> We could abbreviate such monsters in the menu entry and show the full
> identifier in the tooltip of the menu entry.

I'm not sure if this would be more useful:

  Describe `display-...'
  Lookup `display-...' in Manuals
  Show Definition of `display-...'
  Show References for `display-...'

>> There is the menu “Describe” in the submenu “Help” on the manu-bar,
>> but I don't see “Describe Character” in it.
>
> Describe Character makes most sense when the user "is right at that
> character".

Generally, I agree, but the problem is that "Describe Character"
is not specific to the currently discussed emacs-lisp-mode.
Should the context menu always contain "Describe Character"
in all buffers?

> Thus I'd say that "Select All" has no place in the "Context Menu" but
> I'm not very sure where to put it instead: Maybe in a sub-menu where we
> offer to select symbol, s-expression, containing function and the entire
> buffer around the mouse position.  Then we could also add a search
> sub-menu that would allow to search for the symbol near the mouse
> cursor.  But the place where "Select All" should really go to is the
> mode line.

The "Select" sub-menu is a good idea.  For example, LibreOffice has
a sub-menu "Selection Mode" with "Standard" and "Rectangle Selection".
Gimp even has the top-level menu "Select", etc.  But this means that
region-related part of the context menu doesn't need to be the same
as region-related part of the Edit sub-menu of the menu-bar?

>>> BTW: Show/Hide in the Options menu should allow to toggle context menu
>>> mode.
>>
>> Maybe in the next version context menu mode will be enabled by default.
>
> Then we need an entry that allows to toggle it off.

Maybe not in Show/Hide sub-menu that is related only to visible parts
of the screen.





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: [External] : bug#9054: 24.0.50; show source in other window
  2021-09-20 14:11                                       ` bug#9054: [External] : " Drew Adams
@ 2021-09-21  8:32                                         ` martin rudalics
  2021-09-21 17:52                                           ` Drew Adams
  0 siblings, 1 reply; 57+ messages in thread
From: martin rudalics @ 2021-09-21  8:32 UTC (permalink / raw)
  To: Drew Adams, Eli Zaretskii, Juri Linkov; +Cc: larsi, 9054

 >   Command
 >   Function
 >   Option
 >   Variable
 >   Face
 >   Key
 >   File

I suppose you mean to show 'Command' and 'Option' as substitutes for
'Function' and 'Variable' whenever applicable.  I'd still stick to
'Function' and 'Variable' as Juri does now already.

I don't understand what 'Key' would tell the user here.  'File' could be
treated like a link at the mouse position to follow.  'Face' finally
should be part of the character at the mouse position, accessible via
'describe-char'.

 > And even the vanilla Help > Describe has key,
 > function, variable, and face.

Again I'd say that 'describe-key' is hardly related to the position of
the mouse pointer.

 > FWIW, I don't think writing out the name of
 > the symbol (or face or whatever) is needed.

It would disambiguate the object clicking would describe.

 > In the case of symbols, the symbol name is
 > being pointed at.  Yes, in the case of a
 > face or some other thing that's not showing
 > its name, the name might help, but just
 > trying the menu item shows a user what's
 > involved right away.

But we do not handle any symbol - we handle only predefined ones.  For
the rest we currently get some mysterious text in the echo area or no
information at all.  When I write

(setq x 3)

and right click on "x" I get no useful hint at what to try further.
When I evaluate that form via C-x C-e I get instead


x’s value is 3

Not documented as a variable.

   Probably introduced at or before Emacs version 1.4.


which is better (but for that last line).  So maybe in the unevaluated
case a user should get


x's value is void

Not documented as a variable.


instead.

martin






^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-20 15:20                                     ` Juri Linkov
@ 2021-09-21  8:34                                       ` martin rudalics
  2021-09-21 18:05                                         ` Juri Linkov
  0 siblings, 1 reply; 57+ messages in thread
From: martin rudalics @ 2021-09-21  8:34 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Lars Ingebrigtsen, 9054

 >> We could abbreviate such monsters in the menu entry and show the full
 >> identifier in the tooltip of the menu entry.
 >
 > I'm not sure if this would be more useful:
 >
 >    Describe `display-...'
 >    Lookup `display-...' in Manuals
 >    Show Definition of `display-...'
 >    Show References for `display-...'

We could try to abbreviate them in some clever way that could be also
used here on emacs-devel when discussing such variables (rather than the
d-f-c-i-c some people use instead).  But I think that your 'function'
and 'variable' are already good enough (the term "symbol" has gone for
good) and maybe we could write out the identifier in the tooltips as,
for example, instead of

"Find definition of identifier"

we would write

"Find definition of 'setq'"

 > Generally, I agree, but the problem is that "Describe Character"
 > is not specific to the currently discussed emacs-lisp-mode.

Neither Paste nor Undo are so we can place that "Describe Character"
just at the end.  It should be just intuitively evident for the user
that the properties of the character described at the position of the
mouse are different from the properties of the same character at a
different position.  As I claimed before, 'describe-char' tells so many
interesting things which could prompt a user to dig further, as to not
put it into the context menu.

 > Should the context menu always contain "Describe Character"
 > in all buffers?

Definitively.  It even does tell the user something useful about
whitespace and control characters.

 > The "Select" sub-menu is a good idea.  For example, LibreOffice has
 > a sub-menu "Selection Mode" with "Standard" and "Rectangle Selection".
 > Gimp even has the top-level menu "Select", etc.  But this means that
 > region-related part of the context menu doesn't need to be the same
 > as region-related part of the Edit sub-menu of the menu-bar?

A "Select" context submenu should propose something reasonable when
there is no active region.  When there is an active region around the
mouse position it should say _what_ "Undo" undoes and what "Clear"
clears.  And the Edit sub-menu should say the same.

 > Maybe not in Show/Hide sub-menu that is related only to visible parts
 > of the screen.

Tooltips are not visible either until they are shown.

martin





^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: [External] : bug#9054: 24.0.50; show source in other window
  2021-09-21  8:32                                         ` martin rudalics
@ 2021-09-21 17:52                                           ` Drew Adams
  0 siblings, 0 replies; 57+ messages in thread
From: Drew Adams @ 2021-09-21 17:52 UTC (permalink / raw)
  To: martin rudalics, Eli Zaretskii, Juri Linkov; +Cc: larsi, 9054

>  >   Command
>  >   Function
>  >   Option
>  >   Variable
>  >   Face
>  >   Key
>  >   File
> 
> I suppose you mean to show 'Command' and 'Option' as substitutes for
> 'Function' and 'Variable' whenever applicable.

Yes.

I also provide commands `describe-command' and
`describe-option'.  I think the narrower scope
is helpful, in particular for use with completion.

Remember, there I was showing a menu-bar menu,
not a mouse-3 context menu.  So, yes, prompting
in the minibuffer, completion, etc.

> I'd still stick to 'Function' and 'Variable'
> as Juri does now already.

I was only describing what I've done.  Different
strokes for different folks.

> I don't understand what 'Key' would tell the user here.

It's bound to standard command `describe-key'.

> 'File' could be treated like a link at the mouse
> position to follow.

It could.  But I was describing the Help > Describe
menu-bar menu, not a mouse-3 context menu.

In that menu-bar menu, item `File' is bound to
command `describe-file', defined in my code:

 Describe the file named FILENAME.
 If FILENAME is nil, describe current directory
 (`default-directory').

 If the file is an image file then:
  * Show a thumbnail of the image as well.
  * If you have command-line tool `exiftool'
    installed and in your `$PATH' or `exec-path',
    then show EXIF data (metadata) about the image.
    See standard Emacs library `image-dired.el' for
    more information about `exiftool'.

 If FILENAME is the name of an autofile bookmark
 and you use library `Bookmark+', then show also
 the bookmark information (tags etc.).  In this case,
 a prefix arg shows the internal form of the bookmark.

> 'Face' finally should be part of the character at
> the mouse position, accessible via 'describe-char'.

See above - I was showing menu-bar Help > Describe.

But my mouse-3 `Thing At Pointer' > `Describe Face'
menu item invokes command `describe-face', also a
command I define:

 Display the properties of face FACE on FRAME.
 Interactively, FACE defaults to the faces of the
 character after point and FRAME defaults to the
 selected frame.

 If the optional argument FRAME is given, report on
  face FACE in that frame.
 If FRAME is t, report on the defaults for face FACE
  (for new frames).
 If FRAME is omitted or nil, use the selected frame.

>  > And even the vanilla Help > Describe has key,
>  > function, variable, and face.
> 
> Again I'd say that 'describe-key' is hardly related
> to the position of the mouse pointer.

Again, I showed my menu-bar Help > Describe menu.

>  > FWIW, I don't think writing out the name of
>  > the symbol (or face or whatever) is needed.
> 
> It would disambiguate the object clicking would describe.

How important is that before you click?  (1) You
can see what you're pointing at.  (2) When multiple
things are under the pointer you can see which one
you actually got in the *Help* result.

If the name were always short and clear, then your
point would be stronger.

>  > In the case of symbols, the symbol name is
>  > being pointed at.  Yes, in the case of a
>  > face or some other thing that's not showing
>  > its name, the name might help, but just
>  > trying the menu item shows a user what's
>  > involved right away.
> 
> But we do not handle any symbol - we handle only predefined ones.  For
> the rest we currently get some mysterious text in the echo area or no
> information at all.  When I write
> (setq x 3)
> and right click on "x" I get no useful hint at what to try further.
> When I evaluate that form via C-x C-e I get instead
>  x’s value is 3
> 
>  Not documented as a variable.
> 
>    Probably introduced at or before Emacs version 1.4.
>
> which is better (but for that last line).  So maybe in the unevaluated
> case a user should get
>  x's value is void
> 
>  Not documented as a variable.
> instead.

I've no special comment on this.  In general, in my
case if a particular kind of thing under the pointer
isn't defined then the menu item is inactive for
that thing kind.

Whether, for a name such as `x' you want to try to
look it up as a variable and a function etc. and
then activate relevant items, do so.  I'm not sure
it's worth such lookups, and of course there's the
question of which context/environment to look up
such things in.

^ permalink raw reply	[flat|nested] 57+ messages in thread

* bug#9054: 24.0.50; show source in other window
  2021-09-21  8:34                                       ` martin rudalics
@ 2021-09-21 18:05                                         ` Juri Linkov
  0 siblings, 0 replies; 57+ messages in thread
From: Juri Linkov @ 2021-09-21 18:05 UTC (permalink / raw)
  To: martin rudalics; +Cc: Lars Ingebrigtsen, 9054

>>> We could abbreviate such monsters in the menu entry and show the full
>>> identifier in the tooltip of the menu entry.
>>
>> I'm not sure if this would be more useful:
>>
>>    Describe `display-...'
>>    Lookup `display-...' in Manuals
>>    Show Definition of `display-...'
>>    Show References for `display-...'
>
> We could try to abbreviate them in some clever way that could be also
> used here on emacs-devel when discussing such variables (rather than the
> d-f-c-i-c some people use instead).  But I think that your 'function'
> and 'variable' are already good enough (the term "symbol" has gone for
> good) and maybe we could write out the identifier in the tooltips as,
> for example, instead of
>
> "Find definition of identifier"
>
> we would write
>
> "Find definition of 'setq'"

Good idea.

>> Generally, I agree, but the problem is that "Describe Character"
>> is not specific to the currently discussed emacs-lisp-mode.
>
> Neither Paste nor Undo are so we can place that "Describe Character"
> just at the end.  It should be just intuitively evident for the user
> that the properties of the character described at the position of the
> mouse are different from the properties of the same character at a
> different position.  As I claimed before, 'describe-char' tells so many
> interesting things which could prompt a user to dig further, as to not
> put it into the context menu.

The question is whether to show it by default.  The default menu that the
user will see after clicking somewhere in a new buffer will contain just
2 items:

  - Select All
  - Describe Character `x'

I think the second item will confuse the users.  But it can be added
to an optional menu for advanced users.

>> Should the context menu always contain "Describe Character"
>> in all buffers?
>
> Definitively.  It even does tell the user something useful about
> whitespace and control characters.

I can't imagine that a novice user would need to describe a character
and inspect the output of describe-char.

>> The "Select" sub-menu is a good idea.  For example, LibreOffice has
>> a sub-menu "Selection Mode" with "Standard" and "Rectangle Selection".
>> Gimp even has the top-level menu "Select", etc.  But this means that
>> region-related part of the context menu doesn't need to be the same
>> as region-related part of the Edit sub-menu of the menu-bar?
>
> A "Select" context submenu should propose something reasonable when
> there is no active region.  When there is an active region around the
> mouse position it should say _what_ "Undo" undoes and what "Clear"
> clears.  And the Edit sub-menu should say the same.

I don't understand what it could say.  Do you mean it should change to
"Undo in Region"?

>> Maybe not in Show/Hide sub-menu that is related only to visible parts
>> of the screen.
>
> Tooltips are not visible either until they are shown.

Then "Context Menus" could be placed below from "Menu Bar".





^ permalink raw reply	[flat|nested] 57+ messages in thread

end of thread, other threads:[~2021-09-21 18:05 UTC | newest]

Thread overview: 57+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-07-11 18:31 bug#9054: 24.0.50; show source in other window Florian Beck
2011-07-12  8:21 ` martin rudalics
2011-08-31 16:52   ` Juri Linkov
2011-09-01  0:26     ` martin rudalics
2021-09-07 18:12 ` Lars Ingebrigtsen
2021-09-07 19:11   ` martin rudalics
2021-09-07 19:17     ` Lars Ingebrigtsen
2021-09-08  8:29       ` martin rudalics
2021-09-08 10:30         ` Lars Ingebrigtsen
2021-09-09  8:34           ` martin rudalics
2021-09-09 13:13             ` Lars Ingebrigtsen
2021-09-10  8:34               ` martin rudalics
2021-09-09 17:20   ` Juri Linkov
2021-09-10 10:21     ` Lars Ingebrigtsen
2021-09-10 16:15       ` Juri Linkov
2021-09-11  8:38         ` martin rudalics
2021-09-11 18:51           ` Juri Linkov
2021-09-13  8:02             ` martin rudalics
2021-09-13 17:57               ` Juri Linkov
2021-09-13 18:43                 ` Juri Linkov
2021-09-15  9:28                   ` martin rudalics
2021-09-15 16:07                     ` Juri Linkov
2021-09-15 18:48                       ` martin rudalics
2021-09-17  7:21                         ` Juri Linkov
2021-09-17  7:39                           ` martin rudalics
2021-09-17 16:04                             ` Juri Linkov
2021-09-18  7:36                               ` martin rudalics
2021-09-18 16:30                                 ` bug#9054: [External] : " Drew Adams
2021-09-19 16:20                                 ` Juri Linkov
2021-09-19 17:27                                   ` Eli Zaretskii
2021-09-19 17:35                                     ` bug#9054: [External] : " Drew Adams
2021-09-19 17:43                                       ` Eli Zaretskii
2021-09-20  8:21                                     ` martin rudalics
2021-09-20 14:11                                       ` bug#9054: [External] : " Drew Adams
2021-09-21  8:32                                         ` martin rudalics
2021-09-21 17:52                                           ` Drew Adams
2021-09-20  8:21                                   ` martin rudalics
2021-09-20 15:20                                     ` Juri Linkov
2021-09-21  8:34                                       ` martin rudalics
2021-09-21 18:05                                         ` Juri Linkov
2021-09-14 11:07                 ` Lars Ingebrigtsen
2021-09-15  9:28                   ` martin rudalics
2021-09-15  9:30                     ` Lars Ingebrigtsen
2021-09-15  9:42                       ` martin rudalics
2021-09-15  9:27                 ` martin rudalics
2021-09-15 16:05                   ` Juri Linkov
2021-09-15 18:47                     ` martin rudalics
2021-09-16 18:53                       ` Juri Linkov
2021-09-16 19:11                         ` Juri Linkov
2021-09-17  7:39                         ` martin rudalics
2021-09-17 16:05                           ` Juri Linkov
2021-09-18  7:35                             ` martin rudalics
2021-09-11  8:35       ` martin rudalics
2021-09-11 12:43         ` Lars Ingebrigtsen
2021-09-11 16:42           ` martin rudalics
2021-09-13  7:50             ` Lars Ingebrigtsen
2021-09-13  8:10               ` martin rudalics

Code repositories for project(s) associated with this inbox:

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).