emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed

From: Timothy <orgmode@tec.tecosaur.net>
To: emacs-orgmode@gnu.org
Cc: Timothy <orgmode@tec.tecosaur.net>, emacs-orgmode@gnu.org
Subject: Re: [PATCH] Babel evaluation: location and timing information
Date: Thu, 22 Sep 2022 15:05:01 +0800	[thread overview]
Message-ID: <87o7v7998j.fsf@tec.tecosaur.net> (raw)
In-Reply-To: <87r106qwhv.fsf@localhost>

[-- Attachment #1: Type: text/plain, Size: 1661 bytes --]

Hi Ihor,

>> -	    (message “executing %s code block%s…”
>> +	    (message “executing %s %s %s…”
>>  		     (capitalize lang)
>> +                     (pcase (org-element-type (org-element-at-point))
>> +                       (’src-block “code block”)
>> +                       (’babel-call “call”)
>> +                       (’paragraph “inline code block”))
>
> This will not work, for example, when inline src block is located inside
> a headline. One can think of various other non-paragraph scenarios as well.

Good point. Does assuming anything other than a src block or babel call is an
inline src block sound reasonable?

> Also, even though org-element-at-point should be caching recent calls,
> I’d try to test the performance before/after the patch on large number
> of src blocks (like in your config). org-element-at-point can add a fair
> bit of CPU load in some scenarios where we have fallback to the full
> O(Log N) AVL-tree lookup.

I’ll see about giving this a shot at some point. Since parsing would be required
before this point I assumed the document structure would be cached and this
should be fairly cheap. Would `org-element-at-point-no-context' be better
potentially?

>> +                (let ((time-info
>> +                       (if (and exec-time (> (float-time exec-time) 0.05))
>> +                           (format “ (took %.1fs)” (float-time exec-time))
>
> Why 0.05??

Because that’s half the resolution at which the time is displayed at. The idea
is to only show the time when it will show something greater than zero.

All the best,
Timothy

next prev parent reply	other threads:[~2022-09-22  7:22 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-18  3:09 [PATCH] Babel evaluation: location and timing information Timothy
2022-09-19 12:28 ` Fraga, Eric
2022-09-19 14:52 ` Max Nikulin
2022-09-22  7:03   ` Timothy
2022-09-22 12:15     ` Max Nikulin
2022-09-23  2:22       ` Ihor Radchenko
2022-09-23 16:21         ` line-number-at-pos performance and cache-long-scans Max Nikulin
2022-09-20  8:29 ` [PATCH] Babel evaluation: location and timing information Ihor Radchenko
2022-09-22  7:05   ` Timothy [this message]
2022-09-23  2:27     ` Ihor Radchenko
2022-09-23 16:46 ` [PATCH] Babel evaluation: location and timing information (v2) Timothy
2022-09-24  3:11   ` Ihor Radchenko
2022-09-24  9:12     ` Timothy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87o7v7998j.fsf@tec.tecosaur.net \
    --to=orgmode@tec.tecosaur.net \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).