bug#42484: 26.1: org-mode should display value of links in mini-buffer
by activate i mean display, in echo area, whatever it is i want to display. i think help-echo is a text property, and i might or might not want to display it, depending. and i might want to display the other stuff even if there is no help-echo. i use [and adore] org-link-minor mode in elisp mode. it highlights links and timestamps and makes links followable. i even use [[target]] <> within elisp buffers, and org id links that go from elisp to org and vice-versa. if org-link-minor-mode is active in an elisp buffer, i can run the following to detect whether cursor is over an org ts. (defun hoka-eldoc-at-point () (when (eq 'org-date (get-text-property (point) 'face)) (format "%s" (when (fboundp 'alpha-org-time-span) (with-no-warnings (alpha-org-time-span)) then i get the time span in the echo area. a time span is e.g. -1 for yesterday. it could just as well be a timestamp in a different format or lang. so that's great. but i want mouse hover to do the same thing, and to do so with a delay. and i want links of course. more generally, i might occasionally want /some/ eldoc type stuff and /some/ help-echo stuff. so org-link-minor-mode was useful in my case because it [i think it is it] adds face property which can be used. and i thought that might be useful to you. idk though. in my case i find it a bit overwhelming to get whatever solution i use for cursor to also work for mouse [with appropriate delays]. and get whatever else to work and to not have anything annoyingly display. On 1/14/21, Juri Linkov wrote: >> this is an interesting discussion. is there any side discussion that >> takes into account both mouse and cursor? > > Indeed, you can see a side discussion at > https://lists.gnu.org/archive/html/emacs-devel/2020-11/msg00885.html > where we discussed highlighting the completion candidate > the same way whether the mouse pointer hovered over it, > or the cursor moved to its buffer position. > > That discussion also mentions another way to display > help-text using cursor-sensor-mode, i.e. after enabling it, > cursor-sensor-functions can detect when the cursor enters > the help-text property, then display it in the echo area. > >> 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. > > This looks like the 5th possible way to implement this using eldoc, > in addition to tooltips, post-command-hook, help-at-pt, cursor-sensor-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 > > help-at-pt has an option to ignore verbose help-echo in dired. > post-command-hook can be enabled locally only in org-mode buffers. > I don't know how to do the same in eldoc. > >> 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. > > You mean to activate is to display their help-echo? > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
bug#42484: 26.1: org-mode should display value of links in mini-buffer
> this is an interesting discussion. is there any side discussion that > takes into account both mouse and cursor? Indeed, you can see a side discussion at https://lists.gnu.org/archive/html/emacs-devel/2020-11/msg00885.html where we discussed highlighting the completion candidate the same way whether the mouse pointer hovered over it, or the cursor moved to its buffer position. That discussion also mentions another way to display help-text using cursor-sensor-mode, i.e. after enabling it, cursor-sensor-functions can detect when the cursor enters the help-text property, then display it in the echo area. > 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. This looks like the 5th possible way to implement this using eldoc, in addition to tooltips, post-command-hook, help-at-pt, cursor-sensor-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 help-at-pt has an option to ignore verbose help-echo in dired. post-command-hook can be enabled locally only in org-mode buffers. I don't know how to do the same in eldoc. > 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. You mean to activate is to display their help-echo?
bug#42484: 26.1: org-mode should display value of links in mini-buffer
[and whether it is upon typing vs. movement.] On 1/13/21, Samuel Wales wrote: > [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 > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
bug#42484: 26.1: org-mode should display value of links in mini-buffer
[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
bug#42484: 26.1: org-mode should display value of links in mini-buffer
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
bug#42484: 26.1: org-mode should display value of links in mini-buffer
> 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"))
bug#42484: 26.1: org-mode should display value of links in mini-buffer
On 2021-01-12 20:40, Juri Linkov wrote: > >> So customizing 'help-at-pt-display-when-idle' to the value > >> '(htmlize-link) completely solves this problem. > > > > Is that true for non-gui emacs or just for gui emacs? I'm using > > emacs-nox (no GUI) and your solution doesn't seem to work for me. > > I tried with emacs-nox, and it works fine. This feature is activated > only when customized, not just set by setq. Also by default it has > a quite long delay that requires waiting too long to see the link. > Generally it should work quite reasonably by using such customization: > > (customize-set-variable 'help-at-pt-display-when-idle '(htmlize-link)) > (customize-set-variable 'help-at-pt-timer-delay 0.1) I verify that you are correct. Thank you for the explanation of the steps to get it working and noticed. 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. 1 word/minute = 5 char/min = 0.0833 char/sec = 12.0 sec/char 403. 0.3 120 10 0.1 -- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
bug#42484: 26.1: org-mode should display value of links in mini-buffer
>> So customizing 'help-at-pt-display-when-idle' to the value >> '(htmlize-link) completely solves this problem. > > Is that true for non-gui emacs or just for gui emacs? I'm using > emacs-nox (no GUI) and your solution doesn't seem to work for me. I tried with emacs-nox, and it works fine. This feature is activated only when customized, not just set by setq. Also by default it has a quite long delay that requires waiting too long to see the link. Generally it should work quite reasonably by using such customization: (customize-set-variable 'help-at-pt-display-when-idle '(htmlize-link)) (customize-set-variable 'help-at-pt-timer-delay 0.1)
bug#42484: 26.1: org-mode should display value of links in mini-buffer
On 2021-01-11 20:54, Juri Linkov wrote: > So customizing 'help-at-pt-display-when-idle' to the value > '(htmlize-link) completely solves this problem. Is that true for non-gui emacs or just for gui emacs? I'm using emacs-nox (no GUI) and your solution doesn't seem to work for me. -- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
bug#42484: 26.1: org-mode should display value of links in mini-buffer
> In org-mode, when POINT is moved over an org-mode link, wouldn't it be > reasonable for the value of that link to appear in the mini-buffer? The > advantage of that is the user would know where the link points and what > would happen if the link is opened (eg. would an external program open, > would the network be queried). I need this feature too to display not only links, but also file names of generated images after executing SRC blocks. So I've customized the option 'help-at-pt-display-when-idle' to the value 't', and it displays the links and image file names in the echo area. Then later I noticed that it displays also useless help-echo properties in other modes, e.g. on file names in Dired. Fortunately, the same option allows to filter out such useless properties by defining the property whose presence activates displaying the help-echo property. I noticed that only org-mode puts the property 'htmlize-link' on links. So customizing 'help-at-pt-display-when-idle' to the value '(htmlize-link) completely solves this problem.
Re: [b...@gnu.org: Re: bug#42484: 26.1: org-mode should display value of links in mini-buffer]
> Boruch Baum writes: > >> In org-mode, when POINT is moved over an org-mode link, wouldn't it be >> reasonable for the value of that link to appear in the mini-buffer? The >> advantage of that is the user would know where the link points and what >> would happen if the link is opened (eg. would an external program open, >> would the network be queried). That would be very welcome, IMO. FWIW, markdown-mode does that (when markup is hidden) using ElDoc; cf. markdown-eldoc-function.
[b...@gnu.org: Re: bug#42484: 26.1: org-mode should display value of links in mini-buffer]
- Forwarded message from Bastien - Date: Sun, 06 Sep 2020 10:21:33 +0200 From: Bastien To: Boruch Baum Cc: 42484-d...@debbugs.gnu.org Subject: Re: bug#42484: 26.1: org-mode should display value of links in mini-buffer User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Hi Boruch, Boruch Baum writes: > In org-mode, when POINT is moved over an org-mode link, wouldn't it be > reasonable for the value of that link to appear in the mini-buffer? The > advantage of that is the user would know where the link points and what > would happen if the link is opened (eg. would an external program open, > would the network be queried). Can you suggest this feature to the Org list at emacs-orgmode@gnu.org? Such "electric" display could sure be useful, but I would like to get feedback from other Org contributors and users before accepting a patch. I'm closing this as this is not an Emacs bug. Thanks, -- Bastien - End forwarded message - -- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0