emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Samuel Wales <samologist@gmail.com>
To: Juri Linkov <juri@linkov.net>
Cc: Boruch Baum <boruch_baum@gmx.com>, 42484@debbugs.gnu.org
Subject: bug#42484: 26.1: org-mode should display value of links in mini-buffer
Date: Wed, 13 Jan 2021 14:21:34 -0700	[thread overview]
Message-ID: <CAJcAo8sLb5ug=6X4uK5fbqyUr+i4wOmNmWuzo7X9t4DN=3EN_Q@mail.gmail.com> (raw)
In-Reply-To: <CAJcAo8tpOP6hEv87vreoDdWMLR5EmMN5M-cPdg_nTQtHwkmY7w@mail.gmail.com>

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

  reply	other threads:[~2021-01-13 21:22 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200723035629.7jg2pd2mhqjowvh4@E15-2016.optimum.net>
2020-12-06 10:46 ` bug#42484: Updated patch Boruch Baum
2020-12-09 14:17 ` bug#42484: 26.1: org-mode should display value of links in minibuffer Boruch Baum
2021-01-11 18:54 ` bug#42484: 26.1: org-mode should display value of links in mini-buffer Juri Linkov
2021-01-12  9:45   ` Boruch Baum
2021-01-12 18:40     ` Juri Linkov
2021-01-13  5:40       ` Boruch Baum
2021-01-13 18:03         ` Juri Linkov
2021-01-13 21:18           ` Samuel Wales
2021-01-13 21:21             ` Samuel Wales [this message]
2021-01-13 21:22               ` Samuel Wales
2021-01-14  9:10             ` Juri Linkov
2021-01-14 21:02               ` Samuel Wales

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJcAo8sLb5ug=6X4uK5fbqyUr+i4wOmNmWuzo7X9t4DN=3EN_Q@mail.gmail.com' \
    --to=samologist@gmail.com \
    --cc=42484@debbugs.gnu.org \
    --cc=boruch_baum@gmx.com \
    --cc=juri@linkov.net \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).