[-- Attachment #1: Type: text/plain, Size: 356 bytes --] I have to write a number of text-heavy documents which need to be delivered as tables with wrapped paragraphs in most cells. Working directly in table format is pretty arduous and uncomfortable. Has anyone ever written a function to accept a list or subtree as input and process it into a table? If anyone has done something similar, I'd love some tips! [-- Attachment #2: Type: text/html, Size: 422 bytes --]
Hi Matt,
Matt Price writes:
> I have to write a number of text-heavy documents which need to be
> delivered as tables with wrapped paragraphs in most cells. Working
> directly in table format is pretty arduous and uncomfortable. Has
> anyone ever written a function to accept a list or subtree as input
> and process it into a table?
>
> If anyone has done something similar, I'd love some tips!
Some time ago I wrote some functions for my personal use that allow edit
table cells (with a lot of text and/or paragraphs) in a dedicated
buffer. I don't know if something like that is what you are looking for,
but if you are interested, I can clean up the code a bit and upload it
here.
Best regards,
Juan Manuel
Matt Price <moptop99@gmail.com> writes:
> I have to write a number of text-heavy documents which need to be delivered as tables with wrapped paragraphs in most cells. Working directly in
> table format is pretty arduous and uncomfortable. Has anyone ever written a function to accept a list or subtree as input and process it into a table?
>
> If anyone has done something similar, I'd love some tips!
No, have not done that. What formats do you need to export the documents
in?
I ask because if all you need to produce is Latex derived documents
(i.e. PDF, ps etc) and you do plan to write a function yourself to do
this, I would work backwards. Latex tables are not very good for your
use case, but Latex can support what you want to do. Most of the Latex
table packages are not terribly good at formatting tables containing
paragraphs of data. They will typically require lots of hand tweaking to
get the formatting looking right. Getting the right latex package to
support what you need to do will make the function you will need to
write a lot easier. Therefore, I would start with a search of the latex
package archives to find the right package and then write an elisp
function that generates a latex block which formats your subtree using
that package. You probably want something which will format a table with
minipage or similar environments in the cells.
--
Tim Cross
[-- Attachment #1: Type: text/plain, Size: 1944 bytes --] Thanks for the thoughts, Tim. My preference is generally to work in HTML, and in fact if I had a decent platform to work on I could just use a container class and grid or flex layouts, but the learning management system at my institution strips out most styling information when HTML is uploaded, so I will probably need a real table. I odn't think I could really handle doing this in latex. I am a terrible latex user! On Mon, Jul 5, 2021 at 9:27 PM Tim Cross <theophilusx@gmail.com> wrote: > > Matt Price <moptop99@gmail.com> writes: > > > I have to write a number of text-heavy documents which need to be > delivered as tables with wrapped paragraphs in most cells. Working directly > in > > table format is pretty arduous and uncomfortable. Has anyone ever > written a function to accept a list or subtree as input and process it into > a table? > > > > If anyone has done something similar, I'd love some tips! > > No, have not done that. What formats do you need to export the documents > in? > > I ask because if all you need to produce is Latex derived documents > (i.e. PDF, ps etc) and you do plan to write a function yourself to do > this, I would work backwards. Latex tables are not very good for your > use case, but Latex can support what you want to do. Most of the Latex > table packages are not terribly good at formatting tables containing > paragraphs of data. They will typically require lots of hand tweaking to > get the formatting looking right. Getting the right latex package to > support what you need to do will make the function you will need to > write a lot easier. Therefore, I would start with a search of the latex > package archives to find the right package and then write an elisp > function that generates a latex block which formats your subtree using > that package. You probably want something which will format a table with > minipage or similar environments in the cells. > > -- > Tim Cross > > [-- Attachment #2: Type: text/html, Size: 2470 bytes --]
Nearly every day, I'm filled with joy because I no longer have to battle
brain dead LMS!
If your forced to use HTML tables, that is a pain - it will be like
stepping back to the turn of the century when we used tables as the
basic layout structure.
It may be worthwhile verifying what/which styling the system strips. I
battled with one system which stripped in-line 'style' attributes, but
it did allow CSS blocks in the header.
It probably isn't too hard to write a function which will generate your
subtree as a table. One advantage working with HTML has over latex is
that you don't have to worry about lines and line breaks and can have
really long cell lines which will get wrapped in HTML rendering. The
complexity of your function will probably depend on how deeply your tree
goes and how much data is in each node.
Matt Price <moptop99@gmail.com> writes:
> Thanks for the thoughts, Tim.
>
> My preference is generally to work in HTML, and in fact if I had a decent platform to work on I could just use a container class and grid or flex
> layouts, but the learning management system at my institution strips out most styling information when HTML is uploaded, so I will probably need a
> real table.
>
> I odn't think I could really handle doing this in latex. I am a terrible latex user!
>
> On Mon, Jul 5, 2021 at 9:27 PM Tim Cross <theophilusx@gmail.com> wrote:
>
> Matt Price <moptop99@gmail.com> writes:
>
> > I have to write a number of text-heavy documents which need to be delivered as tables with wrapped paragraphs in most cells. Working
> directly in
> > table format is pretty arduous and uncomfortable. Has anyone ever written a function to accept a list or subtree as input and process it into
> a table?
> >
> > If anyone has done something similar, I'd love some tips!
>
> No, have not done that. What formats do you need to export the documents
> in?
>
> I ask because if all you need to produce is Latex derived documents
> (i.e. PDF, ps etc) and you do plan to write a function yourself to do
> this, I would work backwards. Latex tables are not very good for your
> use case, but Latex can support what you want to do. Most of the Latex
> table packages are not terribly good at formatting tables containing
> paragraphs of data. They will typically require lots of hand tweaking to
> get the formatting looking right. Getting the right latex package to
> support what you need to do will make the function you will need to
> write a lot easier. Therefore, I would start with a search of the latex
> package archives to find the right package and then write an elisp
> function that generates a latex block which formats your subtree using
> that package. You probably want something which will format a table with
> minipage or similar environments in the cells.
>
> --
> Tim Cross
--
Tim Cross
On Tuesday, 6 Jul 2021 at 15:10, Tim Cross wrote: > One advantage working with HTML has over latex is > that you don't have to worry about lines and line breaks and can have > really long cell lines which will get wrapped in HTML rendering. Minor point: in LaTeX, the standard tabular environment has "p{X}" for paragraph columns (as opposed to "l" and "r", say) where X is some size (e.g. 10cm) and each entry is formatted as paragraphs. You don't have to worry about line breaks etc. So quite easy really. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-577-gf76d4d : Latest paper written in org: https://arxiv.org/abs/2106.05096
Eric S Fraga <e.fraga@ucl.ac.uk> writes:
> On Tuesday, 6 Jul 2021 at 15:10, Tim Cross wrote:
>> One advantage working with HTML has over latex is
>> that you don't have to worry about lines and line breaks and can have
>> really long cell lines which will get wrapped in HTML rendering.
>
> Minor point: in LaTeX, the standard tabular environment has "p{X}" for
> paragraph columns (as opposed to "l" and "r", say) where X is some size
> (e.g. 10cm) and each entry is formatted as paragraphs. You don't have
> to worry about line breaks etc. So quite easy really.
Yes, that is true. However, you have to decide before hand how wide you
want the columns to be (i.e. it won't auto scale based on other data).
Typically, you have to do some 'trial and error' to work out what width
to make each column and avoid overful parbox warnings etc. With HTML,
you just specify the number of columns and it will scale to fit to the
page (screen) width. So, HTML great for display, sucks for printing.
latex, great for printing, but sucks for display. Getting things right
for latex tables/tabular environments is much harder than for HTML. Then
again, HTML tables sort of suck as well - much more flexible to have div
elements which you can style using a good grid/flow layout scheme.
--
Tim Cross
[-- Attachment #1: Type: text/plain, Size: 521 bytes --] >>> "MP" == Matt Price <moptop99@gmail.com> writes: > I have to write a number of text-heavy documents which need to be delivered > as tables with wrapped paragraphs in most cells. Working directly in table > format is pretty arduous and uncomfortable. Has anyone ever written a > function to accept a list or subtree as input and process it into a table? > If anyone has done something similar, I'd love some tips! There is org-listcruncher, which I started to use some days ago. For my needs it works quite nicely. [-- Attachment #2: smime.p7s --] [-- Type: application/pkcs7-signature, Size: 5673 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1203 bytes --] Hi Matt, sorry for the slow reply... Matt Price writes: > I'd love to try that, thanks. I think it would be really helpful. > Much appreciated! Some previous caveats: - *The code is very raw*. I wrote it almost as a "proof of concept" for my personal use, therefore it is quite improvable. In any case, it works (but i don't know if it will help you get what you want...). - The attached example is optimized to export to LaTeX. Use the tabularx environment, which is ideal for tables with a lot of textual content. - As for the code, there are two basic functions: `my-org/edit-table-cell' and `my-org/kill-edit-table-cell-buffer-and-save'. To edit an empty cell, you have to write something in that cell first. - The basic idea is that within each cell, the content is a single line (unfilled). In the edit buffer, the content is filled. There are two macros to indicate a line break and a paragraph end: {{{nl}}} and {{{par}}}. In the edit buffer you can put line breaks and white lines, but all of that is lost inside the cell once saved (all is a single line), so those macros are needed to indicate line or paragraph breaks (in LaTeX). Best regards, Juan Manuel [-- Attachment #2: test-tables.org --] [-- Type: application/vnd.lotus-organizer, Size: 20363 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2203 bytes --] >>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes: > Hi Matt, sorry for the slow reply... > Matt Price writes: >> I'd love to try that, thanks. I think it would be really helpful. >> Much appreciated! > Some previous caveats: > - *The code is very raw*. I wrote it almost as a "proof of concept" for > my personal use, therefore it is quite improvable. In any case, it > works (but i don't know if it will help you get what you want...). > - The attached example is optimized to export to LaTeX. Use the tabularx > environment, which is ideal for tables with a lot of textual content. Sorry for jumping into that thread. I could not resist downloading your code and trying it out. > - As for the code, there are two basic functions: > `my-org/edit-table-cell' and that worked. > `my-org/kill-edit-table-cell-buffer-and-save'. To edit an empty cell, > you have to write something in that cell first. When I changed the text in a cell and called that function I obtained and error ,---- | | Debugger entered--Lisp error: (wrong-number-of-arguments #f(compiled-function (arg) (interactive "*P") #<bytecode 0x8df3ba5756afab4>) 2) | fill-paragraph(nil t) | (let ((fill-column (point-max)) (emacs-lisp-docstring-fill-column t)) (fill-paragraph nil region)) | unfill-paragraph(t) | funcall-interactively(unfill-paragraph t) | call-interactively(unfill-paragraph) | my-org/kill-edit-table-cell-buffer-and-save() | funcall-interactively(my-org/kill-edit-table-cell-buffer-and-save) | call-interactively(my-org/kill-edit-table-cell-buffer-and-save record nil) | command-execute(my-org/kill-edit-table-cell-buffer-and-save record) | execute-extended-command(nil "my-org/kill-edit-table-cell-buffer-and-save" "my-org/k") | funcall-interactively(execute-extended-command nil "my-org/kill-edit-table-cell-buffer-and-save" "my-org/k") | call-interactively(execute-extended-command nil nil) | command-execute(execute-extended-command) | `---- I am running (a couple of week old) GNU emacs master and org-mode git master. I even restarted my emacs session What do I miss? Regards Uwe Brauer [-- Attachment #2: smime.p7s --] [-- Type: application/pkcs7-signature, Size: 5673 bytes --]
Hi Matt
Le 05/07/2021 à 21:44, Matt Price a écrit :
> I have to write a number of text-heavy documents which need to be
> delivered as tables with wrapped paragraphs in most cells. Working
> directly in table format is pretty arduous and uncomfortable. Has
> anyone ever written a function to accept a list or subtree as input
> and process it into a table?
>
> If anyone has done something similar, I'd love some tips!
Maybe you could use builtin Babel
Hereafter you have a starting point
- Give a name to your input Org list
- Process it with Emacs-Lisp (or whatever language you are comfortable
with) to output it as a table
____ self contained Org Mode example _____
Example of a named list
#+NAME: BBB
- abc
+ 123
+ 456
- def
+ red
+ blue
- ghi
+ big
+ small
Example of converting the named list into a table with Emacs-Lisp
#+begin_src elisp :var bbb=BBB :results table
bbb
#+end_src
#+RESULTS:
| abc | (unordered (123) (456)) |
| def | (unordered (red) (blue)) |
| ghi | (unordered (big) (small)) |
___________________________________________
Hi Uwe, thanks for testing the code.
Uwe Brauer writes:
> I am running (a couple of week old) GNU emacs master and org-mode git
> master. I even restarted my emacs session
>
> What do I miss?
I can't reproduce the issue (GNU Emacs 27.2 and org git master). In my
case everything works as expected (taking into account that with this
code of mine the expectations have to be modest :-).
I will do a test on Emacs master...
Best regards,
Juan Manuel
[-- Attachment #1: Type: text/plain, Size: 558 bytes --] >>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes: > Hi Uwe, thanks for testing the code. > Uwe Brauer writes: >> I am running (a couple of week old) GNU emacs master and org-mode git >> master. I even restarted my emacs session >> >> What do I miss? > I can't reproduce the issue (GNU Emacs 27.2 and org git master). In my > case everything works as expected (taking into account that with this > code of mine the expectations have to be modest :-). Could also be some of my pkg file. I might check it starting emacs -q [-- Attachment #2: smime.p7s --] [-- Type: application/pkcs7-signature, Size: 5673 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1958 bytes --] I think this is exactly what I want (with just a little moreprocessing). Thank you so much for the idea! I'm having a little bit of trouble getting the same output as you though, and I'm wondering if there might be a setting that I need to change. Here is what I tried, and the result. Do you have an idea of what is going wrong here? Thank you! ------------ #+NAME:essay-rubric - Category - A - B - C - D - F - Writing - great - good - ok - lousy - awful #+begin_src emacs-lisp :var contents=essay-rubric :results table contents #+end_src #+RESULTS: #+begin_src emacs-lisp | (("Category" | #+end_src ------------- On Wed, Jul 7, 2021 at 6:29 AM tbanelwebmin <tbanelwebmin@free.fr> wrote: > Hi Matt > > Le 05/07/2021 à 21:44, Matt Price a écrit : > > I have to write a number of text-heavy documents which need to be > > delivered as tables with wrapped paragraphs in most cells. Working > > directly in table format is pretty arduous and uncomfortable. Has > > anyone ever written a function to accept a list or subtree as input > > and process it into a table? > > > > If anyone has done something similar, I'd love some tips! > > Maybe you could use builtin Babel > Hereafter you have a starting point > - Give a name to your input Org list > - Process it with Emacs-Lisp (or whatever language you are comfortable > with) to output it as a table > > > ____ self contained Org Mode example _____ > > Example of a named list > #+NAME: BBB > - abc > + 123 > + 456 > - def > + red > + blue > - ghi > + big > + small > > Example of converting the named list into a table with Emacs-Lisp > #+begin_src elisp :var bbb=BBB :results table > bbb > #+end_src > > #+RESULTS: > | abc | (unordered (123) (456)) | > | def | (unordered (red) (blue)) | > | ghi | (unordered (big) (small)) | > ___________________________________________ > > > [-- Attachment #2: Type: text/html, Size: 2594 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1499 bytes --] thank you Juan Mnauel. I'm testing it out, but I do wonder if I would really rather work with lists and some CSS! On Tue, Jul 6, 2021 at 8:56 AM Juan Manuel Macías <maciaschain@posteo.net> wrote: > Hi Matt, sorry for the slow reply... > > Matt Price writes: > > > I'd love to try that, thanks. I think it would be really helpful. > > Much appreciated! > > Some previous caveats: > > - *The code is very raw*. I wrote it almost as a "proof of concept" for > my personal use, therefore it is quite improvable. In any case, it > works (but i don't know if it will help you get what you want...). > > - The attached example is optimized to export to LaTeX. Use the tabularx > environment, which is ideal for tables with a lot of textual content. > > - As for the code, there are two basic functions: > `my-org/edit-table-cell' and > `my-org/kill-edit-table-cell-buffer-and-save'. To edit an empty cell, > you have to write something in that cell first. > > - The basic idea is that within each cell, the content is a single line > (unfilled). In the edit buffer, the content is filled. There are two > macros to indicate a line break and a paragraph end: {{{nl}}} and > {{{par}}}. In the edit buffer you can put line breaks and white lines, > but all of that is lost inside the cell once saved (all is a single > line), so those macros are needed to indicate line or paragraph breaks > (in LaTeX). > > Best regards, > > Juan Manuel > > [-- Attachment #2: Type: text/html, Size: 1901 bytes --]
[-- Attachment #1: Type: text/plain, Size: 801 bytes --] It's totally interesting. It's not quite designed for what I'm looking to do and is perhaps a bit overpowered for my limited needs but I'm going to test whe nI have a little mroe time! On Tue, Jul 6, 2021 at 7:51 AM Uwe Brauer <oub@mat.ucm.es> wrote: > >>> "MP" == Matt Price <moptop99@gmail.com> writes: > > > I have to write a number of text-heavy documents which need to be > delivered > > as tables with wrapped paragraphs in most cells. Working directly in > table > > format is pretty arduous and uncomfortable. Has anyone ever written a > > function to accept a list or subtree as input and process it into a > table? > > > If anyone has done something similar, I'd love some tips! > > There is org-listcruncher, which I started to use some days ago. For my > needs it works quite nicely. > [-- Attachment #2: Type: text/html, Size: 1224 bytes --]
When I run you example I get:
#+RESULTS:
| Category | (unordered (A) (B) (C) (D) (F)) |
| Writing | (unordered (great) (good) (ok) (lousy) (awful)) |
To get your result I need to modify
:results table
to
:results table code
You may try
:results table raw
Or try your example without any hidden customisation
emacs -q
This info page may be useful:
[[info:org#Results of Evaluation]]
Le 07/07/2021 à 23:13, Matt Price a écrit :
> I think this is exactly what I want (with just a little
> moreprocessing). Thank you so much for the idea!
>
> I'm having a little bit of trouble getting the same output as you
> though, and I'm wondering if there might be a setting that I need to
> change.
>
> Here is what I tried, and the result. Do you have an idea of what is
> going wrong here?
>
> Thank you!
>
>
> ------------
> #+NAME:essay-rubric
> - Category
> - A
> - B
> - C
> - D
> - F
> - Writing
> - great
> - good
> - ok
> - lousy
> - awful
>
> #+begin_src emacs-lisp :var contents=essay-rubric :results table
> contents
> #+end_src
>
> #+RESULTS:
> #+begin_src emacs-lisp
> | (("Category" |
> #+end_src
> -------------
> On Wed, Jul 7, 2021 at 6:29 AM tbanelwebmin <tbanelwebmin@free.fr
> <mailto:tbanelwebmin@free.fr>> wrote:
>
> Hi Matt
>
> Le 05/07/2021 à 21:44, Matt Price a écrit :
> > I have to write a number of text-heavy documents which need to be
> > delivered as tables with wrapped paragraphs in most cells. Working
> > directly in table format is pretty arduous and uncomfortable. Has
> > anyone ever written a function to accept a list or subtree as input
> > and process it into a table?
> >
> > If anyone has done something similar, I'd love some tips!
>
> Maybe you could use builtin Babel
> Hereafter you have a starting point
> - Give a name to your input Org list
> - Process it with Emacs-Lisp (or whatever language you are comfortable
> with) to output it as a table
>
>
> ____ self contained Org Mode example _____
>
> Example of a named list
> #+NAME: BBB
> - abc
> + 123
> + 456
> - def
> + red
> + blue
> - ghi
> + big
> + small
>
> Example of converting the named list into a table with Emacs-Lisp
> #+begin_src elisp :var bbb=BBB :results table
> bbb
> #+end_src
>
> #+RESULTS:
> | abc | (unordered (123) (456)) |
> | def | (unordered (red) (blue)) |
> | ghi | (unordered (big) (small)) |
> ___________________________________________
>
>
Hi, Matt,
Here's a version of this with a bit more processing.
Define this somewhere in your document
#+NAME: list2table
#+BEGIN_SRC elisp :var order="columns"
(let (longest)
(setq data (map 'list 'flatten data))
(setq data (map 'list (lambda (x) (seq-difference x '(unordered ordered))) data))
;; Pad out lists to equal length
(setq longest (seq-max (map 'list 'length data)))
(setq data
(map 'list
(lambda (l)
(append l (make-list (- longest (length l)) "")))
data))
;; Order by columns or rows
(if (string= order "columns")
(apply #'mapcar* #'list data) ; transpose
data))
#+END_SRC
Here is an example list to try it out with:
#+NAME: testlist
- Letters
1. a
2. b
3. c
- Roman numerals
1. i
2. ii
3. iii
- Greek letters
1. alpha
2. beta
3. gamma
Now you can call the src block, passing the name of the list to the
"data" variable.
#+CALL: list2table(data=testlist)
#+RESULTS:
| Letters | Roman numerals | Greek letters |
| a | i | alpha |
| b | ii | beta |
| c | iii | gamma |
The default here is that each top item and its sublist forms a column.
To get rows instead, pass order="rows" (or anything other than
order="columns" really):
#+CALL: list2table(data=testlist, order="rows")
#+RESULTS:
| Letters | a | b | c |
| Roman numerals | i | ii | iii |
| Greek letters | alpha | beta | gamma |
You can use numbered or unnumbered lists. Sublists don't strictly have
to be the same length - the code pads them out to equal length with the
empty string before transposing. However, I would strongly recommend
using numbered sublists of the same length (with blank items as needed),
so you can make sure that items line up correctly.
If you want column headers or rownames, you will need to take care of
that manually before exporting. Using ":colnames yes" will lead to
errors when the source is a list. Might be away to hack org-babel to get
around this but I don't know how. (The only automatic solution I can
think of would be by naming the calls in an unexported section and
referencing them with another layer of calls in the exported section,
using a src block that only passes the data on with :colnames yes. But
that's fiddly.)
Will this work for you?
Yours,
Christian
Matt Price writes:
> I think this is exactly what I want (with just a little moreprocessing).
> Thank you so much for the idea!
>
> I'm having a little bit of trouble getting the same output as you though,
> and I'm wondering if there might be a setting that I need to change.
>
> Here is what I tried, and the result. Do you have an idea of what is going
> wrong here?
>
> Thank you!
>
>
> ------------
> #+NAME:essay-rubric
> - Category
> - A
> - B
> - C
> - D
> - F
> - Writing
> - great
> - good
> - ok
> - lousy
> - awful
>
> #+begin_src emacs-lisp :var contents=essay-rubric :results table
> contents
> #+end_src
>
> #+RESULTS:
> #+begin_src emacs-lisp
> | (("Category" |
> #+end_src
> -------------
> On Wed, Jul 7, 2021 at 6:29 AM tbanelwebmin <tbanelwebmin@free.fr> wrote:
>
>> Hi Matt
>>
>> Le 05/07/2021 à 21:44, Matt Price a écrit :
>> > I have to write a number of text-heavy documents which need to be
>> > delivered as tables with wrapped paragraphs in most cells. Working
>> > directly in table format is pretty arduous and uncomfortable. Has
>> > anyone ever written a function to accept a list or subtree as input
>> > and process it into a table?
>> >
>> > If anyone has done something similar, I'd love some tips!
>>
>> Maybe you could use builtin Babel
>> Hereafter you have a starting point
>> - Give a name to your input Org list
>> - Process it with Emacs-Lisp (or whatever language you are comfortable
>> with) to output it as a table
>>
>>
>> ____ self contained Org Mode example _____
>>
>> Example of a named list
>> #+NAME: BBB
>> - abc
>> + 123
>> + 456
>> - def
>> + red
>> + blue
>> - ghi
>> + big
>> + small
>>
>> Example of converting the named list into a table with Emacs-Lisp
>> #+begin_src elisp :var bbb=BBB :results table
>> bbb
>> #+end_src
>>
>> #+RESULTS:
>> | abc | (unordered (123) (456)) |
>> | def | (unordered (red) (blue)) |
>> | ghi | (unordered (big) (small)) |
>> ___________________________________________
>>
>>
>>
[-- Attachment #1: Type: text/plain, Size: 648 bytes --] >>> "MP" == Matt Price <moptop99@gmail.com> writes: > I have to write a number of text-heavy documents which need to be delivered > as tables with wrapped paragraphs in most cells. Working directly in table > format is pretty arduous and uncomfortable. Has anyone ever written a > function to accept a list or subtree as input and process it into a table? > If anyone has done something similar, I'd love some tips! I am facing currently a similar problem. The best solution, at least for me, is described here: https://emacsnotes.wordpress.com/2020/04/26/create-tables-with-paragraph-like-content-in-org-mode-with-the-least-amount-of-hassle/ [-- Attachment #2: smime.p7s --] [-- Type: application/pkcs7-signature, Size: 5673 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1190 bytes --] Christian et al, I seem to have broken something while fiddling around and I can't quite make out what. Would someone be willing to check for me whether this does or does not produce the desired full table? Right now I am again getting a truncated result and I'm not fully sure what I might be oding wrong. Here is what I have: #+NAME: rubric-one - Grade a. A b. B c. C d. D e. F - Style a. Excellent b. Good c. Adequate d. Lousy e. Failing #+NAME: list2table #+BEGIN_SRC emacs-lisp :var order="columns" data=rubric-one :results table value raw replace (let (longest) (setq data (map 'list '-flatten data)) (setq data (map 'list (lambda (x) (seq-difference x '(unordered ordered))) data)) ;; Pad out lists to equal length (setq longest (seq-max (map 'list 'length data))) (setq data (map 'list (lambda (l) (append l (make-list (- longest (length l)) ""))) data)) ;; Order by columns or rows (if (string= order "columns") (apply #'mapcar* #'list data) ; transpose data)) #+END_SRC #+RESULTS: list2table | Grade | ---------------- thanks as always for the help! [-- Attachment #2: Type: text/html, Size: 1579 bytes --]
Matt Price <moptop99@gmail.com> writes:
> Christian et al,
>
> I seem to have broken something while fiddling around and I can't quite make out what. Would someone be willing to check for me whether this does or does not produce the desired full table? Right now I am again getting a truncated result and I'm not
> fully sure what I might be oding wrong. Here is what I have:
>
> #+NAME: rubric-one
> - Grade
> a. A
> b. B
> c. C
> d. D
> e. F
> - Style
> a. Excellent
> b. Good
> c. Adequate
> d. Lousy
> e. Failing
>
These seem to have zero-width spaces and maybe that breaks the structure. To make sure that the structure is recognized properly,
maybe try a very simple code block:
--8<---------------cut here---------------start------------->8---
#+begin_src elisp :var data=rubric-one :results drawer
data
#+end_src
#+RESULTS:
:results:
((Grade (ordered (A) (B) (C) (D) (F))) (Style (ordered (Excellent) (Good) (Adequate) (Lousy) (Failing))))
:end:
--8<---------------cut here---------------end--------------->8---
If that does not work, then something is fishy with `rubric-one', so start there.
--
Nick
"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler
[-- Attachment #1: Type: text/plain, Size: 1467 bytes --] On Tue, Jul 20, 2021 at 12:06 PM Nick Dokos <ndokos@gmail.com> wrote: > Matt Price <moptop99@gmail.com> writes: > > > Christian et al, > > > > I seem to have broken something while fiddling around and I can't quite > make out what. Would someone be willing to check for me whether this does > or does not produce the desired full table? Right now I am again getting a > truncated result and I'm not > > fully sure what I might be oding wrong. Here is what I have: > > > > #+NAME: rubric-one > > - Grade > > a. A > > b. B > > c. C > > d. D > > e. F > > - Style > > a. Excellent > > b. Good > > c. Adequate > > d. Lousy > > e. Failing > > > These seem to have zero-width spaces and maybe that breaks the structure. > To make sure that the structure is recognized properly, > maybe try a very simple code block: > > > --8<---------------cut here---------------start------------->8--- > #+begin_src elisp :var data=rubric-one :results drawer > data > #+end_src > > #+RESULTS: > :results: > ((Grade (ordered (A) (B) (C) (D) (F))) (Style (ordered (Excellent) (Good) > (Adequate) (Lousy) (Failing)))) > :end: > --8<---------------cut here---------------end--------------->8--- > > If that does not work, then something is fishy with `rubric-one', so start > there. > Yes, I think that using alphabetical lists broke the data structure because I didn't have ~org-list-allow-alphabetical~ set to ~t~ in my init file. User error! sorry. and thank you!! [-- Attachment #2: Type: text/html, Size: 2057 bytes --]