Le 01/05/2020 à 12:15, Nicolas Goaziou a écrit : > Hello, > > tbanelwebmin <tbanelweb...@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