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 -- PR>the simple emacs spreadsheet; Emacspeak advises that package some, but the advice in my opinion 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@xxxxxxxxxxx> 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@xxxxxxxxxxx > > ----------------------------------------------------------------------------- > To unsubscribe from the emacspeak list or change your address on the > emacspeak list send mail to "emacspeak-request@xxxxxxxxxxx" 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@xxxxxxxxxxx" with a subject of "unsubscribe" or "help".
If you have questions about this archive or had problems using it, please send mail to:
priestdo@xxxxxxxxxxx No Soliciting!Emacspeak List Archive | 2010 | 2009 | 2008 | 2007 | 2006 | 2005 | 2004 | 2003 | 2002 | 2001 | 2000 | 1999 | 1998 | Pre 1998