From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#42484: 26.1: org-mode should display value of links in mini-buffer Date: Wed, 13 Jan 2021 20:03:54 +0200 Organization: LINKOV.NET Message-ID: <87lfcxkpk5.fsf@mail.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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36053"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) Cc: 42484@debbugs.gnu.org To: Boruch Baum Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jan 13 19:12:44 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kzkdP-0009IA-D1 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 13 Jan 2021 19:12:43 +0100 Original-Received: from localhost ([::1]:45398 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kzkdO-0005ut-D6 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 13 Jan 2021 13:12:42 -0500 Original-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 ) id 1kzkZq-0003kL-EH; Wed, 13 Jan 2021 13:09:02 -0500 Original-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 ) id 1kzkZq-0004ns-6d; Wed, 13 Jan 2021 13:09:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kzkZq-0000YI-1E; Wed, 13 Jan 2021 13:09:02 -0500 X-Loop: help-debbugs@gnu.org In-Reply-To: <20200723035629.7jg2pd2mhqjowvh4@E15-2016.optimum.net> Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, emacs-orgmode@gnu.org Resent-Date: Wed, 13 Jan 2021 18:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 42484 X-GNU-PR-Package: emacs,org-mode Original-Received: via spool by 42484-submit@debbugs.gnu.org id=B42484.16105613042047 (code B ref 42484); Wed, 13 Jan 2021 18:09:01 +0000 Original-Received: (at 42484) by debbugs.gnu.org; 13 Jan 2021 18:08:24 +0000 Original-Received: from localhost ([127.0.0.1]:36546 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kzkZD-0000Wx-LZ for submit@debbugs.gnu.org; Wed, 13 Jan 2021 13:08:23 -0500 Original-Received: from relay5-d.mail.gandi.net ([217.70.183.197]:60855) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kzkZA-0000Wh-MM for 42484@debbugs.gnu.org; Wed, 13 Jan 2021 13:08:21 -0500 X-Originating-IP: 91.129.98.64 Original-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) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:197909 Archived-At: > 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"))