From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Samuel Wales Newsgroups: gmane.emacs.bugs Subject: bug#42484: 26.1: org-mode should display value of links in mini-buffer Date: Wed, 13 Jan 2021 14:21:34 -0700 Message-ID: References: <87v9c35mny.fsf@mail.linkov.net> <20210112094550.lk2rmhohtpbglarw@E15-2016.optimum.net> <87r1mqv2a6.fsf@mail.linkov.net> <20210113054007.7pdl3ykvlku6namu@E15-2016.optimum.net> <20200723035629.7jg2pd2mhqjowvh4@E15-2016.optimum.net> <87lfcxkpk5.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8252"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Boruch Baum , 42484@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jan 13 22:23:29 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 1kznc0-00021L-W6 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 13 Jan 2021 22:23:29 +0100 Original-Received: from localhost ([::1]:56534 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kznbz-0002Ei-V4 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 13 Jan 2021 16:23:28 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35544) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kznac-0000ep-P3; Wed, 13 Jan 2021 16:22:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:53371) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kznac-000223-Gd; Wed, 13 Jan 2021 16:22:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kznac-0005f2-DE; Wed, 13 Jan 2021 16:22:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Samuel Wales Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, emacs-orgmode@gnu.org Resent-Date: Wed, 13 Jan 2021 21:22:02 +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.161057290321725 (code B ref 42484); Wed, 13 Jan 2021 21:22:02 +0000 Original-Received: (at 42484) by debbugs.gnu.org; 13 Jan 2021 21:21:43 +0000 Original-Received: from localhost ([127.0.0.1]:36684 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kznaI-0005eL-W3 for submit@debbugs.gnu.org; Wed, 13 Jan 2021 16:21:43 -0500 Original-Received: from mail-lj1-f175.google.com ([209.85.208.175]:37783) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kznaH-0005e3-7X for 42484@debbugs.gnu.org; Wed, 13 Jan 2021 16:21:41 -0500 Original-Received: by mail-lj1-f175.google.com with SMTP id w26so4191918ljo.4 for <42484@debbugs.gnu.org>; Wed, 13 Jan 2021 13:21:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ivhW3MoU98fW4ColtRub879Bkl7Wz7cXmKDZHDifMpE=; b=Nyb7gVDPBl0ZzZ7PnFarTULUyhqUN3+5Jow/QgDftVOcJh/dZWCEgrTOfCRQR4ayWJ zI/Vu4iihN/5PxqCM53CDrJMZuQtswckYy8+Q44rZBuDvm6ux0o2h5MCCiFingIceUaB yaZIWqd6RM5VWONSVfUsTtXye/FDXfF31volVqhDoStKPckCOXP6dBacErfIdSvBZmv7 xq5I5MwGie/r4Afihk7N9BMERm8zxW3SXweGPY87H1sX+9ir3LJBzjTrja/ZSFLaEGTv PxhNuFZoipglsTIdest5HJ80dHN1X1kpKjC0H1eLliOqSBuz2CZLx5CbTSMH0gVmwpLi 9sJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ivhW3MoU98fW4ColtRub879Bkl7Wz7cXmKDZHDifMpE=; b=dSjUEq2gWix08+lXKAimuCR4An2NRfYXQv6QM3c8Z4Y3t26IST8tiZhYY1FbvwmtIo lUIzcITPc5WhjBDwNsyd8m0LiC9l2aCyzIFygTuGFVhNt4asj3kDUIBsBg5Iz1kajjX4 3YG1O9DHVwLTp5Cfur0aP/Dv1jWMDeK6Lz0QVRPXHWpyUZ3Fd5eLgvVs6vf/tW9fKeKz h2TR4x65wRwWPl2CFe6KQr1t2JFKgnXfy8sye06LmihT0E1A+irz5CGtP+spQ761ETl0 x6edkG3P+sTUbt2oVj6ZXZqIescxj2gLs20iF65YY9xaLCkC5FqOmpajoexUitRoVzsk q1iQ== X-Gm-Message-State: AOAM533mHbVHZbDxs6t33cXOZHeGNNNjlaSZv6xv3wwaj8vFDEqgVaPV 1hJJX7xUYK8BkdpPUpOLFRu6UGAyvJp+IZUFGQM= X-Google-Smtp-Source: ABdhPJxxxOFohbiJsBRgSWRVxY+iMCFJnyeE3rXeH8RsRiJJ0Dx1X3pGnfz+NaOxLUfMNdfttykVGDGiuerIS0mcxHM= X-Received: by 2002:a2e:99cc:: with SMTP id l12mr1791048ljj.448.1610572895412; Wed, 13 Jan 2021 13:21:35 -0800 (PST) Original-Received: by 2002:ab3:6450:0:0:0:0:0 with HTTP; Wed, 13 Jan 2021 13:21:34 -0800 (PST) In-Reply-To: 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:197921 Archived-At: [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 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 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