Re: [ANN] faster org-table-to-lisp

[tbanelwebmin]

Nicolas, how did you do that? Your version is 25% faster than mine,
and the code is 33% shorter! Very elegant.

Le 01/05/2020 à 00:35, Nicolas Goaziou a écrit :

> tbanelwebmin  writes:
>
>> I found a way to ensure full backward compatibility. I keep the same
>> signature. When a table is given as a string parameter, it is inserted
>> into a temporary buffer, which is then parsed. Overall, the resulting
>> speed is quite satisfactory.
> A, you didn't like my ELEMENT suggestion.

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)?

>
>> I also made the function more tolerant to ill-formed tables: missing
>> "|" or excess of spaces at the end of a row are now gracefully
>> accepted.
> Great!
>
>> (while (not (re-search-forward "\\=\\s-*\n" end t))
> (re-search-forward "\\=..." ...) -> (looking-at "..." ...)

The side effect of `re-search-forward' was to advance point, while
`looking-at' don't move. This does not matter anymore.

>
> Note that Org does not use \\s- but the simpler [ \t].
>
> Also, the regexp assumes the table end with a newline character, which
> may not be the case.
>
>>   (unless (re-search-forward "\\=\\s-*\\([^|\n]*\\)\\(|?\\)" end 
>> t)
>> (user-error "Malformed table at char %s" (point)))
> This cannot happen. The regexp above matches anything, i.e., the empty
> string.

Right! I didn't noticed...

>
>>   (goto-char (match-end 1))
>>   (skip-chars-backward " \t" (match-beginning 1))
>>   (push
>>(buffer-substring-no-properties (match-beginning 1) (point))
>>row)
>>   (goto-char (match-end 2)))
>> (push (nreverse row) table)))
>> (nreverse table)
> I applied your suggestion, with a few simplifications. Hopefully, it
> squeezed a bit more the execution time. Let me know!

Yes! 25%
My two unit tests give correct results.

>
>> The new implementation can be more than 100 times faster. This enhances
>> responsiveness of Babel or Gnuplot blocks handling thousands long
>> tables.
> Looks good. However, we didn't change the signature, so I didn't add
> this to ORG-NEWS. It is in the commit message, tho.
>
> Thank you!
>
Nice team work, thank you too!
Thierry Banel

Re: org-plot - changing colors

[Kyle Meyer]

Stephan Fabel  writes:

> I'm trying to plot a table which looks like this:
>
> | Team  | Bu | R | Bk |  G |  T | % Bu |  % R | % Bk |   %G |
> |---++---++++--+--+--+--|
> | Team 1|  4 | 5 |  2 | 24 | 35 | 11.4 | 14.3 |  5.7 | 68.6 |
> | Team 2|  3 | 2 |  1 | 35 | 41 |  7.3 |  4.9 |  2.4 | 85.4 |
[...]
> Plotting this with
>
> #+PLOT: ind:1 deps:(7 8 9 10) type:2d with:histogram   \
> set:"ylabel '%'" set:"style fill solid 0.5"
>
> works like a charm, except I'd like to change the colors of the
> histogram bars (as it turns out Bu=Blue, R=Red, Bk=Black and G=Green as
> per the title row in the table).
>
> What's the recommended way to go about this? I'm not super familiar with
> gnuplot, but before I go deep there, I figured I'd ask if there's a
> simple 'org-plot'-way of doing this?

I had luck changing the colors with a header like this, where the last
two lines are the additional bits:

   #+PLOT: ind:1 deps:(7 8 9 10) type:2d with:histogram
   #+PLOT: set:"ylabel '%'" set:"style fill solid 0.5" set:"style fill solid 
0.5"
   #+PLOT: set:"lt 1 lc rgb 'blue'" set:"lt 2 lc rgb 'red'"
   #+PLOT: set:"lt 3 lc rgb 'black'" set:"lt 4 lc rgb 'green'"

I know very little about gnuplot and even less about org-plot, though,
so there might be a better way to do this.

Re: [RFC] Change default value for `org-startup-folded'?

[Tim Cross]

Nicolas Goaziou  writes:

> Hello,
>
> Reading a recent message on Emacs devel list, I stumbled upon this:
>
> I needed to go and look up to figure out how to read the org file
> that came with pdf-tools. It isn't that much text, and the annoying
> folding that org does for what amounts to a simple README file is
> gratuitous at best.
>
> it struck me that our default value for `org-startup-folded', which
> t (or `overview') may not be nice for people not used to Org.
>
> It would make sense to make it easier for non-Org users who have to deal
> with Org files to set this variable to `showeverything'. This would also
> be on par with Outline mode, the major mode used to handle, e.g., NEWS
> file.
>
> Even though I think `overview' is a nice value, the logic behind my
> suggestion is that it is easier for an Org user to set
> `org-startup-folded' once and for all than for a non-Org user to
> discover Org folding the hard way.
>
> WDYT?
>
> Regards,

+1 from me. 

-- 
Tim Cross

Re: [ANN] faster org-table-to-lisp

[Nicolas Goaziou]

tbanelwebmin  writes:

> I found a way to ensure full backward compatibility. I keep the same
> signature. When a table is given as a string parameter, it is inserted
> into a temporary buffer, which is then parsed. Overall, the resulting
> speed is quite satisfactory.

A, you didn't like my ELEMENT suggestion.

> I also made the function more tolerant to ill-formed tables: missing
> "|" or excess of spaces at the end of a row are now gracefully
> accepted.

Great!

> (while (not (re-search-forward "\\=\\s-*\n" end t))

(re-search-forward "\\=..." ...) -> (looking-at "..." ...)

Note that Org does not use \\s- but the simpler [ \t].

Also, the regexp assumes the table end with a newline character, which
may not be the case.

>   (unless (re-search-forward "\\=\\s-*\\([^|\n]*\\)\\(|?\\)" end 
> t)
> (user-error "Malformed table at char %s" (point)))

This cannot happen. The regexp above matches anything, i.e., the empty
string.

>   (goto-char (match-end 1))
>   (skip-chars-backward " \t" (match-beginning 1))
>   (push
>(buffer-substring-no-properties (match-beginning 1) (point))
>row)
>   (goto-char (match-end 2)))
> (push (nreverse row) table)))
> (nreverse table)

I applied your suggestion, with a few simplifications. Hopefully, it
squeezed a bit more the execution time. Let me know!

> The new implementation can be more than 100 times faster. This enhances
> responsiveness of Babel or Gnuplot blocks handling thousands long
> tables.

Looks good. However, we didn't change the signature, so I didn't add
this to ORG-NEWS. It is in the commit message, tho.

Thank you!

Re: [PATCH] org-agenda.el: Complete multiple todo keywords

[Kyle Meyer]

akater  writes:

> Done. New patch is attached.

Thanks for the update and the expanded explanations.

The patch looks good to me.  As a minor note for future patches, it's
easier on the receiver if you include the non-patch commentary in one of
the ways that git-am can automatically detect and trim out (see the
discussion section in git-format-patch).  This list is also okay with
just attaching the output of git-format-patch directly.

Assuming you haven't completed copy assignment paperwork with the FSF
(see ), I'll add a
TINYCHANGE cookie to the commit on apply.  Is akater the name you prefer
listed on that site and in the commit message?

Re: How to properly set up reminders for paying cellphone fees in org?

[Kyle Meyer]

Vladimir Nikishkin  writes:

> However, the manual node you're pointing to disagrees with the claim that
> those are equivalent:
>
>>If you need both a repeater and a special warning period in a deadline
>>entry, the repeater should come first and the warning period last
>> DEADLINE: <2005-10-01 Sat +1m -3d>

Thanks for pointing that out.  AFAICT things work fine if you swap them,
but it's best to follow the manual's recommendation here.

Re: [ANN] faster org-table-to-lisp

[tbanelwebmin]

Better, thanks Daniele
Let's go for "handling very large tables"
Regards
Thierry

Le 30/04/2020 à 22:47, Daniele Nicolodi a écrit :

> Hello,
>
> On 30-04-2020 14:28, tbanelwebmin wrote:
>> * Version 9.4 (not yet released)
>> ** Miscellaneous
>> *** Faster org-table-to-lisp
>>
>> The new implementation can be more than 100 times faster. This enhances
>> responsiveness of Babel or Gnuplot blocks handling thousands long tables.
> Nitpicking: I think "handling thousands long tables" should be "handling
> tables with thousands of (rows|columns|cells)" (pick the appropriate
> one), but probably "handling very large tables" is just good enough.
>
> Cheers,
> Dan
>
>
>

Re: [ANN] faster org-table-to-lisp

[Daniele Nicolodi]

Hello,

On 30-04-2020 14:28, tbanelwebmin wrote:
> * Version 9.4 (not yet released)
> ** Miscellaneous
> *** Faster org-table-to-lisp
> 
> The new implementation can be more than 100 times faster. This enhances
> responsiveness of Babel or Gnuplot blocks handling thousands long tables.

Nitpicking: I think "handling thousands long tables" should be "handling
tables with thousands of (rows|columns|cells)" (pick the appropriate
one), but probably "handling very large tables" is just good enough.

Cheers,
Dan

Re: [ANN] faster org-table-to-lisp

[tbanelwebmin]

Le 30/04/2020 à 10:09, Nicolas Goaziou a écrit :

> Hello,
>
> tbanelwebmin  writes:
>
>> Here is an alternative, faster version of org-table-to-lisp. It can be
>> more than 100 times faster.
> Great! Thank you!
>
>> #+BEGIN_SRC elisp
>> (defun org-table-to-lisp-faster (&optional org-table-at-p-done)
>>   "Convert the table at point to a Lisp structure.
>> The structure will be a list.  Each item is either the symbol `hline'
>> for a horizontal separator line, or a list of field values as strings.
>> The table is taken from the buffer at point.
>> When the optional ORG-TABLE-AT-P-DONE parameter is not nil, it is
>> assumed that (org-at-table-p) was already called."
> 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.
>
> Or, to be backward compatible, I suggest
>
>   &optional TEXT TABLE
>
>>   (or org-table-at-p-done (org-at-table-p) (user-error "No table at point"))
>>   (save-excursion
>>     (goto-char (org-table-begin))
>>     (let ((end (org-table-end))
>>   (row)
>>   (table))
> Nitpick:
>
> (row nil)
> (table nil)
>
>>   (while (< (point) end)
>>     (setq row nil)
>>     (search-forward "|" end)
>>     (if (looking-at "-")
>>     (progn
>>   (search-forward "\n" end)
> (forward-line)
>
>>   (push 'hline table))
>>   (while (not (search-forward-regexp "\\=\n" end t))
> (unless (eolp)
>   ...)
>
>>     (unless (search-forward-regexp "\\=\\s-*\\([^|]*\\)" end t)
>>   (user-error "Malformed table at char %s" (point)))
> A row may not be properly ended. It doesn't warrant an error. Could you
> make it more tolerant?
>
> Also `search-forward-regexp' -> `re-search-forward', i.e., use the
> original.
>
>>     (let ((b (match-beginning 1))
>>           (e (match-end   1)))
> Nitpick: spurious spaces.
>
>>   (and (search-backward-regexp "[^ \t]" b t)
>>        (forward-char 1))
>   (skip-chars-backward " \t")
>
>> It is faster because it operates directly on the buffer with
>> (search-forward-regexp). Whereas the standard function splits a string
>> extracted from the buffer.
> You are right. I guess the initial implementation didn't have these
> monster tables in mind.
>
>> This function is a drop-in replacement for the standard one. It can
>> benefit to Babel and Gnuplot.
>>
>> Would it make sense to upgrade Org Mode code base?
> Certainly. Could you add an entry in ORG-NEWS, in "Miscellaneous"?
>
> Regards,
>
Thanks Nicolas for your nice suggestions. I've taken them into
account. Particularly, the use of (skip-chars-backward " \t") gave a
small additional speedup, and simplified the code.

I found a way to ensure full backward compatibility. I keep the same
signature. When a table is given as a string parameter, it is inserted
into a temporary buffer, which is then parsed. Overall, the resulting
speed is quite satisfactory.

I also made the function more tolerant to ill-formed tables: missing
"|" or excess of spaces at the end of a row are now gracefully
accepted.

Regards
Thierry

#+BEGIN_SRC elisp
(defun org-table-to-lisp (&optional txt)
  "Convert the table at point to a Lisp structure.
The structure will be a list.  Each item is either the symbol `hline'
for a horizontal separator line, or a list of field values as strings.
The table is taken from the parameter TXT, or from the buffer at point."
  (if txt
  (with-temp-buffer
(insert txt)
(goto-char (point-min))
(org-table-to-lisp))
(unless (org-at-table-p) (user-error "No table at point"))
(save-excursion
  (goto-char (org-table-begin))
  (let ((end (org-table-end))
(row nil)
(table nil))
(while (< (point) end)
  (setq row nil)
  (search-forward "|" end)
  (if (looking-at "-")
  (progn
(forward-line)
(push 'hline table))
(while (not (re-search-forward "\\=\\s-*\n" end t))
  (unless (re-search-forward "\\=\\s-*\\([^|\n]*\\)\\(|?\\)" end t)
(user-error "Malformed table at char %s" (point)))
  (goto-char (match-end 1))
  (skip-chars-backward " \t" (match-beginning 1))
  (push
   (buffer-substring-no-properties (match-beginning 1) (point))
   row)
  (goto-char (match-end 2)))
(push (nreverse row) table)))
(nreverse table)
#+END_SRC


* Version 9.4 (not yet released)
** Miscellaneous
*** Faster org-table-to-lisp

The new implementation can be more than 100 times faster. This enhances
responsiveness of Babel or Gnuplot blocks handling thousands long tables.

Self-sufficient Org file with customised export? :eval-when?

[akater]

I'd like to write an Org file that would export to a html with fairly
significant tweaks along the way.  The rough idea is, users should be
able to run reasonaly recent vanilla emacs, (require 'ox),
(org-html-export-to-html) and get a fine-tuned html.

I also would like to move relevant Elisp to the end of the Org file
because the text is going to be read by humans, and people with(out)
certain background apparently faint too often when they see Lisp on top
of a text written in markup.

I put an emacs-lisp src block under the last unexported section, with
header arguments :exports none :results none, but it does not seem to be
evaluated on export.  I couldn't find anything relevant in Info directory.

I know that with vanilla emacs one needs to explicitly allow evaluation
of blocks but that can be considred an acceptable preamble.

It would also be great if exporting such a file would not alter the
state of Emacs session too much (wouldn't pollute hooks or add advices,
for example) but that's low priority.  For now, I just want a
self-contained customisation with minimal hassle for users to get the
export result that was intended.  What are my options?


-


If I may prematurely offer my vision: Common Lisp has special operator
eval-when which specifies when the enclosed code is to be evaluated (or
compiled).  Example:

(eval-when (:compile-toplevel) (defun f () ..))

specifies that function f should be defined during compilation only.

I believe it would be neat if Org-mode widely supported :eval-when
header argument inspired by Common Lisp's eval-when.  Usage examples
would be:

#+begin_src emacs-lisp :eval-when compile load
..
#+end_src

#+begin_src emacs-lisp :eval-when tangle
..
#+end_src

#+begin_src emacs-lisp :eval-when export
..
#+end_src

#+begin_src emacs-lisp :eval-when ()
..
#+end_src

where the last setting would be equivalent to the (now-supported)
:eval never.

In my case, I'd write a block with header arguments

:eval-when export :results none

if this feature was supported.

I'm currently working on a Common Lisp-specific feature that will
introduce :eval-when (it will be offered to a Common Lisp library
literate-lisp) so I'm interested in opinions on this as well.

Re: [RFC] Change default value for `org-startup-folded'?

[Amin Bandali]

Hello,

Nicolas Goaziou  writes:

[...]
>
> It would make sense to make it easier for non-Org users who have to deal
> with Org files to set this variable to `showeverything'. This would also
> be on par with Outline mode, the major mode used to handle, e.g., NEWS
> file.
>
[...]

+1 from me as well.


signature.asc
Description: PGP signature

Re: [RFC] Change default value for `org-startup-folded'?

[Marco Wahl]

> Reading a recent message on Emacs devel list, I stumbled upon this:
>
> I needed to go and look up to figure out how to read the org file
> that came with pdf-tools. It isn't that much text, and the annoying
> folding that org does for what amounts to a simple README file is
> gratuitous at best.
>
> it struck me that our default value for `org-startup-folded', which
> t (or `overview') may not be nice for people not used to Org.
>
> It would make sense to make it easier for non-Org users who have to deal
> with Org files to set this variable to `showeverything'. This would also
> be on par with Outline mode, the major mode used to handle, e.g., NEWS
> file.
>
> Even though I think `overview' is a nice value, the logic behind my
> suggestion is that it is easier for an Org user to set
> `org-startup-folded' once and for all than for a non-Org user to
> discover Org folding the hard way.
>
> WDYT?

+1 for the change.

Re: [RFC] Change default value for `org-startup-folded'?

[Eric S Fraga]

On Thursday, 30 Apr 2020 at 17:11, Nicolas Goaziou wrote:
> It would make sense to make it easier for non-Org users who have to deal
> with Org files to set this variable to `showeverything'. This would also
> be on par with Outline mode, the major mode used to handle, e.g., NEWS
> file.

Yes, this is a good suggestion: anything that makes it easier for users
new to org is welcome and anybody else can easily change the default.
-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-555-ge68ae4

Re: Bug: org-preview-latex-process-alist's :latex-header should not fall back to org-format-latex-header [9.3.4 (9.3.4-5-ga0f3bb-elpaplus @ /home/lockywolf/.emacs.d/elpa/org-plus-contrib-20200210/)]

[Nicolas Goaziou]

Hello,

Vladimir Nikishkin  writes:

> There are two almost unrelated latex-using processes in org. One is
> export, the other one is generating previews.
>
> The latter one is far less demanding than the former. Previews only care
> about certain math, whereas exports may very well be super tricky.
>
> Therefore, preparing org documents for export often includes setting a
> separate latex compiler (in 99% of the cases lualatex or xelatex), and a
> custom #+LATEX_HEADER. the latex compiler controlled with
> (setq org-latex-compiler "lualatex")
> (setq org-latex-bib-compiler "biber")
> is completely ignored by the preview process. This is fine, since
> previews only care about small things. However, #+LATEX_HEADER is _not_
> ignored, which means that previews will fail to compile, since
> LATEX_HEADER is prepared for a different compiler.

IIRC, LATEX_HEADER_EXTRA is meant for non-preview compilation.
LATEX_HEADER is for both preview and export.

Regards,

-- 
Nicolas Goaziou

[RFC] Change default value for `org-startup-folded'?

[Nicolas Goaziou]

Hello,

Reading a recent message on Emacs devel list, I stumbled upon this:

I needed to go and look up to figure out how to read the org file
that came with pdf-tools. It isn't that much text, and the annoying
folding that org does for what amounts to a simple README file is
gratuitous at best.

it struck me that our default value for `org-startup-folded', which
t (or `overview') may not be nice for people not used to Org.

It would make sense to make it easier for non-Org users who have to deal
with Org files to set this variable to `showeverything'. This would also
be on par with Outline mode, the major mode used to handle, e.g., NEWS
file.

Even though I think `overview' is a nice value, the logic behind my
suggestion is that it is easier for an Org user to set
`org-startup-folded' once and for all than for a non-Org user to
discover Org folding the hard way.

WDYT?

Regards,

-- 
Nicolas Goaziou

Re: org-mode setting the browser with options

[Neil Cherry]

On 4/29/20 6:49 PM, Neil Cherry wrote:
> On 4/29/20 6:30 PM, Tim Cross wrote:
>>
>> Jude DaShiell  writes:
>>
>>> Two different scripts one yproxy and the other nproxy.
>>> Put the necessary running code in each.
>>>
>>> On Wed, 29 Apr 2020, Neil Cherry wrote:
>>>
 Date: Wed, 29 Apr 2020 13:36:50
 From: Neil Cherry 
 To: Org Mode 
 Subject: org-mode setting the browser with options

 I need to use 2 different Windows browser (proxy and no-proxy is the 
 reason).

 What I want to do is that if it's example.com use firefox (no options). If 
 it's
 example.org use chrome --no-proxy-server. I'm not exacly sure how to 
 approach this.

 Thanks


>>
>> I would look at browse-url built-in package. With browse-url you can set
>> a function that will determine which browser to use based on the url and
>> you can set the options for each supported browser. 
>>
> 
> Thanks, that got me thinking and search-fu found:
> 
> (setq
>  browse-url-browser-function
>  '(
>   ("example\\.com" . browse-url-chrome)
>   ("example\\.org" . browse-url-chrome)
>   ("." . browse-url-default-browser)
>   ))
> 
> Which works perfect!

Slight amendment, I think this code also helped:

(custom-set-variables
 ;; custom-set-variables was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.

 '(browse-url-browser-function (quote browse-url-default-browser))
 '(browse-url-chrome-arguments (quote ("--no-proxy-server")))
 '(browse-url-chrome-program "chrome")

)

Note that the extra lines I'm referring to are the 3 browse-url-... lines in the
custom-set-variables

Thanks
-- 
Linux Home Automation Neil Cherry   nche...@linuxha.com
http://www.linuxha.com/ Main site
http://linuxha.blogspot.com/My HA Blog
Author of:  Linux Smart Homes For Dummies

org-plot - changing colors

[Stephan Fabel]

Hello,

apologies if this is the wrong group.

I'm trying to plot a table which looks like this:

| Team  | Bu | R | Bk |  G |  T | % Bu |  % R | % Bk |   %G |
|---++---++++--+--+--+--|
| Team 1|  4 | 5 |  2 | 24 | 35 | 11.4 | 14.3 |  5.7 | 68.6 |
| Team 2|  3 | 2 |  1 | 35 | 41 |  7.3 |  4.9 |  2.4 | 85.4 |
| Team 3|  5 | 8 |  3 |  6 | 22 | 22.7 | 36.4 | 13.6 | 27.3 |
| Team 4|  6 | 4 |  5 | 15 | 30 | 20.0 | 13.3 | 16.7 | 50.0 |
| Team 5|  5 | 7 |  4 | 22 | 38 | 13.2 | 18.4 | 10.5 | 57.9 |
| Team 6|  8 | 9 |  6 | 27 | 50 | 16.0 | 18.0 | 12.0 | 54.0 |
| Team 7|  1 | 3 |  0 | 19 | 23 |  4.3 | 13.0 |  0.0 | 82.6 |
| Team 8| 10 | 7 |  1 |  4 | 22 | 45.5 | 31.8 |  4.5 | 18.2 |
| Team 9|  3 | 4 |  1 | 15 | 23 | 13.0 | 17.4 |  4.3 | 65.2 |
| Team 10   |  2 | 4 |  1 | 18 | 25 |  8.0 | 16.0 |  4.0 | 72.0 |
| Team 11   |  1 | 1 |  0 | 21 | 23 |  4.3 |  4.3 |  0.0 | 91.3 |
| Team 12   |  8 | 2 |  1 | 45 | 56 | 14.3 |  3.6 |  1.8 | 80.4 |

Plotting this with

#+PLOT: ind:1 deps:(7 8 9 10) type:2d with:histogram   \
set:"ylabel '%'" set:"style fill solid 0.5"

works like a charm, except I'd like to change the colors of the
histogram bars (as it turns out Bu=Blue, R=Red, Bk=Black and G=Green as
per the title row in the table).

What's the recommended way to go about this? I'm not super familiar with
gnuplot, but before I go deep there, I figured I'd ask if there's a
simple 'org-plot'-way of doing this?

Thanks,
Stephan

Re: [ANN] faster org-table-to-lisp

[Nicolas Goaziou]

Hello,

tbanelwebmin  writes:

> Here is an alternative, faster version of org-table-to-lisp. It can be
> more than 100 times faster.

Great! Thank you!

> #+BEGIN_SRC elisp
> (defun org-table-to-lisp-faster (&optional org-table-at-p-done)
>   "Convert the table at point to a Lisp structure.
> The structure will be a list.  Each item is either the symbol `hline'
> for a horizontal separator line, or a list of field values as strings.
> The table is taken from the buffer at point.
> When the optional ORG-TABLE-AT-P-DONE parameter is not nil, it is
> assumed that (org-at-table-p) was already called."

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.

Or, to be backward compatible, I suggest

  &optional TEXT TABLE

>   (or org-table-at-p-done (org-at-table-p) (user-error "No table at point"))
>   (save-excursion
>     (goto-char (org-table-begin))
>     (let ((end (org-table-end))
>   (row)
>   (table))

Nitpick:

(row nil)
(table nil)

>   (while (< (point) end)
>     (setq row nil)
>     (search-forward "|" end)
>     (if (looking-at "-")
>     (progn
>   (search-forward "\n" end)

(forward-line)

>   (push 'hline table))
>   (while (not (search-forward-regexp "\\=\n" end t))

(unless (eolp)
  ...)

>     (unless (search-forward-regexp "\\=\\s-*\\([^|]*\\)" end t)
>   (user-error "Malformed table at char %s" (point)))

A row may not be properly ended. It doesn't warrant an error. Could you
make it more tolerant?

Also `search-forward-regexp' -> `re-search-forward', i.e., use the
original.

>     (let ((b (match-beginning 1))
>           (e (match-end   1)))

Nitpick: spurious spaces.

>   (and (search-backward-regexp "[^ \t]" b t)
>        (forward-char 1))

  (skip-chars-backward " \t")

> It is faster because it operates directly on the buffer with
> (search-forward-regexp). Whereas the standard function splits a string
> extracted from the buffer.

You are right. I guess the initial implementation didn't have these
monster tables in mind.

> This function is a drop-in replacement for the standard one. It can
> benefit to Babel and Gnuplot.
>
> Would it make sense to upgrade Org Mode code base?

Certainly. Could you add an entry in ORG-NEWS, in "Miscellaneous"?

Regards,

-- 
Nicolas Goaziou

Re: [PATCH] org-agenda.el: Complete multiple todo keywords

[akater]

Kyle Meyer  writes:

> Thanks for the patch.  Looks like a nice improvement to me.
>
> akater  writes:
>
>> * lisp/org-agenda.el (org-todo-list): Use completing-read-multiple
>> instead of completing-read when selecting todo keywords to filter by
>> in Agenda.
>
> This and the rest of the lines were unwrapped.  Could you wrap them ~70
> characters?  (The Org repo's .dir-locals.el sets fill-column to 70.)

>> * lisp/org-agenda.el (org-todo-list): Fix a typo in the prompt.
>
> Thanks for spotting that typo.  I think it'd be more common to append
> this description to the entry above rather than adding another
> org-todo-list entry.

Done. New patch is attached.

>> There is minor UX cost to Helm users: while candidates list used to
>> appear immediately to Helm users, now Helm users have to hit TAB to
>> see the list.
>
> Just the opinion of one Helm user, but needing to hit tab for crm-based
> completion has never bothered me too much.  But if it did, Helm allows
> specifying that certain commands should go through the built-in
> completion.
>
> Out of curiosity I tried with the latest ivy (9e0803c), and I also
> needed to hit tab before seeing anything.
>
>> This inconsistency is not present in vanilla Emacs
>> completion.
>
> I'm confused by this.  When I try with no customization (Emacs 26.3), I
> need to hit tab to see any of the candidates.

Yes; my point is, in vanilla Emacs completing-read-multiple and
completing-read behave similarly while in Helm, singleton completion
does not require hitting TAB initially but multiple-candidates
completion does.  I remember initially thinking that I broke completion
altogether when I first introduced crm here.  My confusion didn't last
long but still, I found this a little unpleasant and tried my best to
make it go.

> Looks like you stuck with "|" as the separator, which seems like a good
> idea to me.
>
>> However, it is unfortunate that string patterns are strings themselves
>> and are thus indistinguishable from strings; it would be better if crm
>> exposed separator (the string) on its own in its interface.
>
> I'm not quite sure I follow what you're suggesting with the last bit.
> Could you rephrase the point in a way that is a bit more connected with
> the code change?  This patch sticks with the same separator, so aside
> from being able to complete multiple things, there's no change in
> behavior/added restriction here, right?

Well, this likely shouldn't be in the patch either.  I removed it and
it's fine to forget about it.  The rest of the message elaborates on
this.

What type is crm-separator of? According to crm.el, its default value is
that of the constant crm-default-separator which is regex, i.e. a string
pattern.  That means crm-separator is a string pattern.  It is employed
as a string pattern in (the function) completing-read-multiple to clean
some string from unneeded whitespace.

And yet, using string pattern modelled on the default one in my patch
would break things for Helm users (besides the fact that using it would
simply make the code unnecessary cluttered).  If you substitute said
direct equivalent, activate Helm, eval

(let ((crm-separator "[ \t]*\|[ \t]*"))
  (completing-read-multiple "kwds: "
(mapcar #'list '("TODO" "DONE")) nil nil))

, press TAB C-SPC C-SPC RET | TAB C-SPC C-SPC RET, you'll get corrupted
result: TODO,DONE|TODO|DONE.  This is due to the fact that to make Helm
support non-standard crm-separator, Helm developer had to resort to a
fairly ugly hack trying to distinguish between a string pattern and an
actual separator, otherwise results like TODO,DONE|TODO|DONE would
appear in minibuffer.

The gist of the problem is, Helm needs a separator to insert into
buffer, and it now tries do detect whether crm-separator is regex or
not, only uses it as insertion material in the latter case and reverts
to the default comma otherwise.  Detection is based on string length:
https://github.com/emacs-helm/helm/commit/52e1d74f9ec6647c039012626f96596f0eb4140a
which is of course very unreliable.

This might be considered a low-quality decision in Helm but I'd say it
is natural for a user

- of multiple-candidates completion interface (such as Helm)

- that has to transform collections of candidates into strings on its
  own (this would be true for any Emacs application, I guess)

to need both the separator to search for and the separator to
intersperse a string with.

Some collection types, like this collection type “a collection of Org
todo keywords”, come bundled with specific separator-the-string.  It is
this string that I'm using in mapconcat here.  This string is a natural
part of the interface of many collections of candidates, due to
string-orientedness of everything that Emacs has to deal with, but this
separator-the-string is now inaccessible to users of crm because crm de
facto only exposes regex separator as part of its interface.

These two separators are different objects of different types: one of
them is a pattern, ano