From: tbanelwebmin <tbanelwebmin@free.fr>
To: emacs-orgmode@gnu.org
Subject: Re: [ANN] faster org-table-to-lisp
Date: Fri, 1 May 2020 14:41:21 +0200 [thread overview]
Message-ID: <9f0bbf07-8057-b76d-0023-2124bdd58870@free.fr> (raw)
In-Reply-To: <87v9lg7yh1.fsf@nicolasgoaziou.fr>
Le 01/05/2020 à 12:15, Nicolas Goaziou a écrit :
> Hello,
>
> tbanelwebmin <tbanelwebmin@free.fr> writes:
>
>> Nicolas, how did you do that? Your version is 25% faster than mine,
>> and the code is 33% shorter! Very elegant.
> Thank you. There's nothing fancy, really.
>
> The main difference is that it does not call `org-table-end'. Minor
> tweaks are:
>
> - use simpler regexps,
> - call `skip-chars-forward' whenever possible.
I realized that not calling `org-table-end' may cause a corner case:
| 2 | b |
| c | d |
#+TBLFM: @1$1=2||3
is read as:
(("2" "b") ("c" "d") ("" "3"))
because of the "|" just below the table.
This can be fixed by changing the ending condition from
(while (search-forward "|" (line-end-position) t)
to
(while (re-search-forward "^[ \t]*|" (line-end-position) t)
Not a big deal.
>> Sorry, I may not understood what you said:
>> = Since you're changing the signature, I suggest to provide the table
>> = element instead of ORG-AT-TABLE-P. AFAICT, `org-babel-read-element',
>> = through `org-babel-read-table', would greatly benefit from this.
>>
>> Could you elaborate (if still relevant)?
> If you know the table ELEMENT, you don't need to check if you're at
> a table, nor do you need to compute table boundaries. We could have made
> use of this information to avoid a call to `org-at-table-p', much like
> your initial intent.
>
> Thinking about it, we don't even need to call `org-at-table-p' at all.
> Indeed, this is a low-level, non-interactive, function. We can
> reasonably expect the callers to check if they are really at a table in
> the first place.
>
> It would increase speed for this function noticeably, and the ELEMENT
> argument would not be relevant anymore.
>
> WDYT?
I do agree. We can expect callers to be on a table. If they are not,
they will get `nil', and instantly notice it.
>> The side effect of `re-search-forward' was to advance point, while
>> `looking-at' don't move.
> Ah true. I overlooked that.
>
> Regards,
> --
> Nicolas Goaziou
>
Have fun,
Thierry Banel
next prev parent reply other threads:[~2020-05-01 12:41 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-30 6:34 [ANN] faster org-table-to-lisp tbanelwebmin
2020-04-30 8:09 ` Nicolas Goaziou
2020-04-30 20:28 ` tbanelwebmin
2020-04-30 20:47 ` Daniele Nicolodi
2020-04-30 21:01 ` tbanelwebmin
2020-04-30 22:35 ` Nicolas Goaziou
2020-05-01 6:35 ` tbanelwebmin
2020-05-01 10:15 ` Nicolas Goaziou
2020-05-01 12:41 ` tbanelwebmin [this message]
2020-05-01 13:11 ` Nicolas Goaziou
2020-05-02 7:41 ` tbanelwebmin
2020-05-02 9:35 ` Nicolas Goaziou
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=9f0bbf07-8057-b76d-0023-2124bdd58870@free.fr \
--to=tbanelwebmin@free.fr \
--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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).