From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>
Received: from mp1 ([2001:41d0:2:4a6f::])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	by ms11 with LMTPS
	id EE0VM4M5/19iagAA0tVLHw
	(envelope-from <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>)
	for <larch@yhetil.org>; Wed, 13 Jan 2021 18:18:43 +0000
Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	by mp1 with LMTPS
	id +HjTLoM5/1+gIQAAbx9fmQ
	(envelope-from <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>)
	for <larch@yhetil.org>; Wed, 13 Jan 2021 18:18:43 +0000
Received: from lists.gnu.org (lists.gnu.org [209.51.188.17])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by aspmx1.migadu.com (Postfix) with ESMTPS id 73425940341
	for <larch@yhetil.org>; Wed, 13 Jan 2021 18:18:43 +0000 (UTC)
Received: from localhost ([::1]:56614 helo=lists1p.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.90_1)
	(envelope-from <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>)
	id 1kzkjC-0002PC-3f
	for larch@yhetil.org; Wed, 13 Jan 2021 13:18:42 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:53106)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <Debian-debbugs@debbugs.gnu.org>)
 id 1kzkZq-0003kL-EH; Wed, 13 Jan 2021 13:09:02 -0500
Received: from debbugs.gnu.org ([209.51.188.43]:53240)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <Debian-debbugs@debbugs.gnu.org>)
 id 1kzkZq-0004ns-6d; Wed, 13 Jan 2021 13:09:02 -0500
Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2)
 (envelope-from <Debian-debbugs@debbugs.gnu.org>)
 id 1kzkZq-0000YI-1E; Wed, 13 Jan 2021 13:09:02 -0500
X-Loop: help-debbugs@gnu.org
Subject: bug#42484: 26.1: org-mode should display value of links in mini-buffer
In-Reply-To: <20200723035629.7jg2pd2mhqjowvh4@E15-2016.optimum.net>
Resent-From: Juri Linkov <juri@linkov.net>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@gnu.org, emacs-orgmode@gnu.org
Resent-Date: Wed, 13 Jan 2021 18:09:01 +0000
Resent-Message-ID: <handler.42484.B42484.16105613042047@debbugs.gnu.org>
Resent-Sender: help-debbugs@gnu.org
X-GNU-PR-Message: followup 42484
X-GNU-PR-Package: emacs,org-mode
X-GNU-PR-Keywords: 
To: Boruch Baum <boruch_baum@gmx.com>
Received: via spool by 42484-submit@debbugs.gnu.org id=B42484.16105613042047
 (code B ref 42484); Wed, 13 Jan 2021 18:09:01 +0000
Received: (at 42484) by debbugs.gnu.org; 13 Jan 2021 18:08:24 +0000
Received: from localhost ([127.0.0.1]:36546 helo=debbugs.gnu.org)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <debbugs-submit-bounces@debbugs.gnu.org>)
 id 1kzkZD-0000Wx-LZ
 for submit@debbugs.gnu.org; Wed, 13 Jan 2021 13:08:23 -0500
Received: from relay5-d.mail.gandi.net ([217.70.183.197]:60855)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@linkov.net>) id 1kzkZA-0000Wh-MM
 for 42484@debbugs.gnu.org; Wed, 13 Jan 2021 13:08:21 -0500
X-Originating-IP: 91.129.98.64
Received: from mail.gandi.net (m91-129-98-64.cust.tele2.ee [91.129.98.64])
 (Authenticated sender: juri@linkov.net)
 by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 42D531C0013;
 Wed, 13 Jan 2021 18:08:12 +0000 (UTC)
From: Juri Linkov <juri@linkov.net>
Organization: LINKOV.NET
References: <20200723035629.7jg2pd2mhqjowvh4@E15-2016.optimum.net>
 <87v9c35mny.fsf@mail.linkov.net>
 <20210112094550.lk2rmhohtpbglarw@E15-2016.optimum.net>
 <87r1mqv2a6.fsf@mail.linkov.net>
 <20210113054007.7pdl3ykvlku6namu@E15-2016.optimum.net>
Date: Wed, 13 Jan 2021 20:03:54 +0200
Message-ID: <87lfcxkpk5.fsf@mail.linkov.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-BeenThere: debbugs-submit@debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
X-BeenThere: emacs-orgmode@gnu.org
List-Id: "General discussions about Org-mode." <emacs-orgmode.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-orgmode>,
 <mailto:emacs-orgmode-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/emacs-orgmode>
List-Post: <mailto:emacs-orgmode@gnu.org>
List-Help: <mailto:emacs-orgmode-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
 <mailto:emacs-orgmode-request@gnu.org?subject=subscribe>
Cc: 42484@debbugs.gnu.org
Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org
Sender: "Emacs-orgmode" <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>
X-Migadu-Flow: FLOW_IN
X-Migadu-Spam-Score: -2.36
Authentication-Results: aspmx1.migadu.com;
	dkim=none;
	dmarc=none;
	spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org
X-Migadu-Queue-Id: 73425940341
X-Spam-Score: -2.36
X-Migadu-Scanner: scn0.migadu.com
X-TUID: 8HSTQhlgTROn

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