bug#9054: 24.0.50; show source in other window

bug#9054: 24.0.50; show source in other window

[Florian Beck]

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

bug#9054: 24.0.50; show source in other window

[martin rudalics]

[-- 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 --]

bug#9054: 24.0.50; show source in other window

[Juri Linkov]

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

bug#9054: 24.0.50; show source in other window

[martin rudalics]

 > 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

bug#9054: 24.0.50; show source in other window

[Lars Ingebrigtsen]

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

bug#9054: 24.0.50; show source in other window

[martin rudalics]

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

bug#9054: 24.0.50; show source in other window

[Lars Ingebrigtsen]

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

bug#9054: 24.0.50; show source in other window

[martin rudalics]

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

bug#9054: 24.0.50; show source in other window

[Lars Ingebrigtsen]

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

bug#9054: 24.0.50; show source in other window

[martin rudalics]

 > 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

bug#9054: 24.0.50; show source in other window

[Lars Ingebrigtsen]

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

bug#9054: 24.0.50; show source in other window

[martin rudalics]

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

bug#9054: 24.0.50; show source in other window

[Arthur Miller]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> 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.
Mine is similar; but after I have used my own patch for two days now, it is
actually convenient to use it as a source browser. Especially since you can
scroll it from the source window, and you can also click in the source code in
help buffer itself, C-h f or C-h o, and it will open under the mouse in the same
window and I can switch back and forward. It is almost in a way more convenient
than jumping in source files.

bug#9054: 24.0.50; show source in other window

[martin rudalics]

 > Mine is similar; but after I have used my own patch for two days now, it is
 > actually convenient to use it as a source browser. Especially since you can
 > scroll it from the source window, and you can also click in the source code in
 > help buffer itself, C-h f or C-h o, and it will open under the mouse in the same
 > window and I can switch back and forward. It is almost in a way more convenient
 > than jumping in source files.

I just did C-h f whitespace-display-window, from there went to that
function's source and added a doc-string for it.  Displaying the source
in the help window would have been merely distracting in this scenario.

martin

bug#9054: 24.0.50; show source in other window

[Arthur Miller]

martin rudalics <rudalics@gmx.at> writes:

>> Mine is similar; but after I have used my own patch for two days now, it is
>> actually convenient to use it as a source browser. Especially since you can
>> scroll it from the source window, and you can also click in the source code in
>> help buffer itself, C-h f or C-h o, and it will open under the mouse in the same
>> window and I can switch back and forward. It is almost in a way more convenient
>> than jumping in source files.
>
> I just did C-h f whitespace-display-window, from there went to that
> function's source and added a doc-string for it.  Displaying the source
> in the help window would have been merely distracting in this scenario.
>
Ok, but that is diferrent usage scenario :). You are completely changing
requirement there. What you describe is indeed more handy when you wish to hack
a function. But when you do not wish to hack it, but would like to see what it
does, but stay in the same buffer you were edited, than what you describe would
be nuissance and distraction.

Also, consider again, people new to Emacs. Having source auto shown to them,
makes them probably more akin to see what is going on, how things work and give
more incitament to explore. I think. 

bug#9054: 24.0.50; show source in other window

[martin rudalics]

 >> I just did C-h f whitespace-display-window, from there went to that
 >> function's source and added a doc-string for it.  Displaying the source
 >> in the help window would have been merely distracting in this scenario.
 >>
 > Ok, but that is diferrent usage scenario :). You are completely changing
 > requirement there. What you describe is indeed more handy when you wish to hack
 > a function. But when you do not wish to hack it, but would like to see what it
 > does, but stay in the same buffer you were edited, than what you describe would
 > be nuissance and distraction.

The point I wanted to make was that there may be tenths of different
usage scenarios for perusing the *Help* window and its buffer.

 > Also, consider again, people new to Emacs. Having source auto shown to them,
 > makes them probably more akin to see what is going on, how things work and give
 > more incitament to explore. I think.

There are two major sources of disappointments here - many users are not
proficient in C and often the function they will look up first is only a
stub for the function doing the actual work.

martin

bug#9054: 24.0.50; show source in other window

[Arthur Miller]

martin rudalics <rudalics@gmx.at> writes:

>>> I just did C-h f whitespace-display-window, from there went to that
>>> function's source and added a doc-string for it.  Displaying the source
>>> in the help window would have been merely distracting in this scenario.
>>>
>> Ok, but that is diferrent usage scenario :). You are completely changing
>> requirement there. What you describe is indeed more handy when you wish to hack
>> a function. But when you do not wish to hack it, but would like to see what it
>> does, but stay in the same buffer you were edited, than what you describe would
>> be nuissance and distraction.
>
> The point I wanted to make was that there may be tenths of different
> usage scenarios for perusing the *Help* window and its buffer.

Ah, sorry then, in that case we are in agreement. Yes there are different usage
scenarios. I think what you have considered in this thread, does not even
require help buffer. If someone would just like to pop a source for a symbol,
you could just code an interactive funtion to open the source file for the
symbol, all the code is already there. There is no need to even touch the
help-buffer for that.

>> Also, consider again, people new to Emacs. Having source auto shown to them,
>> makes them probably more akin to see what is going on, how things work and give
>> more incitament to explore. I think.
>
> There are two major sources of disappointments here - many users are not
> proficient in C and often the function they will look up first is only a
> stub for the function doing the actual work.

Yes indeed, I agree with that one. Also many new users would be new to Lisp
too. My proposal was to make it optional to show/hide source, mostly because of
the cpu overhead, but we can also add option to show only lisp sources.

I don't what is the best; I don't think there is a one-solution-fits-all in this
case. Users have different workflows, different backgroudns etc, so maybe it is
best to just be flexible as much as it is possible.

bug#9054: 24.0.50; show source in other window

[Juri Linkov]

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

bug#9054: 24.0.50; show source in other window

[Lars Ingebrigtsen]

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

bug#9054: 24.0.50; show source in other window

[Juri Linkov]

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

bug#9054: 24.0.50; show source in other window

[martin rudalics]

 > 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

bug#9054: 24.0.50; show source in other window

[Juri Linkov]

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

bug#9054: 24.0.50; show source in other window

[martin rudalics]

 > 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

bug#9054: 24.0.50; show source in other window

[Juri Linkov]

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

bug#9054: 24.0.50; show source in other window

[Juri Linkov]

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

bug#9054: 24.0.50; show source in other window

[martin rudalics]

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

bug#9054: 24.0.50; show source in other window

[Juri Linkov]

>>>> (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:")

bug#9054: 24.0.50; show source in other window

[martin rudalics]

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

bug#9054: 24.0.50; show source in other window

[Juri Linkov]

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

bug#9054: 24.0.50; show source in other window

[martin rudalics]

 > 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

bug#9054: 24.0.50; show source in other window

[Juri Linkov]

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

bug#9054: 24.0.50; show source in other window

[martin rudalics]

 > 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

bug#9054: [External] : bug#9054: 24.0.50; show source in other window

[Drew Adams]

> 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

bug#9054: 24.0.50; show source in other window

[Juri Linkov]

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

bug#9054: 24.0.50; show source in other window

[Eli Zaretskii]

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

bug#9054: [External] : bug#9054: 24.0.50; show source in other window

[Drew Adams]

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

bug#9054: [External] : bug#9054: 24.0.50; show source in other window

[Eli Zaretskii]

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

bug#9054: 24.0.50; show source in other window

[martin rudalics]

 > 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

bug#9054: [External] : bug#9054: 24.0.50; show source in other window

[Drew Adams]

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

bug#9054: [External] : bug#9054: 24.0.50; show source in other window

[martin rudalics]

 >   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

bug#9054: [External] : bug#9054: 24.0.50; show source in other window

[Drew Adams]

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

bug#9054: [External] : bug#9054: 24.0.50; show source in other window

[martin rudalics]

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

With context menus we have to find a compromise: Searching manuals or
the code base at the time of displaying the menu might take too long.

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

If I evaluate (setq x 3) and then I'm told that x was "Probably
introduced at or before Emacs version 1.4" something went wrong.

martin

bug#9054: [External] : bug#9054: 24.0.50; show source in other window

[Drew Adams]

>> 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.
> 
> With context menus we have to find a compromise: Searching manuals or
> the code base at the time of displaying the menu might take too long.

Sorry, I don't understand.  I probably can't help you
with what you're trying to do.  I don't know what
searching you're talking about.

All I do is check whether there is such a thing-at-point.
If not, I don't enable the menu item for acting on that
kind of thing-at-point.

When I say "thing-at-point" here, a given test could use
the thingatpt.el code (or similar), or it could use other
code, such as ffap tests.  E.g., for a file or dir I use
this (wrapped in `ignore-errors'):

 (defun mouse3-file-or-dir ()
  "Return file or dir name at point.  Raise error if none."
  (let ((guess  (ffap-guesser)))
    (unless (and guess
                 (or (ffap-file-remote-p guess)
                     (file-directory-p
                       (abbreviate-file-name
                         (expand-file-name guess)))
                     (file-regular-p guess)))
      (error "No file or dir name under mouse pointer"))
    guess))

For Describe Function I use this for :enable:
(or (fboundp (symbol-at-point))  (function-called-at-point))

For Show Code Defining Function I use this:
(function-called-at-point)

And so on.  Are you worried that such :enable tests
"search manuals or the code base"?  I don't see how
they do.  But in any case, I don't see any delay in
displaying the menu.

>  > 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.
> 
> If I evaluate (setq x 3) and then I'm told that x was "Probably
> introduced at or before Emacs version 1.4" something went wrong.

Sorry, I don't follow you.  It doesn't matter whether
I do.  Do whatever you intend to do.  I just wanted
to share what I do, in case it helps.

bug#9054: [External] : bug#9054: 24.0.50; show source in other window

[martin rudalics]

 > All I do is check whether there is such a thing-at-point.
 > If not, I don't enable the menu item for acting on that
 > kind of thing-at-point.

If the thing-at-point is nowhere defined, its context menu should not
show an entry for going to the definition of the thing-at-point.  If the
thing-at-point has no manual entry, its context menu should not show an
entry for looking up the manual entry for the thing-at-point.  Ideally.
Unfortunately, it sometimes may be too time consuming to tell on the fly
whether the thing-at-point is defined and/or has a manual entry.

martin

bug#9054: [External] : bug#9054: 24.0.50; show source in other window

[Drew Adams]

>> All I do is check whether there is such a thing-at-point.
>> If not, I don't enable the menu item for acting on that
>> kind of thing-at-point.
> 
> If the thing-at-point is nowhere defined, its context
> menu should not show an entry for going to the
> definition of the thing-at-point.

The choice between :visible and :enable is just that:
a choice.  Do what you want.

I chose to show those menu items, possibly disabled,
to let users know they exist, and so they can easily
see when the pointer is over a thing to which the
item applies.

You can instead choose to not show the item at all
when it can't be used for the thing under the pointer.

IMO, the UI state change for :visible is a big one,
and it removes helpful info.  It also provides some
other info, but only by _recognizing absence_.  I
tend to use :enable much more than :visible.  YMMV.

> If the thing-at-point has no manual entry, its
> context menu should not show an entry for looking
> up the manual entry for the thing-at-point.

All but one of the functions I mentioned don't
concern manual entries.  They concern *Help* output.
They're `describe-*' commands.

The exception is `Look Up Symbol in Manual', whose
:enable test is just (symbol-at-point).  That was
my choice.  Yes, the command used for that is
`info-lookup-symbol', and yes, it can result in
a message `Not documented as a symbol: whizbang'.

Do you prefer to search the manual unconditionally
all the time, for eah thing under the pointer?
Will you then complain to yourself that that slows
things down too much?  (Then just don't do that.)

Again, do whatever you want - these are design
choices - judgments.  There's no hard-and-fast
rule that governs such things.  (Try XYZ, and see
what users think.)

> Ideally.  Unfortunately, it sometimes may be too
> time consuming to tell on the fly whether the
> thing-at-point is defined and/or has a manual entry.

Yes.  In which case the design question can become
whether it helps users to provide such a menu item
without strict, 100% certainty that it's applicable,
or to just not give users such a menu item at all.
If the perfect test is too costly, do you give up
or use an imperfect test that at least lets users
try for themselves?

Again, your choice.  I made mine, for my code.

bug#9054: [External] : bug#9054: 24.0.50; show source in other window

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "larsi@gnus.org" <larsi@gnus.org>,
>         "9054@debbugs.gnu.org"
> 	<9054@debbugs.gnu.org>
> Date: Wed, 22 Sep 2021 16:09:18 +0000
> 
> >> All I do is check whether there is such a thing-at-point.
> >> If not, I don't enable the menu item for acting on that
> >> kind of thing-at-point.
> > 
> > If the thing-at-point is nowhere defined, its context
> > menu should not show an entry for going to the
> > definition of the thing-at-point.
> 
> The choice between :visible and :enable is just that:
> a choice.  Do what you want.

That's not the issue at hand, because the time it takes to decide
whether a menu item should be :enable'd is as long as the time it
takes to decide whether it should be :visible.  That time _is_ the
issue.

bug#9054: [External] : bug#9054: 24.0.50; show source in other window

[Drew Adams]

> > >> All I do is check whether there is such a thing-at-point.
> > >> If not, I don't enable the menu item for acting on that
> > >> kind of thing-at-point.
> > >
> > > If the thing-at-point is nowhere defined, its context
> > > menu should not show an entry for going to the
> > > definition of the thing-at-point.
> >
> > The choice between :visible and :enable is
> > just that: a choice.  Do what you want.
> 
> That's not the issue at hand, because the time it takes to decide
> whether a menu item should be :enable'd is as long as the time it
> takes to decide whether it should be :visible.  That time _is_ the
> issue.

Of course it takes the same amount of time - for
the same test.  That's not the issue at hand.

Please read the rest of what I wrote.  Martin
said you shouldn't show a menu item unless it
tests OK (in his case with a strict test that
takes too long, but that's beside the point
about :enable/:visible).

The text you quote responds to his statement
that an item shouldn't be shown if a test
fails.  I said there's no such rule; it's a
design choice whether to show a particular
item as disabled or to not show it at all.

We have :enable, and not only :visible, for
a reason.

Again, do what you want.  I've done what I
think is helpful, in my code.  And I've let
you know about that experience.  You're
welcome.

bug#9054: [External] : bug#9054: 24.0.50; show source in other window

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "rudalics@gmx.at" <rudalics@gmx.at>, "juri@linkov.net" <juri@linkov.net>,
>         "larsi@gnus.org" <larsi@gnus.org>,
>         "9054@debbugs.gnu.org"
> 	<9054@debbugs.gnu.org>
> Date: Wed, 22 Sep 2021 16:49:55 +0000
> 
> > > The choice between :visible and :enable is
> > > just that: a choice.  Do what you want.
> > 
> > That's not the issue at hand, because the time it takes to decide
> > whether a menu item should be :enable'd is as long as the time it
> > takes to decide whether it should be :visible.  That time _is_ the
> > issue.
> 
> Of course it takes the same amount of time - for
> the same test.  That's not the issue at hand.
> 
> Please read the rest of what I wrote.

Can't afford it: life is too short.

bug#9054: [External] : bug#9054: 24.0.50; show source in other window

[Drew Adams]

> > > > The choice between :visible and :enable is
> > > > just that: a choice.  Do what you want.
> > >
> > > That's not the issue at hand, because the time it takes to decide
> > > whether a menu item should be :enable'd is as long as the time it
> > > takes to decide whether it should be :visible.  That time _is_ the
> > > issue.
> >
> > Of course it takes the same amount of time - for
> > the same test.  That's not the issue at hand.
> > Please read the rest of what I wrote.
> 
> Can't afford it: life is too short.

Likewise.

And yet you chimed in.

bug#9054: [External] : bug#9054: 24.0.50; show source in other window

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "rudalics@gmx.at" <rudalics@gmx.at>, "juri@linkov.net" <juri@linkov.net>,
>         "larsi@gnus.org" <larsi@gnus.org>,
>         "9054@debbugs.gnu.org"
> 	<9054@debbugs.gnu.org>
> Date: Wed, 22 Sep 2021 18:22:25 +0000
> 
> > > > > The choice between :visible and :enable is
> > > > > just that: a choice.  Do what you want.
> > > >
> > > > That's not the issue at hand, because the time it takes to decide
> > > > whether a menu item should be :enable'd is as long as the time it
> > > > takes to decide whether it should be :visible.  That time _is_ the
> > > > issue.
> > >
> > > Of course it takes the same amount of time - for
> > > the same test.  That's not the issue at hand.
> > > Please read the rest of what I wrote.
> > 
> > Can't afford it: life is too short.
> 
> Likewise.
> 
> And yet you chimed in.

What can I say? hope dies last.

bug#9054: 24.0.50; show source in other window

[martin rudalics]

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

bug#9054: 24.0.50; show source in other window

[Juri Linkov]

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

bug#9054: 24.0.50; show source in other window

[martin rudalics]

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

bug#9054: 24.0.50; show source in other window

[Juri Linkov]

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

bug#9054: 24.0.50; show source in other window

[martin rudalics]

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

If that new buffer is empty, not even these should be shown.

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

It's an entrance into syntax and font-locking, tells me about text and
overlay properties, coding, character sets and composition.  What else
could you desire thinking of how often these topics are discussed here
on these list?

 >> 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"?

I do.  IIUC that's what 'undo' (unfortunately) does when the region is
active.  Likewise it should say "Clear Region".

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

I'd say we should pluralize some of these, namely "Scroll Bars",
"Fringes", "Window Dividers" and "Window Tab Lines", move them below
"Speedbar" and after them add "Tooltips" and "Context Menus" and then
the separator.

martin

bug#9054: 24.0.50; show source in other window

[Juri Linkov]

> It's an entrance into syntax and font-locking, tells me about text and
> overlay properties, coding, character sets and composition.  What else
> could you desire thinking of how often these topics are discussed here
> on these list?

All these overlay properties, coding, character sets and composition
wouldn't be too confusing for beginners?

>>> 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"?
>
> I do.  IIUC that's what 'undo' (unfortunately) does when the region is
> active.

Done, with many other your suggestions implemented, thanks for ideas.

>> Then "Context Menus" could be placed below from "Menu Bar".
>
> I'd say we should pluralize some of these, namely "Scroll Bars",
> "Fringes", "Window Dividers" and "Window Tab Lines", move them below
> "Speedbar" and after them add "Tooltips" and "Context Menus" and then
> the separator.

I have no opinion about pluralization, so I only added "Context Menus".

bug#9054: 24.0.50; show source in other window

[martin rudalics]

 > All these overlay properties, coding, character sets and composition
 > wouldn't be too confusing for beginners?

They confuse me often enough.  Yet they are a great source for digging
further.

martin

bug#9054: 24.0.50; show source in other window

[Juri Linkov]

>> All these overlay properties, coding, character sets and composition
>> wouldn't be too confusing for beginners?
>
> They confuse me often enough.  Yet they are a great source for digging
> further.

Web browsers have for this purpose the context menu item named
"Inspect".  The same could be added to Emacs context menus.

bug#9054: 24.0.50; show source in other window

[martin rudalics]

 > Web browsers have for this purpose the context menu item named
 > "Inspect".  The same could be added to Emacs context menus.

I doubt that it would be of much use in non-markup buffers.

martin

bug#9054: 24.0.50; show source in other window

[martin rudalics]

 > Done, with many other your suggestions implemented, thanks for ideas.

Neat.  I would try to refine the "Select" mechanism a bit:

- The order should be All>Defun>List>Line>Symbol or (preferably) the
   inverse.

- In comments and strings it might be nice to advertise selecting the
   entire comment or string.

- Choosing All, in particular, will practically always relocate point
   and scroll the window.  This might be confusing - many people might
   not understand the combined effect of our "point is always visible"
   and "point is at one end of the active region" paradigms - so we
   should provide some way to retract that action and restore the window
   point and start position afterwards.  Maybe None could do that by
   default but where should List followed by Defun followed by None
   scroll to?

martin

bug#9054: 24.0.50; show source in other window

[Juri Linkov]

>> Done, with many other your suggestions implemented, thanks for ideas.
>
> Neat.  I would try to refine the "Select" mechanism a bit:
>
> - The order should be All>Defun>List>Line>Symbol or (preferably) the
>   inverse.

Done (but not in inverse because other apps like Gimp use such order: All>None).

> - In comments and strings it might be nice to advertise selecting the
>   entire comment or string.

This is a great idea.  I missed such ability for a long time
to be able to select the entire string.  Now this is implemented
using a new thing-at-point target 'list-or-string'.

> - Choosing All, in particular, will practically always relocate point
>   and scroll the window.  This might be confusing - many people might
>   not understand the combined effect of our "point is always visible"
>   and "point is at one end of the active region" paradigms - so we
>   should provide some way to retract that action and restore the window
>   point and start position afterwards.  Maybe None could do that by
>   default but where should List followed by Defun followed by None
>   scroll to?

Good idea, but not implementable.  This supposes that selecting All
should remember the old position of point, then None could restore it.
But what if the user selected the entire buffer with the key 'C-x h',
then selected None?

bug#9054: 24.0.50; show source in other window

[martin rudalics]

 > Done (but not in inverse because other apps like Gimp use such order: All>None).

OK.

 >> - In comments and strings it might be nice to advertise selecting the
 >>    entire comment or string.
 >
 > This is a great idea.  I missed such ability for a long time
 > to be able to select the entire string.  Now this is implemented
 > using a new thing-at-point target 'list-or-string'.

And no such thing for comments?  Instead of

(nth 3 (save-excursion (syntax-ppss pos)

I'd use something like

(let ((state (save-excursion (syntax-ppss pos))))
   (cond
    ((nth 3 state)
     ... use (nth 8 state) and parse until end of string)
    ((nth 4 state)
     ... use (nth 8 state) and parse until end of comment)))

and thus immediately get type, start and end of the syntactic entity at
pos.

 >> - Choosing All, in particular, will practically always relocate point
 >>    and scroll the window.  This might be confusing - many people might
 >>    not understand the combined effect of our "point is always visible"
 >>    and "point is at one end of the active region" paradigms - so we
 >>    should provide some way to retract that action and restore the window
 >>    point and start position afterwards.  Maybe None could do that by
 >>    default but where should List followed by Defun followed by None
 >>    scroll to?
 >
 > Good idea, but not implementable.  This supposes that selecting All
 > should remember the old position of point, then None could restore it.
 > But what if the user selected the entire buffer with the key 'C-x h',
 > then selected None?

What would be bad about that?  Anyway, you could add some variable you'd
set via 'All' or whatever causes pos to move off-screen and have 'None'
inspect that flag to tell whether it should go back.  Clearing the active
region would clear that variable too.

martin

bug#9054: 24.0.50; show source in other window

[Juri Linkov]

>>> - In comments and strings it might be nice to advertise selecting the
>>>    entire comment or string.
>>
>> This is a great idea.  I missed such ability for a long time
>> to be able to select the entire string.  Now this is implemented
>> using a new thing-at-point target 'list-or-string'.
>
> And no such thing for comments?  Instead of
>
> (nth 3 (save-excursion (syntax-ppss pos)
>
> I'd use something like
>
> (let ((state (save-excursion (syntax-ppss pos))))
>   (cond
>    ((nth 3 state)
>     ... use (nth 8 state) and parse until end of string)
>    ((nth 4 state)
>     ... use (nth 8 state) and parse until end of comment)))
>
> and thus immediately get type, start and end of the syntactic entity at
> pos.

I tried to implement the 'thing' for comments, but can't find a function
that moves to the end of the comment.  In case of string, such function is
simply '(forward-sexp)'.

>>> - Choosing All, in particular, will practically always relocate point
>>>    and scroll the window.  This might be confusing - many people might
>>>    not understand the combined effect of our "point is always visible"
>>>    and "point is at one end of the active region" paradigms - so we
>>>    should provide some way to retract that action and restore the window
>>>    point and start position afterwards.  Maybe None could do that by
>>>    default but where should List followed by Defun followed by None
>>>    scroll to?
>>
>> Good idea, but not implementable.  This supposes that selecting All
>> should remember the old position of point, then None could restore it.
>> But what if the user selected the entire buffer with the key 'C-x h',
>> then selected None?
>
> What would be bad about that?  Anyway, you could add some variable you'd
> set via 'All' or whatever causes pos to move off-screen and have 'None'
> inspect that flag to tell whether it should go back.  Clearing the active
> region would clear that variable too.

But there are too many ways to clear the active region.

bug#9054: 24.0.50; show source in other window

[martin rudalics]

 > I tried to implement the 'thing' for comments, but can't find a function
 > that moves to the end of the comment.  In case of string, such function is
 > simply '(forward-sexp)'.

It's 'parse-partial-sexp' with OLDSTATE the state just produced by
'syntax-ppss' and COMMENTSTOP set to 'syntax-table'.  Same for the
string case.  I'd do it lazily since the context menu is modal and it's
unlikely that some timer-based function changes the buffer under its
feet.  Thus save the old state while the menu is active and do the call
when the user wants to mark the comment or string.

 >> What would be bad about that?  Anyway, you could add some variable you'd
 >> set via 'All' or whatever causes pos to move off-screen and have 'None'
 >> inspect that flag to tell whether it should go back.  Clearing the active
 >> region would clear that variable too.
 >
 > But there are too many ways to clear the active region.

Hmm...  The original position would be the one before the region was
made active.  Then you may expand the active region in various ways.
When it's deactivated without deleting the text it contains, go back to
the original position.  But maybe I'm missing some detail.

martin

bug#9054: 24.0.50; show source in other window

[Juri Linkov]

>> I tried to implement the 'thing' for comments, but can't find a function
>> that moves to the end of the comment.  In case of string, such function is
>> simply '(forward-sexp)'.
>
> It's 'parse-partial-sexp' with OLDSTATE the state just produced by
> 'syntax-ppss' and COMMENTSTOP set to 'syntax-table'.  Same for the
> string case.  I'd do it lazily since the context menu is modal and it's
> unlikely that some timer-based function changes the buffer under its
> feet.  Thus save the old state while the menu is active and do the call
> when the user wants to mark the comment or string.

I tried to add a new 'thing-at-point' target 'comment',
but then discovered that it's already supported by

  (thing-at-point 'comment)

because it automatically calls '(forward-comment 1)' and '(forward-comment -1)'.
However, it seems currently 'forward-comment' is broken -
it does nothing inside comments.  Maybe there is a bug?

Meanwhile, I moved Defun/List/Symbol selection items to prog-mode,
and added Paragraph/Sentence/Word selection items to text-mode
as well as to strings/comments in prog-mode.  Please check
if everything is correct.

bug#9054: 24.0.50; show source in other window

[martin rudalics]

 > I tried to add a new 'thing-at-point' target 'comment',
 > but then discovered that it's already supported by
 >
 >    (thing-at-point 'comment)
 >
 > because it automatically calls '(forward-comment 1)' and '(forward-comment -1)'.
 > However, it seems currently 'forward-comment' is broken -
 > it does nothing inside comments.  Maybe there is a bug?

IIUC 'forward-comment' is context-agnostic - you can safely use it only
at top level.  So in the case at hand you would have to run it from the
8th element of the return value of 'syntax-ppss'.  That's why I would
run 'syntax-ppss' from the current mouse position using the return value
of 'syntax-ppss' as OLDSTATE to avoid scanning text twice.

 > Meanwhile, I moved Defun/List/Symbol selection items to prog-mode,
 > and added Paragraph/Sentence/Word selection items to text-mode
 > as well as to strings/comments in prog-mode.  Please check
 > if everything is correct.

I will look as soon as I've pulled the sources again.  I have yet to
rename my "release" tree to "emacs-27", rebuild all targets there, make
emacs 28 my new release tree and rebuild all targets for it.  This
requires secure sources and I'm not yet sure what Paul's fixes have in
store for me.

BTW, I've recently seen this

Debugger entered--Lisp error: (args-out-of-range #<buffer *Help*> 1 2461677)
   parse-partial-sexp(1 2461677)
   syntax-ppss(2461677)
   context-menu-region((keymap #("Context Menu" 0 12 (hide t)) (separator-undo "--") (separator-region "--") (paste menu-item "Paste" mouse-yank-at-click :help "Paste (yank) text most recently cut/copied") (paste-from-menu menu-item "Paste from Kill Menu" (keymap (10 menu-item "\\" #f(compiled-function () (interactive nil) #<bytecode 0x1b8a5eddfe5537c0>)) (9 menu-item "\\" #f(compiled-function () (interactive nil) #<bytecode 0x1b8a5eddfe5537c0>)) (8 menu-item "\\" #f(compiled-function () (interactive nil) #<bytecode 0x1b8a5eddfe5537c0>)) (7 menu-item "\\" #f(compiled-function () (interactive nil) #<bytecode 0x1b8a5eddfe5537c0>)) (6 menu-item "\\" #f(compiled-function () (interactive nil) #<bytecode 0x1b8a5eddfe5537c0>)) (5 menu-item "\\" #f(compiled-function () (interactive nil) #<bytecode 0x1b8a5eddfe5537c0>)) (4 menu-item "\\" #f(compiled-function () (interactive nil) #<bytecode 0x1b8a5eddfe5537c0>)) (3 menu-item "\\" #f(compiled-function () (interactive nil) #<bytecode 0x1b8a5eddfe5537c0>)) (2 menu-item "\\" #f(compiled-function () (interactive nil) #<bytecode 0x1b8a5eddfe5537c0>)) (1 menu-item "\\" #f(compiled-function () (interactive nil) #<bytecode 0x1b8a5eddfe5537c0>)) "Paste from Kill Menu") :help "Choose a string from the kill ring and paste it")) 98)
   #f(compiled-function (fun) #<bytecode -0x1ee96643fef4ee80>)(context-menu-region)
   run-hook-wrapped(#f(compiled-function (fun) #<bytecode -0x1ee96643fef4ee80>) context-menu-region)
   context-menu-map()
   (lambda (_) (context-menu-map))(ignore)
   lookup-key(((down-mouse-3 menu-item "Context Menu" ignore :filter (lambda (_) (context-menu-map))) (mouse-3)) [down-mouse-3] t)
   describe-map((keymap (menu) (down-mouse-3 menu-item "Context Menu" ignore :filter (lambda (_) (context-menu-map))) (mouse-3)) [] nil t ((keymap (M-f4 . kill-frame-or-emacs) (C-M-S-down . window-delete-or-split-down) (C-M-S-right . window-delete-or-split-right) (C-M-S-up . window-delete-or-split-up) (C-M-S-left . window-delete-or-split-left) (M-S-down . windows-clock-down) (M-S-right . windows-clock-right) (M-S-up . windows-clock-up) (M-S-left . windows-clock-left) (M-down . window-delete-or-split-down) (M-up . window-delete-or-split-up) (M-right . my-bury-buffer) (M-left . my-unbury-buffer))) t nil)
   describe-map-tree((keymap (menu) (down-mouse-3 menu-item "Context Menu" ignore :filter (lambda (_) (context-menu-map))) (mouse-3)) t ((keymap (M-f4 . kill-frame-or-emacs) (C-M-S-down . window-delete-or-split-down) (C-M-S-right . window-delete-or-split-right) (C-M-S-up . window-delete-or-split-up) (C-M-S-left . window-delete-or-split-left) (M-S-down . windows-clock-down) (M-S-right . windows-clock-right) (M-S-up . windows-clock-up) (M-S-left . windows-clock-left) (M-down . window-delete-or-split-down) (M-up . window-delete-or-split-up) (M-right . my-bury-buffer) (M-left . my-unbury-buffer))) nil "\f\n`context-menu-mode' Minor Mode Bindings" t nil nil nil)
   describe-buffer-bindings(#<buffer *info*> nil)
   describe-bindings()
   funcall-interactively(describe-bindings)
   call-interactively(describe-bindings nil nil)
   command-execute(describe-bindings)

Any ideas as to what could have happened here?  I must have been hitting
C-h b by accident - as a rule I never call 'describe-bindings' - but
2461677 looks slightly preposterous ...

martin

bug#9054: 24.0.50; show source in other window

[Juri Linkov]

>> I tried to add a new 'thing-at-point' target 'comment',
>> but then discovered that it's already supported by
>>
>>    (thing-at-point 'comment)
>>
>> because it automatically calls '(forward-comment 1)' and '(forward-comment -1)'.
>> However, it seems currently 'forward-comment' is broken -
>> it does nothing inside comments.  Maybe there is a bug?
>
> IIUC 'forward-comment' is context-agnostic - you can safely use it only
> at top level.  So in the case at hand you would have to run it from the
> 8th element of the return value of 'syntax-ppss'.  That's why I would
> run 'syntax-ppss' from the current mouse position using the return value
> of 'syntax-ppss' as OLDSTATE to avoid scanning text twice.

It still needs to scan twice because for thing-at-point it should be
implemented as two functions:

  (put 'comment 'beginning-op 'thing-at-point--beginning-of-comment)
  (put 'comment 'end-op 'thing-at-point--end-of-comment)

> BTW, I've recently seen this
>
> Debugger entered--Lisp error: (args-out-of-range #<buffer *Help*> 1 2461677)
>   parse-partial-sexp(1 2461677)
>   syntax-ppss(2461677)
>   context-menu-region((keymap #("Context Menu" 0 12 (hide t))
>   context-menu-map()
>   describe-buffer-bindings(#<buffer *info*> nil)
>   describe-bindings()
>   funcall-interactively(describe-bindings)
>   call-interactively(describe-bindings nil nil)
>   command-execute(describe-bindings)
>
> Any ideas as to what could have happened here?  I must have been hitting
> C-h b by accident - as a rule I never call 'describe-bindings' - but
> 2461677 looks slightly preposterous ...

It seems you still using old source code?  Because recently this was fixed
in event-end to use (window-point).

bug#9054: 24.0.50; show source in other window

[martin rudalics]

 > It still needs to scan twice because for thing-at-point it should be
 > implemented as two functions:
 >
 >    (put 'comment 'beginning-op 'thing-at-point--beginning-of-comment)
 >    (put 'comment 'end-op 'thing-at-point--end-of-comment)

That should be redesigned in some way, possibly caching the syntax state
together with its 'buffer-modified-tick' when putting the 'beginning-op'.
And I would do the same for strings.  If I'm not completely mistaken,
you have to run the 'foward-sexp' from their beginnings there as well.

 >> BTW, I've recently seen this
 >>
 >> Debugger entered--Lisp error: (args-out-of-range #<buffer *Help*> 1 2461677)
 >>    parse-partial-sexp(1 2461677)
 >>    syntax-ppss(2461677)
 >>    context-menu-region((keymap #("Context Menu" 0 12 (hide t))
 >>    context-menu-map()
 >>    describe-buffer-bindings(#<buffer *info*> nil)
 >>    describe-bindings()
 >>    funcall-interactively(describe-bindings)
 >>    call-interactively(describe-bindings nil nil)
 >>    command-execute(describe-bindings)
 >>
 >> Any ideas as to what could have happened here?  I must have been hitting
 >> C-h b by accident - as a rule I never call 'describe-bindings' - but
 >> 2461677 looks slightly preposterous ...
 >
 > It seems you still using old source code?  Because recently this was fixed
 > in event-end to use (window-point).

Maybe.  Just that I can't remember working with a buffer that large ...

martin

bug#9054: 24.0.50; show source in other window

[Lars Ingebrigtsen]

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

bug#9054: 24.0.50; show source in other window

[martin rudalics]

 > 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

bug#9054: 24.0.50; show source in other window

[Lars Ingebrigtsen]

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

bug#9054: 24.0.50; show source in other window

[martin rudalics]

 > 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

bug#9054: 24.0.50; show source in other window

[Stefan Kangas]

martin rudalics <rudalics@gmx.at> writes:

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

This has already been done, as `print' does not preserve text attributes
(needed to fontify key bindings).

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

Probably, yes, and a whole range of other things.

bug#9054: 24.0.50; show source in other window

[martin rudalics]

 > 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

bug#9054: 24.0.50; show source in other window

[Juri Linkov]

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

bug#9054: 24.0.50; show source in other window

[martin rudalics]

 > 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

bug#9054: 24.0.50; show source in other window

[Juri Linkov]

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

bug#9054: 24.0.50; show source in other window

[Juri Linkov]

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

bug#9054: 24.0.50; show source in other window

[martin rudalics]

  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

bug#9054: 24.0.50; show source in other window

[Juri Linkov]

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

bug#9054: 24.0.50; show source in other window

[martin rudalics]

 > 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

bug#9054: 24.0.50; show source in other window

[martin rudalics]

 > 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

bug#9054: 24.0.50; show source in other window

[Lars Ingebrigtsen]

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

bug#9054: 24.0.50; show source in other window

[martin rudalics]

 > 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

bug#9054: 24.0.50; show source in other window

[Lars Ingebrigtsen]

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

bug#9054: 24.0.50; show source in other window

[martin rudalics]

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

bug#9054: 24.0.50; show source in other window

[Arthur Miller]

Lars Ingebrigtsen <larsi@gnus.org> writes:

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

#+begin_src emacs-lisp
           (add-to-list 'display-buffer-alist
                 `((,(rx bos (or "*Apropos*" "*Help*" "*helpful*" "*info*" "*Summary*")
                         (0+ not-newline))
                    (display-buffer-same-window)
                    (display-buffer-reuse-mode-window display-buffer-pop-up-window)
                    (mode apropos-mode help-mode helpful-mode Info-mode Man-mode))))
#+end_src

I have used that myself; that is from my init file, and it worked fine. But I
see in latest master I don't need to say that for *Help* any more?

bug#9054: 24.0.50; show source in other window

[martin rudalics]

 > #+begin_src emacs-lisp
 >             (add-to-list 'display-buffer-alist
 >                   `((,(rx bos (or "*Apropos*" "*Help*" "*helpful*" "*info*" "*Summary*")
 >                           (0+ not-newline))
 >                      (display-buffer-same-window)
 >                      (display-buffer-reuse-mode-window display-buffer-pop-up-window)
 >                      (mode apropos-mode help-mode helpful-mode Info-mode Man-mode))))
 > #+end_src
 >
 > I have used that myself; that is from my init file, and it worked fine. But I
 > see in latest master I don't need to say that for *Help* any more?

I'm not fluent with 'rx' so I cannot give you a good answer here.  Maybe
the default behavior already does what you want?

martin

bug#9054: 24.0.50; show source in other window

[Arthur Miller]

martin rudalics <rudalics@gmx.at> writes:

>> #+begin_src emacs-lisp
>>             (add-to-list 'display-buffer-alist
>>                   `((,(rx bos (or "*Apropos*" "*Help*" "*helpful*" "*info*" "*Summary*")
>>                           (0+ not-newline))
>>                      (display-buffer-same-window)
>>                      (display-buffer-reuse-mode-window display-buffer-pop-up-window)
>>                      (mode apropos-mode help-mode helpful-mode Info-mode Man-mode))))
>> #+end_src
>>
>> I have used that myself; that is from my init file, and it worked fine. But I
>> see in latest master I don't need to say that for *Help* any more?
>
> I'm not fluent with 'rx' so I cannot give you a good answer here.  Maybe
> the default behavior already does what you want?

Ah, I didn't meant regexes; I meant using display-buffer-alist to tell Emacs to
re-use *Help* buffer instead of creating new ones.

bug#9054: 24.0.50; show source in other window

[martin rudalics]

 > Ah, I didn't meant regexes; I meant using display-buffer-alist to tell Emacs to
 > re-use *Help* buffer instead of creating new ones.

Did you mean to re-use the *Help* buffer _window_ instead of creating a
new one?  I think that should be the rule since the *Help* buffer is
more or less unique but I nowhere see it enforced.

martin

bug#9054: 24.0.50; show source in other window

[Arthur Miller]

martin rudalics <rudalics@gmx.at> writes:

>> Ah, I didn't meant regexes; I meant using display-buffer-alist to tell Emacs to
>> re-use *Help* buffer instead of creating new ones.
>
> Did you mean to re-use the *Help* buffer _window_ instead of creating a
> new one?

Yes, exactly; I meant the window, sorry the wording, I guess my thoughts were elsewhere.

>           I think that should be the rule since the *Help* buffer is
> more or less unique but I nowhere see it enforced.

Generally I agree, I personally prefer one buffer, but I am not sure if it is
*the* best chocice to limit users on only one help buffer at a time. I don't
think I personally have enough experience to actually decide anything on that matter.

For that reason, the way I coded patches I sent in lately regarding help buffer,
I work with it as if there was only one *Help* buffer, and relying on Emacs to
return last one in case there are *Help<1>*, *Help<2>* etc.

bug#9054: 24.0.50; show source in other window

[Lars Ingebrigtsen]

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

> 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've now introduced a `help-window-keep-selected' user option in Emacs
29.  When enabled, these commands will reuse the *Help* window.

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

bug#9054: 24.0.50; show source in other window

[Juri Linkov]

>> 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've now introduced a `help-window-keep-selected' user option in Emacs
> 29.  When enabled, these commands will reuse the *Help* window.

I see help-function-def--button-function now uses pop-to-buffer-same-window.
Should other button types do the same?  Such as help-function-cmacro,
help-variable-def, help-face-def.

BTW, I can't find a discussion about scratch-buffer, so I'll ask here:
when I accidentally delete the *scratch* buffer, the first thing I do is
'C-x b *scratch* RET' and discover an empty buffer.  I wonder would it help
to add a '("\*scratch\*\\'" . scratch-buffer) to 'auto-mode-alist'
that will recreate it after switching to a new buffer with this name?

bug#9054: 24.0.50; show source in other window

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> I see help-function-def--button-function now uses pop-to-buffer-same-window.
> Should other button types do the same?  Such as help-function-cmacro,
> help-variable-def, help-face-def.

Yes, indeed; now fixed.

I didn't notice because I have

(setq help-window-select t)

and that makes these commands also work the same, but it should be
possible to have that nil and help-window-keep-selected t.  I think I've
now got all the various button types, but it's possible more of them
lurk somewhere.

> BTW, I can't find a discussion about scratch-buffer, so I'll ask here:
> when I accidentally delete the *scratch* buffer, the first thing I do is
> 'C-x b *scratch* RET' and discover an empty buffer.  I wonder would it help
> to add a '("\*scratch\*\\'" . scratch-buffer) to 'auto-mode-alist'
> that will recreate it after switching to a new buffer with this name?

Hm...  that seems quite attractive, but also somewhat surprising.  I
mean, `C-x b foo.c RET' doesn't put the resulting buffer in C mode.

On the other hand, the *scratch* buffer is slightly special, so perhaps
this would be helpful for users.  The reason I added the
`scratch-buffer' command is that I remember a number of users saying
that they'd accidentally killed the buffer, and couldn't find a way to
get it back to how it was working (because typing `M-x
lisp-interaction-mode' is a pretty obscure thing to say).

So perhaps it would be helpful to do what you say.

Does anybody have an opinion here?

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

bug#9054: 24.0.50; show source in other window

[Juri Linkov]

>> BTW, I can't find a discussion about scratch-buffer, so I'll ask here:
>> when I accidentally delete the *scratch* buffer, the first thing I do is
>> 'C-x b *scratch* RET' and discover an empty buffer.  I wonder would it help
>> to add a '("\*scratch\*\\'" . scratch-buffer) to 'auto-mode-alist'
>> that will recreate it after switching to a new buffer with this name?
>
> Hm...  that seems quite attractive, but also somewhat surprising.  I
> mean, `C-x b foo.c RET' doesn't put the resulting buffer in C mode.

I get C mode after `C-x b foo.c RET' due to such customization:

```
(setq-default major-mode (lambda ()
                           (if buffer-file-name
                               (fundamental-mode)
                             (let ((buffer-file-name (buffer-name)))
                               (set-auto-mode)))))
```

> On the other hand, the *scratch* buffer is slightly special, so perhaps
> this would be helpful for users.  The reason I added the
> `scratch-buffer' command is that I remember a number of users saying
> that they'd accidentally killed the buffer, and couldn't find a way to
> get it back to how it was working (because typing `M-x
> lisp-interaction-mode' is a pretty obscure thing to say).
>
> So perhaps it would be helpful to do what you say.

Now I tried again to switch to the deleted *scratch* buffer to recreate it,
and it activated the correct mode.  This is because switch-to-buffer
uses set-buffer-major-mode that has special handling for *scratch*:

  if (strcmp (SSDATA (BVAR (XBUFFER (buffer), name)), "*scratch*") == 0)
    function = find_symbol_value (intern ("initial-major-mode"));

bug#9054: 24.0.50; show source in other window

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> Now I tried again to switch to the deleted *scratch* buffer to recreate it,
> and it activated the correct mode.  This is because switch-to-buffer
> uses set-buffer-major-mode that has special handling for *scratch*:
>
>   if (strcmp (SSDATA (BVAR (XBUFFER (buffer), name)), "*scratch*") == 0)
>     function = find_symbol_value (intern ("initial-major-mode"));

Oh, wow.  I thought I had tested that, but apparently not.  And it looks
like it's been this way for decades, at least.

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