# editing tables in emacs/org-mode, latex and emacspeak

Hi Peter,

Haven't heard from you in ages, wasn't even sure that you were
still using Emacspeak:-)

Responses in-lined.

PR> I love the table browsing capability in emacspeak-table and
PR>emacspeak-table-ui.

Me Too:-)

PR> I have two use cases, though, that I haven't found a good way to do.

PR> 1) Reading a colleague's LATeX document with tabular
PR>environments. I'd like to be able to turn the capabilities of
PR>emacs-table loose on these. My solution is to write a very
PR>dumb parser for the LATeX tabular environment into the vector
PR>of vectors used by emacspeak-table. \multicolumn would be a
PR>bit trickier but I think duplicating its content across cells
PR>would be a reasonable first cut. So is this feature already
PR>present and/or easily constructed e.g. via conversion to html?

The above --- writing a simple parser for LaTeX table
environments is the right first step. However that functionality
doesn't exist at present. I'd recommend starting simple and
addressing the type of tables you'd like to work with most
often; also, going to HTML wont make the problem any simpler.

PR> If that worked I would probably add org-mode tables as well.

Org-mode tables might be easier to handle than LaTeX tables in
their full glory. ORG is my prefered means for authoring most
things these days -- and it's editing interface is very rich;
Emacspeak's own support for org's editing features could also
do with some work, so any/all help appreciated.

One possibility would be to use org-mode to write/author, and
have a command that grabs the org-mode table, turns it into
the  vector representation used by emacspeak, and then create a
separate "browse buffer" where you review the table per  your
needs. You could set that buffer up to link back to the edit
buffer, so you can easily jump back and forth between

reviewing and editting.

PR> 2) Editing or creating tables. The preferred way to do this seems to
PR> be table.el advised by emacspeak-etable.el. This is good for

I've actually not used etable since cutting over full-time to org.

PR> producing ascii tables but I miss the
PR> emacspeak browsing capability and I still can't turn off table.el
PR> splitting cells if you add a lot of content. To see what I mean do
PR> the following

I'm deleteing the example below since I'd like to take etable off
the table for now.
Try the same table in org and see if you like the export better;
In general, org-mode is receiving a lot of developer love and
attention, and  that makes it a better candidate.

PR> So is it worth extending the data structure in emacspeak-table to
PR> handle spanning columns and to make it editable?

I'd use the emacspeak table interface for browsing and reviewing,
and use org-mode table support for editing.

That feels like the path of least resistance and will  yield what
you need.  That said, it would have the disadvantage of
splitting apart reading vs editing -- which may not be good
long-term.

That said, Emacspeak has lasted  20 years, so long-term can mean
a long time ---  so we could do the above, and then work toward a
world where org-mode and emacspeak-table-ui  are more tightly
coupled --  that would yield the ideal scenario.

PR> Or are we better off
PR> trying to enhance the emacs table facilities? Or, in the best
PR>case, am I reinventing the wheel?

You're not reinventing the wheel:-)

Another question to ask while coming up with a direction:

Ask who else would find this useful --- as in "useful enough to
work on it". The editting functionality is broadly useful to the
Emacs user -- not just the Emacspeak user. That's what you're
seeing with the development activity in org-mode; we should
leverage that, i.e. not spend time writing an emacspeak specific
edit-table interface.

The table browsing functionality as provided by Emacspeak is
really only useful to the Emacspeak user -- so that is
something we should continue to drive forward.

PR> thanks in advance for any suggestions

I notice that a later message in this thread pointed at ses --
is not complete. I have not needed ses much  given the
functionality in org-mode to calculate within tables; however
if someone would like  to work on improving emacspeak's ses

support, patches would be welcome.
--Raman
Peter

On 12/25/13, Peter Rayner <peter.julien.rayner@gmail.com> wrote:
> I love the table browsing capability in emacspeak-table and
> emacspeak-table-ui.
> I have two use cases, though, that I haven't found a good way to do.
>
> 1) Reading a colleague's LATeX document with tabular environments. I'd
> like to be able to turn the capabilities of emacs-table loose on
> these. My solution is to write a very dumb parser for the LATeX
> tabular environment into the vector of vectors used by
> emacspeak-table. \multicolumn would be a bit trickier but I think
> duplicating its content across cells would be a reasonable first cut.
> So is this feature already present and/or easily constructed e.g. via
> conversion to html?
> If that worked I would probably add org-mode tables as well.
>
> 2) Editing or creating tables. The preferred way to do this seems to
> be table.el advised by emacspeak-etable.el. This is good for producing ascii
> tables but I miss the
> emacspeak browsing capability and I still can't turn off table.el
> splitting cells if you add  a lot of content. To see what I mean do
> the following
>
> In an empty text buffer type
> table-insert
> follow the defaults to give a 3x3 table with cells of 1 row and 5
> columns.
> Now in cell (0,0) enter something like
> this is a particularly large amount of information to squeeze into one
> cell
> You get a buffer which looks like this:
> +-----+-----+-----+
> |this |     |     |
> |is a |     |     |
> |part\|     |     |
> |icul\|     |     |
> |arly |     |     |
> |large|     |     |
> |amou\|     |     |
> |nt   |     |     |
> |of   |     |     |
> |info\|     |     |
> |rmat\|     |     |
> |ion  |     |     |
> |to   |     |     |
> |sque\|     |     |
> |eze  |     |     |
> |into |     |     |
> |1    |     |     |
> |cell |     |     |
> +-----+-----+-----+
> |     |     |     |
> +-----+-----+-----+
> |     |     |     |
> +-----+-----+-----+
>
> The cell will be split vertically which is fine, the dashes suggest
> you have very tall cells for the first row.
> Now run table-generate-source (ctrl-caret) into latex. It generates:
> % This LaTeX table template is generated by emacs 24.2.1
> \begin{tabular}{|l|l|l|}
> \hline
> this & & \\
> is a & & \\
> part$\backslash$ & & \\
> icul$\backslash$ & & \\
> arly & & \\
> large & & \\
> amou$\backslash$ & & \\
> nt & & \\
> of & & \\
> info$\backslash$ & & \\
> rmat$\backslash$ & & \\
> ion & & \\
> to & & \\
> sque$\backslash$ & & \\
> eze & & \\
> into & & \\
> 1 & & \\
> cell & & \\
> \hline
>  & & \\
> \hline
>  & & \\
> \hline
> \end{tabular}
>
> for me, this isn't the LATeX I would like to see here. I would prefer
> to see our very large cell preserved as a single cell. Sure I would
> need to replace the l specifier in the begin{tabular} with a p but
> I could live with that.
>
> So is it worth extending the data structure in emacspeak-table to
> handle spanning columns and to make it editable? Or are we better off
> trying to enhance the emacs table facilities? Or, in the best case, am
> I reinventing the wheel?
> thanks in advance for any suggestions
> Peter
>
>
>
>
>
> --
>
> Peter Rayner
> room 343
> School of Earth Sciences, University of Melbourne, 3010, Vic, Australia
> tel: work: +61 (0)3 8344 9708; fax: +61 (0)3 8344 7761
> mobile +61 402 752 379, skype: petermorag
> mail-to: prayner@unimelb.edu.au
>
> -----------------------------------------------------------------------------
> To unsubscribe from the emacspeak list or change your address on the
> emacspeak list send mail to "emacspeak-request@cs.vassar.edu" with a
> subject of "unsubscribe" or "help".
>
>

-----------------------------------------------------------------------------
To unsubscribe from the emacspeak list or change your address on the
emacspeak list send mail to "emacspeak-request@cs.vassar.edu" with a
subject of "unsubscribe" or "help".