bug#42484: 26.1: org-mode should display value of links in mini-buffer

bug#42484: 26.1: org-mode should display value of links in mini-buffer

[Boruch Baum]

In org-mode, when POINT is moved over an org-mode link, wouldn't it be
reasonable for the value of that link to appear in the mini-buffer? The
advantage of that is the user would know where the link points and what
would happen if the link is opened (eg. would an external program open,
would the network be queried).


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

bug#42484: 26.1: org-mode should display value of links in mini-buffer

[Bastien]

Hi Boruch,

Boruch Baum <boruch_baum@gmx.com> writes:

> In org-mode, when POINT is moved over an org-mode link, wouldn't it be
> reasonable for the value of that link to appear in the mini-buffer? The
> advantage of that is the user would know where the link points and what
> would happen if the link is opened (eg. would an external program open,
> would the network be queried).

Can you suggest this feature to the Org list at emacs-orgmode@gnu.org?

Such "electric" display could sure be useful, but I would like to get
feedback from other Org contributors and users before accepting a patch.

I'm closing this as this is not an Emacs bug.

Thanks,

-- 
 Bastien

bug#42484: 26.1: org-mode should display value of links in mini-buffer

[Boruch Baum]

Per your request, I did submit a post to the org list, which received
only a single response (which was supportive and informative) in three
days, and seems to have been lost in the greater conversations there.
What next?

On 2020-09-06 10:21, Bastien wrote:
> Hi Boruch,
>
> Boruch Baum <boruch_baum@gmx.com> writes:
>
> > In org-mode, when POINT is moved over an org-mode link, wouldn't it be
> > reasonable for the value of that link to appear in the mini-buffer? The
> > advantage of that is the user would know where the link points and what
> > would happen if the link is opened (eg. would an external program open,
> > would the network be queried).
>
> Can you suggest this feature to the Org list at emacs-orgmode@gnu.org?

Done.

> Such "electric" display could sure be useful, but I would like to get
> feedback from other Org contributors and users before accepting a patch.

I'm not sure I'm the one to best offer the patch, but Kevin's mentioned
an idea on the list.

> I'm closing this as this is not an Emacs bug.

Where would I post future org-mode issues?

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

bug#42484: 26.1: org-mode should display value of links in mini-buffer

[Bastien]

Hi Boruch,

Boruch Baum <boruch_baum@gmx.com> writes:

> Per your request, I did submit a post to the org list, which received
> only a single response (which was supportive and informative) in three
> days, and seems to have been lost in the greater conversations there.
> What next?

Someone will have to take the time to implement the feature.

Are you volunteering?  If not, are you willing to find someone that
can implement the feature?  If you cannot find someone yourself, what
can you do to make other volunteers *want* to implement this for you?

> On 2020-09-06 10:21, Bastien wrote:
>> Hi Boruch,
>>
>> Boruch Baum <boruch_baum@gmx.com> writes:
>>
>> > In org-mode, when POINT is moved over an org-mode link, wouldn't it be
>> > reasonable for the value of that link to appear in the mini-buffer? The
>> > advantage of that is the user would know where the link points and what
>> > would happen if the link is opened (eg. would an external program open,
>> > would the network be queried).
>>
>> Can you suggest this feature to the Org list at emacs-orgmode@gnu.org?
>
> Done.

Thanks for this.

>> Such "electric" display could sure be useful, but I would like to get
>> feedback from other Org contributors and users before accepting a patch.
>
> I'm not sure I'm the one to best offer the patch, but Kevin's mentioned
> an idea on the list.

A patch is always useful, even a bad one.

>> I'm closing this as this is not an Emacs bug.
>
> Where would I post future org-mode issues?

The Org mailing list is the right place for posting issues.

Thanks,

-- 
 Bastien

bug#42484: 26.1: org-mode should display value of links in mini-buffer

[Boruch Baum]

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.

Here's an example implementation of the fix:

#+BEGIN_SRC emacs-lisp
(defun my-org-mode-post-command-hook ()
  "Show POINT's \"help-echo\" information in the echo area.
This could be information about an org-link at POINT, or some other data."
  (let ((message-log-max)) ; suppress output to *Messages* buffer
    (message(get-text-property (point) 'help-echo))))

(add-hook 'post-command-hook 'my-org-mode-post-command-hook t t)
#+END_SRC

If you want me to re-submit this as a formal patch with a NEWS entry,
let me know. The org developers may also have some other implementation
they prefer, or some other buffer-local hook they would prefer to use.

On 2020-09-06 10:21, Bastien wrote:
> Hi Boruch,
>
> Boruch Baum <boruch_baum@gmx.com> writes:
> Can you suggest this feature to the Org list at emacs-orgmode@gnu.org?
> Such "electric" display could sure be useful, but I would like to get
> feedback from other Org contributors and users before accepting a
> patch.
Done, with only one response evincing any interest (see below).

> I'm closing this as this is not an Emacs bug.
See paragraph #1, above

From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
To: Boruch Baum <boruch_baum@gmx.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: [bzg@gnu.org: Re: bug#42484: 26.1: org-mode should
display value
of links in mini-buffer]

That would be very welcome, IMO.  FWIW, markdown-mode does that (when
markup is hidden) using ElDoc; cf. markdown-eldoc-function.

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

bug#42484: Please re-open this issue

[Boruch Baum]

Please re-open this issue

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

bug#42484: Please re-open this issue

[Bastien]

Hi Boruch,

Boruch Baum <boruch_baum@gmx.com> writes:

> Please re-open this issue

I will review your proposal this week, so no real need to reopen this
issue.

-- 
 Bastien

bug#42484: Updated patch

[Boruch Baum]

I've been using my solution over the last month+, but with a
modification for cases of links with embedded percent signs. That
happens when for instance a URL wasnt to have an embedded space or other
character. The result is that the elisp function 'message' misinterprets
that as a format field.

(defun my-org-mode-post-command-hook ()
  "Show POINT's \"help-echo\" information in the echo area.
This could be information about an org-link at POINT, or some other
data."
  (let ((message-log-max)) ; suppress output to *Messages* buffer
    (ignore-errors
      (message "%s" (url-unhex-string (get-text-property (point) 'help-echo)) nil t))))

(add-hook 'org-mode-hook 'my-org-mode-hook)

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

bug#42484: Updated patch

[Boruch Baum]

I've been using my solution over the last month+, but with a
modification for cases of links with embedded percent signs. That
happens when for instance a URL wasnt to have an embedded space or other
character. The result is that the elisp function 'message' misinterprets
that as a format field.

(defun my-org-mode-post-command-hook ()
  "Show POINT's \"help-echo\" information in the echo area.
This could be information about an org-link at POINT, or some other
data."
  (let ((message-log-max)) ; suppress output to *Messages* buffer
    (ignore-errors
      (message "%s" (url-unhex-string (get-text-property (point) 'help-echo)) nil t))))

(add-hook 'org-mode-hook 'my-org-mode-hook)

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

bug#42484: 26.1: org-mode should display value of links in minibuffer

[Boruch Baum]

This update improves the solution so that it doesn't step on other
minibuffer echo-area messages when it has nothing to report

(defun my-org-mode-post-command-hook ()
  "Show POINT's \"help-echo\" information in the echo area.
This could be information about an org-link at POINT, or some other data."
  (let ((message-log-max) ; suppress output to *Messages* buffer
        (msg (get-text-property (point) 'help-echo)))
    (when msg
      (ignore-errors
        (message "%s" (url-unhex-string msg) nil t)))))

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

bug#42484: 26.1: org-mode should display value of links in mini-buffer

[Juri Linkov]

> In org-mode, when POINT is moved over an org-mode link, wouldn't it be
> reasonable for the value of that link to appear in the mini-buffer? The
> advantage of that is the user would know where the link points and what
> would happen if the link is opened (eg. would an external program open,
> would the network be queried).

I need this feature too to display not only links, but also
file names of generated images after executing SRC blocks.

So I've customized the option 'help-at-pt-display-when-idle'
to the value 't', and it displays the links and image file names
in the echo area.

Then later I noticed that it displays also useless help-echo
properties in other modes, e.g. on file names in Dired.
Fortunately, the same option allows to filter out such useless
properties by defining the property whose presence activates
displaying the help-echo property.  I noticed that only
org-mode puts the property 'htmlize-link' on links.

So customizing 'help-at-pt-display-when-idle' to the value
'(htmlize-link) completely solves this problem.

bug#42484: 26.1: org-mode should display value of links in mini-buffer

[Boruch Baum]

On 2021-01-11 20:54, Juri Linkov wrote:
> So customizing 'help-at-pt-display-when-idle' to the value
> '(htmlize-link) completely solves this problem.

Is that true for non-gui emacs or just for gui emacs? I'm using
emacs-nox (no GUI) and your solution doesn't seem to work for me.

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

bug#42484: 26.1: org-mode should display value of links in mini-buffer

[Juri Linkov]

>> So customizing 'help-at-pt-display-when-idle' to the value
>> '(htmlize-link) completely solves this problem.
>
> Is that true for non-gui emacs or just for gui emacs? I'm using
> emacs-nox (no GUI) and your solution doesn't seem to work for me.

I tried with emacs-nox, and it works fine.  This feature is activated
only when customized, not just set by setq.  Also by default it has
a quite long delay that requires waiting too long to see the link.
Generally it should work quite reasonably by using such customization:

(customize-set-variable 'help-at-pt-display-when-idle '(htmlize-link))
(customize-set-variable 'help-at-pt-timer-delay 0.1)

bug#42484: 26.1: org-mode should display value of links in mini-buffer

[Boruch Baum]

On 2021-01-12 20:40, Juri Linkov wrote:
> >> So customizing 'help-at-pt-display-when-idle' to the value
> >> '(htmlize-link) completely solves this problem.
> >
> > Is that true for non-gui emacs or just for gui emacs? I'm using
> > emacs-nox (no GUI) and your solution doesn't seem to work for me.
>
> I tried with emacs-nox, and it works fine.  This feature is activated
> only when customized, not just set by setq.  Also by default it has
> a quite long delay that requires waiting too long to see the link.
> Generally it should work quite reasonably by using such customization:
>
> (customize-set-variable 'help-at-pt-display-when-idle '(htmlize-link))
> (customize-set-variable 'help-at-pt-timer-delay 0.1)

I verify that you are correct. Thank you for the explanation of the steps to
get it working and noticed.

Still, I would like to continue to promote my solution, because it's
much simpler and is instantaneous upon key-press. It might also be more
efficient: The help-at-pt solution runs code in all buffers, let's say
every 0.1 seconds, all the time; my solution only runs in the selected
mode(s) buffers but after every key-press, which for an 'average'
touch-typist taking a speed test would be 0.3 seconds.

  1 word/minute = 5 char/min = 0.0833 char/sec = 12.0 sec/char
 40                            3.3333             0.3
120                           10                  0.1


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

bug#42484: 26.1: org-mode should display value of links in mini-buffer

[Juri Linkov]

> Still, I would like to continue to promote my solution, because it's
> much simpler and is instantaneous upon key-press. It might also be more
> efficient: The help-at-pt solution runs code in all buffers, let's say
> every 0.1 seconds, all the time; my solution only runs in the selected
> mode(s) buffers but after every key-press, which for an 'average'
> touch-typist taking a speed test would be 0.3 seconds.

I agree.  Overhead of needlessly running the global timer is what concerns
me too.  But using an idle timer by help-at-pt is not that bad either.
It runs code only after the last key-press in a sequence of many key-presses.
So with idle timer in help-at-pt and the default delay, code runs less often
than by using post-command-hook.  Here are a brief comparison of
advantages and disadvantages of these two approaches:

1. help-at-pt idle timer

Pros:
1.1. runs code once a sequence of key-presses is finished,
     and 1 second has passed after the last key-press,
     where 1 second is the default value of help-at-pt-timer-delay.
     Customizing it to 0.1 removes this advantage because on average
     there is more time between key-presses than 0.1 seconds.

Cons:
1.1. With a bigger value of help-at-pt-timer-delay (by default, 1 second)
     that helps code to run less often (not after every key-press),
     the effect of the primary goal of this feature to display
     the help-echo string is not instantaneous;
1.2. the timer runs globally in all modes (this could be mitigated
     by checking major mode in the timer function).

2. post-command-hook

Pros:
1.1. can be activated locally only in org-mode buffers;
1.2. display of the help-echo string is instantaneous.

Cons:
1.1. runs code after every key-press.

So your approach has more advantages.  The only problem with your code
is that it displays the garbled mojibake on URLs with Unicode symbols,
that need to be decoded to UTF-8 with:

  (message "%s" (decode-coding-string (url-unhex-string msg) 'utf-8))

Also not to step on other more important minibuffer echo-area messages,
help-at-pt-maybe-display has better handling with:

       (or (not (current-message))
	   (string= (current-message) "Quit"))

bug#42484: 26.1: org-mode should display value of links in mini-buffer

[Samuel Wales]

this is an interesting discussion.  is there any side discussion that
takes into account both mouse and cursor?  i have had a devil of a
time trying to get:

1] displaying value of link in echo area [the problem you are
discussing -- don't let me derail it] with a short nonzero delay
2] doing so *for both cursor and mouse* -- too much futzing here
3] also doing other stuff -- also futzing

other stuff includes maybe [or maybe not] showing function signature
or docstrings in elisp buffers [possibly with longer delay], and
showing the time span in number of days from now to the org timestamp
at point or under mouse in any mode.

i have code for the last thing.  the problem is figuring out making
tooltips, eldoc, help-at-pt, or post-command-hook work with mouse and
keyboard without verbose help-echo like in dired.  also the
major/minor modes and

i guess i am saying [back to topic] this is a bit complex and i wonder
if a more orthogonal solution is called for?  as some might want mouse
activation also, and eldoc already shows elisp stuff.

and another suggestion: org-link-minor-mode is what i might use to
identify when to activate org links and timestamps.


On 1/13/21, Juri Linkov <juri@linkov.net> wrote:
>> Still, I would like to continue to promote my solution, because it's
>> much simpler and is instantaneous upon key-press. It might also be more
>> efficient: The help-at-pt solution runs code in all buffers, let's say
>> every 0.1 seconds, all the time; my solution only runs in the selected
>> mode(s) buffers but after every key-press, which for an 'average'
>> touch-typist taking a speed test would be 0.3 seconds.
>
> I agree.  Overhead of needlessly running the global timer is what concerns
> me too.  But using an idle timer by help-at-pt is not that bad either.
> It runs code only after the last key-press in a sequence of many
> key-presses.
> So with idle timer in help-at-pt and the default delay, code runs less
> often
> than by using post-command-hook.  Here are a brief comparison of
> advantages and disadvantages of these two approaches:
>
> 1. help-at-pt idle timer
>
> Pros:
> 1.1. runs code once a sequence of key-presses is finished,
>      and 1 second has passed after the last key-press,
>      where 1 second is the default value of help-at-pt-timer-delay.
>      Customizing it to 0.1 removes this advantage because on average
>      there is more time between key-presses than 0.1 seconds.
>
> Cons:
> 1.1. With a bigger value of help-at-pt-timer-delay (by default, 1 second)
>      that helps code to run less often (not after every key-press),
>      the effect of the primary goal of this feature to display
>      the help-echo string is not instantaneous;
> 1.2. the timer runs globally in all modes (this could be mitigated
>      by checking major mode in the timer function).
>
> 2. post-command-hook
>
> Pros:
> 1.1. can be activated locally only in org-mode buffers;
> 1.2. display of the help-echo string is instantaneous.
>
> Cons:
> 1.1. runs code after every key-press.
>
> So your approach has more advantages.  The only problem with your code
> is that it displays the garbled mojibake on URLs with Unicode symbols,
> that need to be decoded to UTF-8 with:
>
>   (message "%s" (decode-coding-string (url-unhex-string msg) 'utf-8))
>
> Also not to step on other more important minibuffer echo-area messages,
> help-at-pt-maybe-display has better handling with:
>
>        (or (not (current-message))
> 	   (string= (current-message) "Quit"))
>
>
>
>


-- 
The Kafka Pandemic

Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

bug#42484: 26.1: org-mode should display value of links in mini-buffer

[Samuel Wales]

[my point aboutg orthogonal solution is that different mechanisms
would not be needed for mouse and cursor and different stuff to
display in the echo area.  to complete my incomplete sentence,
major/minor modes and potentially differing delays.]

On 1/13/21, Samuel Wales <samologist@gmail.com> wrote:
> this is an interesting discussion.  is there any side discussion that
> takes into account both mouse and cursor?  i have had a devil of a
> time trying to get:
>
> 1] displaying value of link in echo area [the problem you are
> discussing -- don't let me derail it] with a short nonzero delay
> 2] doing so *for both cursor and mouse* -- too much futzing here
> 3] also doing other stuff -- also futzing
>
> other stuff includes maybe [or maybe not] showing function signature
> or docstrings in elisp buffers [possibly with longer delay], and
> showing the time span in number of days from now to the org timestamp
> at point or under mouse in any mode.
>
> i have code for the last thing.  the problem is figuring out making
> tooltips, eldoc, help-at-pt, or post-command-hook work with mouse and
> keyboard without verbose help-echo like in dired.  also the
> major/minor modes and
>
> i guess i am saying [back to topic] this is a bit complex and i wonder
> if a more orthogonal solution is called for?  as some might want mouse
> activation also, and eldoc already shows elisp stuff.
>
> and another suggestion: org-link-minor-mode is what i might use to
> identify when to activate org links and timestamps.
>
>
> On 1/13/21, Juri Linkov <juri@linkov.net> wrote:
>>> Still, I would like to continue to promote my solution, because it's
>>> much simpler and is instantaneous upon key-press. It might also be more
>>> efficient: The help-at-pt solution runs code in all buffers, let's say
>>> every 0.1 seconds, all the time; my solution only runs in the selected
>>> mode(s) buffers but after every key-press, which for an 'average'
>>> touch-typist taking a speed test would be 0.3 seconds.
>>
>> I agree.  Overhead of needlessly running the global timer is what
>> concerns
>> me too.  But using an idle timer by help-at-pt is not that bad either.
>> It runs code only after the last key-press in a sequence of many
>> key-presses.
>> So with idle timer in help-at-pt and the default delay, code runs less
>> often
>> than by using post-command-hook.  Here are a brief comparison of
>> advantages and disadvantages of these two approaches:
>>
>> 1. help-at-pt idle timer
>>
>> Pros:
>> 1.1. runs code once a sequence of key-presses is finished,
>>      and 1 second has passed after the last key-press,
>>      where 1 second is the default value of help-at-pt-timer-delay.
>>      Customizing it to 0.1 removes this advantage because on average
>>      there is more time between key-presses than 0.1 seconds.
>>
>> Cons:
>> 1.1. With a bigger value of help-at-pt-timer-delay (by default, 1 second)
>>      that helps code to run less often (not after every key-press),
>>      the effect of the primary goal of this feature to display
>>      the help-echo string is not instantaneous;
>> 1.2. the timer runs globally in all modes (this could be mitigated
>>      by checking major mode in the timer function).
>>
>> 2. post-command-hook
>>
>> Pros:
>> 1.1. can be activated locally only in org-mode buffers;
>> 1.2. display of the help-echo string is instantaneous.
>>
>> Cons:
>> 1.1. runs code after every key-press.
>>
>> So your approach has more advantages.  The only problem with your code
>> is that it displays the garbled mojibake on URLs with Unicode symbols,
>> that need to be decoded to UTF-8 with:
>>
>>   (message "%s" (decode-coding-string (url-unhex-string msg) 'utf-8))
>>
>> Also not to step on other more important minibuffer echo-area messages,
>> help-at-pt-maybe-display has better handling with:
>>
>>        (or (not (current-message))
>> 	   (string= (current-message) "Quit"))
>>
>>
>>
>>
>
>
> --
> The Kafka Pandemic
>
> Please learn what misopathy is.
> https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
>


-- 
The Kafka Pandemic

Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

bug#42484: 26.1: org-mode should display value of links in mini-buffer

[Samuel Wales]

[my point aboutg orthogonal solution is that different mechanisms
would not be needed for mouse and cursor and different stuff to
display in the echo area.  to complete my incomplete sentence,
major/minor modes and potentially differing delays.]

On 1/13/21, Samuel Wales <samologist@gmail.com> wrote:
> this is an interesting discussion.  is there any side discussion that
> takes into account both mouse and cursor?  i have had a devil of a
> time trying to get:
>
> 1] displaying value of link in echo area [the problem you are
> discussing -- don't let me derail it] with a short nonzero delay
> 2] doing so *for both cursor and mouse* -- too much futzing here
> 3] also doing other stuff -- also futzing
>
> other stuff includes maybe [or maybe not] showing function signature
> or docstrings in elisp buffers [possibly with longer delay], and
> showing the time span in number of days from now to the org timestamp
> at point or under mouse in any mode.
>
> i have code for the last thing.  the problem is figuring out making
> tooltips, eldoc, help-at-pt, or post-command-hook work with mouse and
> keyboard without verbose help-echo like in dired.  also the
> major/minor modes and
>
> i guess i am saying [back to topic] this is a bit complex and i wonder
> if a more orthogonal solution is called for?  as some might want mouse
> activation also, and eldoc already shows elisp stuff.
>
> and another suggestion: org-link-minor-mode is what i might use to
> identify when to activate org links and timestamps.
>
>
> On 1/13/21, Juri Linkov <juri@linkov.net> wrote:
>>> Still, I would like to continue to promote my solution, because it's
>>> much simpler and is instantaneous upon key-press. It might also be more
>>> efficient: The help-at-pt solution runs code in all buffers, let's say
>>> every 0.1 seconds, all the time; my solution only runs in the selected
>>> mode(s) buffers but after every key-press, which for an 'average'
>>> touch-typist taking a speed test would be 0.3 seconds.
>>
>> I agree.  Overhead of needlessly running the global timer is what
>> concerns
>> me too.  But using an idle timer by help-at-pt is not that bad either.
>> It runs code only after the last key-press in a sequence of many
>> key-presses.
>> So with idle timer in help-at-pt and the default delay, code runs less
>> often
>> than by using post-command-hook.  Here are a brief comparison of
>> advantages and disadvantages of these two approaches:
>>
>> 1. help-at-pt idle timer
>>
>> Pros:
>> 1.1. runs code once a sequence of key-presses is finished,
>>      and 1 second has passed after the last key-press,
>>      where 1 second is the default value of help-at-pt-timer-delay.
>>      Customizing it to 0.1 removes this advantage because on average
>>      there is more time between key-presses than 0.1 seconds.
>>
>> Cons:
>> 1.1. With a bigger value of help-at-pt-timer-delay (by default, 1 second)
>>      that helps code to run less often (not after every key-press),
>>      the effect of the primary goal of this feature to display
>>      the help-echo string is not instantaneous;
>> 1.2. the timer runs globally in all modes (this could be mitigated
>>      by checking major mode in the timer function).
>>
>> 2. post-command-hook
>>
>> Pros:
>> 1.1. can be activated locally only in org-mode buffers;
>> 1.2. display of the help-echo string is instantaneous.
>>
>> Cons:
>> 1.1. runs code after every key-press.
>>
>> So your approach has more advantages.  The only problem with your code
>> is that it displays the garbled mojibake on URLs with Unicode symbols,
>> that need to be decoded to UTF-8 with:
>>
>>   (message "%s" (decode-coding-string (url-unhex-string msg) 'utf-8))
>>
>> Also not to step on other more important minibuffer echo-area messages,
>> help-at-pt-maybe-display has better handling with:
>>
>>        (or (not (current-message))
>> 	   (string= (current-message) "Quit"))
>>
>>
>>
>>
>
>
> --
> The Kafka Pandemic
>
> Please learn what misopathy is.
> https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
>


-- 
The Kafka Pandemic

Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

bug#42484: 26.1: org-mode should display value of links in mini-buffer

[Samuel Wales]

[and whether it is upon typing vs. movement.]

On 1/13/21, Samuel Wales <samologist@gmail.com> wrote:
> [my point aboutg orthogonal solution is that different mechanisms
> would not be needed for mouse and cursor and different stuff to
> display in the echo area.  to complete my incomplete sentence,
> major/minor modes and potentially differing delays.]
>
> On 1/13/21, Samuel Wales <samologist@gmail.com> wrote:
>> this is an interesting discussion.  is there any side discussion that
>> takes into account both mouse and cursor?  i have had a devil of a
>> time trying to get:
>>
>> 1] displaying value of link in echo area [the problem you are
>> discussing -- don't let me derail it] with a short nonzero delay
>> 2] doing so *for both cursor and mouse* -- too much futzing here
>> 3] also doing other stuff -- also futzing
>>
>> other stuff includes maybe [or maybe not] showing function signature
>> or docstrings in elisp buffers [possibly with longer delay], and
>> showing the time span in number of days from now to the org timestamp
>> at point or under mouse in any mode.
>>
>> i have code for the last thing.  the problem is figuring out making
>> tooltips, eldoc, help-at-pt, or post-command-hook work with mouse and
>> keyboard without verbose help-echo like in dired.  also the
>> major/minor modes and
>>
>> i guess i am saying [back to topic] this is a bit complex and i wonder
>> if a more orthogonal solution is called for?  as some might want mouse
>> activation also, and eldoc already shows elisp stuff.
>>
>> and another suggestion: org-link-minor-mode is what i might use to
>> identify when to activate org links and timestamps.
>>
>>
>> On 1/13/21, Juri Linkov <juri@linkov.net> wrote:
>>>> Still, I would like to continue to promote my solution, because it's
>>>> much simpler and is instantaneous upon key-press. It might also be more
>>>> efficient: The help-at-pt solution runs code in all buffers, let's say
>>>> every 0.1 seconds, all the time; my solution only runs in the selected
>>>> mode(s) buffers but after every key-press, which for an 'average'
>>>> touch-typist taking a speed test would be 0.3 seconds.
>>>
>>> I agree.  Overhead of needlessly running the global timer is what
>>> concerns
>>> me too.  But using an idle timer by help-at-pt is not that bad either.
>>> It runs code only after the last key-press in a sequence of many
>>> key-presses.
>>> So with idle timer in help-at-pt and the default delay, code runs less
>>> often
>>> than by using post-command-hook.  Here are a brief comparison of
>>> advantages and disadvantages of these two approaches:
>>>
>>> 1. help-at-pt idle timer
>>>
>>> Pros:
>>> 1.1. runs code once a sequence of key-presses is finished,
>>>      and 1 second has passed after the last key-press,
>>>      where 1 second is the default value of help-at-pt-timer-delay.
>>>      Customizing it to 0.1 removes this advantage because on average
>>>      there is more time between key-presses than 0.1 seconds.
>>>
>>> Cons:
>>> 1.1. With a bigger value of help-at-pt-timer-delay (by default, 1
>>> second)
>>>      that helps code to run less often (not after every key-press),
>>>      the effect of the primary goal of this feature to display
>>>      the help-echo string is not instantaneous;
>>> 1.2. the timer runs globally in all modes (this could be mitigated
>>>      by checking major mode in the timer function).
>>>
>>> 2. post-command-hook
>>>
>>> Pros:
>>> 1.1. can be activated locally only in org-mode buffers;
>>> 1.2. display of the help-echo string is instantaneous.
>>>
>>> Cons:
>>> 1.1. runs code after every key-press.
>>>
>>> So your approach has more advantages.  The only problem with your code
>>> is that it displays the garbled mojibake on URLs with Unicode symbols,
>>> that need to be decoded to UTF-8 with:
>>>
>>>   (message "%s" (decode-coding-string (url-unhex-string msg) 'utf-8))
>>>
>>> Also not to step on other more important minibuffer echo-area messages,
>>> help-at-pt-maybe-display has better handling with:
>>>
>>>        (or (not (current-message))
>>> 	   (string= (current-message) "Quit"))
>>>
>>>
>>>
>>>
>>
>>
>> --
>> The Kafka Pandemic
>>
>> Please learn what misopathy is.
>> https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
>>
>
>
> --
> The Kafka Pandemic
>
> Please learn what misopathy is.
> https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
>


-- 
The Kafka Pandemic

Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

bug#42484: 26.1: org-mode should display value of links in mini-buffer

[Juri Linkov]

> this is an interesting discussion.  is there any side discussion that
> takes into account both mouse and cursor?

Indeed, you can see a side discussion at
https://lists.gnu.org/archive/html/emacs-devel/2020-11/msg00885.html
where we discussed highlighting the completion candidate
the same way whether the mouse pointer hovered over it,
or the cursor moved to its buffer position.

That discussion also mentions another way to display
help-text using cursor-sensor-mode, i.e. after enabling it,
cursor-sensor-functions can detect when the cursor enters
the help-text property, then display it in the echo area.

> 1] displaying value of link in echo area [the problem you are
> discussing -- don't let me derail it] with a short nonzero delay
> 2] doing so *for both cursor and mouse* -- too much futzing here
> 3] also doing other stuff -- also futzing
>
> other stuff includes maybe [or maybe not] showing function signature
> or docstrings in elisp buffers [possibly with longer delay], and
> showing the time span in number of days from now to the org timestamp
> at point or under mouse in any mode.

This looks like the 5th possible way to implement this using eldoc,
in addition to tooltips, post-command-hook, help-at-pt, cursor-sensor-mode.

> i have code for the last thing.  the problem is figuring out making
> tooltips, eldoc, help-at-pt, or post-command-hook work with mouse
> and keyboard without verbose help-echo like in dired.  also the
> major/minor modes and

help-at-pt has an option to ignore verbose help-echo in dired.
post-command-hook can be enabled locally only in org-mode buffers.
I don't know how to do the same in eldoc.

> i guess i am saying [back to topic] this is a bit complex and i wonder
> if a more orthogonal solution is called for?  as some might want mouse
> activation also, and eldoc already shows elisp stuff.
>
> and another suggestion: org-link-minor-mode is what i might use to
> identify when to activate org links and timestamps.

You mean to activate is to display their help-echo?

bug#42484: 26.1: org-mode should display value of links in mini-buffer

[Samuel Wales]

by activate i mean display, in echo area, whatever it is i want to
display.  i think help-echo is a text property, and i might or might
not want to display it, depending.  and i might want to display the
other stuff even if there is no help-echo.

i use [and adore] org-link-minor mode in elisp mode.  it highlights
links and timestamps and makes links followable.  i even use
[[target]] <<target>> within elisp buffers, and org id links that go
from elisp to org and vice-versa.

if org-link-minor-mode is active in an elisp buffer, i can run the
following to detect whether cursor is over an org ts.

(defun hoka-eldoc-at-point ()
  (when (eq 'org-date (get-text-property (point) 'face))
    (format "%s"
            (when (fboundp 'alpha-org-time-span)
              (with-no-warnings
                (alpha-org-time-span))))))

then i get the time span in the echo area.  a time span is e.g. -1 for
yesterday.  it could just as well be a timestamp in a different format
or lang.  so that's great.  but i want mouse hover to do the same
thing, and to do so with a delay.  and i want links of course.

more generally, i might occasionally want /some/ eldoc type stuff and
/some/ help-echo stuff.

so org-link-minor-mode was useful in my case because it [i think it is
it] adds face property which can be used.  and i thought that might be
useful to you.  idk though.

in my case i find it a bit overwhelming to get whatever solution i use
for cursor to also work for mouse [with appropriate delays].  and get
whatever else to work and to not have anything annoyingly display.


On 1/14/21, Juri Linkov <juri@linkov.net> wrote:
>> this is an interesting discussion.  is there any side discussion that
>> takes into account both mouse and cursor?
>
> Indeed, you can see a side discussion at
> https://lists.gnu.org/archive/html/emacs-devel/2020-11/msg00885.html
> where we discussed highlighting the completion candidate
> the same way whether the mouse pointer hovered over it,
> or the cursor moved to its buffer position.
>
> That discussion also mentions another way to display
> help-text using cursor-sensor-mode, i.e. after enabling it,
> cursor-sensor-functions can detect when the cursor enters
> the help-text property, then display it in the echo area.
>
>> 1] displaying value of link in echo area [the problem you are
>> discussing -- don't let me derail it] with a short nonzero delay
>> 2] doing so *for both cursor and mouse* -- too much futzing here
>> 3] also doing other stuff -- also futzing
>>
>> other stuff includes maybe [or maybe not] showing function signature
>> or docstrings in elisp buffers [possibly with longer delay], and
>> showing the time span in number of days from now to the org timestamp
>> at point or under mouse in any mode.
>
> This looks like the 5th possible way to implement this using eldoc,
> in addition to tooltips, post-command-hook, help-at-pt, cursor-sensor-mode.
>
>> i have code for the last thing.  the problem is figuring out making
>> tooltips, eldoc, help-at-pt, or post-command-hook work with mouse
>> and keyboard without verbose help-echo like in dired.  also the
>> major/minor modes and
>
> help-at-pt has an option to ignore verbose help-echo in dired.
> post-command-hook can be enabled locally only in org-mode buffers.
> I don't know how to do the same in eldoc.
>
>> i guess i am saying [back to topic] this is a bit complex and i wonder
>> if a more orthogonal solution is called for?  as some might want mouse
>> activation also, and eldoc already shows elisp stuff.
>>
>> and another suggestion: org-link-minor-mode is what i might use to
>> identify when to activate org links and timestamps.
>
> You mean to activate is to display their help-echo?
>


-- 
The Kafka Pandemic

Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html