How to improve my extension source code don't generate so many timers?
I write an extension org-link-beautify (
https://github.com/stardiviner/org-link-beautify). It use text-property to
display all-the-icons icon for links.
When I use `list-timers`, I found many timers like this:
#+begin_example
1179.80 -#f(compiled-function () # [#
("-1003358868.jpg" :v-adjust 0.01) remhash])
1179.80 -#f(compiled-function () # [#
("1004068059.jpg" :v-adjust 0.01) remhash])
1179.80 -#f(compiled-function () # [#
("-1004540555.jpg" :v-adjust 0.01) remhash])
1179.80 -#f(compiled-function () # [#
("-1010525956.jpg" :v-adjust 0.01) remhash])
1179.80 -#f(compiled-function () # [#
("-1011541969.jpg" :v-adjust 0.01) remhash])
1179.80 -#f(compiled-function () # [#
("1011587546.jpg" :v-adjust 0.01) remhash])
1179.80 -#f(compiled-function () # [#
("1012116218.jpg" :v-adjust 0.01) remhash])
1179.80 -#f(compiled-function () # [#
("1013965598.jpg" :v-adjust 0.01) remhash])
1179.81 -#f(compiled-function () # [#
("-1014809589.jpg" :v-adjust 0.01) remhash])
1179.81 -#f(compiled-function () # [#
("-1017207950.jpg" :v-adjust 0.01) remhash])
1179.81 -#f(compiled-function () # [#
("1018964381.jpg" :v-adjust 0.01) remhash])
1179.81 -#f(compiled-function () # [#
("1019711419.jpg" :v-adjust 0.01) remhash])
1179.81 -#f(compiled-function () # [#
("-1019920854.jpg" :v-adjust 0.01) remhash])
1179.91 -#f(compiled-function () # [#
("-1162442495.jpg" :v-adjust 0.01) remhash])
#+end_example
I'm wandering is there someplace I write wrong in my source code:
https://github.com/stardiviner/org-link-beautify/blob/master/org-link-beautify.el
Or maybe this is an mechanism in Org Mode?
[stardiviner] GPG key ID: 47C32433
IRC(freeenode): stardiviner Twitter: @numbchild
Key fingerprint = 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433
Blog: http://stardiviner.github.io/
c-y inserts after entry
in recent maint in emacs 25. * x asd fnjkasn dkfjan ksdjfn kajsdfn ^ajsdf kasdn kfjasnd jkfan ksdfn * kill this whole header line and insert before caret what i expect is that it is inserted above caret what occurs is it gets inserted below * z this is surprising because i expected plain text behavior for yanking. note that i might or might not want plain text behavior for inserting a new header. i have a nagging feeling i am missing a NEWS item here. -- The Kafka Pandemic What is misopathy? https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: [PATCH] org-eldoc: Fix compatibility with Emacs 28
Basil L. Contovounesios writes: >> @@ -161,11 +161,17 @@ (defun org-eldoc-documentation-function () >> (defun org-eldoc-load () >>"Set up org-eldoc documentation function." >>(interactive) >> - (if (boundp 'eldoc-documentation-functions) >> - (add-hook 'eldoc-documentation-functions >> -#'org-eldoc-documentation-function nil t) >> -(setq-local eldoc-documentation-function >> -#'org-eldoc-documentation-function))) >> + ;; This approach is taken from python.el. >> + (with-no-warnings >> +(if (null eldoc-documentation-function) >> +;; Emacs<25 >> +(setq-local eldoc-documentation-function >> +#'org-eldoc-documentation-function) >> + (if (boundp 'eldoc-documentation-functions) >> + (add-hook 'eldoc-documentation-functions >> +#'org-eldoc-documentation-function nil t) >> +(add-function :before-until (local 'eldoc-documentation-function) >> + #'org-eldoc-documentation-function) > > LGTM. My only aesthetic nit would be to replace the nested if with a > flat cond, but that's entirely up to you. I agree with your preference, though it didn't cross my mind when I was lazily copying over from python.el. Will update. Thanks.
Re: Why is Babel-C trimming its output?
Thanks for the investigation Ian. So, since the tests run just fine
without it, and it offers an inconsistent and at times detrimental
feature, can we consider removing it, and/or adding some options for
that?
I'd be fine having to flag my src-block with a ":verbatim t" option to
make sure that the output is not mangled.
Thoughts?
On Fri, Jul 17, 2020 at 7:30 AM ian martins wrote:
>
> Fortunately the author wrote tests, so we can tie the behavior of the code to
> use cases. Unfortunately all the tests pass with the call to org-trim
> removed. Also the call is there from the first commit of the file in git, so
> there's no commit message to explain.
>
> My guess is that it was added to clean up cases that resulted in extra
> trailing whitespace, but I dunno.
>
>
> On Wed, Jul 15, 2020 at 7:12 PM Michaël Cadilhac
> wrote:
>>
>> Hello,
>>
>> Quick question here: in ob-C.el, before returning the output of a C
>> file, there's this line:
>>
>> (setq results (org-trim (org-remove-indentation results)))
>>
>> That seems quite arbitrary; is it on purpose? I have a C file that
>> outputs some sort of list of formatted numbers, e.g.:
>>
>> 0 -17.8
>> 404.4
>> 80 26.7
>> 120 48.9
>>
>> and only the first line gets trimmed, leading to a faulty output.
>>
>> This does not seem to be a universal thing in Babel; for instance:
>>
>> #+begin_src emacs-lisp :exports both :results value raw
>> " 0\n 1\n2\n"
>> #+end_src
>>
>> …results in:
>>
>> #+RESULTS:
>> 0
>> 1
>> 2
>>
>> But the same thing in C:
>>
>> #+begin_src C :exports both :results output raw
>> printf (" 0\n 1\n2\n");
>> #+end_src
>>
>> …results in:
>> #+RESULTS:
>> 0
>> 1
>> 2
>>
>> Cheers,
>> M.
>>
Re: [PATCH] org-eldoc: Fix compatibility with Emacs 28
"Basil L. Contovounesios" writes: > Kyle Meyer writes: > >> All right, thanks. Here's that in patch form. I briefly tested with >> Emacs 26, 27, and 28, and things seemed to work fine (though I'm not an >> org-eldoc user). > > I'm not either, but it seems to get pulled in automatically when > org-plus-contrib is installed - that's how I noticed the errors in Org > buffers. I was also trying to figure out how to shut it off, and there were no obvious knobs to do so. Given that this gets installed implicitly, I think maybe it shouldn't be turned on by default. Isn't this what `org-modules' is for?
Re: Why is Babel-C trimming its output?
Fortunately the author wrote tests, so we can tie the behavior of the code
to use cases. Unfortunately all the tests pass with the call to org-trim
removed. Also the call is there from the first commit of the file in git,
so there's no commit message to explain.
My guess is that it was added to clean up cases that resulted in extra
trailing whitespace, but I dunno.
On Wed, Jul 15, 2020 at 7:12 PM Michaël Cadilhac
wrote:
> Hello,
>
> Quick question here: in ob-C.el, before returning the output of a C
> file, there's this line:
>
> (setq results (org-trim (org-remove-indentation results)))
>
> That seems quite arbitrary; is it on purpose? I have a C file that
> outputs some sort of list of formatted numbers, e.g.:
>
> 0 -17.8
> 404.4
> 80 26.7
> 120 48.9
>
> and only the first line gets trimmed, leading to a faulty output.
>
> This does not seem to be a universal thing in Babel; for instance:
>
> #+begin_src emacs-lisp :exports both :results value raw
> " 0\n 1\n2\n"
> #+end_src
>
> …results in:
>
> #+RESULTS:
> 0
> 1
> 2
>
> But the same thing in C:
>
> #+begin_src C :exports both :results output raw
> printf (" 0\n 1\n2\n");
> #+end_src
>
> …results in:
> #+RESULTS:
> 0
> 1
> 2
>
> Cheers,
> M.
>
>
Re: [PATCH] org-eldoc: Fix compatibility with Emacs 28
On Fri, 2020-07-17 at 01:41, Kyle Meyer wrote: > All right, thanks. Here's that in patch form. I briefly tested with > Emacs 26, 27, and 28, and things seemed to work fine (though I'm not an > org-eldoc user). > I'll plan to apply it in a day or two unless there are objections. So far so good here. It fixes the errors running 28.0.50 (85eaa83 from 2020-07-16) and the latest org-mode-contrib. Thank you, Joe
Re: [PATCH] org-eldoc: Fix compatibility with Emacs 28
Kyle Meyer writes: > All right, thanks. Here's that in patch form. I briefly tested with > Emacs 26, 27, and 28, and things seemed to work fine (though I'm not an > org-eldoc user). I'm not either, but it seems to get pulled in automatically when org-plus-contrib is installed - that's how I noticed the errors in Org buffers. [...] > @@ -161,11 +161,17 @@ (defun org-eldoc-documentation-function () > (defun org-eldoc-load () >"Set up org-eldoc documentation function." >(interactive) > - (if (boundp 'eldoc-documentation-functions) > - (add-hook 'eldoc-documentation-functions > - #'org-eldoc-documentation-function nil t) > -(setq-local eldoc-documentation-function > - #'org-eldoc-documentation-function))) > + ;; This approach is taken from python.el. > + (with-no-warnings > +(if (null eldoc-documentation-function) > + ;; Emacs<25 > + (setq-local eldoc-documentation-function > + #'org-eldoc-documentation-function) > + (if (boundp 'eldoc-documentation-functions) > + (add-hook 'eldoc-documentation-functions > + #'org-eldoc-documentation-function nil t) > + (add-function :before-until (local 'eldoc-documentation-function) > + #'org-eldoc-documentation-function) LGTM. My only aesthetic nit would be to replace the nested if with a flat cond, but that's entirely up to you. Thanks, -- Basil
