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