A View Mode Editor and a simple Calcualtor

[Vincent Yeh]

Interested in editing your tiddler in the view mode in TiddlyWiki? Try this view mode editor plugin TWted (requires TWtid).

Interested in a calculator that supports (partially for now) Excel syntax in Tiddlywiki? Try the simple calculator plugin TWtcalc (requires TWtid).

These plugins are under active development. You are very welcome to give comments/suggestions/bug reports. :-)

The first versions of these plugins were TableEditor and TableCalculator, released in 2012/06/24, that only supported table editing in the view mode. Later they were extended constantly and then evolved into TWtable, TWted and TWtcalc (released 2012/10/19), still only supported table editing. Recently they were further extended to support view mode editing on most of the block elements (see below) in a tiddler, much more than just a table editor, so I decided to start a new thread for these plugins. You can find their earlier history in the old thread "Inline Editing of Tables" started by pepebe.

• TWtid v1.5.0 — The basis of the view mode tiddler editor TWted and simple calculator TWtcalc, including a table renderer.
  • Generalized the codes from TWtable 1.4.6, which works for tables only, to support most kinds of block elements, see descriptions for TWted below.
  • The included table renderer supports
    • scrolling for large tables,
    • multi-lined cell content (you can have a list in a table cell),
    • synchronization among all copies (transcluded and non-transcluded).
  • See TWtid for more details.
• TWted v1.5.0 — The view mode tiddler editor.
  • Edit block elements either in view mode (default) or in edit mode (option description "Active in view mode")
    • If in view mode, the default edit box remains the same;
    • if in edit mode, the view mode remains for viewing only.
      • The system default edit box can be brought up by double clicking in a no-element area (note that some elements are much wider than their content).
  • Works on most of the block elements:
    • Tables —
      • easy access to cell content for editing purposes
      • insertion/deletion of rows/columns
      • copy/cut/paste the cells/rows/columns
    • Lists — both kinds, * and # (corresponding to <UL> and <OL>), as many levels as TiddlyWiki supports;
    • Headers — ! ~ !!!!!!, corresponding to H1 ~ H6;
    • Blockquotes — three levels supported: >, >> and >>>;
    • Blockexamples — lines of text enclosed by two <<<;
    • Preformatted blocks — lines of text enclosed by two triple-braces.
  • A simple previewer to see the output as you are typing.
    • Option txtTWtedPreviewOpacity to change opacity of the previewer. Default to 0.9.
    • Option txtTWtedPreviewCaret to specify the caret symbol in the previewer. Default to the vertical line (|).
  • Edit tiddler title.
  • Two options offering three levels of automation in the editing behavior:
    • Two options:
      • chkTWtedCatTheMouse — Activate/Deactivate edit mode with mouse motion.
      • chkTWtedNoClick — Edit the cell content without clicking it.
    • Three levels of automation:
      • Manual: set both options to false. Click the 'E' button to start/stop editing the closest block element.
      • Half automated: set the 1st option to true and 2nd to false. In this level a table enters edit mode automatically when mouse is hovering over it while other block elements remain manual. 'E' button is hidden, need to lick within the block element (or the table cell) to edit.
      • Automated: set both options to true. Move the mouse over a block element or a table cell to edit. (Warning: this can be annoying in some cases!)
  • Keyboard navigation within the same type of elements.
    • Works with headers, list items, blockquotes and preformats.
    • Move list items, only list items for now, with Ctrl-up/down keys. This, however, only works within the same level at this moment, moving items across different levels will be supported in the future release.
  • Tables are synchronized between transcluded and non-transcluded copies, other block elements are not yet.
  • See TWted for more details.
• TWtcalc v0.7.7 — A simple calculator for TiddlyWiki.
  • Calculates over table cells. For example, if one puts =A1+A2 in the table cell A3, the content of A3 will be the sum of the numerical values in table cells A1 and A2.
  • Supports syntax similar to OpenOffice calc or Microsoft Excel.
  • Automatically adjusts cell reference upon copy-and-pasting.
  • Supports user defined functions written in Javascript. See TWtcalc--Defining your own functions for details.
  • See TWtcalc for a list of predefined functions and further details.

[Vincent Yeh]

Forgot to include the download links:

• TWtid v1.5.0: http://twtable.tiddlyspace.com/#TWtid.min
• TWted v1.5.0: http://twtable.tiddlyspace.com/#TWted.min
• TWtcalc v0.7.7: http://twtable.tiddlyspace.com/#TWtcalc.min

Have Fun!

Vincent

[G.J.Robert]

Hi Vincent,

This is so brilliant. I love the live preview block above the editing area.

Vincent Yeh於 2013年2月9日星期六UTC+8下午10時25分52秒寫道：

[Albert Riedinger]

Hi Vincent,

thank you for your wonderful plugin! It makes it easier to use TW with mobile devices especially with complex content.
I tested it with the AndTidWiki app on a Nexus 7 and I have found the following bugs:

* closing tiddlers with toolbar button or close button on tab (TiddlersBarPlugin) fails > only close others works, but it only closes one of the opened tiddlers at a time (Alpha 2 version doesn't show this behaviour)
* classic edit mode shows TWtid buttons > should be disabled

Furthermore I'd like to suggest some features or feature improvements:

* (!) possibility to edit ordinary text blocks with TWtid (by paragraph)
* (!) possibility to edit whole sections like with EditSectionsPlugin (tiddlytools)
* bigger buttons for touch devices (or is it possible to customize them with CSS? > how?)
* show if tiddler was changed with TWtid (maybe a marker in the tiddler title like the exclamation mark in TiddlersBarPlugin?)
* possibility to make a linebreak with enter key while editing inline elements without leaving edit mode (e.g. to insert a new list item)
* easier modifying plugin related CSS classes (maybe an own plugin stylesheet tiddler would make sense)

Hope that helps a bit. You have done a really great job so far. Keep up the good work!

Best wishes,
Albert

--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Vincent Yeh]

Robert,

Thanks for trying them. Please keep trying and send comments/suggestions/bug reports when you have some. :-)

Have Fun!

Vincent

[Vincent Yeh]

Albert,

On Tuesday, February 19, 2013 7:15:30 PM UTC+8, Albert Riedinger wrote:

Hi Vincent,

thank you for your wonderful plugin! It makes it easier to use TW with mobile devices especially with complex content.
I tested it with the AndTidWiki app on a Nexus 7 and I have found the following bugs:

* closing tiddlers with toolbar button or close button on tab (TiddlersBarPlugin) fails > only close others works, but it only closes one of the opened tiddlers at a time (Alpha 2 version doesn't show this behaviour)
* classic edit mode shows TWtid buttons > should be disabled

Thanks for finding the bugs, especially with Android system, the least tested system for these plugins. I will fix them as soon as I find time.

 

Furthermore I'd like to suggest some features or feature improvements:

* (!) possibility to edit ordinary text blocks with TWtid (by paragraph)

Yes, this is on the top of my ToDo list. The current status is that I can find the correct wiki text for a paragraph, but the way now TWted handles the edit box doesn't work for all paragraphs. I don't want to go into the details but to say that I am re-writing the codes to work for all paragraphs. Should be available soon.

 

* (!) possibility to edit whole sections like with EditSectionsPlugin (tiddlytools)

This should be possible when the above is done.

 

* bigger buttons for touch devices (or is it possible to customize them with CSS? > how?)

CSS is a good idea but I don't know how to handle them in the codes yet. If someone could offer me some hints, or even a template, that would be wonderful!

 

* show if tiddler was changed with TWtid (maybe a marker in the tiddler title like the exclamation mark in TiddlersBarPlugin?)

That can be done.

 

* possibility to make a linebreak with enter key while editing inline elements without leaving edit mode (e.g. to insert a new list item)

This is something I have been thinking about, especially with list items as you suggested. But there are quite some possibilities with list items and I need more time to figure a good way out to handle them.

 

* easier modifying plugin related CSS classes (maybe an own plugin stylesheet tiddler would make sense)

This is again a good idea but, like I mentioned above, I do not know how to handle styles sheets in the codes. :-(

 

Hope that helps a bit. You have done a really great job so far. Keep up the good work!

Thanks for the nice suggestions. :-)

 

Best wishes,
Albert

Have Fun!

Vincent

[Yakov]

Hi Vincent,

glad the development goes on. Could you specify what bug you was talking about in the WYSIWYG discussion? The "cursor in the preview" one?

First, I'd like to suggest some things which are not directly connected with the development:

* how about adding a simple startup message in the repository [1]? Instead of the default GettingStarted tiddler, add a breif intro about the plugins and links to them, so you don't need to attach the links each time and a visitor doesn't need to search

* it seems it's time to update the Descrition slices in both TWted/TWted.min and TWtid/TWtid.min (those are no longer about tables only)

* I think it's better to specify what version of TWtid TWted needs (the same, or not below, or.. you may specify this in the "Needs to have" slice)

* the metadata table of the plugins being cut (see the screenshot 1) don't make them look better; in addition, when one tries to grab the scrollbar, he or she mouseovers it and the table jumps into the edit mode, so scrollbar avoids being cought :) (see the screeshots 2-3, red dot is an approximate posision of the cursor)

** in fact, I didn't get how to avoid this cutting and would like to know; as I pointed before, such behavior shouldn't be default

Then some notes about the new version. In fact v1.5.0 got very buggy.

0. Online version works (there are some details, but that's not that important for now)

1. When I launch a TW v2.6.6 with TWtid.min/TWted.min v1.5.0, I get a blank screen (Opera 12.14, win7 x64)

2. When I launch a TW v2.6.6 with TWtid.min v1.5.0 with no TWted, the same story

3. The same story in FF 19 (both variants)

4. In another testing TW (2.6.5, with SharedTiddlersPlugin 1.5.0 -- when I disable it, I get blank screen) things "work", but there are numerous bugs (no backstage, C/E buttons positioned in wrong places so that no element can be actually edited, encoding problems with non-latin letters after saving/loading...)

Regarding the "WYSIWYG": aside the cursor, I can see that a link is previewed as a link when the cursor is outside its tiddlytext, previewed as [|[text|target]] when I get between "[[" or "]]" (!!) and parts of the "text" depending on the position otherwise (!). The (!!) part is very interesting behavior for a "WYSIWIG-like" way of editing, the (!), in contrast, is rather inconvenient.

The last note for today is this: can the plugin for inline editing be based on hijacking the wikifier [2] and formatters [3] (or only formatters)? It seems (although I don't understand the alrogrythm well) that hijacking

Wikifier.prototype.outputText

can help with editing plain text..

Best regards,

Yakov.

[1] http://twtable.tiddlyspace.com/

[2] https://github.com/TiddlyWiki/tiddlywiki/blob/master/js/Wikifier.js

[3] https://github.com/TiddlyWiki/tiddlywiki/blob/master/js/Formatter.js ,

    https://github.com/TiddlyWiki/tiddlywiki/blob/master/js/FormatterHelpers.js

[Yakov]

PS don't mind my mention of encoding problems, they have another origin.

четверг, 14 марта 2013 г., 1:31:09 UTC+4 пользователь Yakov написал:

[Vincent Yeh]

Hi, Yakov,

On Thursday, March 14, 2013 5:31:09 AM UTC+8, Yakov wrote:

Hi Vincent,

glad the development goes on. Could you specify what bug you was talking about in the WYSIWYG discussion? The "cursor in the preview" one?

The bug was fixed lately so no need to worry about it. However, for your information I'll put some words here to explain. In TWted the editbox adjusts its height as the user is typing, and, for reasons unknown to me, the adjustment requires (for some browsers) first setting its height to 0 to get the correct height of its content (see here if interested). In a recent coding time I accidentally removed some of the codes to set the correct height back, resulting in a zero-height editbox once I started to type. But the editbox still had the focus and received all the keystrokes, and the previewer was still working, so it looked like the previewer was responding to my typing, that gave me a feeling of W-G.

 

First, I'd like to suggest some things which are not directly connected with the development:

* how about adding a simple startup message in the repository [1]? Instead of the default GettingStarted tiddler, add a breif intro about the plugins and links to them, so you don't need to attach the links each time and a visitor doesn't need to search

* it seems it's time to update the Descrition slices in both TWted/TWted.min and TWtid/TWtid.min (those are no longer about tables only) 

* I think it's better to specify what version of TWtid TWted needs (the same, or not below, or.. you may specify this in the "Needs to have" slice)

* the metadata table of the plugins being cut (see the screenshot 1) don't make them look better; in addition, when one tries to grab the scrollbar, he or she mouseovers it and the table jumps into the edit mode, so scrollbar avoids being cought :) (see the screeshots 2-3, red dot is an approximate posision of the cursor)

** in fact, I didn't get how to avoid this cutting and would like to know; as I pointed before, such behavior shouldn't be default

Those are good suggestions. After releasing 1.5.1 I shall spend some time on the documentation.

 

Then some notes about the new version. In fact v1.5.0 got very buggy.

0. Online version works (there are some details, but that's not that important for now)

1. When I launch a TW v2.6.6 with TWtid.min/TWted.min v1.5.0, I get a blank screen (Opera 12.14, win7 x64)

2. When I launch a TW v2.6.6 with TWtid.min v1.5.0 with no TWted, the same story

3. The same story in FF 19 (both variants)

4. In another testing TW (2.6.5, with SharedTiddlersPlugin 1.5.0 -- when I disable it, I get blank screen) things "work", but there are numerous bugs (no backstage, C/E buttons positioned in wrong places so that no element can be actually edited, encoding problems with non-latin letters after saving/loading...)

Honestly I did not test 1.5.0 with Opera and FF so I didn't know about these. The not-yet-released 1.5.1 does not have such problems in my system. Maybe I fixed it somehow without knowing it? We'll see this soon.

Regarding the "WYSIWYG": aside the cursor, I can see that a link is previewed as a link when the cursor is outside its tiddlytext, previewed as [|[text|target]] when I get between "[[" or "]]" (!!) and parts of the "text" depending on the position otherwise (!). The (!!) part is very interesting behavior for a "WYSIWIG-like" way of editing, the (!), in contrast, is rather inconvenient.

I noticed this behavior. It was caused by the "fake cursor", default to the vertical bar (|), that I inserted to the caret position to mimic a cursor in the previewer. This certainly affects the wikilinks because the vertical bar is used to separate the label and URL of the link. I understand this fake cursor must be changed to something else, but I haven't found a better one yet. Any suggestions?

 

The last note for today is this: can the plugin for inline editing be based on hijacking the wikifier [2] and formatters [3] (or only formatters)? It seems (although I don't understand the alrogrythm well) that hijacking

Wikifier.prototype.outputText

can help with editing plain text..

Thanks for the note. Actually I tried this way when I was writing the grandpa TableEditor, but soon gave up and turned to hijacking refreshTiddler(). I couldn't quite understand the formatters, but it seemed to me that I would need to abandon the original and rewrite a new one to replace it (Am I right about this?). Hijacking the refreshTiddler() is easy to implement but the cost is "double rendering": table cells with multi-lined content are rendered twice, first by the system table formatter, then the table renderer in TWtid. Currently it doesn't seem to be a problem because it doesn't delay too much. However, to really avoid this I would suggest the table formatter to have a cell handler, which the TWtid can hijack to render the table cells with multi-lined content before they get rendered by the system formatter.

As for editing plain text in view mode, I am not sure hijacking the wikifier or formatter would help, because view mode editing is to catch some thing after it is rendered while hijacking the wikifier/formatter is to catch some thing before it is rendered. The main concern of view mode editing is not how it is rendered but how to find the corresponding wikitext after it is rendered. The problem I see is "plain text does not have a block element (such as <P> or <DIV>) and signature". TWted needs a block element and its signature to locate the correct wikitext for view mode editing. It relies on block elements because

1. a block element can have a clearly defined index number* in a rendered page, and
2. block elements have their "signature" in the wiki text.
1. For example, a list item is one line of text that starts with either (*) or (#), a heading is one line of text starting with (!), a table is defined by consecutive lines of text that start with (|), etc.

With those signatures and the index number of the block element, TWted can correctly locate the corresponding wiki text. See the [[How?]] section in the to-be-finished document if interested.

This approach works for block elements but fails on plain text in a tiddler. As mentioned above, plain text does not have a block element and plain text does not have a signature. It's just plain text. The solution implemented in TWted 1.5.1 is to "locate the block elements before and after the plain text", get the wiki text in between to edit. It works for a piece of plain text that does have one block element before and one after, such as a section text that is preceded by its own heading and followed by another heading (or any other kinds of block elements). I am left to deal with the situations with missing block elements, either one or both. Should be done soon.

* The index number used in TWted is the "order of appearance" of a block element "within its own type within the same tiddler". 

Thanks for your time and suggestions.

Have fun!

Vincent

[TonG]

Hi Vincent

I was busy with other things and didn't have time to test (meantime
using the v1.4.6 table editor).
So, after a long time I started testing the new versions (v1.5/0.7.7).

To be honest I only need the table editing feature. That feature makes
editing tables a breeze and I think it is worth to make a separate
plugin for that feature alone (I'am still using the "table-only"
version 1.4.6 daily).
I don't need the possibility of editing of other parts (on a PC with
large screen), but I can imagine other users do like it. For mobile
devices it is a different story (small screen).
In most of my TWs I installed Eric Shulman's Quick Edit package, but
after some time I noticed I used that package only for a few special
(custom defined) formats like an iFrame or an iFrame within a slider.
All other formatting (headers, lists, bold, ... and even some CSS
style wrapping) I do "by hand".

For testing (Windows 7, Firefox 19.02) I made a minimal test case
based on the new TW 2.7.1.
When I only added TWtid.min and TWted.min I only got a blank screen
after saving and reloading.
At first I thought it had something to do with the TW version, but
"older" TWs behaved the same.
Older versions of FF did not help either.
Since other browsers also showed a blank page, it wasn't a FF issue.
But I remembered seeing the the v1.5 plugins working (weeks ago I did
some preliminary testing).

When I added TWtid.min, TWted.min *AND* TWtcalc.min (v0.7.7) to an
empty TW everything worked as expected. After deleting TWtcalc.min the
blank page reappeared!
So there is a certain dependency between the plugins.
That wasn't the case with version 1.4.6; I use TWtid and TWted WITHOUT
TWtcalc!

A MTC with TWtid.min, TWted.min and TWtcalc.min did NOT show the
"backstage" button in the upper right corner.
I could go within the backstage with help of the "EnableEdit"
bookmarklet by Saq Imtiaz. It "repairs" the backstage/close buttons
during the session, but after reloading the TW the backstage button
doesn't show again.
With tables, headers and ordered/unordered lists I only see the "C"
button; no "E" button is visible although TWtid and TWted are enabled
and TWted is active in View mode (default settings).
I remember from preliminary testing I saw the "E" button and could do
some editing.
An older (v3.6) portable version of FF behaved the same: no backstage
button, no "E" button.
Chrome portable (v25) behaved the same as well: no backstage button,
no "E" button.

Another strange thing I noted in FF (NOT in Chrome):
----
!!!Ordered list
# item1
# item2
# item3
## item3.1
# item4
# item5
# item6
## item6.1
!!!Unordered list
* item1
* item2
* item3
** item3.1
----
Hovering over the block elements (in FF, v19 & v3.6) you see the "C"
button except for item3 and item6 in the ordered list and item3 in the
unordered list. In Chrome you see it everywhere.

I don't know what is happening; I can't even start testing.
My MTC can be found here [1]

Cheers,

Ton

[1] https://dl.dropbox.com/u/2638511/MTC_TWtid_TWted_TWtcalc.html

On Mar 15, 8:36 am, Vincent Yeh <qmo.w...@gmail.com> wrote:
> Hi, Yakov,
>
> On Thursday, March 14, 2013 5:31:09 AM UTC+8, Yakov wrote:
>
> > Hi Vincent,
>
> > glad the development goes on. Could you specify what bug you was talking
> > about in the WYSIWYG discussion? The "cursor in the preview" one?
>
> > The bug was fixed lately so no need to worry about it. However, for your
>
> information I'll put some words here to explain. In TWted the editbox
> adjusts its height as the user is typing, and, for reasons unknown to me,
> the adjustment requires (for some browsers) first setting its height to 0

> to get the correct height of its content (see here<http://twtable.tiddlyspace.com/#%5B%5BDynamic%20TextArea%20Height%5D%5D>if interested). In a recent coding time I accidentally removed some of the

> some thing *after* it is rendered while hijacking the wikifier/formatter is
> to catch some thing *before* it is rendered. The main concern of view mode

> editing is not how it is rendered but how to find the corresponding
> wikitext after it is rendered. The problem I see is "plain text does not
> have a block element (such as <P> or <DIV>) and signature". TWted needs a
> block element and its signature to locate the correct wikitext for view
> mode editing. It relies on block elements because
>

>    1. a block element can have a clearly defined index number* in a
>    rendered page, and
>    2. block elements have their "signature" in the wiki text.
>       1. For example, a list item is one line of text that starts with

>       either (*) or (#), a heading is one line of text starting with (!), a table
>       is defined by consecutive lines of text that start with (|), etc.
>
> With those signatures and the index number of the block element, TWted can
> correctly locate the corresponding wiki text. See the [[How?]] section in

> the to-be-finished document<http://twtable.tiddlyspace.com/#%5B%5BEditing%20wiki%20text%20in%20th...>if interested.

>
> This approach works for block elements but fails on plain text in a
> tiddler. As mentioned above, plain text does not have a block element and
> plain text does not have a signature. It's just plain text. The solution
> implemented in TWted 1.5.1 is to "locate the block elements before and
> after the plain text", get the wiki text in between to edit. It works for a
> piece of plain text that does have one block element before and one after,
> such as a section text that is preceded by its own heading and followed by
> another heading (or any other kinds of block elements). I am left to deal
> with the situations with missing block elements, either one or both. Should
> be done soon.
>
> * The index number used in TWted is the "order of appearance" of a block
> element "within its own type within the same tiddler".
>
> Thanks for your time and suggestions.
>
> Have fun!
> Vincent
>
>
>
>
>
>
>
> > Best regards,
> > Yakov.
>
> > [1]http://twtable.tiddlyspace.com/
> > [2]https://github.com/TiddlyWiki/tiddlywiki/blob/master/js/Wikifier.js
> > [3]https://github.com/TiddlyWiki/tiddlywiki/blob/master/js/Formatter.js,
>

> >https://github.com/TiddlyWiki/tiddlywiki/blob/master/js/FormatterHelp...

>
> >>> Am 09.02.2013 15:25 schrieb "Vincent Yeh" <qmo....@gmail.com>:
>
> >>>> Forgot to include the download links:
>

> >>>>    - TWtid v1.5.0:http://twtable.tiddlyspace.com/#TWtid.min
> >>>>    - TWted v1.5.0:http://twtable.tiddlyspace.com/#TWted.min
> >>>>    - TWtcalc v0.7.7:http://twtable.tiddlyspace.com/#TWtcalc.min

>
> >>>> Have Fun!
> >>>> Vincent
>
> >>>> On Saturday, February 9, 2013 10:21:03 PM UTC+8, Vincent Yeh wrote:
>
> >>>>> Interested in editing your tiddler in the view mode in TiddlyWiki? Try
> >>>>> this view mode editor plugin TWted (requires TWtid).
>
> >>>>> Interested in a calculator that supports (partially for now) Excel
> >>>>> syntax in Tiddlywiki? Try the simple calculator plugin TWtcalc (requires
> >>>>> TWtid).
>
> >>>>> These plugins are under active development. You are very welcome to
> >>>>> give comments/suggestions/bug reports. :-)
>
> >>>>> The first versions of these plugins were TableEditor and
> >>>>> TableCalculator, released in 2012/06/24, that only supported table editing
> >>>>> in the view mode. Later they were extended constantly and then evolved into
> >>>>> TWtable, TWted and TWtcalc (released 2012/10/19), still only supported
> >>>>> table editing. Recently they were further extended to support view mode
> >>>>> editing on most of the block elements (see below) in a tiddler, much more
> >>>>> than just a table editor, so I decided to start a new thread for these
> >>>>> plugins. You can find their earlier history in the old thread "Inline
> >>>>> Editing of Tables" started by pepebe.
>

> >>>>>    - TWtid v1.5.0 — The basis of the view mode tiddler editor TWted and

> >>>>>    simple calculator TWtcalc, including a table renderer.

> >>>>>       - Generalized the codes from TWtable 1.4.6, which works for

> >>>>>       tables only, to support most kinds of block elements, see descriptions for
> >>>>>       TWted below.

> >>>>>       - The included *table renderer* supports
> >>>>>          - scrolling for large tables,
> >>>>>          - multi-lined cell content (you can have a list in a table
> >>>>>          cell),...
>
> read more »

[Vincent Yeh]

Ton,

On Saturday, March 16, 2013 5:08:42 AM UTC+8, TonG wrote:

Hi Vincent

I was busy with other things and didn't have time to test (meantime
using the v1.4.6 table editor).
So, after a long time I started testing the new versions (v1.5/0.7.7).

To be honest I only need the table editing feature. That feature makes
editing tables a breeze and I think it is worth to make a separate
plugin for that feature alone (I'am still using the "table-only"
version 1.4.6 daily).

Good point! I also had this thought of code separation but for a different reason: they are too fat to be called "plugins"! I will start separating them after releasing 1.5.1/0.7.8. Also I will spend some time on the documentation as mentioned in my last reply to Yakov.

 

I don't need the possibility of editing of other parts (on a PC with
large screen), but I can imagine other users do like it. For mobile
devices it is a different story (small screen).
In most of my TWs I installed Eric Shulman's Quick Edit package, but
after some time I noticed I used that package only for a few special
(custom defined) formats like an iFrame or an iFrame within a slider.
All other formatting (headers, lists, bold, ... and even some CSS
style wrapping) I do "by hand".

For testing (Windows 7, Firefox 19.02) I made a minimal test case
based on the new TW 2.7.1.
When I only added TWtid.min and TWted.min I only got a blank screen
after saving and reloading.
At first I thought it had something to do with the TW version, but
"older" TWs behaved the same.
Older versions of FF did not help either.
Since other browsers also showed a blank page, it wasn't a FF issue.
But I remembered seeing the the v1.5 plugins working (weeks ago I did
some preliminary testing).

When I added TWtid.min, TWted.min *AND* TWtcalc.min (v0.7.7) to an
empty TW everything worked as expected. After deleting TWtcalc.min the
blank page reappeared!
So there is a certain dependency between the plugins.
That wasn't the case with version 1.4.6; I use TWtid and TWted WITHOUT
TWtcalc!

So this explains why I never had the problem of blank page, I always use TWtcalc. Now I have a clear direction where to look for the bug. Thanks a lot!

Thanks for the test case. Next week I shall find some time to have a look and fix them.

 

Have fun!

Vincent

[TonG]

Hi Vincent,

I saw new versions of your plugins (1.5.1/0.7.8) and tried these.
I did not expect a solution for my problems, so just an update of my
testing: They behave exactly the same as the previous ones
(v1.5.0/0.7.7):
* Blank page without TWtcalc (Win7 64-bit, FF 19, Chrome 25).
* No backstage button and E button with all 3 plugins installed (FF &
Chrome).
* Hovering over the block elements (in FF) you see the "C" button

except for item3 and item6 in the ordered list and item3 in the
unordered list. In Chrome you see it everywhere.

Glad to hear you want to make a separate table editor plugin.
Without your plugin(s), editing of (not to small) tables is a
nightmare. I'am using v1.4.6 daily and cannot imagine I succeeded
editing tables in the past without it :). It saves me a lot of time.

Cheers,

Ton

> > > wikifier or...
>
> read more »

[Yakov]

Hi Vincent,

 

Regarding the "WYSIWYG": aside the cursor, I can see that a link is previewed as a link when the cursor is outside its tiddlytext, previewed as [|[text|target]] when I get between "[[" or "]]" (!!) and parts of the "text" depending on the position otherwise (!). The (!!) part is very interesting behavior for a "WYSIWIG-like" way of editing, the (!), in contrast, is rather inconvenient.

I noticed this behavior. It was caused by the "fake cursor", default to the vertical bar (|), that I inserted to the caret position to mimic a cursor in the previewer. This certainly affects the wikilinks because the vertical bar is used to separate the label and URL of the link. I understand this fake cursor must be changed to something else, but I haven't found a better one yet. Any suggestions?

 

So, I specified the behaviour of the preview which I'd call desirable; now about the cursor.

* first, there's  text-decoration:blink;  CSS possibility which can improve the "cursor feeling", although (AFAIK) there's no possibility to change the frequency of the blinking (in Opera it is about twice less frequent than the frequency of the actual cursor blinking)

* second, cursor can be represented as a border of an element with 0 width. Not sure if there's any CSS method to make it blink, but this can be done via javascript+css

* blinking frequency can be changed if it is implemented via javascript + css in both cases

I'm rather surprised by the fact that cursor actually adds a symbol which gets wikified in the preview.. looks like the behaviour which I proposed is complicated in terms of implementation.

 

The last note for today is this: can the plugin for inline editing be based on hijacking the wikifier [2] and formatters [3] (or only formatters)? It seems (although I don't understand the alrogrythm well) that hijacking

Wikifier.prototype.outputText

can help with editing plain text..

Thanks for the note. Actually I tried this way when I was writing the grandpa TableEditor, but soon gave up and turned to hijacking refreshTiddler(). I couldn't quite understand the formatters, but it seemed to me that I would need to abandon the original and rewrite a new one to replace it (Am I right about this?). Hijacking the refreshTiddler() is easy to implement but the cost is "double rendering": table cells with multi-lined content are rendered twice, first by the system table formatter, then the table renderer in TWtid. Currently it doesn't seem to be a problem because it doesn't delay too much. However, to really avoid this I would suggest the table formatter to have a cell handler, which the TWtid can hijack to render the table cells with multi-lined content before they get rendered by the system formatter.

As for editing plain text in view mode, I am not sure hijacking the wikifier or formatter would help, because view mode editing is to catch some thing after it is rendered while hijacking the wikifier/formatter is to catch some thing before it is rendered. The main concern of view mode editing is not how it is rendered but how to find the corresponding wikitext after it is rendered. The problem I see is "plain text does not have a block element (such as <P> or

Here's a scheme which I keep in mind. It can be incorrect for some aspects of current wikifier implementation, but let me draw a picture first.

Let's consider an example:

Here's a text with some

> citation with @@highlightning@@

and then some more text.

What wikifier does? It goes:

$ wikify the whole thing (look for formatters' matches)

$ (located one citation and nothing more)

$ subwikify things before the citation as plain text

$ subwikify the citation

$$ (here the same recursive procedure will find the highlightning and wikify that)

$ subwikify things after the citation

so there's a tree-like algorythm doing the formatting. Formatters only do the "represent in html" thing. Wikifier doesn't get any "feedback" from formatters. AFAIK, wikifier is created on wikification and is forgotten afterwards.

Imagine now this situation:

* wikifier is created on wikification and is persistent for the represented wikified text

* it remembers the tree of subwikification, like

- plain ("Here's a text with some")

- citation

-- plain ("citation with ")

-- highlightning

--- plain ("highlightning")

- plain ("and then some more text.")

  and remembers the text corresponding to each part

* the function which adds text (Wikifier.outputText?) doesn't only create the text, but also adds an onclick handler to the containing element which creates the editor element etc and reports back to the wikifier when the corresponding part of the text (of the wikification tree) should be changed (and hence the wikitext too)

* formatters do some other work, for instance change behaviour of editing for list items (show "*"s in the beginning of the line) or add stuff like "move up/down" buttons

I won't write more details now so you can point the largest mistakes in this scheme, or difficulties in implementation or other things..

 

<DIV>) and signature". TWted needs a block element and its signature to locate the correct wikitext for view mode editing. It relies on block elements because

1. a block element can have a clearly defined index number* in a rendered page, and
2. block elements have their "signature" in the wiki text.
1. For example, a list item is one line of text that starts with either (*) or (#), a heading is one line of text starting with (!), a table is defined by consecutive lines of text that start with (|), etc.

With those signatures and the index number of the block element, TWted can correctly locate the corresponding wiki text. See the [[How?]] section in the to-be-finished document if interested.

So, as you can see, in my proposal these things are done via the "wikification tree". Though, I'm afraid that such hijacking of wikifier can be very labour-demanding (and in fact can turn into rewriting wikifier).

Best regards,

Yakov.

[Vincent Yeh]

TWtid v1.6.0 + TWted v1.6.0 + TWtcalc v0.8.0

There were quite some bug fixes and much improved transclusion support. Edits plain text in addition to block elements. Removed manual mode and flying C buttons, etc.

See release note at http://twtable.tiddlyspace.com/#%5B%5BRelease%20Note%20v1.6.0%2B0.8.0%5D%5D for details.

Please try the transclusion support and help find bugs or give suggestions. Thanks.

Have Fun!

Vincent

On Saturday, February 9, 2013 10:21:03 PM UTC+8, Vincent Yeh wrote:

[Vincent Yeh]

Two examples to try on:

1. transclusion support: http://twtable.tiddlyspace.com/#%5B%5BTransclusion%20support%5D%5D
   
2. general test case: http://twtable.tiddlyspace.com/#TWted--Example--BlockElements

Have Fun!

Vincent

[Arc Acorn]

Nothing seems to be editing in the right place in Firefox... 

Short video: https://docs.google.com/file/d/0B2aMm6viVRKGVFFoRUlvUnJyTVE/edit?usp=sharing

[Yakov]

Hi Vincent,

воскресенье, 14 апреля 2013 г., 14:11:02 UTC+4 пользователь Vincent Yeh написал:

TWtid v1.6.0 + TWted v1.6.0 + TWtcalc v0.8.0

There were quite some bug fixes and much improved transclusion support. Edits plain text in addition to block elements. Removed manual mode and flying C buttons, etc.

Indeed, backstage is back again and DefaultTiddlers are displayed. One small detail: second-level list items are displayed as

* item text

instead of

** item text

(in Opera) In FireFox I have this strange positioning issue like Arc does.

Great news that plain text is being conquered. But the situation of bugs/behaviour is complicated, so let me continue my post in a "follow-me" form.

First, I create a tiddler "New Tiddler" with the following 5 lines of content (in a TW with vanilla theme -- PageTemplate etc, only some additional CSS):

Beginning
* [[TWtid.min]] -- "wikitext manipulator"
* [[TWted.min]] -- "editor"
----
Some more text

As I click on the first list item, I get an edit area and a preview of the second one. If I edit it (say, change to "* [[TWted.min]] -- "editor"+") and press ctrl+enter, I get the first list item visually substituted with the wikified new text which was thought to be from the second item; but if I click "edit" and view the tiddler's text, it becomes clear that actually the second item was changed, and that's a problem of representation.

Next, let's remove the added "+", the text is back to initial.

Now I click one of the two list items again and start pressing the "down" key. The editor acts as if there were *three* list items: two copies of the second one and the first one; and the edit area and the preview for the first one are displayed on the left, under the "no tags" box; moreover, the preview area is grey as is the "no tags" box is.

Next step is trying to click the first line ("Beginning"). Instead of opening the first line, the editor opens actually the two first lines. That's not a bug, but an unexpected behavior.

Than, let's try to click the last two lines. The editor opens the whole text (the previewer behaves accordingly), but the height of the editor area is only two lines.

Finally, when I move the cursor so that the whole text is enclosed in the border and then click it, I get an editor area of 5 lines height which fits the whole text, and I can edit the whole text.

Now let me extend the tiddler. I add the sixth line:

* one more list item

and here more weird things can be found.

The behaviour is changed for two lines: 5th and 6th.

Clicking line 5 (or line 4 which is the same in terms of displayed borders or plain text pieces) shows now *empty* edit and preview areas.

For line 6, there's two details which makes its behaviour unusual. First, edit area doesn't contain "*" and preview area shows just text instead of a list item. Second, when the cursor in the edit area is one the left position (beginning of the text), preview looks normal; but if the cursor is in any other position, the text in the preview becomes aligned to the right.

Regarding transclusions.. I'll skip testing in my local TW since the behaviour is already very complicated. In the online version [1] in both Opera and FireFox I can't edit (clicking doesn't open the editor). Not sure what cookie should be set but it seems that all of them are set to what they are should be..

In conclusion, this version looks much better, but there's still much to fix/work on.

Best regards,

Yakov.

[1] http://twtable.tiddlyspace.com/#[[Transclusion%20support]]

[Vincent Yeh]

Arc,

The plugins disable editing when the tiddler is marked "readOnly" by TiddlyWiki. Maybe try it off line?

Vincent

[Vincent Yeh]

Yakov,

Thanks for the quick reply. What you found with the list items was possibly fixed in the version 1.6.1 just uploaded. I tried locally your example tiddler below with the latest FF 20.0.1 and Opera 12.15 over Win7 x64 and Win XP. It seemed the list item issues you mentioned here are gone. Please try again and let me know if there are more to fix. Thanks again.

Some of the issues, however, I never had before and now (see below). Maybe conflicting with some addons?

On Monday, April 15, 2013 6:54:15 AM UTC+8, Yakov wrote:

Hi Vincent,

воскресенье, 14 апреля 2013 г., 14:11:02 UTC+4 пользователь Vincent Yeh написал:

TWtid v1.6.0 + TWted v1.6.0 + TWtcalc v0.8.0

There were quite some bug fixes and much improved transclusion support. Edits plain text in addition to block elements. Removed manual mode and flying C buttons, etc.

Indeed, backstage is back again and DefaultTiddlers are displayed. One small detail: second-level list items are displayed as

* item text

instead of

** item text

I didn't have this issue, though. Not sure what was wrong.

 

(in Opera) In FireFox I have this strange positioning issue like Arc does.

I got the correct position both on- and off-line. Did you have the positioning issue with local files?

 

Great news that plain text is being conquered. But the situation of bugs/behaviour is complicated, so let me continue my post in a "follow-me" form.

First, I create a tiddler "New Tiddler" with the following 5 lines of content (in a TW with vanilla theme -- PageTemplate etc, only some additional CSS):

Beginning
* [[TWtid.min]] -- "wikitext manipulator"
* [[TWted.min]] -- "editor"
----
Some more text

As I click on the first list item, I get an edit area and a preview of the second one. If I edit it (say, change to "* [[TWted.min]] -- "editor"+") and press ctrl+enter, I get the first list item visually substituted with the wikified new text which was thought to be from the second item; but if I click "edit" and view the tiddler's text, it becomes clear that actually the second item was changed, and that's a problem of representation.

Next, let's remove the added "+", the text is back to initial.

Now I click one of the two list items again and start pressing the "down" key. The editor acts as if there were *three* list items: two copies of the second one and the first one; and the edit area and the preview for the first one are displayed on the left, under the "no tags" box; moreover, the preview area is grey as is the "no tags" box is.

Next step is trying to click the first line ("Beginning"). Instead of opening the first line, the editor opens actually the two first lines. That's not a bug, but an unexpected behavior.

Do you mean you see the editbox containing both

"Beginning"

and

"* [[TWtid.min]] -- "wikitext manipulator"?

I didn't notice this behavior and don't see it in 1.6.1, hopefully fixed somehow?

 

Than, let's try to click the last two lines. The editor opens the whole text (the previewer behaves accordingly), but the height of the editor area is only two lines.

As above.

 

Finally, when I move the cursor so that the whole text is enclosed in the border and then click it, I get an editor area of 5 lines height which fits the whole text, and I can edit the whole text.

This was intended. I thought it should be good if the tiddler was transcluded. In most cases the border is for showing "which part to edit". In others with "sub elements", such as sub lists, there is a new option chkTWtedIncludeSubs in 1.6.1 to tell the plugin whether to include the sub elements or not.

 

Now let me extend the tiddler. I add the sixth line:

* one more list item

and here more weird things can be found.

The behaviour is changed for two lines: 5th and 6th.

Clicking line 5 (or line 4 which is the same in terms of displayed borders or plain text pieces) shows now *empty* edit and preview areas.

Hopefully fixed in 1.6.1.

 

For line 6, there's two details which makes its behaviour unusual. First, edit area doesn't contain "*" and preview area shows just text instead of a list item. Second, when the cursor in the edit area is one the left position (beginning of the text), preview looks normal; but if the cursor is in any other position, the text in the preview becomes aligned to the right.

This seems related to the beginning "second level item" issue. But I never had this issue and the plugins do not remove any character from the text to edit, so not sure what was wrong yet.

 

Regarding transclusions.. I'll skip testing in my local TW since the behaviour is already very complicated. In the online version [1] in both Opera and FireFox I can't edit (clicking doesn't open the editor). Not sure what cookie should be set but it seems that all of them are set to what they are should be..

May be try it off-line? The plugins disable editing features when a tiddler is marked "readOnly" by TiddlyWiki. I guess this is why you can't edit on-line.

 

In conclusion, this version looks much better, but there's still much to fix/work on.

Thanks for the helping feedback! Please try 1.6.1 and see if the list item issues are really fixed.

 

Best regards,

Yakov.

[1] http://twtable.tiddlyspace.com/#[[Transclusion%20support]]

Have Fun!

Vincent

[Arc Acorn]

That test/video was done using an offline copy. 

I downloaded it using the big blue download button in the  Import/export backstage section of the "general test case" link if that helps any.

[Yakov]

Hi Vincent,

tested with all other plugins set off and then the same with versions 1.6.1: the behaviour is almost the same

понедельник, 15 апреля 2013 г., 6:10:02 UTC+4 пользователь Vincent Yeh написал:

Yakov,

Thanks for the quick reply. What you found with the list items was possibly fixed in the version 1.6.1 just uploaded. I tried locally your example tiddler below with the latest FF 20.0.1 and Opera 12.15 over Win7 x64 and Win XP. It seemed the list item issues you mentioned here are gone. Please try again and let me know if there are more to fix. Thanks again.

Some of the issues, however, I never had before and now (see below). Maybe conflicting with some addons?

On Monday, April 15, 2013 6:54:15 AM UTC+8, Yakov wrote:

Hi Vincent,

воскресенье, 14 апреля 2013 г., 14:11:02 UTC+4 пользователь Vincent Yeh написал:

TWtid v1.6.0 + TWted v1.6.0 + TWtcalc v0.8.0

There were quite some bug fixes and much improved transclusion support. Edits plain text in addition to block elements. Removed manual mode and flying C buttons, etc.

Indeed, backstage is back again and DefaultTiddlers are displayed. One small detail: second-level list items are displayed as

* item text

instead of

** item text

I didn't have this issue, though. Not sure what was wrong.

 

This one seems to be gone, or may be I even have mistaken because of the "wrong selection of a list item to edit" issue. Two "*" appear where they should be.

 

(in Opera) In FireFox I have this strange positioning issue like Arc does.

I got the correct position both on- and off-line. Did you have the positioning issue with local files?

 

I meant a local file, couldn't get any editor box online.

 

Great news that plain text is being conquered. But the situation of bugs/behaviour is complicated, so let me continue my post in a "follow-me" form.

First, I create a tiddler "New Tiddler" with the following 5 lines of content (in a TW with vanilla theme -- PageTemplate etc, only some additional CSS):

Beginning
* [[TWtid.min]] -- "wikitext manipulator"
* [[TWted.min]] -- "editor"
----
Some more text

As I click on the first list item, I get an edit area and a preview of the second one. If I edit it (say, change to "* [[TWted.min]] -- "editor"+") and press ctrl+enter, I get the first list item visually substituted with the wikified new text which was thought to be from the second item; but if I click "edit" and view the tiddler's text, it becomes clear that actually the second item was changed, and that's a problem of representation.

Next, let's remove the added "+", the text is back to initial.

Now I click one of the two list items again and start pressing the "down" key. The editor acts as if there were *three* list items: two copies of the second one and the first one; and the edit area and the preview for the first one are displayed on the left, under the "no tags" box; moreover, the preview area is grey as is the "no tags" box is.

Next step is trying to click the first line ("Beginning"). Instead of opening the first line, the editor opens actually the two first lines. That's not a bug, but an unexpected behavior.

Do you mean you see the editbox containing both

"Beginning"

and

"* [[TWtid.min]] -- "wikitext manipulator"?

Yes, right.

 

I didn't notice this behavior and don't see it in 1.6.1, hopefully fixed somehow?

This and all the issues below still present.. My assembly is TW 2.6.5 + Opera 12.15, win7 x64. (ok, retested in TW 2.6.6 as well, should I go 2.7.1 also?)

 

Than, let's try to click the last two lines. The editor opens the whole text (the previewer behaves accordingly), but the height of the editor area is only two lines.

As above.

 

Finally, when I move the cursor so that the whole text is enclosed in the border and then click it, I get an editor area of 5 lines height which fits the whole text, and I can edit the whole text.

This was intended. I thought it should be good if the tiddler was transcluded. In most cases the border is for showing "which part to edit". In others with "sub elements", such as sub lists, there is a new option chkTWtedIncludeSubs in 1.6.1 to tell the plugin whether to include the sub elements or not.

 

Yeah, sure, that's a good behaviour (actually by itself, even without transclusions), I just described what I see in different situations, that wasn't a "bug report".

 

Now let me extend the tiddler. I add the sixth line:

* one more list item

and here more weird things can be found.

The behaviour is changed for two lines: 5th and 6th.

Clicking line 5 (or line 4 which is the same in terms of displayed borders or plain text pieces) shows now *empty* edit and preview areas.

Hopefully fixed in 1.6.1.

 

For line 6, there's two details which makes its behaviour unusual. First, edit area doesn't contain "*" and preview area shows just text instead of a list item. Second, when the cursor in the edit area is one the left position (beginning of the text), preview looks normal; but if the cursor is in any other position, the text in the preview becomes aligned to the right.

This seems related to the beginning "second level item" issue. But I never had this issue and the plugins do not remove any character from the text to edit, so not sure what was wrong yet.

 

Regarding transclusions.. I'll skip testing in my local TW since the behaviour is already very complicated. In the online version [1] in both Opera and FireFox I can't edit (clicking doesn't open the editor). Not sure what cookie should be set but it seems that all of them are set to what they are should be..

May be try it off-line? The plugins disable editing features when a tiddler is marked "readOnly" by TiddlyWiki. I guess this is why you can't edit on-line.

Ok, grabbed the tiddlers from [1] to an offline TW 2.6.6. First, the behaviour of the transclusion macros (tiddler and tabs) when the included tiddler is missing has changed: instead of displaying blank space they appear red with the following error message:

Error while executing macro <<tiddler>>:
TypeError: Cannot convert 'b.tiddler' to object

When included tiddlers are present,

tabs macro:

wow! not only works, but works just fine with those lists etc. In all the tests I previously done in the "New Tiddler", editing within tabs works as expected. The only thing I noticed is this: when I write one-line text, say between lists:

...

* list item

some text

* one more item

...

I can't add an extra line in the text. When text is multi-line, enter adds linebreak, and ctrl+enter causes to exit editor with saving; when text is one line, enter causes editor-exiting and ctrl+enter doesn't do anything.

slider macro:

slider's (meta)behaviour is the best: when it's closed, I can edit the macro, when it's opened, I can edit the content. But it has some editor+preview positioning issues. For instance, change "Test 1"'s text to the following:

some wonderful things!
* one
* two
more
* and

and then try to click the first line in the opened slider (for me, it appeared near the bottom of the whole tiddler).

tiddler macro:

editor shows "<<tiddler 'Test 1'>>" instead of transcluded content.. at least when transcluded content is one-line. I haven't tested deeply, but when the content is changed to 5 lines (" some wonderful things! ..."), I can partially edit the content, but the behaviour has once again many issues.

 

 

In conclusion, this version looks much better, but there's still much to fix/work on.

Thanks for the helping feedback! Please try 1.6.1 and see if the list item issues are really fixed.

Could you please update the slices listed below in all the plugins? They're a bit confusing for me and should be more confusing for those who haven't much experience with TWted/TWtid:

* Description

* Needs to have

* if necessary, Core Version (by the way, I suspect that the "2.6.5." value can be wrongly interpreted by some engines; usually it is "2.6.5"

[TonG]

Hi Vincent,

Some initial testing with Win7 64-bit, FF v20.01, TW v2.71, TWtid/
TWted v1.60, TWtcalc v0.80

1) Cannot reach the backstage (backstage button not available) with
all 3 plugins "activated" (systemConfug tag)
Without the 3 plugins "active" the backstage button is there.
With only TWtid active the backstage button disappears

2) Example "Transclusion support" gives an error in all the
transclusion cases:
Error in macro <<tiddler>>
Error in macro <<slider>>
Error in macro <<tabs>>

Clicking on the error shows:

Error while executing macro <<tiddler>>:

TypeError: b.tiddler is null

After removing the systemConfig tag of all 3 plugins the "Transclusion
support" tiddler does not show errors anymore and works as expected:
everything is transcluded.
=================
Upgraded to TWtid/TWted v1.61
1) Disappearing backstage button remains.
2) No errors anymore in "Transclusion support" example.

I had a quick look at both examples. Most things seem to work.
I did notice the strange behavior with the example of Yakov:
-------------------

* [[TWtid.min]] -- "wikitext manipulator"
* [[TWted.min]] -- "editor"
----
Some more text

-------------------
I will test further and report.

Cheers,

Ton

> * *Description*
> ** **Needs to have* *
> *
> ** *if necessary, *Core Version* (by the way, I suspect that the "2.6.5."
> value can be wrongly interpreted by some engines; usually it is "2.6.5" *
> *
> *
> *

[Vincent Yeh]

Arc,

Yes it helped me understand the positioning problems. I will find a way to fix it. Thanks a lot.

Vincent

[Vincent Yeh]

TWtid v1.6.2 + TWted v1.6.2 + TWtcalc v0.8.1

Ark, Yakov, and Ton,

I think I had fixed the incorrect list item and incorrect positioning issues. Please check and see. The Error in macro <<tabs>>, <<slider>>, <<tiddler>> should be fixed too.

Also fixed some bugs in options panel and added support for IE 10.

See release note at http://twtable.tiddlyspace.com/#%5B%5BRelease%20Note%20v1.6.2%2B0.8.1%5D%5D for download links, test cases and other info.

Have fun!

Vincent

ps. There was a tiddler explaining the positioning issue made yesterday but now gone, possibly due to the recent hardware failure in TiddlySpace. Will make it again later.

[TonG]

Hi Vincent,

I think about replacing Table editor v1.4.6 (which I use daily) by
this version; it means I like this version very much.
Testing with Win7 64-bit, FF v20.01, TW v2.71, TWtid/TWted v1.62,
TWtcalc v0.81.
1) Backstage button visible again.
2) The list item is now correct.
3) Table editing works good.
Some - minor - points:
a) After e.g. row/column editing (insert/copy/paste rows/columns) you
cannot edit the cell contents directly; you need to leave the "table
area" and re-enter this area to enable cell editing again.
b) When using the arrow keys to go from one cell to another, there is
different behavior using "->" (step from cel to cell with content
selected) or "<-" (step first from character to character in a cell
and then to the other cell).
c) By disabling TWtid and TWted (no checkmarks in option panels) stops
editing possibility but leaves the area boundary marks of table and
block elements (an arbitrary viewer of my TW does not want to see
these).
In the "old" table only editor v1.4.6 I used Simon Baird's
ToggleTagPlugin to toggle the systemConfig tags to disable editing and
get rid of the H, C and E buttons.

Cheers,

Ton

On Apr 19, 6:46 am, Vincent Yeh <qmo.w...@gmail.com> wrote:
> TWtid v1.6.2 + TWted v1.6.2 + TWtcalc v0.8.1
>
> Ark, Yakov, and Ton,
>
> I think I had fixed the incorrect list item and incorrect positioning
> issues. Please check and see. The Error in macro <<tabs>>, <<slider>>,
> <<tiddler>> should be fixed too.
>
> Also fixed some bugs in options panel and added support for IE 10.
>

> See release note athttp://twtable.tiddlyspace.com/#%5B%5BRelease%20Note%20v1.6.2%2B0.8.1...for

> ...
>
> read more »

[Vincent Yeh]

Ton,

I am very glad that you like v1.6.2. I hope you will like v1.6.3 even more (because I do).

TWtid v1.6.3+TWted v1.6.3. (No changes made to TWtcalc 0.8.1)

Bug fixes for transclusion support, edit the macro command as well as the transcluded content (see http://twtable.tiddlyspace.com/#%5B%5BTransclusion%20support%5D%5D for details), better focusing border behavior, etc.

See release note athttp://http://twtable.tiddlyspace.com/#%5B%5BRelease%20Note%20v1.6.3%5D%5D 

download links, test cases and other info.

Have fun!

Vincent

[TonG]

Hi Vincent,

I am glad you disabled the focusing borders when TWtid has been disabled.
You are right, I like v1.6.3 even more :)
Unfortunately I can't use it (or v1.6.2) on a daily basis in my main TW.

The Viewmode Editor plugins work good in a MTC, but they don't work correctly in my main TW while Table Editor v1.4.6 does work correctly with the same TW.
The focusing borders, the edit box, the preview box and the 'table modyfying' box (< x >/CXP) are all shifted downwards (about 2.5 lines)
Two examples for a table are given in the screen shots, but the same downshift occurs with all block elements.
N.B. It is the same for v1.6.2 and v1.6.3
I suspected a plugin problem.

My main TW uses the following plugins:
DropDownMenuPlugin
GotoPlugin
ImageSizePlugin
ImportTiddlersPlugin
InlineJavascriptPlugin
ListFiltrPlugin
NestedSlidersPlugin
QuickEditPlugin
QuickNotePlugin
QuickOpenTagPlugin
RenameTagsPlugin
SaveAndReloadMacro
SearchOptionsPlugin
SimpleMessagePlugin
TWted.min
TWtid.min
TabEditPlugin
TableOfContentsPlugin
TableSortingPlugin_TB
TagSearchPlugin
TagsplorerMacro
TiddlerTweakerPlugin
TiddlersBarPluginMP
TiddlyFileImportr
ToggleTagPlugin
YourSearchPlugin

But when I disable all plugins - except TWtid and TWted - the downshift stays.
May be it has something to do with the layout of my TW (CSS stuff for fixed position of my Topmenu and Tiddlersbar).
I'll try to investigate it further.

Cheers,

Ton

[Vincent Yeh]

Ton,

You could be right about the positioning issue. I'll compare the layout of my TiddlySpace and local TiddlyWiki files to see what comes out. Thanks.

Vincent

[TonG]

Hi Vincent,

I think I know what happens in my main TW: it is the CSS stuff I use.
I wanted a fixed position for a topmenu and for the TiddlersBar. I use
this layout in other TWs as well, see e.g. my TW about the history of
the area I was born: http://www.tongerner.tk/. It is in Dutch but that
does not matter for the layout :)
To display the tiddlers correctly I shifted the displayArea downwards
and extended it to the left since there is no MainMenu anymore:
------
#displayArea {
margin: 1em 15.5em 0em 1em;
position: relative;
top:54px;
left:0px;
}
------
That worked great until I tried the View Mode Editor v1.62/1.63 :)
With that I got the shift mentioned in my last post.
After some thinking and experimenting I got it working (with View Mode
Editor) by splitting things up:
------
#displayArea {
margin: 1em 15.5em 0em 1em;
}
------
and
------
.tiddler {
position: relative;
top:54px;
left:0px;
}
------
The focusing borders are now correct in my main TW, but I noticed some
strange things:

1) I cannot edit the Title of the tiddler. It works in a MTC, but not
in my main TW.
The following is in the StyleSheet of my main TW and I suspected the
text-shadow.
------
.title {
font-size: 2em;
font-weight:bold;
color: [[ColorPalette::PrimaryMid]];
text-shadow: 2px 2px 4px #999;
padding-bottom: 6px;
}
------
To my surprise it is the font-size in 'em' that is problematic; a font-
size in 'pt' does work!

2) With he the View Mode Editor v1.63 enabled in a MTC there are
focusing borders around tables and block elements but also around the
tags, but not around the tag box (surrounding the tags) and also not
around the toolbar area.
After disabling the plugin, all focusing borders are gone.

With he the View Mode Editor v1.63 enabled in my main TW there are
focusing borders around tables and block elements but also around the
tags, around the tag box and around the toolbar area.
After disabling the plugin, all focusing borders remain; only editing
is not possible!

Anyway, from now on I'm using v1.63 in my main TW :)

Cheers,

Ton

> ...
>
> read more »

[Vincent Yeh]

Ton,

Thanks for sharing the CSS settings and how you fixed the problem. That gave me a hint of a possible cause to the positioning issue. I found that position: relative; setting in #displayArea was causing the trouble. I played with it a little bit and realized that only position: static or NO positioning setting at all would give the correct offset. I had fixed it in my latest development snapshot and will release it in a few days (with some other fixes).

I do not have the title issue (with your settings and font-size in em). It all worked for me. There could be something else?

Thanks again for sharing the information. It helped me fix one problem.

Have fun!

Vincent

[Yakov]

Hi Vincent,

versions 1.6.3 definitely work much better. Would you mind to change the Description/Core Version/Needs to have slices in the .min versions of the plugins too?

No "extra list items", no strange things with the first list item and many more things got better. Now I can edit both translcusion macro and transcluded content for each of tiddler/slider/tabs, although for tiddler I can do that only with some more text in the edit box (not just <<tiddler ..>>, but also text before and after).

Now a couple of error messages. My "New Tiddler 1" contains the same stuff as in the previous tests, from your site:

------------------------------

@@color:blue;The plugins disable editing features if the tiddler is marked ''readOnly'' by ~TiddlyWiki. You may need to copy it off-line to try.@@

Try change the content in one of the transcluded tiddlers. In this test case changes are synchronized among all copies.
!! {{{<<tiddler>>}}} transcluded
<<tiddler 'Test 1'>>
!! {{{<<slider>>}}} transcluded
<<slider '' 'Test 1' 'Test 1'>>
!! {{{<<tabs>>}}} transcluded
<<tabs ''
'Tab1' '' 'Test 1'
'Tab2' '' 'Test 2'
>>

------------------------------

"Test 1" contains

------------------------------

some wonderful things!
* one
* two
more
* and

------------------------------

and "Test 2":

------------------------------

more interesting things..
Let's try lists:
* item one
* item two
and then more text
* one more item

------------------------------

Now let's go to the "New Tiddler 1":

there's a position of the cursor that allows to open the text of the whole <<tiddler>> transclusion. But if I mouseover the "more" line and click, I get this message:

...

Message: Plain text starts at 0 after LI[text:( two)], ends at -2 before LI[text:( and)] in tiddler <New Tiddler 1>

...

Another one appears if I click the "more" line in the <<tabs>> translcusion:

Message: Plain text starts at 2 after LI[text:()], ends at 0 before LI[text:()] in tiddler <Test 1>

Nothing like that, however, happens when I click "more" line in the <<slider>> transclusion.

I took a look at the old tests of table editing. This one contains some tiny issues:

---------------------

!!!!Section
|со слитыми ячейками|c
|h-cell1|>|h-cell2|h
|c11+|c12|c13|
|~|c22|c23|

|с отсутствующими ячейками|c
|h-cell1|h-cell2|h
|c11|c12|
|c21|
!!!!!!end

|двигаем столбцы|c
||h-cell1|h-cell2||h
|c13|c11|c12|c14|
|c34|c21|c22|c24|
[[тестируемая вставка]]
----
тесты вставки:
<<tiddler [[test 3##Section]]>>

---------------------

First, try navigation via arrows in the first table. If you try up/down in c12, c13, c22 and c23, you'll probably get some strange behaviour (diagonal and other jumping).

In the second table, you can edit the missing cell by direct clicking on it, but can't reach it by arrows from other cells.

In the third one, you can find an "escaping caption" fun :) just mouseover the table and don't stop it -- when I move cursor being over the table, caption goes more and more to the right.

I think that's all for now.

Best regards,

Yakov.

пятница, 26 апреля 2013 г., 17:29:58 UTC+4 пользователь Vincent Yeh написал:

[Vincent Yeh]

Yakov,

Thanks for testing the plugins. The "more" thing is not taken care of yet, and the keyboard navigation issues are still there (for a while already). They will be addressed in the future. Currently I am writing some documentation and preparing to separate the large table support (scrolling of table body, fixed rows/cols, etc.) to reduce the plugin size a bit.

Well, I thought I would separate the "other" part of codes so there is one version for tables only. But soon I realized that was impractical since all editing features share the same core codes. To make one for tables only needs to duplicate the core codes, which does not really help much in reducing the plugin size. Separating the large table support, however, could reduce a noticeable amount of codes, I think, since this part is outside of the core of the plugins.

The version 1.6.4 is mainly on fixing the positioning issue, and some restructuring for the separation of large table support.

See release note athttp://http://twtable.tiddlyspace.com/#%5B%5BRelease%20Note%20v1.6.4%5D%5D 

download links, test cases and other info.

Have fun!

Vincent

p.s. By the way, what do you suggest to change in the plugin information? I have not much idea of what that part should be. Or you can give me some reference?

[Yakov]

Hi,

суббота, 4 мая 2013 г., 20:36:15 UTC+4 пользователь Vincent Yeh написал:

Yakov,

Thanks for testing the plugins. The "more" thing is not taken care of yet, and the keyboard navigation issues are still there (for a while already). They will be addressed in the future. Currently I am writing some documentation and preparing to separate the large table support (scrolling of table body, fixed rows/cols, etc.) to reduce the plugin size a bit.

Well, I thought I would separate the "other" part of codes so there is one version for tables only. But soon I realized that was impractical since all editing features share the same core codes. To make one for tables only needs to duplicate the core codes, which does not really help much in reducing the plugin size. Separating the large table support, however, could reduce a noticeable amount of codes, I think, since this part is outside of the core of the plugins.

The version 1.6.4 is mainly on fixing the positioning issue, and some restructuring for the separation of large table support.

See release note athttp://http://twtable.tiddlyspace.com/#%5B%5BRelease%20Note%20v1.6.4%5D%5D 
download links, test cases and other info.

Have fun!

Vincent

p.s. By the way, what do you suggest to change in the plugin information? I have not much idea of what that part should be. Or you can give me some reference?

Well, TWtid.min has Core Version slice with a value "2.6.5." while it should be CoreVersion with a value "2.6.5"; TWted.min has the Description slice with a value "In-place edit table cells while in TWted you've already changed it to "In-place view mode editor". The same story about Core Version as in TWtid.min is in TWted.min and, by the way, wrong name "Core Version" is used in the TWted and TWtid as well. Finally, TWted.min contains "Needs to have" with an outdated "TWtable" value.

Note: it may be of interest to take a look at the "plugin registration" codes [1], so that you'll know what slices are used by the core.

Other than that, I still recomment to add something helpful to the "GettingStarted" tiddler (or even change the contents of the DefaultTiddlers), -- it's good when your repository has a "starting page" (starting tiddler(s)).

Best regards,

Yakov.

[1] https://github.com/TiddlyWiki/tiddlywiki/blob/master/js/main.js#L141 plus try searching main.js for "loadPlugins"

PS I'll check out the 1.6.4 version some time later (or may be will try the next version).

[TonG]

Hi Vincent,

An update about not being able to edit the title of a tiddler in my main TW:
1) I found the size of the font is important. I can edit the title for a font-size up to and including 1.98em. From 1.99em upwards it is not possible anymore (TWtid/TWtedv1.63).
2) In my main TW I use a modified ViewTemplate with divs for classes tagging, tagged and tagClear between divs toolbar and title. But with a default ViewTemplate the problem stays.
3) In a MTC with TWtid and TWted v1.63 I can edit the title even with a font-size of 10em!
4) With TWtid/TWted v1.64 in my main TW I can edit the title for a font-size up to and including 2.54em. From 2.55em upwards it is not possible anymore.
No idea why.
I made a MTC with topmenus. modified ViewTemplate and with TWtid/TWted v1.64 [1] which has the "title problem": I can edit the title for a font-size up to and including 2.54em. From 2.55em upwards it is not possible anymore.
The font-size for the title is at the top of the StyleSheet.

N.B. With plugins v1.64 there is no "shift" in an old "unmodified" main TW (#displayArea, .tiddler as was in the past), so your solution for the positioning issue works.

Cheers,

Ton

[1] https://dl.dropboxusercontent.com/u/2638511/MTC_TW_271_TWed_164_topmenu.html

[Vincent Yeh]

Ton,

Thanks for the MTC file. It helped me realize how the font-size issue came up. It was caused by some test codes that I tried randomly when I had no idea what caused the position shift in TiddlySpace. I did those tests quite a while ago and forgot to remove them after fixing the positioning issue with your help. After removing them this font-size issue seems gone. It will be in the next release. Thanks again.

By the way, v1.6.4 is quite buggy as I had found and fixed some of them yesterday. It is so because I am still midway to separate large table support. I would suggest to stay with 1.6.3 for now if it worked out for you.

Have fun!

Vincent

[Vincent Yeh]

TWtid v2.0.0 + TWted v2.0.0 + TWtable v2.0.0 + TWtcalc v1.0.0

Major changes to the plugins:

1. Introduced a class TWElement for easy access to wiki text of block elements. It will be fully available in the next release and for now you can try it in your own plugins if suitable. It is very easy to use. See http://twtable.tiddlyspace.com/#TWElement for a short description.
2. Rewrote core codes in a character-based manner (previously was line-based), for possibilites of in-line element access in the future releases.

Find more info and the download links in http://twtable.tiddlyspace.com/#%5B%5BRelease%20Note%20v2.0.0%5D%5D.

Have fun!

Vincent

[Vincent Yeh]

As I was enjoying using the new version at work today, quite some bugs showed up and got fixed, quite enough to have a bug-fix release.

TWtid v2.0.1 + TWted v2.0.1 + TWtable v2.0.1 + TWtcalc v1.0.1

Download links at http://twtable.tiddlyspace.com/#%5B%5BRelease%20Note%20v2.0.1%5D%5D

These versions v2.0.x were largely rewritten in the core codes, compared to previously versions, mainly for

1. in-line element editing capabilities in the future, and
2. the TWElement class for easy access to wiki text on the fly.
   

The original intention to reduce plugin size was dropped because the above two features are far more interesting to me, although large table support was indeed separated to TWtable.

With these plugins you can easily edit, and then save and synchronize, in the view mode, almost all the content in your tiddler, including

1. plain text
2. block elements (tables, lists, headers, blockquotes, pre-formatted blocks)
3. inline elements (not yet complete but soon, strong, italic, underlined, super-/sub-scripts, and @@css-style; some text here@@ ...)
4. transcluded/folded content, either fully or partially,
1. tiddler content transcluded with system macros <<tiddler>>, <<slider>>, and <<tabs>>,
2. section content folded with <<foldHeadings>> macro.
5. Multiply transcluded/folded copies are synchronized in the wrapper (container) level, meaning if you edit the whole content in the transcluded/folded wrapper, then your saved content will be synchronized for all transcluded/folded copies. If you edit one of the elements contained in those wrappers, however, only that element gets refreshed and other copies do not. Element level synchronization is close to finish and shall be available in the next one or two releases.
   

For plugin developers interested in manipulating the wiki text on the fly, please try the TWElement class and tell me how you think. Thanks.

Have Fun!

Vincent

[Yakov]

Hi Vincent,

great stuff, nice that the wrong-heading-to-edit bug is already fixed in 2.0.1. I've got one issue, though: can't get a whole tiddler get "inline-edited" (and, by the way, double-clicking contents of a tiddler doesn't bring the edit mode). At the same time, still #tiddlerDisplay area shows the border when the cursor is in some positions. Also, I suggest to equip "TableEditor" wikiwords in the "Data" slices of TWtid and TWted with "~" so that less "missing" links appear. And probably do the same in the "Licence" slices of all the plugins, for "TiddlyWiki" wikiword. Finally, let me remind the "missing cell issue": in table like this

|c11|c12|
|c21|

one can't get into the missing cell navigating with arrows which is a bit uncomfortable.

Nice to hear that the developing is going on!

Best regards,
Yakov.

понедельник, 3 июня 2013 г., 17:04:00 UTC+4 пользователь Vincent Yeh написал:

[Vincent Yeh]

Yakov,

Thanks for the comments. The inline editing feature is not complete yet and the development will go on after I finish the element level synchronization.

These days I've got a few more bug fixes and improved keyboard navigation to include missing cells. You might be interested to try.

TWtid v2.0.2 + TWted v2.0.2 + TWtcalc v1.0.2

See release note for download links.

Have Fun!

Vincent

[Yakov]

Hi Vincent,

 

These days I've got a few more bug fixes and improved keyboard navigation to include missing cells. You might be interested to try.

Now editing this table:

|с отсутствующими ячейками|c
|h-cell1|h-cell2|h
|c11|c12|
|c21|

works fine (I enter the missing with arrows and editing works as expected). However, more complicated test

|с отсутствующими ячейками|c
|h-cell1|h-cell2|..|h
|c11|c12|..|
|c21|
la-la-la

brings some issues. They are rather complicated to replicate (especially if there's more complicated content instead "la-la-la" and before the table). But let me point one simple example:

1. Enter the cell c21.
2. Move to the missing c22 using "right" arrow.
3. Add a dot to the c22 (so that content is ".").
4. Move to the right again (this will require two presses of "right").
5. Move to the right again (getting into c21) -- its content is shown as empty.
6. Move to the right yet again (into c22) -- its content is shown as the captioin of the table.
* I haven't tested what happens if the cells are edited on steps 5. and 6. which you can do for further inverstigation.

Another thing is once I start navigating with arrows, I tend to move the cursor outside the table which stops the editing mode. I'd propose to change this behaviour.. (once navigation with arrows started, leaving of the edit mode should be done by pressing ctrl+enter or esc only)

As for editing the whole tiddler contents, it works now.

I think that's all for now.

Best regards,
Yakov.
 

TWtid v2.0.2 + TWted v2.0.2 + TWtcalc v1.0.2

[Vincent Yeh]

Yakov,

On Friday, June 14, 2013 5:41:45 AM UTC+8, Yakov wrote:

Hi Vincent,
 

These days I've got a few more bug fixes and improved keyboard navigation to include missing cells. You might be interested to try.

Now editing this table:

|с отсутствующими ячейками|c
|h-cell1|h-cell2|h
|c11|c12|
|c21|

works fine (I enter the missing with arrows and editing works as expected). However, more complicated test

That's great!

 

|с отсутствующими ячейками|c
|h-cell1|h-cell2|..|h
|c11|c12|..|
|c21|
la-la-la

I thought of such situations while coding, but figured it too complicated and decided to leave it later. I can find time to work on this next month.

 

brings some issues. They are rather complicated to replicate (especially if there's more complicated content instead "la-la-la" and before the table). But let me point one simple example:

1. Enter the cell c21.
2. Move to the missing c22 using "right" arrow.
3. Add a dot to the c22 (so that content is ".").
4. Move to the right again (this will require two presses of "right").
5. Move to the right again (getting into c21) -- its content is shown as empty.
6. Move to the right yet again (into c22) -- its content is shown as the captioin of the table.
* I haven't tested what happens if the cells are edited on steps 5. and 6. which you can do for further inverstigation.

Another thing is once I start navigating with arrows, I tend to move the cursor outside the table which stops the editing mode. I'd propose to change this behaviour.. (once navigation with arrows started, leaving of the edit mode should be done by pressing ctrl+enter or esc only)

 

That's a good idea. Thanks for the suggestion. It'll be done some time next month.

Have Fun!

Vincent

[Vincent Yeh]

TWtid v2.0.3 + TWted v2.0.3 + TWtcalc v1.0.3 + TWtable v2.0.3

Main thing is element level synchronization, plus bug fixes. See release note http://twtable.tiddlyspace.com/#%5B%5BRelease%20Note%20v2.0.3%5D%5D

Have fun!

[Vincent Yeh]

TWtid v2.0.4 + TWted v2.0.4 + TWtcalc v1.0.4 + TWtable v2.0.4

Mainly bug fixes for table resizing and issues with TableSortingPlugin, SortableGridPlugin, and FoldHeadingPlugin.

For download links and more descriptions please see release note at http://twtable.tiddlyspace.com/#%5B%5BRelease%20Note%20v2.0.4%5D%5D.

Have fun!

Vincent

[Arc Acorn]

I don't see this ability in TWtid/TWted but is it possible, or will it ever be possible to have it disabled/inactive on startup, and than use a view mode toolbar command or such to enable it when needed?

[Vincent Yeh]

Arc,

Yes that is possible and I will start thinking of it as soon as I have time. Thank you for the idea that I never thought of.

Have fun!

Vincent

[Vincent Yeh]

TWtid v2.0.5 + TWted v2.0.5 + TWtcalc v1.0.5 + TWtable v2.0.5

Bug fixes for table scrolling and keyboard navigation.

For download links and more descriptions please see release note at http://twtable.tiddlyspace.com/#%5B%5BRelease%20Note%20v2.0.5%5D%5D.

Arc your suggestion shall be postponed to next release for I found some other changes are needed together to accomplish it.

Have fun!

Vincent

[Yakov]

Hi Vincent,

I will have time for further considerate testing after 9th of August, but I'd like to suggest one more idea which can inspire WYSIWYG-like approach.

The idea is simple: the "cursor" is already somewhat implemented in the preview; but what about implementing selection?

Best regards,
Yakov.

вторник, 30 июля 2013 г., 19:21:18 UTC+4 пользователь Vincent Yeh написал:

[Vincent Yeh]

Yakov,

 

Thank you very much for your always helping efforts!

The idea of selection is indeed one step closer to the WYSIWYG situation, I will certainly think about it. Thanks again.

 

Vincent

[Yakov]

Hello Vincent,

any new achievements so far? Any success with the "selection" idea?

I have finally updated all my TWs to 2.6.5+, so no problems in real-life tesing is expected now. I have refactored all the tests into a somewhat consistent sequence, so let me list all the current issues again (probably that won't be bad for the "bird's-eye-view"). I'd like to highlight the last part, about MathJax, which is very important for me and I'll be very thankful if you solve the main issue about it. So, let's start.

[TWtid/TWted/TWtable 2.0.5 + TW 2.6.5 with STP 2.4.0 + Opera 12.16 + Win7 x64]

0. Separate bugs/notes/questions

0.1 Is the chkTWtedEditAllTables option outdated? It seems that tables are all editable even if the checkbox is unchecked.
0.2 The "i-show-the-element-to-edit-on-click-here" border still appears around the displayArea (id=tiddlerDisplay) and elements with the tagged, tagging classes [which is not desirable]
0.3 If TWted is not launched, but TWtid is (with or without TWtable), backstage is not displayed and on start no tiddlers (from DefaultTiddlers) is displayed

1. Editing simple text

1.1 bug: if the [makrdown] text contains an html-entity (special symbol notation, say &sect;), when I enter the inline editor, it is turned to its "html output", namely §. Although it's a semi-feature (in many cases it just improves the readability), in some cases it's not desirable: if I write an example like this: {{{&sect;}}} → {{{§}}} , after such a transformation I get {{{§}}} → {{{§}}} which is not good.
1.2 the previewer still doesn't work well with long texts because if one starts editing its beginning, the preview of it is above the top end of the screen. Desired behaviour is to cut the previewer and make it autoscroll. Is it the position of the cursor in the previewer which is difficult to grab? I can suggest some solutions on this, but of'course it all depends on the implentation.
1.3 the previewer shows the content in a different styling, as if it was in the SideBar -- this causes, for instant, displaying quotes with simple indents and buttons from macros like <<tag>> not very notable

2. Editing lists

editing of list items that already exist works fine, deleting them is simple and changing the "order" (number of *) of a list item is easy, but there are several issues, too:
2.1 no way to edit new list items (aside editing the whote text). For non-touchscreen devices that could work fine by pressing ctrl+enter
2.2 no way to move list items up and down (although one can copy-paste the content from one list item to another and vise versa, that's not fast..). Could work with alt+up/down
2.3 for list item like this two:

* text{{jD{
some content, like with
> citation
}}} some text after
* text +++[nested slider]
see NestedSlidersPlugin at TiddlyTools
=== some text after

it is only possible to edit the first line, although the list item is somposed from the three lines in each case.. (I use such syntax regularly, that's why I mention this complex example)

3. Editing tables

I haven't refactored all the tests here, but let's start from some issues anyway:

3.1 a single cell is not styled correctly: somewhy it gets "bad" width and sometimes occupies more lines then it's expected. Try this one:

|single cell|

for me, the right border is too much to the right; and this one

|single cell single cell single cell single cell|

occupies two lines (an ordinary monitor, not mobile); without TWted this behaviour disappears.

3.2 I still miss the "move colomn left/right" buttons, would be very nice to have them
3.3 Missing cells after other missing ones are not editable (cases like this:

|a|b|c|
|d|
|e|f|

), but I must admit, there's a workaround: edit the cell after d, then the one next to it, then clear the first one (although that's not very handy).

4. Editing translcuded content

Almost everything is ideal here (I haven't tested the transclusions from the same tiddler, though). The only things are:

4.1 when transcluding with the <<tiddler>> macro, I can edit the transcluded content, but can't edit the macro itself
4.2 There's a bug which I failed to create a separate simple example for; because of this, I attach a slightly modified TW where I test most of the InlineEditing stuff (I removed all the other plugins). To get the bug, you'll need to click the "test" button in the tiddler "InlineEditingPluginHere", choose the "4 Transclusions ..." and in the opened tiddler to mouseover the first table and then move the mouse away. What I get is the whole content of the tiddler is "compressed" by half. May be this is connected with the "wrong table widths" bug (3.1).

5. Complex content

5.1 "One-line" text blocks (without linebreaks \n) in some surrounding, like

* list item
text block
* list item

can't be made "multiline": each enter, ctrl+enter and shift+enter causes exiting the edit mode instead of adding a new line.

5.2 Navigation with arrows is a desirable feature: now it's impossible even to jump between different text blocks with arrow keyboard buttons (which is possible for list items), and ideally it should be possible to.. well, navigate like in some office app -- in the example from 5.1 to jump from the first list item to the text block by pressing "down", the same for jumping from the latter to the next list item etc.

6 Using with MathJax and rewikification

What MathJax (a library that creates math formulae using LaTeX syntax) makes different is the speed of wikification: processing long formulae may take several seconds. Current implementation (see below) adds a number of formatters and hijacks wikify so that original wikify is used first, and the math typesetting is applied to the whole text afterwards. This can be changed to applying typesetting by formatters themselves for each formulae, although I haven't tested performance of such implementation yet.

6.1 The main issue is rewikification. When a symbol is added/removed or cursor is moved (and the "l" symbol is, hence, added in another place), the whole content is wikified again (in the previewer). This makes previewer almost useless once a big formula is added. In the archive [1] you may find an example (the "elder" folder contains MathJax and a copy of "mainstream" PluginMathJax; in the main test file "InlineEditingPlugins + MathJax test.html" there's TwFormulaePlugin which isn't much different from PluginMathJax 1.3). To see how it works, open "InlineEditingPlugins + MathJax test.html", click "tests", open "6 Extras: MathJax tests". Then, copy the first line to another tiddler and play with it -- works fine. Then, copy the part before "=================", try it again and see the difference (in performance of the previewer). Finally, see the whole tiddler "6 Extras: MathJax tests", try to edit the whole content with the previewer: as some formulae are big, you won't see any preview of them while editing.

The question is -- can this behaviour be changed so that only parts of wikitext that are changed are rewikified? Another way to improve the situation is to make rewikification "inertial": add a parameter txtDelayRewikificationMilliseconds which defines a minimal time gap between rewikifications: this will allow at least to see the edited text.

6.2 The second and the third issues are written in the end of the tiddler "6 Extras: MathJax tests". The positioning issue actually affects not only formulae in this tiddler, but the text blocks as well (starting from the second one). Click, for instance, the formulae E = c pi/2 * .... -- the text isn't only taken from the wrong place, it also contains the closing part of the "$$...$$" wrapper.. Yeap, like in the issue 2.3 it's wrappers that are not handled well...

6.3 The third issue is a minor one: alghouth it's supposed that the text in the edit areas should be aligned to the left, it's aligned to the center instead (for many of the parts of the "6 Extras: MathJax tests" tiddler).

-------------------------------------------

So, that's all that I have gathered for now. There are some minor issues that can be fixed in the next release as they can be fixed easily (I suppose), like 0.2, 1.3, (may be) 3.1; some issues to think of and which can help reasonably improve workflow; and some major issues like 6.1, 2.1, 2.2 in solving of which I'm really looking forward and with whick I would like to help if there's something I can do (aside diving into the whole source of TWtid/TWted, of'course). What do you think?

Best regards,
Yakov.

[1] http://yakovl.bplaced.net/TW/materials_for_discussions/InlineEditingPlugins%20+%20MathJax%20test.7z

[Vincent Yeh]

Hi, Yakov,

 

Very thankful for your detailed tests and descriptions/comments/suggestions. You must have spent a lot of time on it.

 

On Thursday, September 19, 2013 7:23:06 PM UTC+8, Yakov wrote:

Hello Vincent,

any new achievements so far? Any success with the "selection" idea?

 

I have been busy with my work and not coding since the last release of 2.0.5 on Jul 30, and the situation is very likely to last untill the end of the year. I can find small time pieces eash day to work on these, but certainly it will take a longer time.

 

I have finally updated all my TWs to 2.6.5+, so no problems in real-life tesing is expected now. I have refactored all the tests into a somewhat consistent sequence, so let me list all the current issues again (probably that won't be bad for the "bird's-eye-view"). I'd like to highlight the last part, about MathJax, which is very important for me and I'll be very thankful if you solve the main issue about it. So, let's start.

[TWtid/TWted/TWtable 2.0.5 + TW 2.6.5 with STP 2.4.0 + Opera 12.16 + Win7 x64]

0. Separate bugs/notes/questions

0.1 Is the chkTWtedEditAllTables option outdated? It seems that tables are all editable even if the checkbox is unchecked.

This option is still current and this bug shoul be easy. I will look into this and fix it in the next release.

 

0.2 The "i-show-the-element-to-edit-on-click-here" border still appears around the displayArea (id=tiddlerDisplay) and elements with the tagged, tagging classes [which is not desirable]

0.3 If TWted is not launched, but TWtid is (with or without TWtable), backstage is not displayed and on start no tiddlers (from DefaultTiddlers) is displayed
 

I do not have these two issues with IE10/Win8 x64 (the only browser/OS combo at hand right now). Will check with other combinations next week. (We are having a four day long weekend for the Moon festival, during which we usually have a gathering with families or a party with friends. But this time we are having a huge tropical storm.)

 

1. Editing simple text

1.1 bug: if the [makrdown] text contains an html-entity (special symbol notation, say &sect;), when I enter the inline editor, it is turned to its "html output", namely §. Although it's a semi-feature (in many cases it just improves the readability), in some cases it's not desirable: if I write an example like this: {{{&sect;}}} → {{{§}}} , after such a transformation I get {{{§}}} → {{{§}}} which is not good.

This is fixed today and will go in the next release. Although I do not know the cause, the fix is easy: assign the content text after, rather then at the same time of, the creation of editbox with jQuery. That is, separate the codes from

 

$ta = jQuery('<textarea>'+txt+'</textarea>');

 

to

 

$ta = jQuery('<textarea></textarea>');

$ta.val(txt);

 

1.2 the previewer still doesn't work well with long texts because if one starts editing its beginning, the preview of it is above the top end of the screen. Desired behaviour is to cut the previewer and make it autoscroll. Is it the position of the cursor in the previewer which is difficult to grab? I can suggest some solutions on this, but of'course it all depends on the implentation.
1.3 the previewer shows the content in a different styling, as if it was in the SideBar -- this causes, for instant, displaying quotes with simple indents and buttons from macros like <<tag>> not very notable

I am aware of these two for quite a while but still haven't figured a good solution yet. For 1.2 I am thinking of a "line previewer" which supposedly shows only one line of content. If it really works then it shall be easy to put over (and cover) the current line. But I haven't got it yet. For 1.3 I have no idea how to fix yet. Currently I just do 1) copy style and 2) call wikify() in TWtid.wikify_element(). I do not understand why it is not 100% reproduced. I tried to dig into the wikifier functions but unfortunately the key parts are just like Klingon to me.

 

2. Editing lists

editing of list items that already exist works fine, deleting them is simple and changing the "order" (number of *) of a list item is easy, but there are several issues, too:
2.1 no way to edit new list items (aside editing the whote text). For non-touchscreen devices that could work fine by pressing ctrl+enter

I do not have a decent solution for this yet. My workaround is to 1) edit the immediately preceding item and 2) make a new line at the end and start that new line with the desired list item.

 

2.2 no way to move list items up and down (although one can copy-paste the content from one list item to another and vise versa, that's not fast..). Could work with alt+up/down

Ctrl-up/down should do the work, but currently it only works for items within the same level and fails when the item moves into a different level.

 

2.3 for list item like this two:

* text{{jD{
some content, like with
> citation
}}} some text after
* text +++[nested slider]
see NestedSlidersPlugin at TiddlyTools
=== some text after

it is only possible to edit the first line, although the list item is somposed from the three lines in each case.. (I use such syntax regularly, that's why I mention this complex example)

I never thought of such an interesting way to make a list item. Will spend time studying it later. 

 

3. Editing tables

I haven't refactored all the tests here, but let's start from some issues anyway:

3.1 a single cell is not styled correctly: somewhy it gets "bad" width and sometimes occupies more lines then it's expected. Try this one:

|single cell|

for me, the right border is too much to the right; and this one

|single cell single cell single cell single cell|

occupies two lines (an ordinary monitor, not mobile); without TWted this behaviour disappears.

Sure I'll try them later.

 

3.2 I still miss the "move colomn left/right" buttons, would be very nice to have them

I'll think about it.

 

3.3 Missing cells after other missing ones are not editable (cases like this:

|a|b|c|
|d|
|e|f|

), but I must admit, there's a workaround: edit the cell after d, then the one next to it, then clear the first one (although that's not very handy).

In principle this can be done in the plugin by determining the indices (row, col) of the "ought-to-be-there" cell, then create and append it, together with all the missing ones preceding it. It can be fixed.

 

4. Editing translcuded content

Almost everything is ideal here (I haven't tested the transclusions from the same tiddler, though). The only things are:

4.1 when transcluding with the <<tiddler>> macro, I can edit the transcluded content, but can't edit the macro itself

Well, in the test case http://twtable.tiddlyspace.com/#%5B%5BTransclusion%20support%5D%5D it is possible. Could you tell me the differences between this test case and yours so I can find the key?

 

4.2 There's a bug which I failed to create a separate simple example for; because of this, I attach a slightly modified TW where I test most of the InlineEditing stuff (I removed all the other plugins). To get the bug, you'll need to click the "test" button in the tiddler "InlineEditingPluginHere", choose the "4 Transclusions ..." and in the opened tiddler to mouseover the first table and then move the mouse away. What I get is the whole content of the tiddler is "compressed" by half. May be this is connected with the "wrong table widths" bug (3.1).

Will look into it as soon as I get time.

 

5. Complex content

5.1 "One-line" text blocks (without linebreaks \n) in some surrounding, like

* list item
text block
* list item

can't be made "multiline": each enter, ctrl+enter and shift+enter causes exiting the edit mode instead of adding a new line.

The above example works fine in my IE10/Win8 x64 here. Will check with more combinations next week.

 

5.2 Navigation with arrows is a desirable feature: now it's impossible even to jump between different text blocks with arrow keyboard buttons (which is possible for list items), and ideally it should be possible to.. well, navigate like in some office app -- in the example from 5.1 to jump from the first list item to the text block by pressing "down", the same for jumping from the latter to the next list item etc.

I'd love this feature myself and will certainly think about it.

 

6 Using with MathJax and rewikification

What MathJax (a library that creates math formulae using LaTeX syntax) makes different is the speed of wikification: processing long formulae may take several seconds. Current implementation (see below) adds a number of formatters and hijacks wikify so that original wikify is used first, and the math typesetting is applied to the whole text afterwards. This can be changed to applying typesetting by formatters themselves for each formulae, although I haven't tested performance of such implementation yet.

6.1 The main issue is rewikification. When a symbol is added/removed or cursor is moved (and the "l" symbol is, hence, added in another place), the whole content is wikified again (in the previewer). This makes previewer almost useless once a big formula is added. In the archive [1] you may find an example (the "elder" folder contains MathJax and a copy of "mainstream" PluginMathJax; in the main test file "InlineEditingPlugins + MathJax test.html" there's TwFormulaePlugin which isn't much different from PluginMathJax 1.3). To see how it works, open "InlineEditingPlugins + MathJax test.html", click "tests", open "6 Extras: MathJax tests". Then, copy the first line to another tiddler and play with it -- works fine. Then, copy the part before "=================", try it again and see the difference (in performance of the previewer). Finally, see the whole tiddler "6 Extras: MathJax tests", try to edit the whole content with the previewer: as some formulae are big, you won't see any preview of them while editing.

The question is -- can this behaviour be changed so that only parts of wikitext that are changed are rewikified? Another way to improve the situation is to make rewikification "inertial": add a parameter txtDelayRewikificationMilliseconds which defines a minimal time gap between rewikifications: this will allow at least to see the edited text.

I am suffering from this problem, too, and thought of partial wikification but could not get it as, like I mentioned above, I simply do not understand the key parts of the wikifier functions.

 

6.2 The second and the third issues are written in the end of the tiddler "6 Extras: MathJax tests". The positioning issue actually affects not only formulae in this tiddler, but the text blocks as well (starting from the second one). Click, for instance, the formulae E = c pi/2 * .... -- the text isn't only taken from the wrong place, it also contains the closing part of the "$$...$$" wrapper.. Yeap, like in the issue 2.3 it's wrappers that are not handled well...

Thanks for making the test file. I will check with it next week. 

6.3 The third issue is a minor one: alghouth it's supposed that the text in the edit areas should be aligned to the left, it's aligned to the center instead (for many of the parts of the "6 Extras: MathJax tests" tiddler).

-------------------------------------------

So, that's all that I have gathered for now. There are some minor issues that can be fixed in the next release as they can be fixed easily (I suppose), like 0.2, 1.3, (may be) 3.1; some issues to think of and which can help reasonably improve workflow; and some major issues like 6.1, 2.1, 2.2 in solving of which I'm really looking forward and with whick I would like to help if there's something I can do (aside diving into the whole source of TWtid/TWted, of'course). What do you think?

I'd love to have you help in these for sure, especially in the partial wikification thing. I really have problems understanding the codes.If you have any idea to achieve it without digging into the wikifier codes, I'd be more than happy to hear it.

 

Thanks again for so much information and so much effort you put behind.

 

Best,

Vincent

[Yakov]

Hi Vincent,

yeap, like you have noticed, your "second" message (after my reply), but also the two others -- got deleted somewhy; anyway, I got them in my email as I'm subscribed for the comments.

Now, "let's talk business" :)

The table row/colomn moving kind of works, but very slowly. In a simple example

|a|b|
|c|d|

moving colomns takes 6-12 seconds, moving rows -- ~4 seconds; it seems that the moving is stored each time but it is not always displayed.. (for better testing I disabled all other plugins and even opened just one tiddler with such table, but still in both Opera and FF I get these problems). By the way, this may be of interest (see the updates to the most voted answer): http://stackoverflow.com/questions/268490/jquery-document-createelement-equivalent

By the way, as far as I understand, this

Although I do not know the cause, the fix is easy: assign the content text after, rather then at the same time of, the creation of editbox with jQuery. That is, separate the codes from

 

$ta = jQuery('<textarea>'+txt+'</textarea>');

 

to

 

$ta = jQuery('<textarea></textarea>');

$ta.val(txt);

is because creating element using this syntax http://api.jquery.com/jQuery/#jQuery2 actually parses html, and for textarea parsed text is set, but if you set the value via val, you get it "as is".

The html entitites issue, like you said, is gone and the chkTWtedEditAllTables option now works as expected, great.

Some ideas/notes for the issues:

1.3 May be adding some classes that content wrappers have (like "tiddler selected" or "viewer") to the previewer will make styling the same.

2.1 I'd say that's somewhat ok if I can add new lines in an "edit list item" area by pressing some keys. For now, I can only copy-paste the newline symbol from elsewhere (all enter, ctrl+enter, shift+enter, alt+enter either don't do anything or close the edit area), but by adding a newline a list item before, after and of any level can be created.

2.2 Wow, this works! (although causes some jumping of the screen up and down and, like you said, doesn't work well with list items of different level)

4.1 in the tiddler you sited it is said:

move the cursor to the right until the focusing borders become larger

well, the problem is on moving to the right the focusing borders either disapper (for text blocks) or don't become larger (list items) and the only way [in my setup] to get the whole transcluded content selected is to put mouse somewhere on the left of the content.

6.1 Ok.. you can ask me some direct questions, but "in vacuum".. Well, the two main function to look at are .subWikifyUnterm (it's simpler, but is used only "once" -- in the .subWikify) and .subWikifyTerm (it is used, for instance, in some formatters like heading, and uses termRegExpr property of formatters). Another important note is that it's easier to start from formatters and then dig wikifying. Finally, it's very important (and not obvious) that formatters keep an eye on the w.nextMatch index: see, for instance, the macro formatter. [*]

Honestly, I haven't overviewed the whole thing yet.

Best regards,
Yakov.

[*] https://github.com/TiddlyWiki/tiddlywiki/blob/master/js/Wikifier.js
    https://github.com/TiddlyWiki/tiddlywiki/blob/master/js/Formatter.js

 

[TWtid/TWted/TWtable 2.0.5 + TW 2.6.5 with STP 2.4.0 + Opera 12.16 + Win7 x64]

0. Separate bugs/notes/questions
 

0.2 The "i-show-the-element-to-edit-on-click-here" border still appears around the displayArea (id=tiddlerDisplay) and elements with the tagged, tagging classes [which is not desirable]

0.3 If TWted is not launched, but TWtid is (with or without TWtable), backstage is not displayed and on start no tiddlers (from DefaultTiddlers) is displayed
 

I do not have these two issues with IE10/Win8 x64 (the only browser/OS combo at hand right now). Will check with other combinations next week. (We are having a four day long weekend for the Moon festival, during which we usually have a gathering with families or a party with friends. But this time we are having a huge tropical storm.)

 

1. Editing simple text

[Vincent Yeh]

TWtid v2.0.6 + TWted v2.0.7 + TWtcalc v1.0.7 + TWtable v2.0.6

Added a popup menu that shows the plugin options when moue is over the right most part of the tiddler title area. It is a popup menu that disappears when you click on it, so it is good only for checkbox options but not the text options. I didn't realize it until just now but I don't have time for this today nor in the next (quite a) few days, so decided to release anyways and fix it later.

There are also quite some bug fixes in all the plugins. See release note at http://twtable.tiddlyspace.com/#%5B%5BRelease%20Note%20v2.0.7+v2.0.6%5D%5D

Vincent

@Yakov,

On Wednesday, October 2, 2013 3:24:24 AM UTC+8, Yakov wrote:

Hi Vincent,

yeap, like you have noticed, your "second" message (after my reply), but also the two others -- got deleted somewhy; anyway, I got them in my email as I'm subscribed for the comments.

Now, "let's talk business" :)

The table row/colomn moving kind of works, but very slowly. In a simple example

|a|b|
|c|d|

moving colomns takes 6-12 seconds, moving rows -- ~4 seconds; it seems that the moving is stored each time but it is not always displayed.. (for better testing I disabled all other plugins and even opened just one tiddler with such table, but still in both Opera and FF I get these problems). By the way, this may be of interest (see the updates to the most voted answer): http://stackoverflow.com/questions/268490/jquery-document-createelement-equivalent

This is strange for I do not see such a behavior with my browsers. I will need more time to figure it out.

 

By the way, as far as I understand, this

Although I do not know the cause, the fix is easy: assign the content text after, rather then at the same time of, the creation of editbox with jQuery. That is, separate the codes from

 

$ta = jQuery('<textarea>'+txt+'</textarea>');

 

to

 

$ta = jQuery('<textarea></textarea>');

$ta.val(txt);

is because creating element using this syntax http://api.jquery.com/jQuery/#jQuery2 actually parses html, and for textarea parsed text is set, but if you set the value via val, you get it "as is".

I see. That is quite reasonable. Thanks for the explanation.

 

The html entitites issue, like you said, is gone and the chkTWtedEditAllTables option now works as expected, great.

Some ideas/notes for the issues:

1.3 May be adding some classes that content wrappers have (like "tiddler selected" or "viewer") to the previewer will make styling the same.

Yes you are right! Adding "tiddler selected" fixes the problem! Thanks!

 

2.1 I'd say that's somewhat ok if I can add new lines in an "edit list item" area by pressing some keys. For now, I can only copy-paste the newline symbol from elsewhere (all enter, ctrl+enter, shift+enter, alt+enter either don't do anything or close the edit area), but by adding a newline a list item before, after and of any level can be created.

Maybe you did not check the Multi-line rendering mode option (TWtid options). Setting it to true then you should be able to type Enter when editing a list item.

 

2.2 Wow, this works! (although causes some jumping of the screen up and down and, like you said, doesn't work well with list items of different level)

4.1 in the tiddler you sited it is said:

move the cursor to the right until the focusing borders become larger

well, the problem is on moving to the right the focusing borders either disapper (for text blocks) or don't become larger (list items) and the only way [in my setup] to get the whole transcluded content selected is to put mouse somewhere on the left of the content.

Yeah I noticed this behavior after reading your comment. You are right that in this case it is not easy to tell the size difference of the focus borders when mouse cursor is at different places of a list item. For now I have no clear idea how to make it better. Will think more about it in the near future. (You are welcome to tell me your ideas for sure.:-)

 

6.1 Ok.. you can ask me some direct questions, but "in vacuum".. Well, the two main function to look at are .subWikifyUnterm (it's simpler, but is used only "once" -- in the .subWikify) and .subWikifyTerm (it is used, for instance, in some formatters like heading, and uses termRegExpr property of formatters). Another important note is that it's easier to start from formatters and then dig wikifying. Finally, it's very important (and not obvious) that formatters keep an eye on the w.nextMatch index: see, for instance, the macro formatter. [*]

For example, if I just want to hijack some function to render a multi-lined table cell, where do I cut-in?

Anyways, I know you are busy so just ignore my questions/comments that are too annoying.

Have fun!

Vincent

[Eric Shulman]

On Friday, November 8, 2013 9:27:15 AM UTC-8, Vincent Yeh wrote:

Added a popup menu that shows the plugin options when moue is over the right most part of the tiddler title area. It is a popup menu that disappears when you click on it, so it is good only for checkbox options but not the text options. I didn't realize it until just now but I don't have time for this today nor in the next (quite a) few days, so decided to release anyways and fix it later.

This will solve the problem:

   http://www.TiddlyTools.com/#StickyPopupPlugin

enjoy,

-e

Eric Shulman

TiddlyTools / ELS Design Studios

HELP ME TO HELP YOU - MAKE A CONTRIBUTION TO MY "TIP JAR"...

   http://TiddlyTools.github.com/fundraising.html#MakeADonation

Professional TiddlyWiki Consulting Services...

Analysis, Design, and Custom Solutions:

   http://www.TiddlyTools.com/#Contact

[Vincent Yeh]

That's a great help! Thanks a lot, Eric!

Arc I think it is now easier to do what you suggested a while ago: disable/enable the plugins as desired.

Have fun!

Vincent

[Vincent Yeh]

Yakov,

I was supposed to do something else but couldn't get it off my mind, so decided to spent some time on the table column moving issue (row moving seems to work fine). I found two situations that cause the column moving very slow and one that causes infinite loop:

1. when there are empty cells in a row
2. when using TWtcalc and some of the moved cells contain block references (such as =sum(A1:B3))
3. table at the end of a tiddler and does not end with a new line (infinite loop)
   

The reasons are

1. a bug that I introduced in a recent bug fix for another situation (this is fixed in my current snapshot and will go in the next release)
   
2. In TWtcalc I haven't done auto adjustment on block references yet (single cell references are auto-adjusted upon copy-and-pasting, row/column moving, and sorting), so this issue shall continue for a while
   
3. a situation that I did not think of (fixed in the current snapshot and goes in the next release)
   

Row/Column moving does not  work for tables with missing cells yet.

Do the above three situations cover yours or you have something different?

Vincent

[Yakov]

Hi Vincent,

I've updated the plugins and have done some testing..

I have problems with moving colomns in quite a simple test case:   in my setup (Win7 x64 + Opera 12.16 + TW 2.6.5 + latest .min versions of the plugins + some plugins -- STP, NestedSlidersPlugin, minor tweaks) with a tiddler as simple as

Start with text
|a|c|b|
|d|f|e|
|g|j|i|
end with text

and all other tiddlers closed, when I push the button to move any colomn, I don't see any change, the saving message appears in a second or two, I'm not able to do anything else with my TW (cursor doesn't change as I move it over different buttons) and when I refresh the page, the change is applied (the colomn is moved).


I like the new mouseover popups with options, very nice that now each one is shorter than the previous thing that contained options for all the plugins.


While testing the colomn moving issue, I've found a new bug. To reproduce, create a tiddler with the following content and follow the instructions:

Try to edit the text after the table: mouseover the textblock and click (for me, instead of opening the block editing is opened for the whole tiddler content), try to add "2 " before the class brackets (in the beginning of the line), press ctrl+enter. The change is not displayed for me, and neither it is saved (open the content by the "edit" toolbar button). Also , the preview is of wrong widths and has much more height because of that.
|a|
{{DDn{v2.0.5: more text}}}


By the way, the difference in the version numbers of TWtid/TWted add a bit of inconvenience for tracking changes/bugs, so I'd recommend keep the version numbers the same by "dumb" incrementing of those that were not changed and stating that in the changelog.


Another new (minor) bug: inline editing of tiddler title doesn't change its "modified" date.


Despite adding the tiddler selected classes, the styling is not applied correctly to the previewer. However, I've also noticed that the previewer is currently a span element instead of div, which may be the origin of the problem.. In you release notes you've written about some errors when the viewer class is added -- that may be connected with the fact that this class is added to elements generated by the view macro, and some refreshing/.. stuff is applied to such things.


Opera DragonFly tells me that there's a tremendous amount (>500) of unhandled errors that origin from the TWtid.min line 1536 (tiddler_title method). Error text is "Cannot convert 'a' to object" (a is the only argument in the .min version).


Looks like an arbitrary popup have become "close on mouseout"-enabled (this happens with tag macro, references toolbar command popups and others). As you've done some popup business recently, I think it's worth debugging at the first place.


Ok, looks like that's all for today :)

Best regards,
Yakov.

воскресенье, 10 ноября 2013 г., 17:12:59 UTC+4 пользователь Vincent Yeh написал:

[Vincent Yeh]

Yakov,

It is always exciting to see your reply. These days I played a bit with your simple test tiddler in my Win7x64 box (in VirtualBox / Ubuntu 13.10) and Win8x64 notebook, using Opera 17.0 in both cases, and found a couple of situations that can cause extremely slow performance in column moving. I managed to fix them and the current version seems to work fine with Opera 17.0+TW2.6.5. However, I don't know if it works with Opera 12.16, so before releasing it could you please test this file (https://www.dropbox.com/s/i06c3jmjjmuug1v/empty.2.6.5.html) with Opera 12.16 and tell me the result? It is just TWtid+TWted 2.0.8 (both minimized) and NestedSlidersPlugin+STP installed in an otherwise empty 2.6.5 TW file, with your test tiddler of course.

I will find time to try other stuffs you mentioned in the last post.

Have fun!
Vincent

[Yakov]

Hello Vincent,

четверг, 14 ноября 2013 г., 12:58:40 UTC+4 пользователь Vincent Yeh написал:

Yakov,

It is always exciting to see your reply.

Nice to hear this, I would expect that countless bug reports sound rather exhausting at times :)
 

These days I played a bit with your simple test tiddler in my Win7x64 box (in VirtualBox / Ubuntu 13.10) and Win8x64 notebook, using Opera 17.0 in both cases, and found a couple of situations that can cause extremely slow performance in column moving. I managed to fix them and the current version seems to work fine with Opera 17.0+TW2.6.5. However, I don't know if it works with Opera 12.16, so before releasing it could you please test this file (https://www.dropbox.com/s/i06c3jmjjmuug1v/empty.2.6.5.html) with Opera 12.16 and tell me the result? It is just TWtid+TWted 2.0.8 (both minimized) and NestedSlidersPlugin+STP installed in an otherwise empty 2.6.5 TW file, with your test tiddler of course.

Right, in your assembly it works perfectly quick, which is not the case in mine, though. Further digging showed that the problem rises when autosaving is enabled: in this example, saving is called 7 times! You can test this by simple baking of the config.options.chkAutoSave = true; option: if TiddlySaver is missing, you'll probably get 7 alerts about saving disabled; and if TS is present, you'll probably get the delay of about 3-5 seconds.
 

I will find time to try other stuffs you mentioned in the last post.

Great; the "all popups got the 'close on mouseout'" issue has already gone.

Best regards,
Yakov.

[Ton Gerner]

Hi Vincent,

After a few months silence, you "reappeared" a month ago. Glad to hear you are still busy with your plugins.

Just to inform you, I am using your plugins daily for - pure - table editing. I use the (old) versions v1.6.4 of TWtid and TWted.
I stay with the old versions (they work in most cases) since I do not have time to test newer versions.

As I once said:

"Table editing was always very difficult in TW and is now a pleasure with your plugin(s). On the other hand it would be nice to just have a no frills table editor."

Keep up the good work.

Cheers,

Ton

[Vincent Yeh]

Wtid v2.0.8 + TWted v2.0.8 + TWtcalc v1.0.8 + TWtable v2.0.8

Improved previewer, bug fixes for table column moving (but still there is autoSave issue, see below), popups and math.
See release note at http://twtable.tiddlyspace.com/#[[Release%20Note%20v2.0.8]] for details and download links.

• There is still the autoSave issue remains unsolved.
  
• With Opera and Chrome, the file save operation is triggered multiple times if (and only if) the system option AutoSave is checked, whereas the autoSaveChanges() function is confirmed to be called just once. I have no idea how to fix this yet.
  

Have fun!
Vincent

[Vincent Yeh]

Ton,

Thanks for using the plugins and the nice comments about them. I will consider this for sure. Actually after the introduction in v2.0.0 I have been thinking of optimizing and isolating TWElement, the base codes that offers easy access to wiki text associated with a DOM element (see http://twtable.tiddlyspace.com/#TWElement for details), so that it can be easily used in other plugins. Once I get this done, it should be possible to further customize the combinations of plugins that best fits your needs.

Have fun!
Vincent

[Yakov]

Hello Vincent,

now the previewer works with the correct styling! Really cool. I like the scrollable thing, too, -- this helps as a temporary solution for big blocks.

The problem of making one-line text blocks multiline got solved partially: in this example

text
* list item
text
* list item
text

I can make the first text block [before list items] multiline (by pressing enter and typing the second line), but the blocks in the middle and in the end still can't be turned multiline (the editor exits on enter and shift+enter and nothing happens on ctrl+enter). This, coupled with several other tests, makes me think that any other thing before a text block (list, line quotation, table) makes it "non-expandable".

The wrong positioning for formulae is solved indeed, and the speed of preview update is now quite reasonable, I'd say (except for really big formulae blocks). This is rather usable now! I've noticed one more thing, though: inline formulae are not editable separately from the text. Can this be fixed without much effort or the editable-element-should-be-block business is rather important? Really huge progress.

Still have that "squeeze and inflate" bugs: in

text
|short line|
text
|long line with many words|
text

in the cell with the short line, there's extra ~margin on the right, with size bigger than that of the text; table has the property width: 128px; which seems to be the cause of this effect.
In the cell with the long line, the content is multiline instead of one-line, and the table has the property width: 175px; which, again, seem to cause the effect.

In general, a very inspiring update, may be I'll redo some other test for it, too.

Best regards,
Yakov.

воскресенье, 17 ноября 2013 г., 10:50:56 UTC+4 пользователь Vincent Yeh написал:

[Vincent Yeh]

Yakov,

On Sunday, November 24, 2013 4:08:27 AM UTC+8, Yakov wrote:

Hello Vincent,

now the previewer works with the correct styling! Really cool. I like the scrollable thing, too, -- this helps as a temporary solution for big blocks.

Thanks. It does look better than before.
 

The problem of making one-line text blocks multiline got solved partially: in this example

text
* list item
text
* list item
text

I can make the first text block [before list items] multiline (by pressing enter and typing the second line), but the blocks in the middle and in the end still can't be turned multiline (the editor exits on enter and shift+enter and nothing happens on ctrl+enter). This, coupled with several other tests, makes me think that any other thing before a text block (list, line quotation, table) makes it "non-expandable".

After trying a while, I could reproduce your situation by "turning off the multi-line rendering mode" (the config.options.chkTWtidMultiLine option). If this is your case then you can check that option to "(not really) fix" the situation. I said "not really" because the inconsistent behavior between the text blocks, when chkTWtidMultiLine is unchecked, is indeed a bug in the codes. I have fixed it (hopefully for real) in the current snapshot and will release it in a couple of days.
 

The wrong positioning for formulae is solved indeed, and the speed of preview update is now quite reasonable, I'd say (except for really big formulae blocks). This is rather usable now! I've noticed one more thing, though: inline formulae are not editable separately from the text. Can this be fixed without much effort or the editable-element-should-be-block business is rather important? Really huge progress.

The inline element editing was done a few releases ago but still not quite comfortable to use, especially in cases where the rendered element has a width much smaller than its defining wiki text. In my own experiences this turned out to happen more often then I expected, especially with math formulas. For example, \(\vec{\mathbf x}\) generates only one symbol representing a vector x. This makes it uncomfortable in editing an inline element so I haven't started promoting this feature. For inline math there is another issue I haven't fixed yet: inline math can start (and end) with a dollar sign, while a TWtcalc formula can refer to a table cell with a dollar sign (absolute referencing). The former requires a pair, while the latter does not. This sometimes causes confusion and I haven't got an elegant solution yet.
 

Still have that "squeeze and inflate" bugs: in

text
|short line|
text
|long line with many words|
text

in the cell with the short line, there's extra ~margin on the right, with size bigger than that of the text; table has the property width: 128px; which seems to be the cause of this effect.
In the cell with the long line, the content is multiline instead of one-line, and the table has the property width: 175px; which, again, seem to cause the effect.

The bigger size in the short cell is probably due to the "default to minimum 8 char for the option txtTWtidMinCellWidth". Changing it to a smaller number and it will be fine (but edit box tries to fit into the cell width and may become too narrow to edit). The two-line height in the longer one, however, is happening with TW2.6.5 but not with 2.8.1. I added codes to enlarge it a bit if the TW version is earlier than 2.8.0, but I haven't tested it with other versions of TW yet.
 

In general, a very inspiring update, may be I'll redo some other test for it, too.

Thanks a lot. It keeps me going further.

Have fun!
Vincent


 

[Yakov]

Hi Vincent,

The problem of making one-line text blocks multiline got solved partially: in this example

text
* list item
text
* list item
text

I can make the first text block [before list items] multiline (by pressing enter and typing the second line), but the blocks in the middle and in the end still can't be turned multiline (the editor exits on enter and shift+enter and nothing happens on ctrl+enter). This, coupled with several other tests, makes me think that any other thing before a text block (list, line quotation, table) makes it "non-expandable".

After trying a while, I could reproduce your situation by "turning off the multi-line rendering mode" (the config.options.chkTWtidMultiLine option). If this is your case then you can check that option to "(not really) fix" the situation. I said "not really" because the inconsistent behavior between the text blocks, when chkTWtidMultiLine is unchecked, is indeed a bug in the codes. I have fixed it (hopefully for real) in the current snapshot and will release it in a couple of days.

True story, switching chkTWtidMultiLine to true helped. Could you remind what this option is about and why the behaviour set by true is not default?

 

The wrong positioning for formulae is solved indeed, and the speed of preview update is now quite reasonable, I'd say (except for really big formulae blocks). This is rather usable now! I've noticed one more thing, though: inline formulae are not editable separately from the text. Can this be fixed without much effort or the editable-element-should-be-block business is rather important? Really huge progress.

The inline element editing was done a few releases ago but still not quite comfortable to use, especially in cases where the rendered element has a width much smaller than its defining wiki text. In my own experiences this turned out to happen more often then I expected, especially with math formulas. For example, \(\vec{\mathbf x}\) generates only one symbol representing a vector x. This makes it uncomfortable in editing an inline element so I haven't started promoting this feature. For inline math there is another issue I haven't fixed yet: inline math can start (and end) with a dollar sign, while a TWtcalc formula can refer to a table cell with a dollar sign (absolute referencing). The former requires a pair, while the latter does not. This sometimes causes confusion and I haven't got an elegant solution yet.

I see. How about this one: for block elements, leave "preview appears above" behaviour as is the case now, but for inline ones, make it "edit area appears below" instead? I mean, the preview is displayed in the same element as the actual (say, formula) was, but the edit area appears below it in a separate "window" (like the current previewer appears in a separate "window" above the element). This, of'course, will have the same problem in the previewer if the result gets larger than it was, but this can be overcome by displaying the previewer as a separate "window" not above or below the element (which is edited), but over the element. This will have a drawback of not very neat look (the previewer hovering over the text outside the formula when it's larger; minimum width has to be set equal to the width before editing), but is at least more comfortable to use. Alternatively, the previewer can be kept in the edited element itself, and when the width is changed, the whole containing text block can be rewikified (with current text of the part being edited).

 

Still have that "squeeze and inflate" bugs: in

text
|short line|
text
|long line with many words|
text

in the cell with the short line, there's extra ~margin on the right, with size bigger than that of the text; table has the property width: 128px; which seems to be the cause of this effect.
In the cell with the long line, the content is multiline instead of one-line, and the table has the property width: 175px; which, again, seem to cause the effect.

The bigger size in the short cell is probably due to the "default to minimum 8 char for the option txtTWtidMinCellWidth".

Correct.
 

Changing it to a smaller number and it will be fine (but edit box tries to fit into the cell width and may become too narrow to edit). The two-line height in the longer one, however, is happening with TW2.6.5 but not with 2.8.1.

Doesn't happen in 2.7.1 too.
 

I added codes to enlarge it a bit if the TW version is earlier than 2.8.0, but I haven't tested it with other versions of TW yet.

Not sure what do you mean here..


Actually, I've stumbled upon a new issue with the popups: now I have the popups with TWtxx plugins' options somewhat like 1px height (no possibility to change any option). Unfortunately, I can't inspect the elements, but I guess that's exactly heigth: 1px.

Best regards,
Yakov.

[Vincent Yeh]

Yakov,

On Monday, November 25, 2013 5:35:04 AM UTC+8, Yakov wrote:

Hi Vincent,

The problem of making one-line text blocks multiline got solved partially: in this example

text
* list item
text
* list item
text

I can make the first text block [before list items] multiline (by pressing enter and typing the second line), but the blocks in the middle and in the end still can't be turned multiline (the editor exits on enter and shift+enter and nothing happens on ctrl+enter). This, coupled with several other tests, makes me think that any other thing before a text block (list, line quotation, table) makes it "non-expandable".

After trying a while, I could reproduce your situation by "turning off the multi-line rendering mode" (the config.options.chkTWtidMultiLine option). If this is your case then you can check that option to "(not really) fix" the situation. I said "not really" because the inconsistent behavior between the text blocks, when chkTWtidMultiLine is unchecked, is indeed a bug in the codes. I have fixed it (hopefully for real) in the current snapshot and will release it in a couple of days.

True story, switching chkTWtidMultiLine to true helped. Could you remind what this option is about and why the behaviour set by true is not default?

The very initial intention was to create a plugin that makes it easy to edit table cells, which by default are not expected to be multi-lined. This should be the reason, as far as I can remember, that I set this option default to false. At the beginning this option was only to switch multi-line mode for table cells, but later also extended to cover list items. Container elements (could be DIV or SPAN), however, are multi-lined by nature and not affected by this option.
 

 

The wrong positioning for formulae is solved indeed, and the speed of preview update is now quite reasonable, I'd say (except for really big formulae blocks). This is rather usable now! I've noticed one more thing, though: inline formulae are not editable separately from the text. Can this be fixed without much effort or the editable-element-should-be-block business is rather important? Really huge progress.

The inline element editing was done a few releases ago but still not quite comfortable to use, especially in cases where the rendered element has a width much smaller than its defining wiki text. In my own experiences this turned out to happen more often then I expected, especially with math formulas. For example, \(\vec{\mathbf x}\) generates only one symbol representing a vector x. This makes it uncomfortable in editing an inline element so I haven't started promoting this feature. For inline math there is another issue I haven't fixed yet: inline math can start (and end) with a dollar sign, while a TWtcalc formula can refer to a table cell with a dollar sign (absolute referencing). The former requires a pair, while the latter does not. This sometimes causes confusion and I haven't got an elegant solution yet.

I see. How about this one: for block elements, leave "preview appears above" behaviour as is the case now, but for inline ones, make it "edit area appears below" instead? I mean, the preview is displayed in the same element as the actual (say, formula) was, but the edit area appears below it in a separate "window" (like the current previewer appears in a separate "window" above the element). This, of'course, will have the same problem in the previewer if the result gets larger than it was, but this can be overcome by displaying the previewer as a separate "window" not above or below the element (which is edited), but over the element. This will have a drawback of not very neat look (the previewer hovering over the text outside the formula when it's larger; minimum width has to be set equal to the width before editing), but is at least more comfortable to use. Alternatively, the previewer can be kept in the edited element itself, and when the width is changed, the whole containing text block can be rewikified (with current text of the part being edited).

 

I can try this for sure.
 

Still have that "squeeze and inflate" bugs: in

text
|short line|
text
|long line with many words|
text

in the cell with the short line, there's extra ~margin on the right, with size bigger than that of the text; table has the property width: 128px; which seems to be the cause of this effect.
In the cell with the long line, the content is multiline instead of one-line, and the table has the property width: 175px; which, again, seem to cause the effect.

The bigger size in the short cell is probably due to the "default to minimum 8 char for the option txtTWtidMinCellWidth".

Correct.
 

Changing it to a smaller number and it will be fine (but edit box tries to fit into the cell width and may become too narrow to edit). The two-line height in the longer one, however, is happening with TW2.6.5 but not with 2.8.1.

Doesn't happen in 2.7.1 too.

Good to know. Thanks.
 

 

I added codes to enlarge it a bit if the TW version is earlier than 2.8.0, but I haven't tested it with other versions of TW yet.

Not sure what do you mean here..

I meant I've fixed it in the current snapshot.
 

Actually, I've stumbled upon a new issue with the popups: now I have the popups with TWtxx plugins' options somewhat like 1px height (no possibility to change any option). Unfortunately, I can't inspect the elements, but I guess that's exactly heigth: 1px.

I noticed this in the weekend and got it fixed as well. The next release shall be available soon.

Have fun!
Vincent


 

[Vincent Yeh]

TWtid v2.0.9 + TWted v2.0.9 + TWtcalc v1.0.9

Bug fixes for a few issues. See release note at http://twtable.tiddlyspace.com/#[[Release%20Note%20v2.0.9]] for details and download links.

I need to focus on my work till the end of year, so unless for urgent bug fixes the next release shall come out next year.

In the next (or a couple of more) release the plugins will experience another phase change. The very core of TWtxx plugins, the TWElement that offers easy access to wiki text and transclusion synchronization for DOM elements, will be completely separated out of TWtid and stand alone as a single plugin (currently ~22KB minimized). This TWElement does not just serve as the base of TWtxx plugins, but also work (hopefully) with other plugins that need access to wiki text and/or transclusion synchronization. Table editing features will also be separated out of TWted so that people who don't need to edit other elements can have a slimmer choice.

Have fun!
Vincent

[Yakov]

Hello Vincent,

I've been using inline editing (and previewing) when writing some real-time notes/solving rather simple math problems and have noticed that, while inline editing is now very helpful (rather than confusing because of bugs/other issues), there's a distinct "drawback" for such applications, which can be called shortly "lack of granularity".

In one case I was working with a list of notes -- in that case the main bottleneck was creating a new list item on the fly. To create one, I have to either copy-paste the linebreak symbol from another editor and create a new list item therein (in this case I get the preview of 2 and then more list items instead of one; which slows me down when the number of formulae in the previewed text grows); another approach is create a list item by inserting a linebreak, exit the edit mode and then open the new item to edit; or just open usual edit mode, type linebreak and create a new list item. Each approach is, of'course not very comfortable.

In the other case I was writing a text (no list items), and the problem is it is not divided anyhow (like between "paragraphs"), so as the number of formulae grows, the whole thing slows down. Fortunately, once an outline formula ($$...$$) is created, I can exit the edit mode and then open it only for the part of the text after the formula. Still, I have to exit-open the edit mode and do this once I want to move from one part of the text to another/to an outline formulae.

These issues were mentioned before, but I'd like to highlight them as sort of bottleneck issues of the workflow.

Another thing I've notices when working with formulae is that when I push shift or ctrl, the preview starts to blink (as long as I keep the button pushed). I guess the plugins probably process the keyDown events, and I think it would be more reasonable to process the keyUp events -- in this case long pressing will cause only one refresh of the previewer instead of a series. Also, it's probably not necessary to process keyUps of ctrl, alt and shift buttons.

Any progress with inline formulae/your plans about core? By the way, what do you think about compatibility of inline editing and the CodeMirror stuff [1]? (that's presumably a long story..)

Best regards,
Yakov.

[1] https://groups.google.com/forum/#!searchin/tiddlywiki/codemirror/tiddlywiki/KRnQvzazULE/MUGP-s3TPpgJ

вторник, 26 ноября 2013 г., 10:01:28 UTC+4 пользователь Vincent Yeh написал:

[Vincent Yeh]

Yakov,

Thanks for raising the issues and the nice comments/questions. Yes I have noticed those bottlenecks you mentioned and have been thinking of possible solutions for them, including the possibilities of a true WYSIWYG editor. But as all we know a WYSIWYG wiki editor for now is something difficult if not impossible, the current solution I am implementing is a floating button that goes with the focusing borders and carries menu items for the creation of new elements, such as tables, list items, etc, similar to the one that goes with the focusing borders around tiddler title and carries menu items for plugin options. This is the easiest way for now and shall work on mobile devices as well as desktops. It should come into play in the next one or two releases.

The plain text is a bit more complicated than DOM elements, for a piece of plain text does not have any signature in its wiki text as other DOM elements do, there might still be issues like these remained in the coming solution. In addition, I am also working on a way to locate the character upon mouse click (for a future work mode even closer to the WYSIWYG expectations), which takes plain text equally as other DOM elements and hopefully will take these issues out for good.

As for the keydown/keyup issue, I remember I had tried both ways and for some reason I do not recall now that I chose to use the keydown event. The issue you mentioned is solved in my current development snapshot and shall be gone in the next release. Thanks for brining it up.

The core codes are now separated from the plugins and collected into a new one called twve.core, with twve standing for TiddlyWiki View mode Editor. This will be the new base that combines the basic features in TWtid and TWted. Extra features that are list-item-specific or other block-element-specific go in twve.extra. All the table related codes go into twve.table and twve.table.large. TWtcalc is renamed to twve.tcalc and continues to offer basic spreadsheet functionalities in TiddlyWiki environment.

With this code structure one can install one of the following combinations:

1. twve.core + twve.table for table editing (plus twve.table.large for large table supports);
2. twve.core + twve.extra + twve.table for all editing features (including all types of block elements and plain text);
3. either one of above + twve.tcalc for simple spreadsheet functionalities.
   

For plugin authors who want access to wiki text of a DOM element or the capability of transclusion synchronization, you can either take the whole twve.core or extract the necessary parts to combine with your codes.

I planned to have the next release on 1/31, the first day of the next Chinese lunar year, but now I am not sure of it as I still have quite some things to finish before the New Year's break. We will see.

I am not quite sure about the CodeMirror stuff. I thought it already inline-editable. Is it not?

Have Fun!
Vincent

[Yakov]

Hi Vincent,

понедельник, 27 января 2014 г., 12:45:15 UTC+4 пользователь Vincent Yeh написал:

Yakov,

Thanks for raising the issues and the nice comments/questions. Yes I have noticed those bottlenecks you mentioned and have been thinking of possible solutions for them, including the possibilities of a true WYSIWYG editor. But as all we know a WYSIWYG wiki editor for now is something difficult if not impossible, the current solution I am implementing is a floating button that goes with the focusing borders and carries menu items for the creation of new elements, such as tables, list items, etc, similar to the one that goes with the focusing borders around tiddler title and carries menu items for plugin options. This is the easiest way for now and shall work on mobile devices as well as desktops. It should come into play in the next one or two releases.

Right, I thought of this solution for touch-devices, too. I think for keyboard devices some hotkey combinations activating the menu items (like "add list item") would do well.

A small note about WYSIWYG. May be you remember, I previously mentioned an idea that once a possibility to place different (wikified) elements in the edit area ("plain text area") is implemented, WYSIWYG is one step away.. today I've noticed that google implemented similar stuff in some services, including Gmail (attachments, citations). Although this should be of little help (Gmail is not open-source), may be this can provide some ideas..
 

The plain text is a bit more complicated than DOM elements, for a piece of plain text does not have any signature in its wiki text as other DOM elements do, there might still be issues like these remained in the coming solution. In addition, I am also working on a way to locate the character upon mouse click (for a future work mode even closer to the WYSIWYG expectations), which takes plain text equally as other DOM elements and hopefully will take these issues out for good.

Ah, sounds really good. Locating a character should help with the previewer auto-scrolling, too (I guess).

As for the keydown/keyup issue, I remember I had tried both ways and for some reason I do not recall now that I chose to use the keydown event. The issue you mentioned is solved in my current development snapshot and shall be gone in the next release. Thanks for brining it up.

The core codes are now separated from the plugins and collected into a new one called twve.core, with twve standing for TiddlyWiki View mode Editor. This will be the new base that combines the basic features in TWtid and TWted. Extra features that are list-item-specific or other block-element-specific go in twve.extra. All the table related codes go into twve.table and twve.table.large. TWtcalc is renamed to twve.tcalc and continues to offer basic spreadsheet functionalities in TiddlyWiki environment.

With the new core, will it be a simple task to activate inline editing only for some elements? Like, say, only for transclusions? I think it would be helpful for thorough testing and consistent adoption in multiple TW documents (as TW doesn't have comprehensive "undo changes" engine and I use autosaving; and as I have stumbled upon some minor data loss in complicated test cases, I still use inline editing very carefully, in a limited number of documents). An especially nice application is the combination of ForEachTiddlerPlugin (write action with transclusion) + inline editing plugins to create editable aggregated tables, like with GridPlugin, but with lots of different advantages (which requires only the editing of transclusion with the tiddler macro).
 

With this code structure one can install one of the following combinations:

1. twve.core + twve.table for table editing (plus twve.table.large for large table supports);
2. twve.core + twve.extra + twve.table for all editing features (including all types of block elements and plain text);
3. either one of above + twve.tcalc for simple spreadsheet functionalities.
   

For plugin authors who want access to wiki text of a DOM element or the capability of transclusion synchronization, you can either take the whole twve.core or extract the necessary parts to combine with your codes.

Actually, this sounds like the thing I'm talking about.

I planned to have the next release on 1/31, the first day of the next Chinese lunar year, but now I am not sure of it as I still have quite some things to finish before the New Year's break. We will see.

Aha! Now I know when the New Year begins (is it actually called New Year?). I was going to ask this question previously, but forgot about it.
 

I am not quite sure about the CodeMirror stuff. I thought it already inline-editable. Is it not?

The idea is reverse: to use CodeMirror syntax highlightning inside the inline edit box. A simple use-case: a have a large plugin, with long source code. I can divide it into blocks like:

/***
la-la-la, some metadata and notes
***/
//{{{
part of the code
//}}}
// // Some header/notes/..
//{{{
another chunck of code
//}}}
...

(like in [1] or with even smaller parts) and it would be helpful to be able to open only one block with the CodeMirror highlightning. This can be combined with some sliders for even better workflow with large codes.

Best regards,
Yakov.

[1] http://twtable.tiddlyspace.com/#TWtid.2.0.10
 

[Vincent Yeh]

Hi Yakov,

On Tuesday, January 28, 2014 6:23:32 AM UTC+8, Yakov wrote:

Hi Vincent,

понедельник, 27 января 2014 г., 12:45:15 UTC+4 пользователь Vincent Yeh написал:

Yakov,

Thanks for raising the issues and the nice comments/questions. Yes I have noticed those bottlenecks you mentioned and have been thinking of possible solutions for them, including the possibilities of a true WYSIWYG editor. But as all we know a WYSIWYG wiki editor for now is something difficult if not impossible, the current solution I am implementing is a floating button that goes with the focusing borders and carries menu items for the creation of new elements, such as tables, list items, etc, similar to the one that goes with the focusing borders around tiddler title and carries menu items for plugin options. This is the easiest way for now and shall work on mobile devices as well as desktops. It should come into play in the next one or two releases.

Right, I thought of this solution for touch-devices, too. I think for keyboard devices some hotkey combinations activating the menu items (like "add list item") would do well.

Hotkeys for desktops is a good idea. Thanks.
 

A small note about WYSIWYG. May be you remember, I previously mentioned an idea that once a possibility to place different (wikified) elements in the edit area ("plain text area") is implemented, WYSIWYG is one step away.. today I've noticed that google implemented similar stuff in some services, including Gmail (attachments, citations). Although this should be of little help (Gmail is not open-source), may be this can provide some ideas..

You are right that placing different elements in the edit area is necessary, but that I still don't know how to do yet. The easiest way for me is to let the TiddlyWiki's wikifier do the hard work and take the output to show. That is what the current previewer does.

I don't know Gmail has such features. Do you mean Google supports wiki-style syntax?
 

 

The plain text is a bit more complicated than DOM elements, for a piece of plain text does not have any signature in its wiki text as other DOM elements do, there might still be issues like these remained in the coming solution. In addition, I am also working on a way to locate the character upon mouse click (for a future work mode even closer to the WYSIWYG expectations), which takes plain text equally as other DOM elements and hopefully will take these issues out for good.

Ah, sounds really good. Locating a character should help with the previewer auto-scrolling, too (I guess).

As for the keydown/keyup issue, I remember I had tried both ways and for some reason I do not recall now that I chose to use the keydown event. The issue you mentioned is solved in my current development snapshot and shall be gone in the next release. Thanks for brining it up.

The core codes are now separated from the plugins and collected into a new one called twve.core, with twve standing for TiddlyWiki View mode Editor. This will be the new base that combines the basic features in TWtid and TWted. Extra features that are list-item-specific or other block-element-specific go in twve.extra. All the table related codes go into twve.table and twve.table.large. TWtcalc is renamed to twve.tcalc and continues to offer basic spreadsheet functionalities in TiddlyWiki environment.

With the new core, will it be a simple task to activate inline editing only for some elements? Like, say, only for transclusions?

I am not 100% sure if I understand you correctly, but I think yes, it should be possible with the new code structure.
 

I think it would be helpful for thorough testing and consistent adoption in multiple TW documents (as TW doesn't have comprehensive "undo changes" engine and I use autosaving; and as I have stumbled upon some minor data loss in complicated test cases, I still use inline editing very carefully, in a limited number of documents).

Sorry to hear that. It is true that I only do simple tests that satisfy my own needs and I use them quite happily every day. But for more complicated cases, yes please keep using it with caution. Better yet, please keep giving me feedbacks when you see bugs or have suggestions, I will always try to fix or implement them if possible.
 

An especially nice application is the combination of ForEachTiddlerPlugin (write action with transclusion) + inline editing plugins to create editable aggregated tables, like with GridPlugin, but with lots of different advantages (which requires only the editing of transclusion with the tiddler macro).

This I will leave to people familiar with ForEachTiddlerPlugin, I still don't quite understand it (the syntax particularly) and don't know how to use it.
 

 

With this code structure one can install one of the following combinations:

1. twve.core + twve.table for table editing (plus twve.table.large for large table supports);
2. twve.core + twve.extra + twve.table for all editing features (including all types of block elements and plain text);
3. either one of above + twve.tcalc for simple spreadsheet functionalities.
   

For plugin authors who want access to wiki text of a DOM element or the capability of transclusion synchronization, you can either take the whole twve.core or extract the necessary parts to combine with your codes.

Actually, this sounds like the thing I'm talking about.

Yes it is something you suggested quite some time ago, plus the suggestion from Ton for a table-only editor. Though took me a while to come to this point, I am quite happy with this structure for it is now more element-oriented instead of more functionality-oriented as it was before. Will be easier for future development. Thanks to you and Ton.
 

I planned to have the next release on 1/31, the first day of the next Chinese lunar year, but now I am not sure of it as I still have quite some things to finish before the New Year's break. We will see.

Aha! Now I know when the New Year begins (is it actually called New Year?). I was going to ask this question previously, but forgot about it.

It is the New Year according to the ancient Chinese lunar calender, which the Chinese people have been using for thousands of years, with modifications from time to time, of course. Even now that people are officially using the modern solar calender, it is still widely used in the Chinese societies. Although having (almost) the same 365 days a year, it does not synchronize with the modern solar calender. For example, this lunar year started from 2/9 of 2013, next is 1/31 of 2014, even next would be 2/19 of 2015. With Chinese zodiac this ending one is the year of Snake, the coming one is that of the Horse, the even next one is that of the Goat.
 

 

I am not quite sure about the CodeMirror stuff. I thought it already inline-editable. Is it not?

The idea is reverse: to use CodeMirror syntax highlightning inside the inline edit box. A simple use-case: a have a large plugin, with long source code. I can divide it into blocks like:

/***
la-la-la, some metadata and notes
***/
//{{{
part of the code
//}}}
// // Some header/notes/..
//{{{
another chunck of code
//}}}
...

(like in [1] or with even smaller parts) and it would be helpful to be able to open only one block with the CodeMirror highlightning. This can be combined with some sliders for even better workflow with large codes.

Opening only one block is already possible in the view mode (see http://twtable.tiddlyspace.com/#TWted--Example--BlockElements). But I am not sure if I can do highlighting in an edit box (a TEXTAREA). I can certainly give it a try, though.

I am pretty sure now that I am not able to deliver the next release on 1/31, so I will just relax and have a nice New Year's break with families. See you after the break!

Have fun!
Vincent
 

[Yakov]

Hello Vincent,

ok, time to go into more details.

A small note about WYSIWYG. May be you remember, I previously mentioned an idea that once a possibility to place different (wikified) elements in the edit area ("plain text area") is implemented, WYSIWYG is one step away.. today I've noticed that google implemented similar stuff in some services, including Gmail (attachments, citations). Although this should be of little help (Gmail is not open-source), may be this can provide some ideas..

You are right that placing different elements in the edit area is necessary, but that I still don't know how to do yet. The easiest way for me is to let the TiddlyWiki's wikifier do the hard work and take the output to show. That is what the current previewer does.

First, I'd like to mention here an awkward idea of mine which still may be of some interest. The good part: instead of putting just l symbol in the place where the cursor is, more complicated stuff can be put in there. For instance, <html><span class="inline_edit_cursor">l</span></html> will generate a span element with a certain class, and such an element can be tracked after the wikification, its position can be found in the previewer, and the previewer can behave accordingly. The bad part: once cursor gets inside a wrapping like {{{...}}} or $...$, the whole thing stops working, and we get the whole <html><span class="inline_edit_cursor">l</span></html> inside the pre element, or inside a formula etc. Because of this problems, I haven't mentioned this previously, but now I see a better possibility. Before I mention it, let me notice that WYSIWYGish selection can be implemented in a similar way: just place the <html><span class="inline_edit_selection"> in the begin point and the </span></html> part in the actual end of the selection. Of'course this would cause extra problems with the inside text not being wikified etc.

As I was writing the previous paragraph, I've thought of a better idea. Instead of ordinary wikification, we can use post-wikification (like in MathJax plugin). Consider this: in the place of the cursor, we put some combination of special (and may be alphabet or even hieroglyph) symbols, like, say _|_ (this is a bad combination, I'll discuss the requirements below) and hijack the wikify function so that after ordinary wikification the combination of symbols is located and turned into some element which represents the cursor and can be easily located. Not sure what's the best way to quickly locate the symbol combination in the whole DOM. Now, there's a limitation for the symbol combination: wikification shouldn't turn them into smth else (like pipe symbol | in the combination above can be interpreted as a table cell separator or part of the prettyLink [[text|target]] syntax. So I think an appropriate way to go is to use a combination of symbols from different languages (which hardly will be put together in any text). Like <Chinese hieroglyph meaning pointer><Russian letter ы><French letter ç>. Similarly, an end of selection symbol combintation can be introduced.
 

I don't know Gmail has such features. Do you mean Google supports wiki-style syntax?
 

No, I mean Gmail has a WYSIWYG editor which can hold blocks (attachments, citations) inside itself which is similar to the idea of wikified blocks floating inside the edit field.

By the way, have you any ideas about implementing manual row/colomn resize in tables? Native wiki-syntax seems to be incompatible with such things, so this probably would require changing the "table" formatter, too.. But this would be a really helpful option.

Now. let me rephrase my ideas/questions regarding partial inline editing. Like I said, several inline editing possibilities are of especial value (for me, prime things are transclusion and tables), and it would be nice to be able to turn them of and some of the others -- off (until they are well-tested) -- to use them more extensively. This

The core codes are now separated from the plugins and collected into a new one called twve.core, with twve standing for TiddlyWiki View mode Editor. This will be the new base that combines the basic features in TWtid and TWted. Extra features that are list-item-specific or other block-element-specific go in twve.extra. All the table related codes go into twve.table and twve.table.large. TWtcalc is renamed to twve.tcalc and continues to offer basic spreadsheet functionalities in TiddlyWiki environment.

[...]

For plugin authors who want access to wiki text of a DOM element or the capability of transclusion synchronization, you can either take the whole twve.core or extract the necessary parts to combine with your codes.

made me think that with the new core it would be sort of easy thing to achieve, will it? I mean, to turn on inline editing for certain elements.

 

An especially nice application is the combination of ForEachTiddlerPlugin (write action with transclusion) + inline editing plugins to create editable aggregated tables, like with GridPlugin, but with lots of different advantages (which requires only the editing of transclusion with the tiddler macro).

This I will leave to people familiar with ForEachTiddlerPlugin, I still don't quite understand it (the syntax particularly) and don't know how to use it.

I see. Actually, tests showed that FET + inline editing plugins (may I call them IEPs? there are so many names...) doesn't work as expected, and actually that's because partial transclusion doesn't work as expected. So let me first show a simple use-case of FET that you can easily reproduce (which may be helpful in understanding both how FET works and what tasks it can help with), than I'll move to the newly discovered partial transclusion and perview issues.

1. FET example
This is example of how to create a simple "summary table" produced from several tiddlers. For your convenience, I've created an assembly which is attached to this message (so instead of following the instructions below [which contain some explanations, too], you can just download and test; nevermind the "Error when including" message, the absence of the config TW doesn't have any impact):
* create several tiddlers with slices, like tiddlers about fruits (tagged "fruit") with slices "color" and "average weight" (actually, "average_weight", core slices don't support spaces, as far as I remember, which can be easily "fixed"), fill them somehow..
----
Apple
|color|green, yellow, red|
|average_weight|200g|
----
Orange
|color|orange|
|average_weight|100g|
----
* create a tiddler with a FET macro:
----
Fruits
<<forEachTiddler
  where 'tiddler.tags.contains("fruit")'
  write '"\n|[["+tiddler.title+"]]|<<tiddler [["+tiddler.title+"::color]]>"+">|"+
         "<<tiddler [["+tiddler.title+"::average_weight]]>"+">|"'
    begin '"|fruit name|color|average weight|"'
>>
----
and you'll get a table which contains transcluded values of color and weight from the fruit tiddlers, sort of "report" table.

FET works in a quite simple manner in this example: for each tiddler, it evaluates the line
  '"\n|[["+tiddler.title+"]]|<<tiddler [["+tiddler.title+"::color]]>"+">|"+
   "<<tiddler [["+tiddler.title+"::average_weight]]>"+">|"'
and writes that wikitext to its buffer, than creates an element and wikifies the whole thing in there. The begin line is evaluated and added to the beginning of the wikitext (that's how I created the header of the table). Then, ordinary wikisyntax is used; tiddler is a context variable holding the iterated tiddler. And the division of the ">>" part into ">"+">" parts is here merely to prevent the formatter to see that >> thing as a delimeter of the forEachTiddler macro itself.

Now, the important part here is that I used transclusion instead of just inserting store.getTiddlerText(tiddler.title+"::color") -- this is where I'm expecting to use inline editing so that I can edit slices right inside the "summary table", without opening the tiddlers Apple or Orange. And here I've got the partial transclusion problem.

2. Partial transclusion problem. Now, it's enough to have only the Apple tiddler given above. If I create a tiddler
----
Test
<<tiddler [[Apple::color]]>>
----
I see what is expected: wikified text is "green, yellow, red". But if I click the thing for inline editing, in the edit box I get this wikitext:
|color|green, yellow, red|
|average_weight|200g|
which is the whole text of the Test tiddler. Somehow I've overlooked this in my transclusion tests, but, well, I haven't finished the complete set yet. By the way, there's no such issue for transcluded sections.

You can find this example in the attachment, too (find the Test tiddler somewhere on the top of the timeline).

3. Another problem I've discovered while testing this is the permaview issue (not preview): it, well, doesn't work for me in both Opera and FireFox [in my test place with STP and NestedSlidersPlugin]; an interesting detail is -- permalink button on tiddlers does work. I'd recommend to try to reproduce this in any of your TWs, and if that's not successful, try the assembly in the attachment.

 

I planned to have the next release on 1/31, the first day of the next Chinese lunar year, but now I am not sure of it as I still have quite some things to finish before the New Year's break. We will see.

Aha! Now I know when the New Year begins (is it actually called New Year?). I was going to ask this question previously, but forgot about it.

It is the New Year according to the ancient Chinese lunar calender, which the Chinese people have been using for thousands of years, with modifications from time to time, of course. Even now that people are officially using the modern solar calender, it is still widely used in the Chinese societies. Although having (almost) the same 365 days a year, it does not synchronize with the modern solar calender. For example, this lunar year started from 2/9 of 2013, next is 1/31 of 2014, even next would be 2/19 of 2015. With Chinese zodiac this ending one is the year of Snake, the coming one is that of the Horse, the even next one is that of the Goat.
 

 

I am not quite sure about the CodeMirror stuff. I thought it already inline-editable. Is it not?

The idea is reverse: to use CodeMirror syntax highlightning inside the inline edit box. A simple use-case: a have a large plugin, with long source code. I can divide it into blocks like:

/***
la-la-la, some metadata and notes
***/
//{{{
part of the code
//}}}
// // Some header/notes/..
//{{{
another chunck of code
//}}}
...

(like in [1] or with even smaller parts) and it would be helpful to be able to open only one block with the CodeMirror highlightning. This can be combined with some sliders for even better workflow with large codes.

Opening only one block is already possible in the view mode (see http://twtable.tiddlyspace.com/#TWted--Example--BlockElements). But I am not sure if I can do highlighting in an edit box (a TEXTAREA). I can certainly give it a try, though.

A pointer to save your time: the actual creation of the CM editor is provided by the CMEditCommands [1] (see the line cm.startEditor(...); i'm not sure whether exploring Mario's/Jim's code is a better option than exploring examples at the CM site or vise versa..), not by zCodeMirrorPlugin (although the latter is required).

By the way, CodeMirror itself can bring some more ideas about WYSIWYG. If you examine the DOM using FireBug or something similar, you'll see that the textarea of CodeMirror is much more complicated thing than just a simple texterea.

Ok, that's probably all for today.

Best regards,
Yakov.

[1] http://codemirror.tiddlyspace.com/#CMEditCommands

[Yakov]

PS and yes, happy New Year :)

вторник, 28 января 2014 г., 10:15:20 UTC+4 пользователь Vincent Yeh написал:

[Vincent Yeh]

Yakov,

Thanks for the New Year's Greetings. I had a very enjoyable break with families and friends, and now I am back to work.

On Saturday, February 1, 2014 6:02:13 AM UTC+8, Yakov wrote:

Hello Vincent,

ok, time to go into more details.

A small note about WYSIWYG. May be you remember, I previously mentioned an idea that once a possibility to place different (wikified) elements in the edit area ("plain text area") is implemented, WYSIWYG is one step away.. today I've noticed that google implemented similar stuff in some services, including Gmail (attachments, citations). Although this should be of little help (Gmail is not open-source), may be this can provide some ideas..

You are right that placing different elements in the edit area is necessary, but that I still don't know how to do yet. The easiest way for me is to let the TiddlyWiki's wikifier do the hard work and take the output to show. That is what the current previewer does.

First, I'd like to mention here an awkward idea of mine which still may be of some interest. The good part: instead of putting just l symbol in the place where the cursor is, more complicated stuff can be put in there. For instance, <html><span class="inline_edit_cursor">l</span></html> will generate a span element with a certain class, and such an element can be tracked after the wikification, its position can be found in the previewer, and the previewer can behave accordingly. The bad part: once cursor gets inside a wrapping like {{{...}}} or $...$, the whole thing stops working, and we get the whole <html><span class="inline_edit_cursor">l</span></html> inside the pre element, or inside a formula etc. Because of this problems, I haven't mentioned this previously, but now I see a better possibility. Before I mention it, let me notice that WYSIWYGish selection can be implemented in a similar way: just place the <html><span class="inline_edit_selection"> in the begin point and the </span></html> part in the actual end of the selection. Of'course this would cause extra problems with the inside text not being wikified etc.

This is an interesting idea and I can give it a try, but I have this question: "Is this how CodeMirror is working?" I think CodeMirror is doing the caret thing well, maybe I can copy its way?
 

As I was writing the previous paragraph, I've thought of a better idea. Instead of ordinary wikification, we can use post-wikification (like in MathJax plugin). Consider this: in the place of the cursor, we put some combination of special (and may be alphabet or even hieroglyph) symbols, like, say _|_ (this is a bad combination, I'll discuss the requirements below) and hijack the wikify function so that after ordinary wikification the combination of symbols is located and turned into some element which represents the cursor and can be easily located. Not sure what's the best way to quickly locate the symbol combination in the whole DOM. Now, there's a limitation for the symbol combination: wikification shouldn't turn them into smth else (like pipe symbol | in the combination above can be interpreted as a table cell separator or part of the prettyLink [[text|target]] syntax. So I think an appropriate way to go is to use a combination of symbols from different languages (which hardly will be put together in any text). Like <Chinese hieroglyph meaning pointer><Russian letter ы><French letter ç>. Similarly, an end of selection symbol combintation can be introduced.

In the current development snapshot I can, for simple cases though, already locate the character (and the selected text) in one DOM element in the mouseup event, using the window.getSelection() method and some of the core codes in my plugins (I've written a brief explanation for this, see http://twve.tiddlyspace.com/#[[Locating%20the%20character]]. Note that the codes of the plugins are not uploaded to the space yet.).
 

 

I don't know Gmail has such features. Do you mean Google supports wiki-style syntax?
 

No, I mean Gmail has a WYSIWYG editor which can hold blocks (attachments, citations) inside itself which is similar to the idea of wikified blocks floating inside the edit field.

By the way, have you any ideas about implementing manual row/colomn resize in tables? Native wiki-syntax seems to be incompatible with such things, so this probably would require changing the "table" formatter, too.. But this would be a really helpful option.

This I haven't thought about yet because I don't really need this feature. Isn't there something like the Resizalbe in jQuery UI available for TiddlyWiki?
 

Now. let me rephrase my ideas/questions regarding partial inline editing. Like I said, several inline editing possibilities are of especial value (for me, prime things are transclusion and tables), and it would be nice to be able to turn them of and some of the others -- off (until they are well-tested) -- to use them more extensively. This

The core codes are now separated from the plugins and collected into a new one called twve.core, with twve standing for TiddlyWiki View mode Editor. This will be the new base that combines the basic features in TWtid and TWted. Extra features that are list-item-specific or other block-element-specific go in twve.extra. All the table related codes go into twve.table and twve.table.large. TWtcalc is renamed to twve.tcalc and continues to offer basic spreadsheet functionalities in TiddlyWiki environment.

[...]

For plugin authors who want access to wiki text of a DOM element or the capability of transclusion synchronization, you can either take the whole twve.core or extract the necessary parts to combine with your codes.

made me think that with the new core it would be sort of easy thing to achieve, will it? I mean, to turn on inline editing for certain elements.

I see. It should not be difficult, I think. I will certainly think about it.
 

 

An especially nice application is the combination of ForEachTiddlerPlugin (write action with transclusion) + inline editing plugins to create editable aggregated tables, like with GridPlugin, but with lots of different advantages (which requires only the editing of transclusion with the tiddler macro).

This I will leave to people familiar with ForEachTiddlerPlugin, I still don't quite understand it (the syntax particularly) and don't know how to use it.

I see. Actually, tests showed that FET + inline editing plugins (may I call them IEPs? there are so many names...) doesn't work as expected, and actually that's because partial transclusion doesn't work as expected. So let me first show a simple use-case of FET that you can easily reproduce (which may be helpful in understanding both how FET works and what tasks it can help with), than I'll move to the newly discovered partial transclusion and perview issues.

Right now I feel like calling the collection of my plugins twve, the TiddlyWiki View mode Editor, but surely you can call it the way you like.

I guess this is because the plugins do not support slices but only sections in cases of partial transclusion, as described in http://twtable.tiddlyspace.com/#TransclusionSupport--PartialTransclusion. They do not support slices because I never used slices myself. I never used them because I never understood their use. I will look into this for sure.
 

You can find this example in the attachment, too (find the Test tiddler somewhere on the top of the timeline).

3. Another problem I've discovered while testing this is the permaview issue (not preview): it, well, doesn't work for me in both Opera and FireFox [in my test place with STP and NestedSlidersPlugin]; an interesting detail is -- permalink button on tiddlers does work. I'd recommend to try to reproduce this in any of your TWs, and if that's not successful, try the assembly in the attachment.

Yes you are right the permalink button works but the permaview does not, in your InlineEditingPlugin.html file. I have found that the mere installation of TWtid causes this problem, but I haven't located the actual cause yet. What I know now are

1. there is a "title is null" exception happening at String.encodeTiddlyLink = function(title) { return title.indexOf(" ") == -1 ? title : "[[" + title + "]]"; };, a method which I don't even know its existence,
2. it works in my TW files.

I shall need more time to figure it out.

 

I planned to have the next release on 1/31, the first day of the next Chinese lunar year, but now I am not sure of it as I still have quite some things to finish before the New Year's break. We will see.

Aha! Now I know when the New Year begins (is it actually called New Year?). I was going to ask this question previously, but forgot about it.

It is the New Year according to the ancient Chinese lunar calender, which the Chinese people have been using for thousands of years, with modifications from time to time, of course. Even now that people are officially using the modern solar calender, it is still widely used in the Chinese societies. Although having (almost) the same 365 days a year, it does not synchronize with the modern solar calender. For example, this lunar year started from 2/9 of 2013, next is 1/31 of 2014, even next would be 2/19 of 2015. With Chinese zodiac this ending one is the year of Snake, the coming one is that of the Horse, the even next one is that of the Goat.
 

 

I am not quite sure about the CodeMirror stuff. I thought it already inline-editable. Is it not?

The idea is reverse: to use CodeMirror syntax highlightning inside the inline edit box. A simple use-case: a have a large plugin, with long source code. I can divide it into blocks like:

/***
la-la-la, some metadata and notes
***/
//{{{
part of the code
//}}}
// // Some header/notes/..
//{{{
another chunck of code
//}}}
...

(like in [1] or with even smaller parts) and it would be helpful to be able to open only one block with the CodeMirror highlightning. This can be combined with some sliders for even better workflow with large codes.

Opening only one block is already possible in the view mode (see http://twtable.tiddlyspace.com/#TWted--Example--BlockElements). But I am not sure if I can do highlighting in an edit box (a TEXTAREA). I can certainly give it a try, though.

A pointer to save your time: the actual creation of the CM editor is provided by the CMEditCommands [1] (see the line cm.startEditor(...); i'm not sure whether exploring Mario's/Jim's code is a better option than exploring examples at the CM site or vise versa..), not by zCodeMirrorPlugin (although the latter is required).

By the way, CodeMirror itself can bring some more ideas about WYSIWYG. If you examine the DOM using FireBug or something similar, you'll see that the textarea of CodeMirror is much more complicated thing than just a simple texterea.

Great! That is very good to know. Thanks a lot!

First day of work after the New Year's break, not to the full gear yet, but accelerating for sure.

Have Fun!
Vincent
 

Best regards,
Yakov.

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0

...

[Vincent Yeh]

Yakov,

I've found the cause for the failure in the permaview button in your InlineEditingPlugins.html: TWtid adds the focusing borders and the floating menus (TWted further adds the edit box and the previewer) into #tiddlerDisplay without the attribute "tiddler", while in TiddlyWiki 2.6.5 the Story.prototype.forEachTiddler() function assumes all the children of #tiddlerDisplay have a non-empty value to the attribute "tiddler". Therefore the Story.forEachTiddler() fails in TW 2.6.5 with TWtid installed. In later versions of TiddlyWiki (at least 2.7.2 and beyond) this assumption was removed by adding a test to ensure non-empty value to that attribute before calling the callback function passed to forEachTiddler(), so Story.forEachTiddler() does not fail with TWtid.

To resolve this issue either you upgrade to a later version of TiddlyWiki, or I change the behavior in TWtid and TWted to add those elements into another container (#displayArea, maybe?). Either way takes some time, I believe.

Have Fun!
Vincent

Best regards,
Yakov.

<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);borde

...

[Yakov]

Hello Vincent,

right, I'm migrating to TW 2.7.1 and a test showed that the permaview issue doesn't take place in there. Actually, that's correct for the TW 2.6.6 as well.

First, I'd like to mention here an awkward idea of mine which still may be of some interest. The good part: instead of putting just l symbol in the place where the cursor is, more complicated stuff can be put in there. For instance, <html><span class="inline_edit_cursor">l</span></html> will generate a span element with a certain class, and such an element can be tracked after the wikification, its position can be found in the previewer, and the previewer can behave accordingly. The bad part: once cursor gets inside a wrapping like {{{...}}} or $...$, the whole thing stops working, and we get the whole <html><span class="inline_edit_cursor">l</span></html> inside the pre element, or inside a formula etc. Because of this problems, I haven't mentioned this previously, but now I see a better possibility. Before I mention it, let me notice that WYSIWYGish selection can be implemented in a similar way: just place the <html><span class="inline_edit_selection"> in the begin point and the </span></html> part in the actual end of the selection. Of'course this would cause extra problems with the inside text not being wikified etc.

This is an interesting idea and I can give it a try, but I have this question: "Is this how CodeMirror is working?" I think CodeMirror is doing the caret thing well, maybe I can copy its way?
 

It seems to be the case: DOM inspection shows
<div class="CodeMirror-cursor" style="height: 18px; left: 13px; top: 72px; visibility: hidden;"> </div>
<div class="CodeMirror-cursor CodeMirror-secondarycursor" style="display: none; visibility: hidden;"> </div>
elements which probably produce the cursor (at some point the visibility: hidden; portion disappears), but I'm not quite sure. Anyway, CodeMirror doesn't have to deal with the problem mentioned above, as it defines the "formatters" by itself, while we have some already defined formatters. We can hijack/overwrite formatters, though: for instance, make the characterFormat formatter [1] "understand" the <html><span class="inline_edit_cursor">l</span></html> portion inside the {{{...}}} wrapper, but that would be an ungrateful practice, as some non-core formatters would require that thing as well (like the formulae $$...$$ wrapper formatter).. Though, may be it's possible to write a relatively general solution by post-wikifying the <html><span class="inline_edit_cursor">l</span></html> sequence inside various elements.. which brings me again to the second idea.

As I was writing the previous paragraph, I've thought of a better idea. Instead of ordinary wikification, we can use post-wikification (like in MathJax plugin). Consider this: in the place of the cursor, we put some combination of special (and may be alphabet or even hieroglyph) symbols, like, say _|_ (this is a bad combination, I'll discuss the requirements below) and hijack the wikify function so that after ordinary wikification the combination of symbols is located and turned into some element which represents the cursor and can be easily located. Not sure what's the best way to quickly locate the symbol combination in the whole DOM. Now, there's a limitation for the symbol combination: wikification shouldn't turn them into smth else (like pipe symbol | in the combination above can be interpreted as a table cell separator or part of the prettyLink [[text|target]] syntax. So I think an appropriate way to go is to use a combination of symbols from different languages (which hardly will be put together in any text). Like <Chinese hieroglyph meaning pointer><Russian letter ы><French letter ç>. Similarly, an end of selection symbol combintation can be introduced.

In the current development snapshot I can, for simple cases though, already locate the character (and the selected text) in one DOM element in the mouseup event, using the window.getSelection() method and some of the core codes in my plugins (I've written a brief explanation for this, see http://twve.tiddlyspace.com/#[[Locating%20the%20character]]. Note that the codes of the plugins are not uploaded to the space yet.).
 

That's good news, this sounds like the idea is quite implementable.
 

 

I don't know Gmail has such features. Do you mean Google supports wiki-style syntax?
 

No, I mean Gmail has a WYSIWYG editor which can hold blocks (attachments, citations) inside itself which is similar to the idea of wikified blocks floating inside the edit field.

By the way, have you any ideas about implementing manual row/colomn resize in tables? Native wiki-syntax seems to be incompatible with such things, so this probably would require changing the "table" formatter, too.. But this would be a really helpful option.

This I haven't thought about yet because I don't really need this feature. Isn't there something like the Resizalbe in jQuery UI available for TiddlyWiki?

It doesn't seem to be the case. May be it's better to forget about it, as it looks like it would require too much code to incorporate (Resizable Widget + UI Core + Widget Factory + Mouse Interaction) as well as some efforts to understand (and modify) the "table" formatter [2] to make resizing storable, although this would be a useful feature for organizing different drafts.

 

Now. let me rephrase my ideas/questions regarding partial inline editing. Like I said, several inline editing possibilities are of especial value (for me, prime things are transclusion and tables), and it would be nice to be able to turn them of and some of the others -- off (until they are well-tested) -- to use them more extensively. This

The core codes are now separated from the plugins and collected into a new one called twve.core, with twve standing for TiddlyWiki View mode Editor. This will be the new base that combines the basic features in TWtid and TWted. Extra features that are list-item-specific or other block-element-specific go in twve.extra. All the table related codes go into twve.table and twve.table.large. TWtcalc is renamed to twve.tcalc and continues to offer basic spreadsheet functionalities in TiddlyWiki environment.

[...]

For plugin authors who want access to wiki text of a DOM element or the capability of transclusion synchronization, you can either take the whole twve.core or extract the necessary parts to combine with your codes.

made me think that with the new core it would be sort of easy thing to achieve, will it? I mean, to turn on inline editing for certain elements.

I see. It should not be difficult, I think. I will certainly think about it.
 

 

An especially nice application is the combination of ForEachTiddlerPlugin (write action with transclusion) + inline editing plugins to create editable aggregated tables, like with GridPlugin, but with lots of different advantages (which requires only the editing of transclusion with the tiddler macro).

This I will leave to people familiar with ForEachTiddlerPlugin, I still don't quite understand it (the syntax particularly) and don't know how to use it.

I see. Actually, tests showed that FET + inline editing plugins (may I call them IEPs? there are so many names...) doesn't work as expected, and actually that's because partial transclusion doesn't work as expected. So let me first show a simple use-case of FET that you can easily reproduce (which may be helpful in understanding both how FET works and what tasks it can help with), than I'll move to the newly discovered partial transclusion and perview issues.

Right now I feel like calling the collection of my plugins twve, the TiddlyWiki View mode Editor, but surely you can call it the way you like.

Ok :)

Ah, I see. Can I help with some questions here? Basically, slices are quite similar to sections; the main difference, I would say, is that slices are "memorized" in the store.slices map [3] and are recalced when there's no slices defined for a certain tiddler (hence, on change of a tiddler, all slices corresponding to that tiddler are to be deleted, like in [4]; or, when I change the store.slicesRE to add the support of multinational slices, I delete all of them afterwards: store.slices = {} and after that they are calced again when they are needed [5]).

Best regards,
Yakov.

[1] https://github.com/TiddlyWiki/tiddlywiki/blob/master/js/Formatter.js#L421
[2] https://github.com/TiddlyWiki/tiddlywiki/blob/master/js/Formatter.js#L7
[3] https://github.com/TiddlyWiki/tiddlywiki/blob/master/js/TiddlyWiki.js#L14
[4] https://github.com/TiddlyWiki/tiddlywiki/blob/master/js/TiddlyWiki.js#L28
[5] https://github.com/TiddlyWiki/tiddlywiki/blob/master/js/TiddlyWiki.js#L211

Best regards,
Yakov.

|a|b|c|
|d|
|e|f|</s

...

[Yakov]

PS almost forgot. There's another feature which can be quite useful by itself, but also is somewhat an approach towards WYSIWYG -- that's hotkeys support for things like bold wrapper or creating a list item (or toggling: paragraph/list item). Some ideas of implementation (not hotkeys but the textarea manipulation) can be found in QuickEditPackage [1], although implementation in there is not as advanced as one would expect from a WYSIWYG editor (for instance, when one selects some text and click B(old), (s)he gets ''text'', and if B is clicked again, the result is ''''text'''' and not text which would be preferrable). I think it's at least worth mentioning as this probably should be accounted in the plugin architecture.

Best regards,
Yakov.

[1] http://tiddlytools.com/#QuickEditPackage

среда, 5 февраля 2014 г., 11:06:01 UTC+4 пользователь Vincent Yeh написал:

...

[Yakov]

Hello Vincent,

have you heard of DOM Range? I've stumbled upon an interesting article in Russian, but here's some "official" links [1,2,3] from it. This may be helpful for WYSIWYG, so may deserve some reading.

Best regards,
Yakov.

[1] http://www.w3.org/TR/DOM-Level-2-Traversal-Range/ranges.html
[2] https://developer.mozilla.org/en-US/docs/Web/API/Selection // implementation of selections in FireFox
[3] https://developer.mozilla.org/en-US/docs/Web/API/range // implementation of Range itself in FireFox

суббота, 9 февраля 2013 г., 18:21:03 UTC+4 пользователь Vincent Yeh написал:

Interested in editing your tiddler in the view mode in TiddlyWiki? Try this view mode editor plugin TWted (requires TWtid).

Interested in a calculator that supports (partially for now) Excel syntax in Tiddlywiki? Try the simple calculator plugin TWtcalc (requires TWtid).

These plugins are under active development. You are very welcome to give comments/suggestions/bug reports. :-)

The first versions of these plugins were TableEditor and TableCalculator, released in 2012/06/24, that only supported table editing in the view mode. Later they were extended constantly and then evolved into TWtable, TWted and TWtcalc (released 2012/10/19), still only supported table editing. Recently they were further extended to support view mode editing on most of the block elements (see below) in a tiddler, much more than just a table editor, so I decided to start a new thread for these plugins. You can find their earlier history in the old thread "Inline Editing of Tables" started by pepebe.

• TWtid v1.5.0 — The basis of the view mode tiddler editor TWted and simple calculator TWtcalc, including a table renderer.
  • Generalized the codes from TWtable 1.4.6, which works for tables only, to support most kinds of block elements, see descriptions for TWted below.
  • The included table renderer supports
    • scrolling for large tables,
    • multi-lined cell content (you can have a list in a table cell),
    • synchronization among all copies (transcluded and non-transcluded).
  • See TWtid for more details.
• TWted v1.5.0 — The view mode tiddler editor.
  • Edit block elements either in view mode (default) or in edit mode (option description "Active in view mode")
    • If in view mode, the default edit box remains the same;
    • if in edit mode, the view mode remains for viewing only.
      • The system default edit box can be brought up by double clicking in a no-element area (note that some elements are much wider than their content).
  • Works on most of the block elements:
    • Tables —
      • easy access to cell content for editing purposes
      • insertion/deletion of rows/columns
      • copy/cut/paste the cells/rows/columns
    • Lists — both kinds, * and # (corresponding to <UL> and <OL>), as many levels as TiddlyWiki supports;
    • Headers — ! ~ !!!!!!, corresponding to H1 ~ H6;
    • Blockquotes — three levels supported: >, >> and >>>;
    • Blockexamples — lines of text enclosed by two <<<;
    • Preformatted blocks — lines of text enclosed by two triple-braces.
  • A simple previewer to see the output as you are typing.
    • Option txtTWtedPreviewOpacity to change opacity of the previewer. Default to 0.9.
    • Option txtTWtedPreviewCaret to specify the caret symbol in the previewer. Default to the vertical line (|).
  • Edit tiddler title.
  • Two options offering three levels of automation in the editing behavior:
    • Two options:
      • chkTWtedCatTheMouse — Activate/Deactivate edit mode with mouse motion.
      • chkTWtedNoClick — Edit the cell content without clicking it.
    • Three levels of automation:
      • Manual: set both options to false. Click the 'E' button to start/stop editing the closest block element.
      • Half automated: set the 1st option to true and 2nd to false. In this level a table enters edit mode automatically when mouse is hovering over it while other block elements remain manual. 'E' button is hidden, need to lick within the block element (or the table cell) to edit.
      • Automated: set both options to true. Move the mouse over a block element or a table cell to edit. (Warning: this can be annoying in some cases!)
  • Keyboard navigation within the same type of elements.
    • Works with headers, list items, blockquotes and preformats.
    • Move list items, only list items for now, with Ctrl-up/down keys. This, however, only works within the same level at this moment, moving items across different levels will be supported in the future release.
  • Tables are synchronized between transcluded and non-transcluded copies, other block elements are not yet.
  • See TWted for more details.
• TWtcalc v0.7.7 — A simple calculator for TiddlyWiki.
  • Calculates over table cells. For example, if one puts =A1+A2 in the table cell A3, the content of A3 will be the sum of the numerical values in table cells A1 and A2.
  • Supports syntax similar to OpenOffice calc or Microsoft Excel.
  • Automatically adjusts cell reference upon copy-and-pasting.
  • Supports user defined functions written in Javascript. See TWtcalc--Defining your own functions for details.
  • See TWtcalc for a list of predefined functions and further details.

[Vincent Yeh]

Hi Yakov,

Sorry that I did not respond in the past week, there has been something important going on in my home...

Thanks for sharing the information. Yes I had heard of it but haven't understood it yet. I will check it when I have time.

I am not having fun!
Vincent

...

[MetalSoviet]

Can these things be used in the offline TW5 file or only in TiddlySpot?

• • • Three levels of automation:

• • • • Automated: set both options to true. Move the mouse over a block element or a table cell to edit. (Warning: this can be annoying in some cases!)

• • Keyboard navigation within the same type of elements.
    • Works with headers, list items, blockquotes and preformats.
    • Move list items, only list items for now, with Ctrl-up/down keys. This, however, only works within the same level at this moment, moving items across different levels will be supported in the future release.
  • Tables are synchronized between transcluded and non-transcluded copies, other block elements are not yet.
  • See TWted for more details.

[Vincent Yeh]

Hi MetalSoviet,

To work with TW5 is on the top of the todo list, in the near future they shall do.
I am not sure of TiddlySpot, never tried. I am sure they work in TiddlySpace, though.

Have fun!
Vincent

• • </li

...

[Yakov]

Hello Vincent,

Recently, I've stumbled upon a bug, which seems the one that caused some data loss previously, and this time made it reproducable, so here we go:

1. create a tiddler with this text:
code 1
code 2
2. open the inline-edit-mode, select the first line (without the line break), cut it by pressing ctrl+x (leaving an emtpy line)
3. add a new line after code 2 by pressing enter, paste the first line by pressing ctrl+v
4. press ctrl+z to undo
What happens in my tests (in both Opera 12.16 and latest FireFox, TW 2.7.1, twve 2.0.8): instead of getting the line inserted, I get the whole text substituted with that line.
What one has to do in such a case is press ctrl+z two more times (or just press esc), but when this happens unexpectedly, on can easily press up or smth else, getting the "corrupted" content saved.. (which happened to me at least couple of times).
PS in fact, it's enough to cut any part of the text, paste it anywhere and then press ctrl+z

By the way, any progress with editing of slices?

Best regards,
Yakov.

среда, 26 марта 2014 г., 19:55:23 UTC+4 пользователь Vincent Yeh написал:

...

[Vincent Yeh]

Yakov,

Thanks for the help. I think I have fixed that bug in the current snapshot. Hopefully it is gone for good.

I haven't got the slices yet, but have been debugging the next version (tons of bug fixes!). I am also preparing a document for plugin authors to use the twve.core for view mode editing and/or transclusion synchronization purposes. After that I will work on the slice things and try to make it available in the next release (if it's easy).

Have fun!
Vincent

• • • Preformatted blocks — lines of text enclosed by two&nbsp

...

[Yakov]

четверг, 10 апреля 2014 г., 10:56:59 UTC+4 пользователь Vincent Yeh написал:

Yakov,

Thanks for the help. I think I have fixed that bug in the current snapshot. Hopefully it is gone for good.

I haven't got the slices yet, but have been debugging the next version (tons of bug fixes!).

That's good. The 2.0.8 build often makes Opera 12.16 crash, so I use it mostly with FireFox. I'll wait for the next version before I start to figure how to reproduce those crashes (if they don't vanish).
 

I am also preparing a document for plugin authors to use the twve.core for view mode editing and/or transclusion synchronization purposes. After that I will work on the slice things and try to make it available in the next release (if it's easy).

RIght. Probably taking a look at the setSlice method in the Eric's GridPlugin [1] would ease the implementation.

Best regards,
Yakov.

[1] http://www.TiddlyTools.com/#GridPlugin
 

• • • Lists — both kinds, * and # (corresponding to <UL&gt

...

[Vincent Yeh]

On Friday, April 11, 2014 5:58:27 AM UTC+8, Yakov wrote:

четверг, 10 апреля 2014 г., 10:56:59 UTC+4 пользователь Vincent Yeh написал:

Yakov,

Thanks for the help. I think I have fixed that bug in the current snapshot. Hopefully it is gone for good.

I haven't got the slices yet, but have been debugging the next version (tons of bug fixes!).

That's good. The 2.0.8 build often makes Opera 12.16 crash, so I use it mostly with FireFox. I'll wait for the next version before I start to figure how to reproduce those crashes (if they don't vanish).

Opera...practically I don't use it (because I don't know how to enable cookies with it) so I never had serious tests of the plugins with it. I now use FireFox so it should work fine. I used to use Chrome but stopped after the failure of TiddlySavor due to Java's security things. Although TiddlySavor works now and some of my files do save with it, I still have others failing to save without a clear reason. I will stick to FireFox till I figure it out.
 

 

I am also preparing a document for plugin authors to use the twve.core for view mode editing and/or transclusion synchronization purposes. After that I will work on the slice things and try to make it available in the next release (if it's easy).

RIght. Probably taking a look at the setSlice method in the Eric's GridPlugin [1] would ease the implementation.

Great! Good to know! Thanks a lot!
 

• • Edit block elements either in view mode (default) or in edit mode (option description "Active in view mode")<ul style="margin:0px 0px 0

...

[Vincent Yeh]

Release of twve (TiddlyWiki View mode Editor) v3.0.0 (formerly TWtid, TWted, TWtable, and TWtcalc).

• The twve is divided into several plugins. To know which ones to install, see the Installation section in release note (http://twve.tiddlyspace.com/#[[Release%20Note%20v3.0.0]]).
• For other information, such as new features, examples, or bug fixes, see the release note at http://twve.tiddlyspace.com/#[[Release%20Note%20v3.0.0]].
  

Have Fun!
Vincent

p.s. Yakov, I haven't got the slice things done yet. Hopefully next release.

...

[Vincent Yeh]

Re-uploaded the twve.table.min v3.0.0 for a tiny correction. If you have already downloaded this plugin, please download again. Sorry for the mistake.

Have Fun!
Vincent

...

[Vincent Yeh]

Oops! Found a small bug in twve.tcalc that stops calculations when the tiddler is just loaded. Had fixed it and uploaded the twve.tcalc.min v3.0.1 just now.

Have Fun!
Vincent

...

[Ton Gerner]

Hi Vincent,

I am still using the old versions TWted.min_v1.4.6 & TWtable.min_v1.4.6.
Since I am mainly interested in the table editor, I only installed twve.core v3.0.0 & twve.table v3.0.0 in a fresh TW v2.8.1 (using Windows 7 64-bit, Firefox v29.01, and Chrome v34.0.1847.137) and did some quick tests.

Completely according to Murphy's law, the first test I did went wrong ;-)

1) I tested with an available table that contained pretty links in cells.
I think you can imagine what happened: the "|" in the pretty link was seen as a cell boundary and the row will contain an extra cell. So when editing you get a cell with e.g. "[[Google" and the next cell with "http://www.google.com]]"

I had never seen this before, so I checked a TW containing the old version v1.4.6. There it worked "normal". I think you lost a precondition during refactoring.

2) When hovering over a table I get the "Hamburger" icon with a tooltip "table menu" *and* a message "transpose", but when clicking the "Hamburger" nothing happens. What is it supposed to do? Like clicking the "C" in the old version, a link to "twve.core Options" and "twve.table Options?

3) When clicking the GettingStarted tiddler (at a "blank" spot within the dotted boundaries), I get a message "tiddler[GettingStarted] does not exist!"

Are there any plans to make a TW5 version?

Cheers,

Ton

...

[Vincent Yeh]

Ton,

Thanks for the quick test and respond!

On Wednesday, May 14, 2014 4:34:48 PM UTC+8, Ton Gerner wrote:

Hi Vincent,

I am still using the old versions TWted.min_v1.4.6 & TWtable.min_v1.4.6.
Since I am mainly interested in the table editor, I only installed twve.core v3.0.0 & twve.table v3.0.0 in a fresh TW v2.8.1 (using Windows 7 64-bit, Firefox v29.01, and Chrome v34.0.1847.137) and did some quick tests.

Completely according to Murphy's law, the first test I did went wrong ;-)

 

Hahaha! That's nice!
 

1) I tested with an available table that contained pretty links in cells.
I think you can imagine what happened: the "|" in the pretty link was seen as a cell boundary and the row will contain an extra cell. So when editing you get a cell with e.g. "[[Google" and the next cell with "http://www.google.com]]"

I had never seen this before, so I checked a TW containing the old version v1.4.6. There it worked "normal". I think you lost a precondition during refactoring.

Yeah, I was wondering why you are having this trouble and I am not, but soon I found that I accidentally moved that part of codes into twve.extra, which you did not install and I did (and that explains why I don't have this problem). Sorry and thank you. This is a no-need-to-code bug and easy to fix: just move that part of codes into either twve.core or twve.table. I'll fix it tonight.
 

2) When hovering over a table I get the "Hamburger" icon with a tooltip "table menu" *and* a message "transpose", but when clicking the "Hamburger" nothing happens. What is it supposed to do? Like clicking the "C" in the old version, a link to "twve.core Options" and "twve.table Options?

There is an option chktwveTableTranspose that you need to check to enable transposition (otherwise the "transpose" message is dimmed and not functioning). See the instructions given in Transposition example.

I put in this option long time ago and did not mention it at all, because the transposition codes were not correct and could mess up with the other part of the tiddler text (see this document if you are interested in the details). I am thinking of removing it since (I think) the codes are correct and safe now.
 

3) When clicking the GettingStarted tiddler (at a "blank" spot within the dotted boundaries), I get a message "tiddler[GettingStarted] does not exist!"

Ah, that's a debug message for me. I will take it off tonight.
 

Are there any plans to make a TW5 version?

Yes, I am actually working on it, but I haven't got clear the plugin and refreshing mechanisms yet... If you can point me to a simple example, it will be highly appreciated!
 

Best regards,
Yakov.

[1] <a href="http://www.TiddlyTools.com/#GridPlugin" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fwww.TiddlyTools.com%2F%23GridPlugin\46sa\75D\46sntz\0751\46usg\75AFQjCNHCd8HZ3eK6sceRQsqKqRlPBMxe2A';return true;"

...

[Ton Gerner]

Hi Vincent,

On Wednesday, May 14, 2014 11:47:03 AM UTC+2, Vincent Yeh wrote:

Ton,

Thanks for the quick test and respond!

On Wednesday, May 14, 2014 4:34:48 PM UTC+8, Ton Gerner wrote:

Hi Vincent,

I am still using the old versions TWted.min_v1.4.6 & TWtable.min_v1.4.6.
Since I am mainly interested in the table editor, I only installed twve.core v3.0.0 & twve.table v3.0.0 in a fresh TW v2.8.1 (using Windows 7 64-bit, Firefox v29.01, and Chrome v34.0.1847.137) and did some quick tests.

Completely according to Murphy's law, the first test I did went wrong ;-)

 

Hahaha! That's nice!
 

1) I tested with an available table that contained pretty links in cells.
I think you can imagine what happened: the "|" in the pretty link was seen as a cell boundary and the row will contain an extra cell. So when editing you get a cell with e.g. "[[Google" and the next cell with "http://www.google.com]]"

I had never seen this before, so I checked a TW containing the old version v1.4.6. There it worked "normal". I think you lost a precondition during refactoring.

Yeah, I was wondering why you are having this trouble and I am not, but soon I found that I accidentally moved that part of codes into twve.extra, which you did not install and I did (and that explains why I don't have this problem). Sorry and thank you. This is a no-need-to-code bug and easy to fix: just move that part of codes into either twve.core or twve.table. I'll fix it tonight.

 

Yeah, that explains it.

 

2) When hovering over a table I get the "Hamburger" icon with a tooltip "table menu" *and* a message "transpose", but when clicking the "Hamburger" nothing happens. What is it supposed to do? Like clicking the "C" in the old version, a link to "twve.core Options" and "twve.table Options?

There is an option chktwveTableTranspose that you need to check to enable transposition (otherwise the "transpose" message is dimmed and not functioning). See the instructions given in Transposition example.

I put in this option long time ago and did not mention it at all, because the transposition codes were not correct and could mess up with the other part of the tiddler text (see this document if you are interested in the details). I am thinking of removing it since (I think) the codes are correct and safe now.

 
I did not notice the possibility of transposing a table but like the idea.
Can you add the option menu (the "C" in the old version) to the "Hamburger"? I found the "C" a little bit distracting in normal view; the "Hamburger" is only visible when hovering.

 

3) When clicking the GettingStarted tiddler (at a "blank" spot within the dotted boundaries), I get a message "tiddler[GettingStarted] does not exist!"

Ah, that's a debug message for me. I will take it off tonight.
 

Are there any plans to make a TW5 version?

Yes, I am actually working on it, but I haven't got clear the plugin and refreshing mechanisms yet... If you can point me to a simple example, it will be highly appreciated!

Sorry, I can't help you; I am just an end user, no developer or programmer.
Post your question in the Dev group and Jeremy or others can answer your questions for sure.

Cheers,

Ton

...

[Vincent Yeh]

Hi Ton,

It is a good idea to add the Options Menu to the table menu (the hamburger you said), so I did. Thanks.

Release of the twve v3.0.1, mainly some quick bug fixes. See Release Note v3.0.1 for more information.

Another thing is that I forgot to include the twve.tablelarge module in the Release Note v3.0.0 (now updated), which offers large table support such as scrollable table body and scrolling synchronization among all transcluded copies, etc.

Have Fun!
Vincent

p.s. Actually the Options Menu was implemented and shows itself at the top-right corner of the tiddler title. But it is in the twve.extra module and doesn't help in your case.

...

[Ton Gerner]

Hi Vincent,

Your fixes in v3.0.1 work:

1) Prettylinks do not add an extra cell and can be edited in the normal way.

2) Options menu works good

3) Hovering over GettingStarted doesn't show dotted boundaries and clicking this tiddler does not give a message anymore.

I now will try it in my main TWclassic.

Cheers,

Ton

...

[Vincent Yeh]

Ton,

Glad they worked for you! And since you haven't mentioned any bugs till now, I'll take it as a good news, and I have one, too.

Release of v3.0.2.

1. Quite some bug fixes and some improvements. See Release Note v3.0.2 at TiddlySpace or TiddlySpot
   
2. Cloned the twve page from TiddlySpace to TiddlySpot
   • I have fixed the Error in macro issue with TiddlySpot (see this thread in TiddlyWiki Group), you can copy the fixed PasswordOptionsPlugin from my twve.tiddlyspot.com.

Have Fun!
Vincent

<blockquote style="margin:0;margin-left:

...

[Ton Gerner]

Hi Vincent

Sorry i did not respond earlier but I have been busy with upgrading all my TW5s and customization guides for TW5 to v5.0.12-beta.

One issue I had with twve.core/twve.table v3.0.1 was with the SiteSubtitle of TW; for some reason new text there behaved not normal (sometimes appeared in 2 - different - places).
Just forget it since with v3.0.2 I don't see that issue anymore.

My last remark in my previous post was : "I now will try it in my main TWclassic."

I did that but noticed my backstage button had disappeared. I remembered we have seen this before [1].

An empty TW with twve.core/twve.table does show the backstage button, so it can be one of my plugins is interfering.
The list of my plugins:

DropDownMenuPlugin
GotoPlugin
ImageSizePlugin
ImportTiddlersPlugin
InlineJavascriptPlugin
ListFiltrPlugin
NestedSlidersPlugin
QuickEditPlugin
QuickNotePlugin
QuickOpenTagPlugin
RenameTagsPlugin
SaveAndReloadMacro
SearchOptionsPlugin
SimpleMessagePlugin
SystemInfoPlugin
TabEditPlugin
TableOfContentsPlugin
TableSortingPlugin_TB
TagSearchPlugin
TagsplorerMacro
TiddlerTweakerPlugin
TiddlersBarPluginMP
TiddlyFileImportr
ToggleTagPlugin
YourSearchPlugin

  TWted (v1.4.6)
  TWtable (v1.4.6)

or

  twve.core.min
  twve.table.min

But that missing backstage button was a minor problem.
Normal table editing was almost not possible. First of all row and column numbers did not appear when hovering over the table and the extra menu (row/column handling) did not show either.
When trying to edit a cell, in most cases the tiddler itself showed in - a strange - edit mode (difficult to describe).
I had the impression it had something to do with the TiddlersBarPlugin and/or TabEditPlugin, but did not investigate it further.
Then I switched back to TWted (v1.4.6)/TWtable (v1.4.6) to get my TW working again ;-)

Today, after installing v3.0.2 a big surprise: no weird behavior anymore, I could edit a table in the "normal" way.

But:
* A tiddler without a table is editable: the title and the text (dashed boxes around title and body when hovering)
* Not only the table is editable. The title and the body text of a tiddler (with or without table) can be edited as well and that gives rise to strange effects.
Normally you click outside the table to leave edit mode.
Clicking outside the tiddler toe leave title/body text editing works partly: you have to click to the left or to the right of the tiddler to leave edit mode. Clicking below the tiddler does nothing.

An empty TW with twve.core/twve.table did behave differently:
* A tiddler Test without a table is not editable (not the title, not the text; no dashed boxes around title and body when hovering)
* When trying to edit a tiddler with a table and some text, you can edit the table and the body text but you *cannot* edit the title.

But after a reboot, the tiddler Test was editable! The strange thing is that shadow tiddlers like GettingStarted and MainMenu were not editable.
Still stranger, overwritten shadow tiddlers like SiteTitle and SitSubtitle, are not editable as well, while new made tiddlers are editable!

Very, very strange.

Another problem is that tiddlers with tables are not always refreshed (in my main TW). See images of normal table and table that is not refreshed.

Cheers,

Ton

[1] https://groups.google.com/d/msg/tiddlywiki/0FT6iBneYOk/2Dwr7WHogJ8J

I put in this option long time ago and did not mention it at all, because the transposition codes were not correct and could mess up with the other part of the tiddler text (see <a href="http://twve.tiddlyspace.com/#%5B%5BTransposing%20a%20table%20--%20backward%20thinking%5D%5D" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Ftwve.tiddlyspace.com%2F%23%255B%255BTransposing%2520a%2520table%2520--%2520backward%2520thinking%255D%255D\46sa\75D\46sntz\0751\46usg\75AFQjCN

...

[Vincent Yeh]

Hi Ton,

Glad to hear you again!

On Friday, May 23, 2014 9:03:28 PM UTC+8, Ton Gerner wrote:

Hi Vincent

Sorry i did not respond earlier but I have been busy with upgrading all my TW5s and customization guides for TW5 to v5.0.12-beta.

No problem. I am also struggling to study the plugin and refreshing mechanism of TW5 and still not quite sure how exactly to port my plugins over yet.

One issue I had with twve.core/twve.table v3.0.1 was with the SiteSubtitle of TW; for some reason new text there behaved not normal (sometimes appeared in 2 - different - places).
Just forget it since with v3.0.2 I don't see that issue anymore.

Great, although I really have no idea what that "not normal" thing is.
 

My last remark in my previous post was : "I now will try it in my main TWclassic."

I did that but noticed my backstage button had disappeared. I remembered we have seen this before [1].

An empty TW with twve.core/twve.table does show the backstage button, so it can be one of my plugins is interfering.
The list of my plugins:

Wow, a good list of plugins to test!
 

 

DropDownMenuPlugin
GotoPlugin
ImageSizePlugin
ImportTiddlersPlugin
InlineJavascriptPlugin
ListFiltrPlugin
NestedSlidersPlugin
QuickEditPlugin
QuickNotePlugin
QuickOpenTagPlugin
RenameTagsPlugin
SaveAndReloadMacro
SearchOptionsPlugin
SimpleMessagePlugin
SystemInfoPlugin
TabEditPlugin
TableOfContentsPlugin
TableSortingPlugin_TB

Is this TableSortingPlugin_TB different from TableSortingPlugin? I do have TableSortingPlugin and the twve work fine with it, but I don't seem to find the _TB version anywhere. Can you send me a copy of it? This is the one that seems to me most related to tables and I'd like to start with it.
 

TagSearchPlugin
TagsplorerMacro
TiddlerTweakerPlugin
TiddlersBarPluginMP
TiddlyFileImportr
ToggleTagPlugin
YourSearchPlugin

  TWted (v1.4.6)
  TWtable (v1.4.6)

or

  twve.core.min
  twve.table.min

But that missing backstage button was a minor problem.
Normal table editing was almost not possible. First of all row and column numbers did not appear when hovering over the table and the extra menu (row/column handling) did not show either.
When trying to edit a cell, in most cases the tiddler itself showed in - a strange - edit mode (difficult to describe).
I had the impression it had something to do with the TiddlersBarPlugin and/or TabEditPlugin, but did not investigate it further.
Then I switched back to TWted (v1.4.6)/TWtable (v1.4.6) to get my TW working again ;-)

Today, after installing v3.0.2 a big surprise: no weird behavior anymore, I could edit a table in the "normal" way.

Hmmm, that could be the fixed bugs related to sorting, I guess.
 

But:
* A tiddler without a table is editable: the title and the text (dashed boxes around title and body when hovering)

* Not only the table is editable. The title and the body text of a tiddler (with or without table) can be edited as well and that gives rise to strange effects.

Well, with twve.core all wrappers -- elements containing tiddler content, being normally loaded or <<tabs>>, <<tiddler>>, <<slider>> transcluded -- are editable in the view mode, because all the required codes are there in twve.core. Those codes are in twve.core because they are closely related to the transclusion synchronization features included in the core: both features must understand

1. how to identify the elements holding the content, and
   
2. how to locate their wiki text,

in order to perform their tasks. That means, when I am able to synchronize the transcluded (and normally loaded) content, I am able to edit them in the view mode.

I felt strange to disable them since the codes are all there ready to use. But maybe that is bothering you? Maybe I should include options to enable/disable which parts to edit?
 

Normally you click outside the table to leave edit mode.
Clicking outside the tiddler toe leave title/body text editing works partly: you have to click to the left or to the right of the tiddler to leave edit mode. Clicking below the tiddler does nothing.

 

An empty TW with twve.core/twve.table did behave differently:
* A tiddler Test without a table is not editable (not the title, not the text; no dashed boxes around title and body when hovering

* When trying to edit a tiddler with a table and some text, you can edit the table and the body text but you *cannot* edit the title.

But after a reboot, the tiddler Test was editable! The strange thing is that shadow tiddlers like GettingStarted and MainMenu were not editable.
Still stranger, overwritten shadow tiddlers like SiteTitle and SitSubtitle, are not editable as well, while new made tiddlers are editable!

Well, I deliberately disabled editing features for shadow tiddlers because I think they are better left alone in the view mode. By "new made" do you mean "new made shadow tiddler"? If so then I need to check...
 

Very, very strange.

Another problem is that tiddlers with tables are not always refreshed (in my main TW). See images of normal table and table that is not refreshed.

I saw similar results with FoldHeadingsPlugin, does any of your plugins do things like folding/unfolding? If so then I know how to fix it. If not then I need to spend some time...

Time to bed,  have a nice weekend.

Have Fun!
Vincent
 

<blockquote style="margin:0;margin-left

...

[Yakov]

Hi Vincent,

great work -- both in quantity and quality (many bugs have gone)!

I haven't redone all the tests (for the 3.x series) yet, but have done some of them (one bug have been already fixed in 3.0.2), so let's start from a lesser amount of feedback (which is still plenty, probably).

1. Ordinary text
1.1 For a long multiline text block (say, 50 lines), the edit area is generated with heigh not only for all the lines (without cutting and scroll bar), but even higher, which is not convenient.
1.2 From this, I deduced a proposal for a rough solution for the previewer autoscolling (for big text block, the previewed text is sometimes out of the screen):
# maximum height of both edit area and previewer should be 50% of the screen height, otherwise they got scrollbar
# when edit mode is opened, if the height of either edit area or previewer is > 33% of the screen height, the page is autoscrolled so that the top border of the previewer coincides with the top of the screen
# if the previewer has the scrollbar, it is (onscroll of the edit area) automatically scrolled (see jQuery.scrollTop), so that the ratio (scroll position/total height) is the same for the edit area and the previewer

2. Lists
2.1 Now the list items order is changed not only on ctrl+up/down, but also on ctrl+left/right (which is totally inconvenient -- ctrl+left is usually used for quick navigation, to jump over words)
2.2 Changing of the list order is rather slow
2.3 Still:
2.3.1 both ctrl+enter and enter work as "save and exit the list item edit area", I propose to leave the functionality to ctrl+enter and process enter as adding of a new line -- otherwise there's no good (inline) way to add a new list item
2.3.2 complex list items like this are not handled properly (same thing with nested sliders in list items):
* start list item {{justDiv{
> citation
}}} end list item
2.3.3 multi-level lists don't interact well with list items order changing

3. Tables (haven't made consistent testing yet)
3.1 Multiline cells interact in an incorrect way with the following text. To understand what I mean, try this in a tiddler:
|text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text long enough to be multiline|
text
3.2 Inline editing (at least adding/removing colomns) seem to remove additional classes. Say, I have a borderless table
|borderless|k
|text|
After I add a new colomn, the table becomes with borders (it is ok for edit mode, but in view mode I would like to have my CSS applied). The |borderless|k part is not removed, if the tiddler is reopened, the borders are gone again.
CSS here is
.borderless, .borderless tr, .borderless th, .borderless td { border: none !important; }
Note the !important part: without it, the stying is not applied at all -- I would consider this as a bug, too.

4. Compability bugs
n.1 Nested sliders are somewhy open on load, try this syntax (usually, for "open on load" ++++[label]text=== syntax is used)
+++[nested sliders are somewhy]
open on load
===

Ok, that's all for now. Nice to see the development going on!

Best regards,
Yakov.

PS waiting for slice editing, too :)

пятница, 23 мая 2014 г., 20:48:47 UTC+4 пользователь Vincent Yeh написал:

...

[Vincent Yeh]

Hi Yakov,

On Saturday, May 24, 2014 5:02:12 AM UTC+8, Yakov wrote:

Hi Vincent,

great work -- both in quantity and quality (many bugs have gone)!

Thanks!
 

I haven't redone all the tests (for the 3.x series) yet, but have done some of them (one bug have been already fixed in 3.0.2), so let's start from a lesser amount of feedback (which is still plenty, probably).

1. Ordinary text
1.1 For a long multiline text block (say, 50 lines), the edit area is generated with heigh not only for all the lines (without cutting and scroll bar), but even higher, which is not convenient.

Ah, I did not notice this. Thanks for bringing it up.
 

1.2 From this, I deduced a proposal for a rough solution for the previewer autoscolling (for big text block, the previewed text is sometimes out of the screen):
# maximum height of both edit area and previewer should be 50% of the screen height, otherwise they got scrollbar
# when edit mode is opened, if the height of either edit area or previewer is > 33% of the screen height, the page is autoscrolled so that the top border of the previewer coincides with the top of the screen
# if the previewer has the scrollbar, it is (onscroll of the edit area) automatically scrolled (see jQuery.scrollTop), so that the ratio (scroll position/total height) is the same for the edit area and the previewer

That's good idea. I will work on it after this weekend.
 

2. Lists
2.1 Now the list items order is changed not only on ctrl+up/down, but also on ctrl+left/right (which is totally inconvenient -- ctrl+left is usually used for quick navigation, to jump over words)

I see. Never used ctrl-left/right to jump over words so didn't know that. Thanks for telling me about it.
 

2.2 Changing of the list order is rather slow

Hmmm, I just noticed in my example that it caused an infinite loop when I tried to move down the last item, but worked quite smoothly in other cases, even when moving up the very first one (well, you may get strange results but that's how TiddlyWiki renders lists, not the twve). Are you saying it is slow in general, or just cases similar to what I mentioned? If it is general then I would guess it's some interference with other plugins.
 

2.3 Still:
2.3.1 both ctrl+enter and enter work as "save and exit the list item edit area", I propose to leave the functionality to ctrl+enter and process enter as adding of a new line -- otherwise there's no good (inline) way to add a new list item

Good point (to add a new list item when you are in another).
 

2.3.2 complex list items like this are not handled properly (same thing with nested sliders in list items):
* start list item {{justDiv{
> citation
}}} end list item

Ah! You can actually have a list item this way! I thought list items are always single lined! This will now change the rules of the game.
 

2.3.3 multi-level lists don't interact well with list items order changing

I guess you mean "the sub-lists don't move with the parent", am I right? This has been something in my mind but not possible until now. It was not possible because the twve used to work on items instead of lists, and that made it difficult to locate wiki text of lists as a whole (and difficult to do partial refreshing). Starting v3.0.2 with the improved partial refreshing codes for list items, it is now possible to locate the wiki text of lists as a whole, and should be possible to move sub-lists with their parent. I will think about it soon.
.

Although logically when we speak of lists we mean the structured content, but technically in a browser the lists (UL / OL) do not hold content but list items (LI), each of which holds the content for us. Therefore technically it is the items, not the lists, that have simple and definite correspondence with the wiki text. That's why the twve used to work on items but not lists.

3. Tables (haven't made consistent testing yet)
3.1 Multiline cells interact in an incorrect way with the following text. To understand what I mean, try this in a tiddler:
|text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text text long enough to be multiline|
text

Hmmm, this is odd. I shall take a deep look into the codes...
By the way, you can put "multi-lined" content, such as lists, blockquotes, etc., in a table cell, as shown in this example.
 

3.2 Inline editing (at least adding/removing colomns) seem to remove additional classes. Say, I have a borderless table
|borderless|k
|text|
After I add a new colomn, the table becomes with borders (it is ok for edit mode, but in view mode I would like to have my CSS applied). The |borderless|k part is not removed, if the tiddler is reopened, the borders are gone again.
CSS here is
.borderless, .borderless tr, .borderless th, .borderless td { border: none !important; }
Note the !important part: without it, the stying is not applied at all -- I would consider this as a bug, too.

This I really have no idea. The twve does not do anything about styles because I have very limited knowledge about CSS statements. If that is a bug in twve, that must be due to the nothing be done about styles. In that case it may take a long time to fix...
 

4. Compability bugs
n.1 Nested sliders are somewhy open on load, try this syntax (usually, for "open on load" ++++[label]text=== syntax is used)
+++[nested sliders are somewhy]
open on load
===

I stopped using nested sliders quite a while ago because I can not keep its syntax in mind longer than three days. But yes, I can make twve compatible with it for sure.
 

Ok, that's all for now. Nice to see the development going on!

Best regards,
Yakov.

PS waiting for slice editing, too :)

Yeah, I am working on it. But just for my information, what are the typical cases that people use slices? I only know that the table at the beginning of most plugins is one example, but can't think of others with my poor experiences on slices.

And just to make sure, I guess you mean to edit the "transcluded slices", right? From what I learned in this page, slices can be defined in one of the following ways:

1. name: value
2. |name:|value|
3. |name|value|
4. |''name:''|value|
5. |//~WikiName://|value|

and all of them are already editable with twve : the first is like a plain text, while the rest are tables.
 

1. Quite some bug fixes and some improvements. See Release Note v3.0.2 at <a href="http://twve.tiddlyspace.com/#%5B%5BRelease%20Note%20v3.0.2%5D%5D" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Ftwve.tiddlyspace.com%2F%23%255B%255BRelease%2520Note%2520v3.0.2%255D%255D\46sa\75D\46sntz\0751\46usg\75AFQjCNGntRPcm5q5R6VsOD3MLL6E5WzI7A';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Ftwve.tiddlyspac

...