What to use for tables with lengthy text in cells?

What to use for tables with lengthy text in cells?

[Matt Price]

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

I have a project which will require me to enter about a paragraph in each
of 5 fields several times a day. I would use org tables, but I need to be
able to see the table contents in the buffer, and org hides long lines. I
tried using table.el but it feels incredibly clumsy - for instance, I can't
find a way to add a row to the end of the table, which seems crazy.

I am wondering  what other people do in this situation - I guess I could
use a spreadsheet or an odt document but I would much rather stay in emacs
if I can.

Thanks as always,
Matt

[-- Attachment #2: Type: text/html, Size: 612 bytes --]

Re: What to use for tables with lengthy text in cells?

[Rasmus]

Hi Matt,

Matt Price <moptop99@gmail.com> writes:

> I have a project which will require me to enter about a paragraph in each
> of 5 fields several times a day. I would use org tables, but I need to be
> able to see the table contents in the buffer, and org hides long lines. I
> tried using table.el but it feels incredibly clumsy - for instance, I can't
> find a way to add a row to the end of the table, which seems crazy.

AFAIK there's no "word-wrap for tables" (but it would be cool).

I never figured out tabel.el, either.  I don't 

> I am wondering  what other people do in this situation - I guess I could
> use a spreadsheet or an odt document but I would much rather stay in emacs
> if I can.

I'm sure you are already aware of this, but the only way I can think of is
the following:

|-------+-------+-------+-------+-------|
| <5>   | <5>   | <5>   | <5>   | <5>   |
|-------+-------+-------+-------+-------|
|       |       |       |       |       |
#+TBLFM: 

Which will truncate the column at <5> characters and where you can edit a
cell with "C-c `"...

—Rasmus

-- 
Lasciate ogni speranza, voi che leggete questo.

Re: What to use for tables with lengthy text in cells?

[Charles C. Berry]

On Mon, 2 Mar 2015, Matt Price wrote:

> I have a project which will require me to enter about a paragraph in each
> of 5 fields several times a day. I would use org tables, but I need to be
> able to see the table contents in the buffer, and org hides long lines. I
> tried using table.el but it feels incredibly clumsy - for instance, I can't
> find a way to add a row to the end of the table, which seems crazy.
>
> I am wondering  what other people do in this situation - I guess I could
> use a spreadsheet or an odt document but I would much rather stay in emacs
> if I can.

I sometimes use babel blocks for this purpose.

For example, with ob-org.el loaded, with this org file:


--8<---------------cut here---------------start------------->8---
#+NAME: abc
#+BEGIN_SRC org :exports none
   This is chunk ~abc~.
#+END_SRC

Formatting via ascii:
#+BEGIN_SRC emacs-lisp :var x=abc() :exports results
(org-export-string-as x 'ascii t)
#+END_SRC

And plainly: call_abc()
--8<---------------cut here---------------end--------------->8---

export via ascii yields:


--8<---------------cut here---------------start------------->8---
Formatting via ascii:
,----
| This is chunk `abc'.
`----

And plainly: `This is chunk ~abc~.'
--8<---------------cut here---------------end--------------->8---


You can also use the noweb idiom to capture the contents of
any kind of src block.

HTH,

Chuck

Re: What to use for tables with lengthy text in cells?

[Charles C. Berry]

On Mon, 2 Mar 2015, Charles C. Berry wrote:

> On Mon, 2 Mar 2015, Matt Price wrote:
>
>> I have a project which will require me to enter about a paragraph in each
>> of 5 fields several times a day. I would use org tables, but I need to be
>> able to see the table contents in the buffer, and org hides long lines. I
>> tried using table.el but it feels incredibly clumsy - for instance, I can't
>> find a way to add a row to the end of the table, which seems crazy.
>> 
>> I am wondering  what other people do in this situation - I guess I could
>> use a spreadsheet or an odt document but I would much rather stay in emacs
>> if I can.
>
> I sometimes use babel blocks for this purpose.
>

But I did not give an example of filling in a table using that
strategy.

So here is an example of how you would use that strategy to fill out a
table with fields that get edited. Obviously, you can use the string
resulting from org-fill-template in other ways than in the example
below.

--8<---------------cut here---------------start------------->8---

* Not exported							   :noexport:

Define a table template (and put it out of the way in a subtree that
is not exported)

#+name: tmplt
#+BEGIN_SRC org
   | Never change me | %a                    |
   | %b              | Dont modify me either |
#+END_SRC

Define the fill-in cells and be sure they are not exported:

#+name: pcta
#+BEGIN_SRC org
this is ~a~.
#+END_SRC

#+name: pctb
#+BEGIN_SRC org
this is *b*.
#+END_SRC


* This gets exported

#+HEADER: :var a=pcta() :var b=pctb() :var tm=tmplt() 
#+BEGIN_SRC emacs-lisp :wrap latex :exports results
   (org-export-string-as
    (org-fill-template tm `(("a" . ,a)("b" . ,b)))
    'latex t)
#+END_SRC

#+RESULTS:
#+BEGIN_latex
\begin{center}
\begin{tabular}{ll}
Never change me & this is \verb~a~.\\
this is \textbf{b}. & Dont modify me either\\
\end{tabular}
\end{center}
#+END_latex

--8<---------------cut here---------------end--------------->8---

HTH,

Chuck

Re: What to use for tables with lengthy text in cells?

[Tory S. Anderson]

It's not a perfect solution (many of us have wished for some way of doing multi-line cells in orgmode, but there's no clear solution...) but I use a combination of width restraints[1] and toggle-truncate-lines, which I've bound to <F5>. If it comes to the worst, I would probably pull out csv-mode and use a CSV file. I think the problem is that there's no simple way to wrap within just a cell in Emacs. 

"Charles C. Berry" <ccberry@ucsd.edu> writes:

> On Mon, 2 Mar 2015, Charles C. Berry wrote:
>
>> On Mon, 2 Mar 2015, Matt Price wrote:
>>
>>> I have a project which will require me to enter about a paragraph in each
>>> of 5 fields several times a day. I would use org tables, but I need to be
>>> able to see the table contents in the buffer, and org hides long lines. I
>>> tried using table.el but it feels incredibly clumsy - for instance, I can't
>>> find a way to add a row to the end of the table, which seems crazy.
>>> 
>>> I am wondering  what other people do in this situation - I guess I could
>>> use a spreadsheet or an odt document but I would much rather stay in emacs
>>> if I can.
>>
>> I sometimes use babel blocks for this purpose.
>>
>
> But I did not give an example of filling in a table using that
> strategy.
>
> So here is an example of how you would use that strategy to fill out a
> table with fields that get edited. Obviously, you can use the string
> resulting from org-fill-template in other ways than in the example
> below.
>
>
> * Not exported							   :noexport:
>
> Define a table template (and put it out of the way in a subtree that
> is not exported)
>
> #+name: tmplt
> #+BEGIN_SRC org
>    | Never change me | %a                    |
>    | %b              | Dont modify me either |
> #+END_SRC
>
> Define the fill-in cells and be sure they are not exported:
>
> #+name: pcta
> #+BEGIN_SRC org
> this is ~a~.
> #+END_SRC
>
> #+name: pctb
> #+BEGIN_SRC org
> this is *b*.
> #+END_SRC
>
>
> * This gets exported
>
> #+HEADER: :var a=pcta() :var b=pctb() :var tm=tmplt() 
> #+BEGIN_SRC emacs-lisp :wrap latex :exports results
>    (org-export-string-as
>     (org-fill-template tm `(("a" . ,a)("b" . ,b)))
>     'latex t)
> #+END_SRC
>
> #+RESULTS:
> #+BEGIN_latex
> \begin{center}
> \begin{tabular}{ll}
> Never change me & this is \verb~a~.\\
> this is \textbf{b}. & Dont modify me either\\
> \end{tabular}
> \end{center}
> #+END_latex
>
> HTH,
>
> Chuck

Footnotes: 
[1]  http://orgmode.org/manual/Column-width-and-alignment.html#Column-width-and-alignment

Re: What to use for tables with lengthy text in cells?

[Jude DaShiell]

Why not do it this way?  An org table gets a second file created along 
with it.  That second file holds all writing going into the table.  That 
second file has a link for each cell too.  All links point to the 
original org table file and each entry in the second file at its end has 
a return link that returns the user to the original org table.  
Alternatively, all of this could be stored in the table file itself with 
perhaps only the large content cells having links to below the table 
proper area which when opened would show the longer text and provide a 
return link back to the original cell in the table.  Probably all it 
would need is a #+DATA header separating the table from the longer cells 
content area so users could know what was what when examining the file.  
If this sounds too off the wall, I had some high quality coffee this 
morning.

On Tue, 3 Mar 2015, Tory S. Anderson wrote:

> It's not a perfect solution (many of us have wished for some way of doing multi-line cells in orgmode, but there's no clear solution...) but I use a combination of width restraints[1] and toggle-truncate-lines, which I've bound to <F5>. If it comes to the worst, I would probably pull out csv-mode and use a CSV file. I think the problem is that there's no simple way to wrap within just a cell in Emacs. 
> 
> "Charles C. Berry" <ccberry@ucsd.edu> writes:
> 
> > On Mon, 2 Mar 2015, Charles C. Berry wrote:
> >
> >> On Mon, 2 Mar 2015, Matt Price wrote:
> >>
> >>> I have a project which will require me to enter about a paragraph in each
> >>> of 5 fields several times a day. I would use org tables, but I need to be
> >>> able to see the table contents in the buffer, and org hides long lines. I
> >>> tried using table.el but it feels incredibly clumsy - for instance, I can't
> >>> find a way to add a row to the end of the table, which seems crazy.
> >>> 
> >>> I am wondering  what other people do in this situation - I guess I could
> >>> use a spreadsheet or an odt document but I would much rather stay in emacs
> >>> if I can.
> >>
> >> I sometimes use babel blocks for this purpose.
> >>
> >
> > But I did not give an example of filling in a table using that
> > strategy.
> >
> > So here is an example of how you would use that strategy to fill out a
> > table with fields that get edited. Obviously, you can use the string
> > resulting from org-fill-template in other ways than in the example
> > below.
> >
> >
> > * Not exported							   :noexport:
> >
> > Define a table template (and put it out of the way in a subtree that
> > is not exported)
> >
> > #+name: tmplt
> > #+BEGIN_SRC org
> >    | Never change me | %a                    |
> >    | %b              | Dont modify me either |
> > #+END_SRC
> >
> > Define the fill-in cells and be sure they are not exported:
> >
> > #+name: pcta
> > #+BEGIN_SRC org
> > this is ~a~.
> > #+END_SRC
> >
> > #+name: pctb
> > #+BEGIN_SRC org
> > this is *b*.
> > #+END_SRC
> >
> >
> > * This gets exported
> >
> > #+HEADER: :var a=pcta() :var b=pctb() :var tm=tmplt() 
> > #+BEGIN_SRC emacs-lisp :wrap latex :exports results
> >    (org-export-string-as
> >     (org-fill-template tm `(("a" . ,a)("b" . ,b)))
> >     'latex t)
> > #+END_SRC
> >
> > #+RESULTS:
> > #+BEGIN_latex
> > \begin{center}
> > \begin{tabular}{ll}
> > Never change me & this is \verb~a~.\\
> > this is \textbf{b}. & Dont modify me either\\
> > \end{tabular}
> > \end{center}
> > #+END_latex
> >
> > HTH,
> >
> > Chuck
> 
> Footnotes: 
> [1]  http://orgmode.org/manual/Column-width-and-alignment.html#Column-width-and-alignment
> 
> 
> 

jude <jdashiel@shellworld.net>
Twitter: @JudeDaShiell

Re: What to use for tables with lengthy text in cells?

[Skip Collins]

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

Here's another suggestion. There could be an optional org table mode in
which horizontal lines are used to separate rows:

| Lorem ipsum dolor sit amet,         | foo |
| consectetur adipiscing elit. Sed    |     |
| sit amet luctus sapien. Phasellus   |     |
| malesuada, ipsum et hendrerit       |     |
| mattis, neque neque sodales risus,  |     |
| hendrerit consectetur enim ipsum eu |     |
| felis.                              |     |
|-------------------------------------+-----|
| Vestibulum ante ipsum primis in     | bar |
| faucibus orci luctus et ultrices    |     |
| posuere cubilia Curae; Nulla dictum |     |
| iaculis sodales. Sed elementum      |     |
| semper leo, venenatis lacinia odio  |     |
| eleifend vitae. Aliquam lectus      |     |
| felis, tempor nec lacus ut,         |     |
| consequat tincidunt nisl.           |     |
|-------------------------------------+-----|
| Fusce eu nunc sit amet orci         | baz |
| lobortis accumsan. Vivamus laoreet  |     |
| ante pellentesque, scelerisque      |     |
| tellus nec, ultrices nibh. Etiam    |     |
| scelerisque lobortis erat, in       |     |
| consectetur nisi tincidunt a. Duis  |     |
| eu est elit. Pellentesque fringilla |     |
| gravida ligula, non convallis       |     |
| ligula viverra sollicitudin.        |     |

Perhaps adding the required machinery to allow in-cell paragraph filling
would not be too difficult?

[-- Attachment #2: Type: text/html, Size: 1711 bytes --]

Re: What to use for tables with lengthy text in cells?

[Tory S. Anderson]

Not a bad idea, but this would be incompatible with the existing useof horizontal lines to separate sections and export to visual lines, right? 

Skip Collins <skip.collins@gmail.com> writes:

> Here's another suggestion. There could be an optional org table mode
> in which horizontal lines are used to separate rows:
>
> | Lorem ipsum dolor sit amet,         | foo |
> | consectetur adipiscing elit. Sed    |     |
> | sit amet luctus sapien. Phasellus   |     |
> | malesuada, ipsum et hendrerit       |     |
> | mattis, neque neque sodales risus,  |     |
> | hendrerit consectetur enim ipsum eu |     |
> | felis.                              |     |
> |-------------------------------------+-----|
> | Vestibulum ante ipsum primis in     | bar |
> | faucibus orci luctus et ultrices    |     |
> | posuere cubilia Curae; Nulla dictum |     |
> | iaculis sodales. Sed elementum      |     |
> | semper leo, venenatis lacinia odio  |     |
> | eleifend vitae. Aliquam lectus      |     |
> | felis, tempor nec lacus ut,         |     |
> | consequat tincidunt nisl.           |     |
> |-------------------------------------+-----|
> | Fusce eu nunc sit amet orci         | baz |
> | lobortis accumsan. Vivamus laoreet  |     |
> | ante pellentesque, scelerisque      |     |
> | tellus nec, ultrices nibh. Etiam    |     |
> | scelerisque lobortis erat, in       |     |
> | consectetur nisi tincidunt a. Duis  |     |
> | eu est elit. Pellentesque fringilla |     |
> | gravida ligula, non convallis       |     |
> | ligula viverra sollicitudin.        |     |
>
> Perhaps adding the required machinery to allow in-cell paragraph
> filling would not be too difficult?

Re: What to use for tables with lengthy text in cells?

[Skip Collins]

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

Yes, it would be incompatible. But there could be a mechanism to enable the
multi-line mode on a per-table basis. For display and grouping purposes,
horizontal lines could still be allowed by adding two consecutive lines:
|-------------------------------------+-----|
|-------------------------------------+-----|

Or another character could be used for the line separator:
|=====================================+=====|


2015-03-05 11:56 GMT-05:00 Tory S. Anderson <torys.anderson@gmail.com>:
>
> Not a bad idea, but this would be incompatible with the existing useof
horizontal lines to separate sections and export to visual lines, right?
>
> Skip Collins <skip.collins@gmail.com> writes:
>
> > Here's another suggestion. There could be an optional org table mode
> > in which horizontal lines are used to separate rows:
> >
> > | Lorem ipsum dolor sit amet,         | foo |
> > | consectetur adipiscing elit. Sed    |     |
> > | sit amet luctus sapien. Phasellus   |     |
> > | malesuada, ipsum et hendrerit       |     |
> > | mattis, neque neque sodales risus,  |     |
> > | hendrerit consectetur enim ipsum eu |     |
> > | felis.                              |     |
> > |-------------------------------------+-----|
> > | Vestibulum ante ipsum primis in     | bar |
> > | faucibus orci luctus et ultrices    |     |
> > | posuere cubilia Curae; Nulla dictum |     |
> > | iaculis sodales. Sed elementum      |     |
> > | semper leo, venenatis lacinia odio  |     |
> > | eleifend vitae. Aliquam lectus      |     |
> > | felis, tempor nec lacus ut,         |     |
> > | consequat tincidunt nisl.           |     |
> > |-------------------------------------+-----|
> > | Fusce eu nunc sit amet orci         | baz |
> > | lobortis accumsan. Vivamus laoreet  |     |
> > | ante pellentesque, scelerisque      |     |
> > | tellus nec, ultrices nibh. Etiam    |     |
> > | scelerisque lobortis erat, in       |     |
> > | consectetur nisi tincidunt a. Duis  |     |
> > | eu est elit. Pellentesque fringilla |     |
> > | gravida ligula, non convallis       |     |
> > | ligula viverra sollicitudin.        |     |
> >
> > Perhaps adding the required machinery to allow in-cell paragraph
> > filling would not be too difficult?

[-- Attachment #2: Type: text/html, Size: 2906 bytes --]

Re: What to use for tables with lengthy text in cells?

[Skip Collins]

One more crazy idea. What if there were a choice of two vertical
separators? Currently '|' is the only character used for this purpose.
If, however, something like '\' were used to signal a multi-line cell,
then it would be possible to control this feature on a row-by-row
basis. As soon as the user replaces one of the '|' characters with
'\', all vertical separators in that row also change, converting all
of its cells to multi-line text. This has the advantage of being
backward compatible and not overloading the horizontal line separator.

Re: What to use for tables with lengthy text in cells?

[Tory S. Anderson]

I think \ is overloaded for export purposes, but maybe / is clear? I think that's a good idea. 

Skip Collins <skip.collins@gmail.com> writes:

> One more crazy idea. What if there were a choice of two vertical
> separators? Currently '|' is the only character used for this purpose.
> If, however, something like '\' were used to signal a multi-line cell,
> then it would be possible to control this feature on a row-by-row
> basis. As soon as the user replaces one of the '|' characters with
> '\', all vertical separators in that row also change, converting all
> of its cells to multi-line text. This has the advantage of being
> backward compatible and not overloading the horizontal line separator.

Re: What to use for tables with lengthy text in cells?

[Skip Collins]

It might even be desirable to mix single and multi line cells in the
same row. That would introduce some restrictions on how single-line
cells are edited when they are in a row that contains multi-line
cells. I suppose they could be collapsed onto the first line in the
cell by replacing newlines with spaces. That would also have to be
handled carefully when converting a multi-line cell back to single
line.

On Fri, Mar 6, 2015 at 11:48 AM, Tory S. Anderson
<torys.anderson@gmail.com> wrote:
> I think \ is overloaded for export purposes, but maybe / is clear? I think that's a good idea.
>
> Skip Collins <skip.collins@gmail.com> writes:
>
>> One more crazy idea. What if there were a choice of two vertical
>> separators? Currently '|' is the only character used for this purpose.
>> If, however, something like '\' were used to signal a multi-line cell,
>> then it would be possible to control this feature on a row-by-row
>> basis. As soon as the user replaces one of the '|' characters with
>> '\', all vertical separators in that row also change, converting all
>> of its cells to multi-line text. This has the advantage of being
>> backward compatible and not overloading the horizontal line separator.