From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 2PJsCatk/18CbAAA0tVLHw (envelope-from ) for ; Wed, 13 Jan 2021 21:22:51 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id gIc+Batk/18ZSgAAB5/wlQ (envelope-from ) for ; Wed, 13 Jan 2021 21:22:51 +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 AC1DB9403A9 for ; Wed, 13 Jan 2021 21:22:50 +0000 (UTC) Received: from localhost ([::1]:53004 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kznbN-0000j5-Ml for larch@yhetil.org; Wed, 13 Jan 2021 16:22:49 -0500 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 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 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 Subject: bug#42484: 26.1: org-mode should display value of links in mini-buffer 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 X-GNU-PR-Keywords: To: Juri Linkov Received: via spool by 42484-submit@debbugs.gnu.org id=B42484.161057290321725 (code B ref 42484); Wed, 13 Jan 2021 21:22:02 +0000 Received: (at 42484) by debbugs.gnu.org; 13 Jan 2021 21:21:43 +0000 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 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 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) MIME-Version: 1.0 Received: by 2002:ab3:6450:0:0:0:0:0 with HTTP; Wed, 13 Jan 2021 13:21:34 -0800 (PST) In-Reply-To: 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> From: Samuel Wales Date: Wed, 13 Jan 2021 14:21:34 -0700 Message-ID: Content-Type: text/plain; charset="UTF-8" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Boruch Baum , 42484@debbugs.gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -1.26 Authentication-Results: aspmx1.migadu.com; dkim=fail (headers rsa verify failed) header.d=gmail.com header.s=20161025 header.b=Nyb7gVDP; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=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: AC1DB9403A9 X-Spam-Score: -1.26 X-Migadu-Scanner: scn0.migadu.com X-TUID: PVjLKJbM6/+1 [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