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

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

bug#9054: 24.0.50; show source in other window


From: martin rudalics
Subject: bug#9054: 24.0.50; show source in other window
Date: Tue, 21 Sep 2021 10:34:04 +0200

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





reply via email to

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