On Tue, Aug 29, 2017 at 9:55 AM, Arjan <arjanmos...@gmail.com> wrote:
> I'd like to work with tabular data in my Leo outlines, such that the table > structure is visualized inside a node body (aligned column widths) and a > key binding should facilitate navigation/data entry (e.g. tab jumps to next > column). In other words, it should work roughly like OrgMode tables. > I have just created #546 <https://github.com/leo-editor/leo-editor/issues/546> for this. In February of this year I began work on tables.py (in LeoPluginsRef.leo), but have done nothing with it since. I've started looking at this and it seems the basic transformations aren't > too problematic. But, I'm not very experienced with Python (or other > languages, for that matter), nor with Leo plugins. I've made a first very > rough version which seems to work for the basics. So my questions are: Is > the idea in general likely to work well in Leo? And, how terrible is the > attached approach? ;) > I would welcome any help you could give. You might find some of the code in tables.py useful, or not. > I've made an @button with two functions (see below): text_to_table() turns > lines with |-separators into a list of lists (rows containing cells), and > align_table() aligns the columns in such a table using whitespace, and > returns the whole thing as a string. > > Some specifics I'm wondering about now: > 1) Is it possible to re-assign e.g. the tab key to trigger the alignment, > but only on nodes of a new type (say @tabular)? > Anything is possible, given enough work. Leo already has special cases for the tab key, so rather than mess with bindings themselves, scripts (or tables.py) could monkey-patch the code. The code is in question is the updateTab helper of the EditCommandsClass.selfInsertCommand method, in leo/commands/editCommands.py. As you can see, there is a lot going on there, and in the doPlainTab and updateAutoIndent helpers. But that is where I might look. But for testing I would just define some new commands, and bind some other keys to those commands. Later, if you really want to, I would look at "overloading" the tab key. > 2) Would same be possible for a newly defined "@language tabular", so it > would work on just the tabular section of a node? > Maybe. Again, I would focus on the alignment code first, and leave the frills for later. > 3) The current approach relies on number of characters for aligning, so a > mono-spaced font is required. Is it possible to use a particular font for > just a particular node type (or language)? > Sure, if you work really hard. I would stick with using blanks (with a mono font) for starters. > 4) Or are there ways of aligning text other than via mono-spaced fonts? > You could use hard tabs, but that will create other problems. I recommend using blanks. > 5) Is it feasible to use two different vnode body formats, where the GUI > format would use the whitespace and visual separator such as |, but the > on-disk format would be transformed to CSV or tab-separated plain text > (stripped of the extra alignment whitespace)? > Let me answer this "sideways". I actually don't remember anything about my original intentions for tables.py, but almost surely they were based on trying to duplicate org-mode's table editing <http://orgmode.org/manual/Built_002din-table-editor.html#Built_002din-table-editor> as closely as possible. I recommend that you do the same, which means, I think, that all you should be trying to do is insert '|' and space characters automagically. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
