Tables with tab space instead of pipe?

[Mat]

This idea for tables feels so simple that I'm probably missing something obvious, so FWIW:

Instead of - or at least optionally to -  using pipe ("|") as the separator, how about using tab space? This way you can make a frameless table in edit mode which is converted to regular framed cells table in viewmode. I can think of some pretty simple rules for this conversion (ie of the type "a cell starts wherever text is preceeded by a tab, except newline which..." etc.)

(BTW, exactly how do you make a tab space in TW? I'm forced to open some other program and copy paste.)

<:-)

[PMario]

Hi Mat,
I think having tabs and spaces as table seperators is not possible, since spaces allready have a special meaning. And it would cause backwards compatibility problems .... a lot of them :)

|left alligned text | center | right alligned|

For tabs, just use the tab key :)

backstage: tweaks
check: Use the tab key to insert tab characters instead of moving between fields - chkInsertTabs

-m

[Mat]

Thanks for your reply PMario.

First off, when I wrote "tab space" I mean only pressing the tab button (I was trying to avoid confusion from the double meaning of tab but I guess I did the exact opposite ;-)

Is your point still valid then? (The center / right align is thus not relevant).

Are there other places where tabs are used in the code?

Regardless, if necessary it would be easy (?) to use some type of indicator where this should be valid. Perhaps somting like in current tables where you have a marker for the headline row etc

Also, I'm kind of having TW5 in mind where backward compatability is so far less important anyway.

The current pipe way is just very messy for anything but the simplest of tables, IMO.

backstage: tweaks
check: Use the tab key to insert tab characters instead of moving between fields - chkInsertTabs

Aha, will try! The ideal, for me, would be to have tab move between fields - or rather, from title, to tags, to text (it currently moves from title to text) - and then behave like tab character. Do you know if this is possible?

<:-)

[Jeremy Ruston]

I'm not keen on giving the tab character special meanings within markup (other than classing it as whitespace), because it breaks the printability of wikitext source. Otherwise a virtue of wikitext is its explicitness (compared to MS Word with it's hidden paragraph markers that act as an anchor for formatting). The other problem is that it is hard to type a tab character on many systems (eg iphone, ipad).

Having said that, I'd definitely like to evolve an easier to type and read format for tables. MediaWiki lets tables be typed as a cell on each line, which I like a lot.

As to handling the tab key on desktop browsers, my current thinking is that for the majority of users the simplest behaviour is for the tab key to always move between fields, and never to insert tab characters. As with TW classic, we'll need to provide some way for advanced users to insert tab characters when they want them.

Keyboard shortcuts are moving up my list for TW5. My aim is to allow it to be entirely driven by the keyboard, and to allow a high degree of configurability by users. You will, for instance, be able to navigate the tag pills and their associated lists.

Best wishes

Jeremy

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Jeremy Ruston
mailto:jeremy...@gmail.com

[Mat]

On Monday, July 22, 2013 10:43:23 AM UTC+2, Jeremy Ruston wrote:

I'm not keen on giving the tab character special meanings within markup (other than classing it as whitespace), because it breaks the printability of wikitext source. Otherwise a virtue of wikitext is its explicitness (compared to MS Word with it's hidden paragraph markers that act as an anchor for formatting).

Actually, it's the other way around (unless I misunderstand you): Tab character was explicitly created to make tables. It is the de facto international standard to make tables. But maybe I do misunderstan you because I don't get what breakign the printability of wikitext source means - if you print source text then tab characters are printed as well, no?

 

The other problem is that it is hard to type a tab character on many systems (eg iphone, ipad).

Tru, altho pipe is also a bit iffy. This gives me ain idea for a plugin (which, if I could code...) - I've found that you, in edit mode, can include tab characters before the pipe sign and not have them show up in view mode. This makes it possible to create tables that are more easy on the eye in edit mode. A plugin could convert pipes into pipes+tabs on done'ing the tiddler so that the next time you open it in edit mode it includes tab characters! It could for instance use the header row as a template for cell width or perhaps use the "longest cell content" per column as template.
IF that stil would "break the printability of wikitext sournce", then maybe it's possible to store some local variable or array with column width that re-generates this display...in edit mode... (...if that is at all possible...)

 

Having said that, I'd definitely like to evolve an easier to type and read format for tables. MediaWiki lets tables be typed as a cell on each line, which I like a lot.

Interesting. Possibly a decent route - but still very much a compromise from a user perspective. It misses out on the very 2D essence of a table IMO.
 

As to handling the tab key on desktop browsers, my current thinking is that for the majority of users the simplest behaviour is for the tab key to always move between fields, and never to insert tab characters. As with TW classic, we'll need to provide some way for advanced users to insert tab characters when they want them.

Just a note here: In Cinta Notes, you jump between title, text and tags with tab key - but you can also get there directly with up/down arrow keys! Very convenient actually and it creates a more connected feeling between the fields. (Related: you can't tab key backwards.)

Keyboard shortcuts are moving up my list for TW5. My aim is to allow it to be entirely driven by the keyboard, and to allow a high degree of configurability by users. You will, for instance, be able to navigate the tag pills and their associated lists.

Interesting. I don't know how this navigation will be manifested, but again arrow keys for navigation may be worth considering as an option.

<:-)

[Leo Razoumov]

On Mon, Jul 22, 2013 at 4:43 AM, Jeremy Ruston <jeremy...@gmail.com> wrote:
> I'm not keen on giving the tab character special meanings within markup
> (other than classing it as whitespace), because it breaks the printability
> of wikitext source. Otherwise a virtue of wikitext is its explicitness
> (compared to MS Word with it's hidden paragraph markers that act as an
> anchor for formatting). The other problem is that it is hard to type a tab
> character on many systems (eg iphone, ipad).
>

+1.
Also there are people like me who prefer to edit large tidlers in external
editors (I use emacs launched via "It's all text" firefox addon).
For me tab character is just a type of whitespace and very often (as a
programmer)
my editors expand a tab into 4 spaces.

Please, do *not* give tab-char any special meaning!

--Leo--

[Jeremy Ruston]

Actually, it's the other way around (unless I misunderstand you): Tab character was explicitly created to make tables. It is the de facto international standard to make tables.

I don't think that the tab character is used in any of the popular markup languages. It's origin was more about aligning columns than tables: with tabs it's usual to have to include variable number of tabs after a cell to get to the next column, making them useless for parsing meaning.

 

But maybe I do misunderstan you because I don't get what breakign the printability of wikitext source means - if you print source text then tab characters are printed as well, no?

What I mean is that a <code> block containing sample wikitext source will not readably show the tab characters; nor would printing the wikitext source. That makes wikitext harder to teach and harder to learn.

We could work around it by displaying the tab character as a right arrow, or something, but that's not something that is supported by browser textareas out of the box.

 

The other problem is that it is hard to type a tab character on many systems (eg iphone, ipad).

Tru, altho pipe is also a bit iffy.

No, the tab character is impossible to type on an iPad; the pipe is just awkward. Huge difference.

 

 

Having said that, I'd definitely like to evolve an easier to type and read format for tables. MediaWiki lets tables be typed as a cell on each line, which I like a lot.

Interesting. Possibly a decent route - but still very much a compromise from a user perspective. It misses out on the very 2D essence of a table IMO.

It's the 2D essence of the table that gets awkward to type if you start to get word wrap. MediaWiki offers it's multiline syntax alongside an ordinary 2D syntax; you can use either.

 

As to handling the tab key on desktop browsers, my current thinking is that for the majority of users the simplest behaviour is for the tab key to always move between fields, and never to insert tab characters. As with TW classic, we'll need to provide some way for advanced users to insert tab characters when they want them.

Just a note here: In Cinta Notes, you jump between title, text and tags with tab key - but you can also get there directly with up/down arrow keys! Very convenient actually and it creates a more connected feeling between the fields. (Related: you can't tab key backwards.)

Keyboard shortcuts are moving up my list for TW5. My aim is to allow it to be entirely driven by the keyboard, and to allow a high degree of configurability by users. You will, for instance, be able to navigate the tag pills and their associated lists.

Interesting. I don't know how this navigation will be manifested, but again arrow keys for navigation may be worth considering as an option.

The plan is certainly to use the conventional keys for navigation.

Best wishes

Jeremy