display value of links in mini-buffer (was: Re: bug archiving policy)

display value of links in mini-buffer (was: Re: bug archiving policy)

[Yuri Khan]

On Sun, 6 Dec 2020 at 16:29, Boruch Baum <boruch_baum@gmx.com> wrote:

> I've been having an awful time trying to update a simple bugfix patch to
> a recent bug report[1].

> [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42484

From a message in that bug report:

> This turned out to be so suspiciously trivial, it may well be a bug-fix
> rather than a feature request. The org-mode code-base had already been
> setting the 'help-echo property for links, etc. in over a dozen places
> across several files, so there was clearly at one point an intention to
> do something with the property, but I don't see it being used *anywhere*,
> just defined. My guess is that at some point, this feature existed and
> got removed, but I don't have the resources (full git and email
> histories) to do that research.

The 'help-echo property is displayed in a tooltip when you point with
the mouse at the text that has this property.

The primary client of this property is the modeline, window borders,
and other parts of the UI you’re expected to interact with using a
mouse (and where you can’t actually move the point).

However, some modes also put 'help-echo property over text in a
buffer: buttons and links in Customize, links in Info, links in Eww,
diagnostics in Flymake. All of them would benefit from the behavior
you’re asking of Org: display tooltip text in the echo area when point
enters text so propertized.

There is a command ‘display-local-help’, bound to ‘<f1> .’, that can
be called manually. It would be nice to have a minor mode that would
basically invoke that whenever the point moves.

Basically, instead of bickering about Org maintainers not wanting to
track Org feature requests in the Emacs bug tracker, I propose that we
extend the scope of the request so that it becomes a genuine Emacs
feature request.

Re: display value of links in mini-buffer (was: Re: bug archiving policy)

[Boruch Baum]

On 2020-12-06 17:54, Yuri Khan wrote:
> The 'help-echo property is displayed in a tooltip when you point with
> the mouse at the text that has this property.

Ah. I don't see that behavior as I use emacs-nox.

> I propose that we extend the scope of the request so that it becomes a
> genuine Emacs feature request.

Your explanation is great, and I'm fine with your proposal. Should this
post be copied or referenced to the re-opened bug thread? It may be that
the same trivial patch I suggested there for org-mode might suffice to
satisfy the proposal emacs-wide.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Re: display value of links in mini-buffer (was: Re: bug archiving policy)

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Sun, 6 Dec 2020 17:54:40 +0700
> Cc: Emacs-Devel List <emacs-devel@gnu.org>
> 
> However, some modes also put 'help-echo property over text in a
> buffer: buttons and links in Customize, links in Info, links in Eww,
> diagnostics in Flymake. All of them would benefit from the behavior
> you’re asking of Org: display tooltip text in the echo area when point
> enters text so propertized.
> 
> There is a command ‘display-local-help’, bound to ‘<f1> .’, that can
> be called manually. It would be nice to have a minor mode that would
> basically invoke that whenever the point moves.
> 
> Basically, instead of bickering about Org maintainers not wanting to
> track Org feature requests in the Emacs bug tracker, I propose that we
> extend the scope of the request so that it becomes a genuine Emacs
> feature request.

We already have the kbd-help property (display-local-help supports
it); would that fit the bill?

Re: display value of links in mini-buffer (was: Re: bug archiving policy)

[Boruch Baum]

On 2020-12-06 13:26, Eli Zaretskii wrote:
> > From: Yuri Khan <yuri.v.khan@gmail.com>
> > Date: Sun, 6 Dec 2020 17:54:40 +0700
> > Cc: Emacs-Devel List <emacs-devel@gnu.org>
> >
> > However, some modes also put 'help-echo property over text in a
> > ...
>
> We already have the kbd-help property (display-local-help supports
> it); would that fit the bill?

Why need for two separate properties? Should the two be combined if they
serve essentially the same purpose?

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Re: display value of links in mini-buffer (was: Re: bug archiving policy)

[Eli Zaretskii]

> Date: Sun, 6 Dec 2020 06:35:02 -0500
> From: Boruch Baum <boruch_baum@gmx.com>
> Cc: Yuri Khan <yuri.v.khan@gmail.com>, emacs-devel@gnu.org
> 
> > We already have the kbd-help property (display-local-help supports
> > it); would that fit the bill?
> 
> Why need for two separate properties?

Because they are supposed to produce different effects: kbd-help shows
the message in the echo area, even on GUI frames.  They never pop up
tooltips, AFAIK.

In any case, we already have these two, it isn't like we are
discussing whether to create a second property.

Re: display value of links in mini-buffer (was: Re: bug archiving policy)

[Yuri Khan]

On Sun, 6 Dec 2020 at 18:39, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Sun, 6 Dec 2020 06:35:02 -0500
> > From: Boruch Baum <boruch_baum@gmx.com>
> > Cc: Yuri Khan <yuri.v.khan@gmail.com>, emacs-devel@gnu.org
> >
> > > We already have the kbd-help property (display-local-help supports
> > > it); would that fit the bill?
> >
> > Why need for two separate properties?
>
> Because they are supposed to produce different effects: kbd-help shows
> the message in the echo area, even on GUI frames.  They never pop up
> tooltips, AFAIK.

$ emacs -Q
(insert (propertize "foo" 'kbd-help "bar")) C-x C-e

Observed behavior: the text ‘foo’ is inserted right after the closing
parentheses. No effect on the echo area. If I move the point around,
no effect on the echo area. If I press ‘<f1> .’, I get “bar”.

So, if we agree that kbd-help is the right property, the code to
display it when the point moves in still needs to be written.

Additionally, we’d need to either convince authors of modes that place
a 'help-echo property on buffer text that they should also place a
'kbd-help property; or have the proposed mode fall back to 'help-echo
if there is no 'kbd-help at point as ‘display-local-help’ does.

Re: display value of links in mini-buffer (was: Re: bug archiving policy)

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Sun, 6 Dec 2020 18:51:43 +0700
> Cc: Boruch Baum <boruch_baum@gmx.com>, Emacs developers <emacs-devel@gnu.org>
> 
> So, if we agree that kbd-help is the right property, the code to
> display it when the point moves in still needs to be written.

Yes, of course.  I didn't mean to say this is already implemented,
just that we have a beginning and some infrastructure.

Re: display value of links in mini-buffer (was: Re: bug archiving policy)

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Sun, 6 Dec 2020 17:54:40 +0700
> Cc: Emacs-Devel List <emacs-devel@gnu.org>
> 
> However, some modes also put 'help-echo property over text in a
> buffer: buttons and links in Customize, links in Info, links in Eww,
> diagnostics in Flymake. All of them would benefit from the behavior
> you’re asking of Org: display tooltip text in the echo area when point
> enters text so propertized.

That could be annoying in some modes that have a lot of these
help-echo properties.  For example, in Dired you will see a lot of
traffic in the echo-area if the help-echo text at point will be
displayed there, because point generally moves there between file
names, each of which has a help-echo on it.

So maybe "reusing" help-echo that way is not the best alternative.

Re: display value of links in mini-buffer (was: Re: bug archiving policy)

[Yuri Khan]

On Sun, 6 Dec 2020 at 18:44, Eli Zaretskii <eliz@gnu.org> wrote:

> > However, some modes also put 'help-echo property over text in a
> > buffer: buttons and links in Customize, links in Info, links in Eww,
> > diagnostics in Flymake. All of them would benefit from the behavior
> > you’re asking of Org: display tooltip text in the echo area when point
> > enters text so propertized.
>
> That could be annoying in some modes that have a lot of these
> help-echo properties.  For example, in Dired you will see a lot of
> traffic in the echo-area if the help-echo text at point will be
> displayed there, because point generally moves there between file
> names, each of which has a help-echo on it.

Yes, because the Dired 'help-echo text is pretty useless:

    mouse-1: visit this file in other window

I pretty much live in Dired with ‘dired-hide-details’ turned on most
of the time; it would be great to have the details (size and mode or
symlink target) in the echo area.

Re: display value of links in mini-buffer (was: Re: bug archiving policy)

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Sun, 6 Dec 2020 19:04:22 +0700
> Cc: Boruch Baum <boruch_baum@gmx.com>, Emacs developers <emacs-devel@gnu.org>
> 
> > That could be annoying in some modes that have a lot of these
> > help-echo properties.  For example, in Dired you will see a lot of
> > traffic in the echo-area if the help-echo text at point will be
> > displayed there, because point generally moves there between file
> > names, each of which has a help-echo on it.
> 
> Yes, because the Dired 'help-echo text is pretty useless:
> 
>     mouse-1: visit this file in other window

You are entitled to your opinion, but others might disagree.  And
there are other similar modes that provide the same "useless"
help-echo, for example many modes that list buffers in a table.

RE: display value of links in mini-buffer (was: Re: bug archiving policy)

[Drew Adams]

> > Yes, because the Dired 'help-echo text is pretty useless:
> >   mouse-1: visit this file in other window
> 
> You are entitled to your opinion, but others might disagree.  

For one thing, it would be debatable just what file or dir
info to show in the echo area.

However, this is what Dired+ uses, in place of that echo text,
if `describe-file' is also available (library `help-fns+.el'):

  mouse-1: visit in another window, C-h RET: describe

`C-h RET' then gives you info about the file/dir in *Help*:

 z:/dir/for/foobar/stuff/
 ------------------------

 File Type:                  Normal file
 Permissions:                -rw-rw-rw-
 Size in bytes:              809215
 Time of last access:        Sat Dec  5 10:02:55 2020 (Pacific Standard Time)
 Time of last modification:  Sat Dec  5 10:02:55 2020 (Pacific Standard Time)
 Time of last status change: Sat Dec  5 09:27:17 2020 (Pacific Standard Time)
 Number of links:            1
 User ID (UID):              37786
 Group ID (GID):             513
 Inode:                      2814749767263948
 Device number:              315267003

And if the file is the name of an autofile bookmark (library
`Bookmark+'), then it also shows the bookmark information
(tags etc.):

 Bookmark `foobar.el'
 --------------------

 File:		foobar.el
 Directory:		z:/dir/for/foobar/stuff/
 Position:		0
 Tags:
  "blue"
  "white"

There's only so much info that can be usefully put in
a help echo.  Info about possible actions (keys, mouse
events) _is_ helpful, IMO, even if in some cases that
info might be standard/trivial.  If some of those keys
or mouse actions provide help, however, that's a good
to make help available, and it's not limited to the
echo-area space.

Re: display value of links in mini-buffer (was: Re: bug archiving policy)

[Boruch Baum]

On 2020-12-06 08:42, Drew Adams wrote:
> > > Yes, because the Dired 'help-echo text is pretty useless:
> > >   mouse-1: visit this file in other window
> >
> > You are entitled to your opinion, but others might disagree.
>
> For one thing, it would be debatable just what file or dir
> info to show in the echo area.
>
> However, this is what Dired+ uses, in place of that echo text,
> if `describe-file' is also available (library `help-fns+.el'):
>
>   mouse-1: visit in another window, C-h RET: describe
>
> `C-h RET' then gives you info about the file/dir in *Help*:

This speaks to a prior long thread about the user-friendliness of emacs
to new users, in that the keybinding hints are useful to new users and a
nice reminder to experienced users who have stepped away from use long
enough to forget, but once the keybindings are learned the keybinding
hints lose ALL value for that user and Yuri's type of suggestion for
supplemental information becomes more useful.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

RE: display value of links in mini-buffer (was: Re: bug archiving policy)

[Drew Adams]

> This speaks to a prior long thread about the user-friendliness of emacs
> to new users, in that the keybinding hints are useful to new users and
> a nice reminder to experienced users who have stepped away from use long
> enough to forget, but once the keybindings are learned the keybinding
> hints lose ALL value for that user and Yuri's type of suggestion for
> supplemental information becomes more useful.

Your general point may make some sense.  Certainly
repeated use of something makes reminders about it
less useful.

But it's true not only just case by case for a
given user, but case by case for specific contexts.
For example, a `mouse-1' action reminder in Dired
is different from the same elsewhere, whether or
not the action itself is similar.  And even for a
given user, things change over time, including use
patterns/habits and awareness.  They can change not
only in the direction of less need of a reminder.

The answer to this kind of thing at a general level
is to provide more user control.  There are various
ways of doing that, from providing feedback levels
(degrees) to providing customization of specific
kinds of feedback.

One size may not fit all, but for now we have one
size, and it should fit most, and in particular most
who are not too familiar with the given context.