[tw] Re: A View Mode Editor and a simple Calcualtor

[Yakov]

Hi Vincent,

how are you? Any progress with twve?

Best regards,
Yakov.

Hi Vincent,
inline elements get their widths from the content width, so to get through
this, we have to understand the inline elements styling well.. this article
is helpful: [1]. From there, I get the idea that it is padding that should
be set. A simple solution: add to CSS
span[refresh="content"] { padding: 0 1em; }
or may be 0 1px. Try it, it allows to edit empty section transclusion.
Now, this has a number of drawbacks that you can see if you add this to
StyleSheet and use some transclusion, especially in
MainMenu/SideBarCommands, all of them originate from the fact that all
tiddler macros get padding, not only empty ones. So, something like [2]
can be done (after wikifying/refreshing) either with changing the display
property or with just changing padding.
test
<<tiddler [[test##section]]>>
<<tiddler [[test::slice]]>>
|slice||
!section
Section is edited.. well, there comes the bug I've mentioned previously,
but the content of the section becomes what it was expected to become
(although, couple of times I got the content appended to !section without
a linebreak, but I can't reproduce that). But when I edit the slice through
the transclusion, I always get the content put to the wrong place: I write
"text" to the second transclusion, and get text|slice|| line saved
instead of |slice|text|.
Best regards,
Yakov.
[1] http://www.maxdesign.com.au/articles/inline/
[2]
http://stackoverflow.com/questions/11572905/min-width-on-inline-not-inline-block-behaving-element
четверг, 14 августа 2014 г., 18:09:38 UTC+4 пПльзПватель Vincent Yeh
Yakov,
Thanks for the reply that showed me different results from what I had and
got me to look further into the details for a cause. Fortunately I found
it. It was the ExternalTiddlerPlugin that kept me from getting the empty
slices. In the handler function of ExternalTiddlerPlugin (that overrides
that of the original config.macros.tiddler.handler), an empty content is
considered non-existing and gets skipped, without even creating the SPAN
element. That's why I couldn't find it with an empty slice value.
Removing the ExternalTiddlerPlugin I got the same results as you did: the
original config.macros.tiddler.handler got executed and an empty SPAN got
created. However, even though there is an empty SPAN created for an empty
slice, the *twve* still cannot find it with the mouse pointer, *because
the empty SPAN has zero width*. I'll need to think of some way
particularly for that. Shall take a short while.
Have Fun!
Vincent
Hi Vincent,
basically, when you work with the mode changing/refreshing of the story,
you shouldn't rely on displayMessage: in some cases, it fails to display
messages (or, probably, the message is shown and closed so quickly that
even the display doesn't actually show it). Instead, use console.log or
alert (don't use the last one if you expect many messages, though; on the
other hand, there are some cases when messages in the console are shown in
an unexpected order).
//{{{
config.macros.tiddler.handler =
function(place,macroName,params,wikifier,paramString,tiddler)
{
console.log("msg");
displayMessage("msg");
var allowEval = true;
var stack = config.macros.tiddler.tiddlerStack;
if(stack.length > 0 && config.evaluateMacroParameters == "system") {
// included tiddler and "system" evaluation required, so check
tiddler tagged appropriately
var title = stack[stack.length-1];
var pos = title.indexOf(config.textPrimitives.sectionSeparator);
if(pos != -1)
title = title.substr(0,pos); // get the base tiddler title
var t = store.getTiddler(title);
if(!t || t.tags.indexOf("systemAllowEval") == -1)
allowEval = false;
}
params = paramString.parseParams("name",nul
...

[Vincent Yeh]

Hi Yakov,

Thanks for asking. The removal of jQuery dependencies is almost done and quite some bugs are fixed. The next release shall come out soon.

[Vincent Yeh]

The removal of jQuery and the resulting debugging took a lot longer than I
expected. Finally I've got it done and tested with all the Examples given
in TiddlySpot <http://twve.tiddlyspot.com/#Examples> (or in TiddlySpace
<http://twve.tiddlyspace.com#Examples>).

- Major changes
- Said goodbye to jQuery -- now *they may not work in old browsers*.
- major bug fixes -- old bugs that were sleeping long and new ones
from rewriting
- better partial refreshing -- better performance for large tiddlers.

You are welcome to try and give feedback! See Release Note in TiddlySpot
<http://twve.tiddlyspot.com/#[[Release%20Note%20v3.2.0]]> (or in TiddlySpace
<http://twve.tiddlyspace.com/#[[Release%20Note%20v3.2.0]]>) for download
links and more details.

Have fun!
Vincent

Post by Vincent Yeh
Hi Yakov,
Thanks for asking. The removal of jQuery dependencies is almost done and
quite some bugs are fixed. The next release shall come out soon.

[Vincent Yeh]

Some bug fixes and improvements in *twve* v3.2.1. Welcome to try and give
feedback! See Release Note in TiddlySpot
<http://twve.tiddlyspot.com/#%5B%5BRelease%20Note%20v3.2.0%5D%5D> (or in
TiddlySpace
<http://twve.tiddlyspace.com/#%5B%5BRelease%20Note%20v3.2.0%5D%5D>) for
download links and more details.

In a few more releases the *twve* shall go to TW5, I hope.

Have Fune!
Vincent

Post by Vincent Yeh
The removal of jQuery and the resulting debugging took a lot longer than I
expected. Finally I've got it done and tested with all the Examples given
in TiddlySpot <http://twve.tiddlyspot.com/#Examples> (or in TiddlySpace
<http://twve.tiddlyspace.com#Examples>).
- Major changes
- Said goodbye to jQuery -- now *they may not work in old browsers*.
- major bug fixes -- old bugs that were sleeping long and new ones
from rewriting
- better partial refreshing -- better performance for large tiddlers.
You are welcome to try and give feedback! See Release Note in TiddlySpot
<http://twve.tiddlyspot.com/#%5B%5BRelease%20Note%20v3.2.0%5D%5D> (or in
TiddlySpace
<http://twve.tiddlyspace.com/#%5B%5BRelease%20Note%20v3.2.0%5D%5D>) for
download links and more details.
Have fun!
Vincent
...

[Vincent Yeh]

Updated links for the release note.

See Release Note in TiddlySpot
<http://twve.tiddlyspot.com/#[[Release%20Note%20v3.2.1]]> (or in TiddlySpace
<http://twve.tiddlyspace.com/#[[Release%20Note%20v3.2.1]]>) for download
links and more details.

Post by Vincent Yeh
Some bug fixes and improvements in *twve* v3.2.1. Welcome to try and give
feedback! See Release Note in TiddlySpot
<http://www.google.com/url?q=http%3A%2F%2Ftwve.tiddlyspot.com%2F%23%255B%255BRelease%2520Note%2520v3.2.0%255D%255D&sa=D&sntz=1&usg=AFQjCNFolcj-py5lxSlNMRJ_x4tWJcgajg>
(or in TiddlySpace
<http://twve.tiddlyspace.com/#%5B%5BRelease%20Note%20v3.2.0%5D%5D>) for
download links and more details.
In a few more releases the *twve* shall go to TW5, I hope.
Have Fune!
Vincent

Post by Vincent Yeh
The removal of jQuery and the resulting debugging took a lot longer than
I expected. Finally I've got it done and tested with all the Examples
given in TiddlySpot <http://twve.tiddlyspot.com/#Examples> (or in
TiddlySpace <http://twve.tiddlyspace.com#Examples>).
- Major changes
- Said goodbye to jQuery -- now *they may not work in old browsers*
.
- major bug fixes -- old bugs that were sleeping long and new ones
from rewriting
- better partial refreshing -- better performance for large tiddlers.
You are welcome to try and give feedback! See Release Note in TiddlySpot
<http://twve.tiddlyspot.com/#%5B%5BRelease%20Note%20v3.2.0%5D%5D> (or in
TiddlySpace
<http://twve.tiddlyspace.com/#%5B%5BRelease%20Note%20v3.2.0%5D%5D>) for
download links and more details.
Have fun!
Vincent
...

[Yakov]

Hi Vincent,

sorry, I'm terribly busy these weeks, so no time for thorough testing for
now. But I'm glad that the development is going on and that you've done
this migrating, this was quite a task. I've downloaded the new versions and
may be will test them on the go; but the main thing that I can see and
would like to highlight for now is -- it is important to create adquate
navigation between elements. I mean, if I click a <b> element produced with
''...'' wrapper, I'm not able to navigate to the next text part using
arrows (instead, I navigate between b elements in different parts of the
text), which hinders the workflow considerably.

Best regards,
Yakov.

пПМеЎельМОк, 22 Ўекабря 2014 г., 9:29:10 UTC+3 пПльзПватель Vincent Yeh

Post by Vincent Yeh
Updated links for the release note.
See Release Note in TiddlySpot
<http://twve.tiddlyspot.com/#%5B%5BRelease%20Note%20v3.2.1%5D%5D> (or in
TiddlySpace
<http://twve.tiddlyspace.com/#%5B%5BRelease%20Note%20v3.2.1%5D%5D>) for
download links and more details.
Some bug fixes and improvements in *twve* v3.2.1. Welcome to try and give
feedback! See Release Note in TiddlySpot
<http://www.google.com/url?q=http%3A%2F%2Ftwve.tiddlyspot.com%2F%23%255B%255BRelease%2520Note%2520v3.2.0%255D%255D&sa=D&sntz=1&usg=AFQjCNFolcj-py5lxSlNMRJ_x4tWJcgajg>
(or in TiddlySpace
<http://twve.tiddlyspace.com/#%5B%5BRelease%20Note%20v3.2.0%5D%5D>) for
download links and more details.
In a few more releases the *twve* shall go to TW5, I hope.
Have Fune!
Vincent
The removal of jQuery and the resulting debugging took a lot longer than I
expected. Finally I've got it done and tested with all the Examples given
in TiddlySpot <http://twve.tiddlyspot.com/#Examples> (or in
...

[Vincent Yeh]

Hi Yakov,

Good to hear from you again! The navigation issue you mentioned has been
worked on over a few releases and is finally possible in the current one
(but not yet implemented). It was not easy in the past versions due to the
wiki text searching strategy: search within the same type. That strategy
made it possible to quickly locate the wiki text of a DOM element, but
difficult to move the cursor to the next sibling of a different type. In
the past few releases I had implemented another strategy: search
sequentially. This will make it easy to move cursor over to the next
sibling, whatever element type it is, at the cost of a noticeable slow down
in the searching speed. I am working on this "normal navigation" and
hopefully it will come out in the next couple of releases.

Have Fun!
Vincent

Post by Yakov
Hi Vincent,
sorry, I'm terribly busy these weeks, so no time for thorough testing for
now. But I'm glad that the development is going on and that you've done
this migrating, this was quite a task. I've downloaded the new versions and
may be will test them on the go; but the main thing that I can see and
would like to highlight for now is -- it is important to create adquate
navigation between elements. I mean, if I click a <b> element produced with
''...'' wrapper, I'm not able to navigate to the next text part using
arrows (instead, I navigate between b elements in different parts of the
text), which hinders the workflow considerably.
Best regards,
Yakov.
пПМеЎельМОк, 22 Ўекабря 2014 г., 9:29:10 UTC+3 пПльзПватель Vincent Yeh
Updated links for the release note.
See Release Note in TiddlySpot
<http://twve.tiddlyspot.com/#%5B%5BRelease%20Note%20v3.2.1%5D%5D> (or in
TiddlySpace
<http://twve.tiddlyspace.com/#%5B%5BRelease%20Note%20v3.2.1%5D%5D>) for
download links and more details.
Some bug fixes and improvements in *twve* v3.2.1. Welcome to try and give
feedback! See
...

[Vincent Yeh]

Releasing the *twve* 3.2.2, with some bug fixes. See release note at
TiddlySpot <http://twve.tiddlyspot.com/#%5B%5BRelease%20Note%20v3.2.2%5D%5D>
or TiddlySpace
<http://twve.tiddlyspace.com/#%5B%5BRelease%20Note%20v3.2.2%5D%5D>.
Download links are given in the Installation section in the release note.

Yakov, the normal navigation is on going and will come out in the next
release.

Happy New Year!

Post by Vincent Yeh
Hi Yakov,
Good to hear from you again! The navigation issue you mentioned has been
worked on over a few releases and is finally possible in the current one
(but not yet implemented). It was not easy in the past versions due to the
wiki text searching strategy: search within the same type. That strategy
made it possible to quickly locate the wiki text of a DOM element, but
difficult to move the cursor to the next sibling of a different type. In
the past few releases I had implemented another strategy: search
sequentially. This will make it easy to move cursor over to the next
sibling, whatever element type it is, at the cost of a noticeable slow down
in the searching speed. I am working on this "normal navigation" and
hopefully it will come out in the next couple of releases.
Have Fun!
Vincent
Hi Vincent,
sorry, I'm terribly busy these weeks, so no time for thorough testing for
now. But I'm glad that the development is going on and that you've done
this migrating, this was quite a task. I've downloaded the new versions and
may be will test them on the go; but the main thing that I can see and
would like to highlight for now is -- it is important to create adquate
navigation between elements. I mean, if I click a <b> element produced with
''...'' wrapper, I'm not able to navigate to the next text part using
arrows (instead, I navigate between b elements in different parts of the
text), which hinders the workflow considerably.
Best regards,
Yakov.
пПМеЎельМОк, 22 Ўекабря 2014 г., 9:29:10 UTC+3 пПльзПватель Vincent Yeh
Updated links for the release note.
See
...

[Yakov]

Hi Vincent,

nice to hear! Keep on :) I really appreciate using twve for writing drafts
with formulae, and "normal" navigation will help tremendously.

Best regards,
Yakov.

Post by Vincent Yeh
Releasing the *twve* 3.2.2, with some bug fixes. See release note at
TiddlySpot
<http://twve.tiddlyspot.com/#%5B%5BRelease%20Note%20v3.2.2%5D%5D> or
TiddlySpace
<http://twve.tiddlyspace.com/#%5B%5BRelease%20Note%20v3.2.2%5D%5D>.
Download links are given in the Installation section in the release note.
Yakov, the normal navigation is on going and will come out in the next
release.
Happy New Year!
Hi Yakov,
Good to hear from you again! The navigation issue you mentioned has been
worked on over a few releases and is finally possible in the current one
(but not yet implemented). It was not easy in the past versions due to the
wiki text searching strategy: search within the same type. That strategy
made it possible to quickly locate the wiki text of a DOM element, but
difficult to move the cursor to the next sibling of a different type. In
the past few releases I had implemented another strategy: search
sequentially. This will make it easy to move cursor over to the next
sibling, whatever element type it is, at the cost of a noticeable slow down
in the searching speed. I am working on this "normal navigation" and
hopefully it will come out in the next couple of releases.
Have Fun!
Vincent
Hi Vincent,
sorry, I'm terribly busy these weeks, so no time for thorough testing for
now. But I'm glad that the development is go
...

[Yakov]

By the way, a couple of things I've noticed about v3.2.2:

* when editing a list item, pressing any button other than one of the
arrows (a letter or ctrl or shift..) hides the text edit area; applying
changes (enter/ctrl+enter) makes actually save changes, but not exit the
edit mode, and also saving keeps being applied each ~1 second (pressing esc
causes exiting from the edit mode, though)

* editing a list item with subitems hides subitems (but doesn't delete them
in the tiddler's text)

also, there's an issue that I can't reproduce accurately: sometimes not
each list item is editable. Try to create a tiddler with the following text
(in Russian; it's only 4 lines)

* {{DDn{v3.2.2 МажатОе ctrl, shift, сОЌвПльМых клавОш -- слПвПЌ, всегП,
крПЌе стрелПк, кПгЎа реЎактОруется блПк элеЌеМта спОска, вызывает ~сПкрытОе
текстПвПгП пПля, в кПтПрПЌ прПОсхПЎОт реЎактОрПваМОе + прО прОЌеМеМОО
ОзЌеМеМОй сПхраМеМОе вызывается Ме ПЎМажЎы, а МачОМает запускаться
регулярМП с ОМтервалПЌ ~1 сек (прО этПЌ preview area Ме убОрается; МП ЌПжМП
выйтО Оз этПгП сПстПяМОя МажатОеЌ esc)}}}...
** Ме ПбязательМП прО этПЌ, чтПбы в элеЌеМте спОска кПМтеМт был ПбёрМут в
<html><code>{{DDn{...}}}</code></html>
* v3.2.2 {{DDn{Ме все элеЌеМты спОска реагОруют Ма mouseover/click [сЎелать
вПспрПОзвПЎОЌыЌ]}}}
* {{DDn{v3.2.2 Мельзя ЎПбавлять МПвые элеЌеМты спОска без реЎактОрПваМОя
текста целОкПЌ (хПтя ЌПжМП былП бы Ўелать этП пП ctrl+enter -- чтП,
впрПчеЌ, Ме ПчеМь пПЎхПЎОт Ўля тачскрОМ-устрПйств), крПЌе как кПпОруя О
вставляя переМПс стрПкО ПткуЎа-МОбуЎь ещё.}}}

and then move the coursor from the top to the bottom of the text and then
click the last item trying to edit it (try others as well and also watch
the "editable" visual selection). For me, almost always the third (counting
** as well) or the last item is not editable, but further moving coursor
here and there can change this.

Best regards,
Yakov.

Post by Vincent Yeh
Releasing the *twve* 3.2.2, with some bug fixes. See release note at
TiddlySpot
<http://twve.tiddlyspot.com/#%5B%5BRelease%20Note%20v3.2.2%5D%5D> or
TiddlySpace
<http://twve.tiddlyspace.com/#%5B%5BRelease%20Note%20v3.2.2%5D%5D>.
Download links are given in the Installation section in the release note.
Yakov, the normal navigation is on going and will come out in the next
release.
Happy New Year!
Hi Yakov,
Good to hear from you again! The navigation issue you mentioned has been
worked on over a few releases and is finally possible in the current one
(but not yet implemented). It was not easy in the past versions due to the
wiki text searching strategy: search within the same type. That strategy
made it possible to quickly locate the wiki text of a DOM element, but
difficult to move the cursor to the next sibling of a different type. In
the past few releases I had implemented another strategy: search
sequentially. This will make it easy to move cursor over to the next
sibling, whatever element type it is, at the cost of a noticeable slow down
in the searching speed. I am working on this "normal navigation" and
hopefully it will come out in the next couple of releases.
Have Fun!
Vincent
Hi Vincent,
sorry, I'm terribly busy these weeks, so no time for thorough testing for
now. But I'm glad that the development i
...

[Vincent Yeh]

Yakov,

Thanks for the information. I ran your test and realized the cause of it:
the *twve* does not understand the CSS wrapper syntax, such as the {{Dn{
... }}} in your case. I will find time to add this support hopefully today
or tomorrow. If I don't make it in these two days, I will do it after the
Lunar New Year's break (18-22).

Happy New Year!

Vincent

Post by Yakov
* when editing a list item, pressing any button other than one of the
arrows (a letter or ctrl or shift..) hides the text edit area; applying
changes (enter/ctrl+enter) makes actually save changes, but not exit the
edit mode, and also saving keeps being applied each ~1 second (pressing esc
causes exiting from the edit mode, though)
* editing a list item with subitems hides subitems (but doesn't delete
them in the tiddler's text)
also, there's an issue that I can't reproduce accurately: sometimes not
each list item is editable. Try to create a tiddler with the following text
(in Russian; it's only 4 lines)
* {{DDn{v3.2.2 МажатОе ctrl, shift, сОЌвПльМых клавОш -- слПвПЌ, всегП,
крПЌе стрелПк, кПгЎа реЎактОруется блПк элеЌеМта спОска, вызывает ~сПкрытОе
текстПвПгП пПля, в кПтПрПЌ прПОсхПЎОт реЎактОрПваМОе + прО прОЌеМеМОО
ОзЌеМеМОй сПхраМеМОе вызывается Ме ПЎМажЎы, а МачОМает запускаться
регулярМП с ОМтервалПЌ ~1 сек (прО этПЌ preview area Ме убОрается; МП ЌПжМП
выйтО Оз этПгП сПстПяМОя МажатОеЌ esc)}}}...
** Ме ПбязательМП прО этПЌ, чтПбы в элеЌеМте спОска кПМтеМт был ПбёрМут в
<html><code>{{DDn{...}}}</code></html>
* v3.2.2 {{DDn{Ме все элеЌеМты спОска реагОруют Ма mouseover/click
[сЎелать вПспрПОзвПЎОЌыЌ]}}}
* {{DDn{v3.2.2 Мельзя ЎПбавлять МПвые элеЌеМты спОска без реЎактОрПваМОя
текста целОкПЌ (хПтя ЌПжМП былП бы Ўелать этП пП ctrl+enter -- чтП,
впрПчеЌ, Ме ПчеМь пПЎхПЎОт Ўля тачскрОМ-устрПйств), крПЌе как кПпОруя О
вставляя переМПс стрПкО ПткуЎа-МОбуЎь ещё.}}}
and then move the coursor from the top to the bottom of the text and then
click the last item trying to edit it (try others as well and also watch
the "editable" visual selection). For me, almost always the third (counting
** as well) or the last item is not editable, but further moving coursor
here and there can change this.
Best regards,
Yakov.
пятМОца, 13 февраля 2015 г., 7:28:41 UTC+3 пПльзПватель Vincent Yeh
Releasing the *twve* 3.2.2, with some bug fixes. See release note at
TiddlySpot
<http://twve.tiddlyspot.com/#%5B%5BRelease%20Note%20v3.2.2%5D%5D> or
...

[Vincent Yeh]

Yakov,

Today I spent some time working on the css wrapper thing but couldn't get it done. I am afraid you will have to wait for a few more days!

In the next 5 days I will be eating and drinking a lot, seeing families and friends and having fun with them. Will be back after that.

Happy New Year!

[Vincent Yeh]

*twve* v3.2.3

Major changes include

1. added support for CSS wrappers created using {{Class name{ .... }}};
- This, however, was only tested with very simple cases.
2. a few newly defined functions and some bug fixes in *twve.tcalc*

For more information and download links please see ReleaseNote v3.2.3 in
TiddlySpot <http://twve.tiddlyspot.com/#[[Release%20Note%20v3.2.3]]> or in
TiddlySpace <http://twve.tiddlyspace.com/#[[Release%20Note%20v3.2.3]]>.

Comments, suggestions, bug reports are all welcome!

Have fun!
Vincent

Yakov,
Today I spent some time working on the css wrapper thing but couldn't get
it done. I am afraid you will have to wait for a few more days!
In the next 5 days I will be eating and drinking a lot, seeing families
and friends and having fun with them. Will be back after that.
Happy New Year!

[Vincent Yeh]

*twve* 3.2.4

Major changes include

1. Added support for
- regular expression in the open/close tags of elements;
- MathJax auto numbering;
- *cross-table calculations*;
- *parts-per notations in calculations*;
- *time addition/subtraction in the format of hh:mm:ss or hh:mm or
mm:ss*;
- vector calculations.
2. Added functions
- LENGTH/LEN(cell)
- VALUE/VAL(cell[,n])
- VALUEWITH/VALWITH(cell,preceding[,following])
- SUMIN(cell[,n1,n2,...])
- SUMWITH(cell,preceding[,following])

For more information and download links please see ReleaseNote v3.2.4 in
TiddlySpot <http://twve.tiddlyspot.com/#%5B%5BRelease%20Note%20v3.2.4%5D%5D>
or in TiddlySpace
<http://twve.tiddlyspace.com/#%5B%5BRelease%20Note%20v3.2.4%5D%5D>.

Comments, suggestions, bug reports are all welcome!

Have fun!
Vincent

Post by Vincent Yeh
*twve* v3.2.3
Major changes include
1. added support for CSS wrappers created using {{Class name{ .... }}};
- This, however, was only tested with very simple cases.
2. a few newly defined functions and some bug fixes in *twve.tcalc*
For more information and download links please see ReleaseNote v3.2.3 in
TiddlySpot
<http://twve.tiddlyspot.com/#%5B%5BRelease%20Note%20v3.2.3%5D%5D> or in
TiddlySpace
<http://twve.tiddlyspace.com/#%5B%5BRelease%20Note%20v3.2.3%5D%5D>.
Comments, suggestions, bug reports are all welcome!
Have fun!
Vincent
Yakov,
Today I spent some time working on the css wrapper thing but couldn't get
it done. I am afraid you will have to wait for a few more days!
...

[Yakov]

Hi Vincent,

nice to see that the development is going on! It was a hard year, but
probably I'll be able to provide consistent feedback during most of the
summer.

Now, a couple of things from the top of my head:
1) I haven't been using v 3.2.3 actively and now noticed that it and 3.2.4
have a major bug in table editing: if the first cell is empty, which is
quite a frequent case, like in
||param1|param2|param3|
|object1|value11|value12|value13|
|object2|value21|value22|value23|
, opening cells in the second row opens values of the wrong cell! Minimal
test cases:
||a|
|b|c|
here, "b" and "c" raws show empty values;

||a|b|
|c|d|e|
here "c" and "d" show empty values while "e" shows "a". Meaning that they
take values from the cells that are to the top left from them.

Even more tricky, if I put those to together in one tiddler (separated with
double line break), editing "e" in the second table acutally edits "a" in
the first one! (but /shows/ it as thought as the right cells was changed:
to "see the truth", open the ordinary edit mode).

2) I've seen at [1] the discussion about the excel-like interface library.
It works quite nicely (very good thing it does so with the clipboard), so I
wonder if you consider using it. Of'course the fact that it uses jQuery is
quite bad, but if the implementation is not very difficult, this can be
done as an optional addition for those who use twve with TWc.

Best regards,
Yakov.

[1] https://groups.google.com/forum/#!topic/tiddlywikidev/LJ4QE6FB-lg

пПМеЎельМОк, 15 ОюМя 2015 г., 19:09:45 UTC+3 пПльзПватель Vincent Yeh

Post by Vincent Yeh
*twve* 3.2.4
Major changes include
1. Added support for
- regular expression in the open/close tags of elements;
- MathJax auto numbering;
- *cross-table calculations*;
- *parts-per notations in calculations*;
- *time addition/subtraction in the format of hh:mm:ss or hh:mm or
mm:ss*;
- vector calculations.
2. Added functions
- LENGTH/LEN(cell)
- VALUE/VAL(cell[,n])
- VALUEWITH/VALWITH(cell,preceding[,following])
- SUMIN(cell[,n1,n2,...])
- SUMWITH(cell,preceding[,following])
For more information and download links please see ReleaseNote v3.2.4 in
TiddlySpot
<http://twve.tiddlyspot.com/#%5B%5BRelease%20Note%20v3.2.4%5D%5D> or in
TiddlySpace
<http://twve.tiddlyspace.com/#%5B%5BRelease%20Note%20v3.2.4%5D%5D>.
Comments, suggestions, bug reports are all welcome!
Have fun!
Vincent
*twve* v3.2.3
Major changes include
1. added support for CSS wrappers created using {{Class name{ .... }}};
- This, however, was only tested with very simple cases.
2. a few newly defined functions and some bug fixes in *twve.tcalc*
For more information and download links please see
...

[Vincent Yeh]

Yakov,

Good to hear from you again, and thanks a lot for the bug report and
suggestions. After a quick test I realized that bug has long been there, I
just never found it. Thanks again for finding it for me. It is fixed in my
current snapshot and will be gone in the next release.

About the Handsontable, I do seriously consider using it. However, instead
of making the *twve* work with it directly, I am thinking of another plugin
that works with Handsontable, and make that plugin recognized in *twve*.
That way we should have the benefit that people have the choice to work
with Handsontable solely or to include *twve*.

Have fun!
Vincent

Post by Yakov
Hi Vincent,
nice to see that the development is going on! It was a hard year, but
probably I'll be able to provide consistent feedback during most of the
summer.
1) I haven't been using v 3.2.3 actively and now noticed that it and 3.2.4
have a major bug in table editing: if the first cell is empty, which is
quite a frequent case, like in
||param1|param2|param3|
|object1|value11|value12|value13|
|object2|value21|value22|value23|
, opening cells in the second row opens values of the wrong cell! Minimal
||a|
|b|c|
here, "b" and "c" raws show empty values;
||a|b|
|c|d|e|
here "c" and "d" show empty values while "e" shows "a". Meaning that they
take values from the cells that are to the top left from them.
Even more tricky, if I put those to together in one tiddler (separated
with double line break), editing "e" in the second table acutally edits "a"
in the first one! (but /shows/ it as thought as the right cells was
changed: to "see the truth", open the ordinary edit mode).
2) I've seen at [1] the discussion about the excel-like interface library.
It works quite nicely (very good thing it does so with the clipboard), so I
wonder if you consider using it. Of'course the fact that it uses jQuery is
quite bad, but if the implementation is not very difficult, this can be
done as an optional addition for those who use twve with TWc.
Best regards,
Yakov.
[1] https://groups.google.com/forum/#!topic/tiddlywikidev/LJ4QE6FB-lg
пПМеЎельМОк, 15 ОюМя 2015 г., 19:09:45 UTC+3 пПльзПватель Vincent Yeh
*twve* 3.2.4
Major changes include
1. Added support for
- regular expression in the open/close tags of elements;
- MathJax auto numbering;
- *cross-table calculations*;
- *parts-per notations in calculations*;
- *time addition/subtraction in the format of hh:mm:ss or hh:mm or
mm:ss*;
- vector calculations.
2. Added functions
- LENGTH/LEN(cell)
- VALUE/VAL(cell[,n])
- VALUEWITH/VALWITH(cell,preceding[,following])
- SUMIN(cell[,n1,n2,...])
- SUMWITH(cell,preceding[,following])
For more information and download links please see
...

[Vincent Yeh]

Hello, everyone,

It's been a while since last release of *twve*. I've been busy at work and
spending very limited time on it.

Today I am back here to release *twve* v3.2.5, with some bug fixes and *quite
a few addition of functions* to *tcalc*.

For more information and download links, see Release Note v3.2.5 at
TiddlySpot <http://twve.tiddlyspot.com/#[[Release%20Note%20v3.2.5]]> ro
TiddlySpace <http://twve.tiddlyspace.com/#[[Release%20Note%20v3.2.5]]>.

Have a nice weekend!

Vincent

Yakov,
Good to hear from you again, and thanks a lot for the bug report and
suggestions. After a quick test I realized that bug has long been there, I
just never found it. Thanks again for finding it for me. It is fixed in my
current snapshot and will be gone in the next release.
About the Handsontable, I do seriously consider using it. However, instead
of making the *twve* work with it directly, I am thinking of another
plugin that works with Handsontable, and make that plugin recognized in
*twve*. That way we should have the benefit that people have the choice
to work with Handsontable solely or to include *twve*.
Have fun!
Vincent
Hi Vincent,
nice to see that the development is going on! It was a hard year, but
probably I'll be able to provide consistent feedback during most of the
summer.
1) I haven't been using v 3.2.3 actively and now noticed that it and 3.2.4
have a major bug in table editing: if the first cell is empty, which is
quite a frequent case, like in
||param1|param2|param3|
|object1|value11|value12|value13|
|object2|value21|value22|value23|
, opening cells in the second row opens values of the wrong cell! Minimal
||a|
|b|c|
here, "b" and "c" raws show empty values;
||a|b|
|c|d|e|
here "c" and "d" show empty values while "e" shows "a". Meaning that they
take values from the cells that are to the top left from them.
Even more tricky, if I put those to together in one tiddler (separated
with double line break), editing "e" in the second table acutally edits "a"
in the first one! (but /shows/ it as thought as the right cells was
changed: to "see the truth", open the ordinary edit mode).
2) I've seen at [1] the discussion about the excel-like interface library.
It works quite nicely (very good thing it does so with the clipboard), so I
wonder if you consider using it. Of'course the fact that it uses jQuery is
quite bad, but if the implementation is not very difficult, this can be
done as an optional addition for those who use twve with TWc.
Best regards,
Yakov.
[1]
...

[Yakov]

Hello Vincent,

nice to hear from you again! Glad there's some progress, too.

I've done some tests and here's some results:

- menu of twve (in tiddlers) now works fine in FF but is not displayed at
all

- still have poorly reproducible bug: sometimes opening the ordinary edit
mode and then exiting it by esc (after, say, copying the text without
modifying) causes "are you sure you'd like to abandon changes?" message

- text blocks got some new strange behaviour (I guess that's temporal
thing): below is a self-explanatory two-paragraph tiddler:
open this paragraph to edit, type a letter: instead of being added it to
the end of the paragraph, it is added in a new line. The misleading thing
is: if one presses "right" the cursor if displayed //on the end of the
paragraph//, but once typing is started, it "jumps" to the next line (is
displayed there) and letters are added there.

paragraph 2

- (still looking forward to get arrow navigation between "paragraphs"; nice
thing is they are no longer splitted by inline elements inside them)

- *important:* when a list item is opened for editing, several causes
(pressing ctrl/shift/alt/clicking inside it/...) make edit area "disappear"
(in fact it gets hidden under the previewer, as far as I can see), and
after saving (pressing enter) the editor almost (or fully) get disabled

That's all for now, I haven't run the whole set of tests yet.

Best regards,
Yakov.

Post by Vincent Yeh
Hello, everyone,
It's been a while since last release of *twve*. I've been busy at work
and spending very limited time on it.
Today I am back here to release *twve* v3.2.5, with some bug fixes and *quite
a few addition of functions* to *tcalc*.
For more information and download links, see Release Note v3.2.5 at
TiddlySpot
<http://twve.tiddlyspot.com/#%5B%5BRelease%20Note%20v3.2.5%5D%5D> ro
TiddlySpace
<http://twve.tiddlyspace.com/#%5B%5BRelease%20Note%20v3.2.5%5D%5D>.
Have a nice weekend!
Vincent
Yakov,
Good to hear from you again, and thanks a lot for the bug report and
suggestions. After a quick test I realized that bug has long been there, I
just never found it. Thanks again for finding it for me. It is fixed in my
current snapshot and will be gone in the next release.
About the Handsontable, I do seriously consider using it. However, instead
of making the *twve* work with it directly, I am thinking of another
plugin that works with Handsontable, and make that plugin recognized in
*twve*. That way we should have the benefit that people have the choice
to work with Handsontable solely or to include *twve*.
Have fun!
Vincent
Hi Vincent,
nice to see that the development is going on! It was a hard year, but
probably I'll be able to provide consistent feedback during most of the
summer.
1) I haven't been using v 3.2.3 actively and now noticed that it and 3.2.4
have a major bug in table editing: if the first cell is empty, which is
quite a frequent case, like in
||param1|param2|param3|
|object1|value11|value12|
...

[Vincent Yeh]

This post might be inappropriate. Click to display it.

[Yakov]

Hi Vincent,

- menu of twve (in tiddlers) now works fine in FF but is not displayed at

Post by Vincent Yeh
all
In my FF (42.0 / Win10) it is displayed as expected. Which version of FF
you are using?

Sorry, here "in Opera 12.x" is missing, it works in FF as expected

- still have poorly reproducible bug: sometimes opening the ordinary edit

Post by Vincent Yeh

Post by Yakov
mode and then exiting it by esc (after, say, copying the text without
modifying) causes "are you sure you'd like to abandon changes?" message

That message is probably not from *twve*, I don't find anywhere such a
message in the codes.

The exact message is that from the core ("Are you sure you want to abandon
your changes to '%0'?"), which is config.commands.cancelTiddler.warning,
the origin of the text is surely not twve, but the behaviour may originate
from it. Still, this is a poorly reproduced bug, so if no ideas here, let's
skip it for the time being

Post by Vincent Yeh
- *important:* when a list item is opened for editing, several causes
(pressing ctrl/shift/alt/clicking inside it/...) make edit area "disappear"
(in fact it gets hidden under the previewer, as far as I can see), and
after saving (pressing enter) the editor almost (or fully) get disabled
I do not have such a behavior in my browser. Are you using 2.8.1 as I am,
or some earlier version?

This is in 2.7.1, yes. (CoreVersion slices of all plugins say "2.7.0" or
"2.6.5" for now.. are they not up-to-date?)

By the way, I am having trouble porting *tcalc* to TW5: I can create a

Post by Vincent Yeh
plugin and I do see the plugin listed in control panel, but the codes are
not loaded at all (I couldn't find the code module in Firebug)! You know
what's going wrong?

Unfortunatelly, I don't know much about TW5 and most likely can't help here.

Best regards,
Yakov.

[Vincent Yeh]

Yakov,

Post by Yakov
Hi Vincent,
- menu of twve (in tiddlers) now works fine in FF but is not displayed at
all
In my FF (42.0 / Win10) it is displayed as expected. Which version of FF
you are using?
Sorry, here "in Opera 12.x" is missing, it works in FF as expected

The Opera I just downloaded and installed says 33.0, it works just fine. Do
you consider using the latest one?

Post by Yakov
- still have poorly reproducible bug: sometimes opening the ordinary edit
mode and then exiting it by esc (after, say, copying the text without
modifying) causes "are you sure you'd like to abandon changes?" message
That message is probably not from *twve*, I don't find anywhere such a
message in the codes.
The exact message is that from the core ("Are you sure you want to
abandon your changes to '%0'?"), which is config.commands.cancelTiddler.
warning, the origin of the text is surely not twve, but the behaviour may
originate from it. Still, this is a poorly reproduced bug, so if no ideas
here, let's skip it for the time being

Sure. Let me know if you have it regularly, please.

Post by Yakov
...

Core 2.7.1, I am not sure at this moment. I will try it after a few busy
days and see what I can do.

Thanks again for your feedback.

Have Fun!

Vincent

[Vincent Yeh]

Yakov,

Post by Yakov
Hi Vincent,
- menu of twve (in tiddlers) now works fine in FF but is not displayed at

Post by Vincent Yeh
all
In my FF (42.0 / Win10) it is displayed as expected. Which version of FF
you are using?

Sorry, here "in Opera 12.x" is missing, it works in FF as expected
- still have poorly reproducible bug: sometimes opening the ordinary edit

Post by Vincent Yeh

Post by Yakov
mode and then exiting it by esc (after, say, copying the text without
modifying) causes "are you sure you'd like to abandon changes?" message

That message is probably not from *twve*, I don't find anywhere such a
message in the codes.

The exact message is that from the core ("Are you sure you want to
abandon your changes to '%0'?"), which is config.commands.cancelTiddler.
warning, the origin of the text is surely not twve, but the behaviour may
originate from it. Still, this is a poorly reproduced bug, so if no ideas
here, let's skip it for the time being

Post by Vincent Yeh
- *important:* when a list item is opened for editing, several causes
(pressing ctrl/shift/alt/clicking inside it/...) make edit area "disappear"
(in fact it gets hidden under the previewer, as far as I can see), and
after saving (pressing enter) the editor almost (or fully) get disabled
I do not have such a behavior in my browser. Are you using 2.8.1 as I am,
or some earlier version?

This is in 2.7.1, yes. (CoreVersion slices of all plugins say "2.7.0" or
"2.6.5" for now.. are they not up-to-date?)

I tried with 2.7.1 using the latest Opera 33.0 / Win10, it works fine. I
guess it could be the old Opera 12.x (which I haven't tried yet), or a
plugin conflict (I am betting on this). Can you give me a possible list of
conflicting plugins so I can try on?

Have fun!

Vincent

Post by Yakov
By the way, I am having trouble porting *tcalc* to TW5: I can create a

Post by Vincent Yeh
plugin and I do see the plugin listed in control panel, but the codes are
not loaded at all (I couldn't find the code module in Firebug)! You know
what's going wrong?

Unfortunatelly, I don't know much about TW5 and most likely can't help here.
Best regards,
Yakov.

[Yakov]

Hi Vincent,

as for Opera 12.x, I don't care much, really, but I use it for some dev
purposes. It has a very convenient engine which simplifies DOM inspection
tremendously and has some other nice features. Just saying (still, the bug
may appear in another browser, for now I usually test TW things only in
FireFox).

Post by Vincent Yeh

Post by Yakov

Post by Yakov
- *important:* when a list item is opened for editing, several causes
(pressing ctrl/shift/alt/clicking inside it/...) make edit area "disappear"
(in fact it gets hidden under the previewer, as far as I can see), and
after saving (pressing enter) the editor almost (or fully) get disabled
I do not have such a behavior in my browser. Are you using 2.8.1 as I
am, or some earlier version?

This is in 2.7.1, yes. (CoreVersion slices of all plugins say "2.7.0" or
"2.6.5" for now.. are they not up-to-date?)

I tried with 2.7.1 using the latest Opera 33.0 / Win10, it works fine. I
guess it could be the old Opera 12.x (which I haven't tried yet), or a
plugin conflict (I am betting on this). Can you give me a possible list of
conflicting plugins so I can try on?
again, this bug is in FireFox (latest one, Windows 7) + TW 2.7.1 and is

perfectly reproducible.

Best regards,
Yakov.

[Yakov]

Hi Vincent,

how are you? Any progress with the development? (arrow navigation between
blocks, that stuff :)

Best regards,
Yakov.

[Vincent Yeh]

Yakov,

Yes there is good progress in the arrow navigation: I can now use the left/right arrow keys to navigate between paragraphs and block elements within the same tiddler, but there is still some debugging to do. It won't be released in a few weeks because the coming Chinese new year break and my recent schedule. I can give you a snapshot copy to try if you like.

Have fun!

[Yakov]

Hi Vincent,

nice to hear :)
that would be lovely (although I'll probably report some bugs that you're
already aware of).

Best regards and nice holidays,
Yakov.

Yakov,
Yes there is good progress in the arrow navigation: I can now use the
left/right arrow keys to navigate between paragraphs and block elements
within the same tiddler, but there is still some debugging to do. It won't
be released in a few weeks because the coming Chinese new year break and my
recent schedule. I can give you a snapshot copy to try if you like.
Have fun!

[Vincent Yeh]

Yakov,

Here is a link to a test file for the current snapshot of the *twve*
plugins with simple keyboard navigation functionality. Please try with
different tiddler content and help speed up the debugging. :-)

https://www.dropbox.com/s/8tm3ipkb1h34tiz/twve.pre-pre4.wysiwyg.html?dl=0

Have Fun!
Vincent

Post by Yakov
Hi Vincent,
nice to hear :)
that would be lovely (although I'll probably report some bugs that you're
already aware of).
Best regards and nice holidays,
Yakov.
втПрМОк, 2 февраля 2016 г., 13:28:33 UTC+3 пПльзПватель Vincent Yeh

Yakov,
Yes there is good progress in the arrow navigation: I can now use the
left/right arrow keys to navigate between paragraphs and block elements
within the same tiddler, but there is still some debugging to do. It won't
be released in a few weeks because the coming Chinese new year break and my
recent schedule. I can give you a snapshot copy to try if you like.
Have fun!

[Vincent Yeh]

The DropBox link in the last reply was a bit strange, I changed it in this
one and added another OneDrive link. They should be fine.

Yakov,
Here is a link to a test file for the current snapshot of the *twve*
plugins with simple keyboard navigation functionality. Please try with
different tiddler content and help speed up the debugging. :-)
- DropBox
<https://dl.dropboxusercontent.com/u/23745840/twve.pre-pre4.wysiwyg.html>
- OneDrive
<https://onedrive.live.com/redir?resid=9750EE20E90E3E35!8135&authkey=!AHyqTGBworXmgno&ithint=file%2chtml>
Have Fun!
Vincent
Hi Vincent,
nice to hear :)
that would be lovely (although I'll probably report some bugs that you're
already aware of).
Best regards and nice holidays,
Yakov.
втПрМОк, 2 февраля 2016 г., 13:28:33 UTC+3 пПльзПватель Vincent Yeh
...

[Yakov]

Hi Vincent,

navigation between blocks makes nice impression indeed! Now, let me point
some issues (for now, tested in FF only):

1. Create a tiddler with a short paragraph (shorter than a line), an empty
line and another paragraph (line after 2 linebreaks). Go to the view mode,
click the first paragraph, go to the its end. Press right: what I get is an
*extra* block to the right from the first paragraph, then I press right
again, I get the empty line block (which is ok), then the second paragraph.
Interestingly enough, if I have a paragraph, a linebreak and a list item
(only one linebreak after the paragraph before the "*" symbol), I get this
"extra block", too; however, list items don't generate this "extra block"
(which can be seen if tiddler contains a list item and then a paragraph).
Another aspect: empty lines don't generate the "extra block".

2. In this case, I would expect "down" arrow to act like the "left" arrow.
Well, not exactly in the same manner, but surely "down" should also bring
me to the next block.

3. Adding a new text block to an end of a tiddler works nicely. But if in a
tiddler with a couple of text blocks, A and B (double linebreak between
them) I go to A, then press (in the end) enter-enter (creating a couple of
new lines) and add some text to the new "paragraph" (C), and then press
"right", I get to the new empty line between A and C. What is expected: I
get to the empty line between C and B.

Ok, there's more, but let's make a pause here: I even don't know if you
have changed the code since the latest post (if so, please send another
snapshot/update the dropbox file).

Best regards,
Yakov.

Post by Vincent Yeh
The DropBox link in the last reply was a bit strange, I changed it in this
one and added another OneDrive link. They should be fine.
Yakov,
Here is a link to a test file for the current snapshot of the *twve*
plugins with simple keyboard navigation functionality. Please try with
different tiddler content and help speed up the debugging. :-)
- DropBox
<https://dl.dropboxusercontent.com/u/23745840/twve.pre-pre4.wysiwyg.html>
-
...

[Vincent Yeh]

Yakov,

Post by Yakov
Hi Vincent,
navigation between blocks makes nice impression indeed! Now, let me point

Glad to hear this from you!

Post by Yakov
1. Create a tiddler with a short paragraph (shorter than a line), an empty
line and another paragraph (line after 2 linebreaks). Go to the view mode,
click the first paragraph, go to the its end. Press right: what I get is an
*extra* block to the right from the first paragraph, then I press right
again, I get the empty line block (which is ok), then the second paragraph.
Interestingly enough, if I have a paragraph, a linebreak and a list item
(only one linebreak after the paragraph before the "*" symbol), I get this
"extra block", too; however, list items don't generate this "extra block"
(which can be seen if tiddler contains a list item and then a paragraph).
Another aspect: empty lines don't generate the "extra block".

The "extra block" corresponds to a BR element in the DOM tree. A paragraph
is usually followed by a BR, therefore you see that extra block. An empty
line is nothing but a BR, so that edit box for an empty line is already
that "extra box" itself, and that's why you don't get another extra box
again. Anything that's not followed by a BR does not give you this extra
box.

I am still thinking of a good way to handle those BR's.....

Post by Yakov
2. In this case, I would expect "down" arrow to act like the "left" arrow.
Well, not exactly in the same manner, but surely "down" should also bring
me to the next block.

The down and up arrows are not implemented because I have not yet figured
out how to move the cursor in a visually consistent way. I mean when I
press the up arrow I do expect to see the cursor go straight above instead
of to the very left of the element above, don't I?

Post by Yakov
3. Adding a new text block to an end of a tiddler works nicely. But if in
a tiddler with a couple of text blocks, A and B (double linebreak between
them) I go to A, then press (in the end) enter-enter (creating a couple of
new lines) and add some text to the new "paragraph" (C), and then press
"right", I get to the new empty line between A and C. What is expected: I
get to the empty line between C and B.

This is a bug to fix for sure. Thanks for finding it for me.

Post by Yakov
Ok, there's more, but let's make a pause here: I even don't know if you
have changed the code since the latest post (if so, please send another
snapshot/update the dropbox file).

A couple of bug fixes were done but not much. Maybe a bit later when I got
the above bug fixed.

Thanks a lot and have fun!
Vincent

Post by Yakov
Best regards,
Yakov.
...

[Yakov]

Hi Vincent,

Post by Vincent Yeh

Post by Yakov
1. Create a tiddler with a short paragraph (shorter than a line), an
empty line and another paragraph (line after 2 linebreaks). Go to the view
mode, click the first paragraph, go to the its end. Press right: what I get
is an *extra* block to the right from the first paragraph, then I press
right again, I get the empty line block (which is ok), then the second
paragraph. Interestingly enough, if I have a paragraph, a linebreak and a
list item (only one linebreak after the paragraph before the "*" symbol), I
get this "extra block", too; however, list items don't generate this "extra
block" (which can be seen if tiddler contains a list item and then a
paragraph). Another aspect: empty lines don't generate the "extra block".

The "extra block" corresponds to a BR element in the DOM tree. A paragraph
is usually followed by a BR, therefore you see that extra block. An empty
line is nothing but a BR, so that edit box for an empty line is already
that "extra box" itself, and that's why you don't get another extra box
again. Anything that's not followed by a BR does not give you this extra
box.
I am still thinking of a good way to handle those BR's.....
Well, I think a BR element should generate an edit block only if it is

followed by another BR, and if changes are to be applied the text should be
inserted after it [the first one].

Post by Vincent Yeh

Post by Yakov
2. In this case, I would expect "down" arrow to act like the "left"
arrow. Well, not exactly in the same manner, but surely "down" should also
bring me to the next block.

The down and up arrows are not implemented because I have not yet figured
out how to move the cursor in a visually consistent way. I mean when I
press the up arrow I do expect to see the cursor go straight above instead
of to the very left of the element above, don't I?

That's a fair note. But I think this is not to be taken into account until
the edit-area+preview pair is substituted with a WYSIWYGish edit area. Once
that is done, you can calculate the X coordinate of the cursor, predict
which coordinate it will get if it is place after the first letter of the
line, after the second etc and decide which variant is closest to the
current, and act accordingly. Alternatively, you can implement the
behaviour of office-like editors: they find the position which is not
closest (by X) to the current one, but rather to the "previous left"
position which is changed on pressing anything but up or down (with
exception of start/end-of-text positions). To simplify understanding this
alternative behaviour, I'll illustrate it this way:

consider the text below, "x" are letters, "l" is the cursor:

xxxxxxxxxxxxxxxxxxxxxxxxxxx*l*xxxxx
xxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

If one presses "down" twice, in the first model (s)he will get:

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxx
xxxxxxxxxxx*l*xxxxxxxxxxxxxxxxxxxxx

but in the second (s)he will get:

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxx*l*xxxxx

So, after you understand the illustration, you may want to re-read my
description which may be not very clear without it..

Again, untill a WYSIWYGish edit area is not implemented, you probably don't
have to implement this "go right below" stuff (while the "down to get to
the next block" behaviour is needed constantly when navigating through
text). Yet, there's a third path: on "down", open the new text edit area
(with preview) and predict the cursor position.

Auxiliary: to find X coordinate of the cursor in textarea and in other
elements, you probably have to use different tools.
For textareas, [1] may be see helpful
For other elements, see [2] (but that's for *selection* and you will
probably emulate a cursor anyway, and the cursor element will probably
bring a better way by itself)

Best regards,
Yakov.

[1]
http://stackoverflow.com/questions/29709/how-do-i-get-the-x-y-pixel-coordinates-of-the-caret-in-text-boxes
[2]
http://stackoverflow.com/questions/6846230/coordinates-of-selected-text-in-browser-page

[Yakov]

Hi Vincent,

Post by Yakov
1. Create a tiddler with a short paragraph (shorter than a line), an
empty line and another paragraph (line after 2 linebreaks). Go to the view
mode, click the first paragraph, go to the its end. Press right: what I get
is an *extra* block to the right from the first paragraph, then I press
right again, I get the empty line block (which is ok), then the second
paragraph. Interestingly enough, if I have a paragraph, a linebreak and a
list item (only one linebreak after the paragraph before the "*" symbol), I
get this "extra block", too; however, list items don't generate this "extra
block" (which can be seen if tiddler contains a list item and then a
paragraph). Another aspect: empty lines don't generate the "extra block".
The "extra block" corresponds to a BR element in the DOM tree. A
paragraph is usually followed by a BR, therefore you see that extra block.
An empty line is nothing but a BR, so that edit box for an empty line is
already that "extra box" itself, and that's why you don't get another extra
box again. Anything that's not followed by a BR does not give you this
extra box.
I am still thinking of a good way to handle those BR's.....
Well, I think a BR element should generate an edit block only if it is
followed by another BR, and if changes are to be applied the text should be
inserted after it [the first one].

That is a good idea, but what confuses me now is the seemingly
unpredictable appearance/disappearance of the BR's immediately before/after
a block element...

I have to admit, I'm not sure what possible problem you're talking about
(well, at least I don't understand what are the possible causes). Or may be
you have tested this already?

Best regards,
Yakov.

[Vincent Yeh]

Yakov,

Post by Yakov
Hi Vincent,

Post by Yakov
1. Create a tiddler with a short paragraph (shorter than a line), an
empty line and another paragraph (line after 2 linebreaks). Go to the view
mode, click the first paragraph, go to the its end. Press right: what I get
is an *extra* block to the right from the first paragraph, then I press
right again, I get the empty line block (which is ok), then the second
paragraph. Interestingly enough, if I have a paragraph, a linebreak and a
list item (only one linebreak after the paragraph before the "*" symbol), I
get this "extra block", too; however, list items don't generate this "extra
block" (which can be seen if tiddler contains a list item and then a
paragraph). Another aspect: empty lines don't generate the "extra block".
The "extra block" corresponds to a BR element in the DOM tree. A
paragraph is usually followed by a BR, therefore you see that extra block.
An empty line is nothing but a BR, so that edit box for an empty line is
already that "extra box" itself, and that's why you don't get another extra
box again. Anything that's not followed by a BR does not give you this
extra box.
I am still thinking of a good way to handle those BR's.....
Well, I think a BR element should generate an edit block only if it is
followed by another BR, and if changes are to be applied the text should be
inserted after it [the first one].

That is a good idea, but what confuses me now is the seemingly
unpredictable appearance/disappearance of the BR's immediately before/after
a block element...

I have to admit, I'm not sure what possible problem you're talking about
(well, at least I don't understand what are the possible causes). Or may be
you have tested this already?

I meant the correspondence between a \n character and a BR element. At the
beginning I thought that every BR corresponds to one \n, but did not see
such a correspondence in the rendered tiddlers. That's why I thought it
unpredictable.

These days I played a bit more and found that if "one block element is
immediately following another", then that \n between the wiki text defining
the two block elements is not rendered as a BR. All other cases \n's seem
to have their corresponding BR's. I will find time to implement this
finding in the codes and see how it works. I'll send you a new snapshot
when I have one (may take a while though).

Have fun!
Vincent

Post by Yakov
Best regards,
Yakov.

[Yakov]

Hi Vincent,

I meant the correspondence between a \n character and a BR element. At the

Post by Vincent Yeh
beginning I thought that every BR corresponds to one \n, but did not see
such a correspondence in the rendered tiddlers. That's why I thought it
unpredictable.
These days I played a bit more and found that if "one block element is
immediately following another", then that \n between the wiki text defining
the two block elements is not rendered as a BR. All other cases \n's seem
to have their corresponding BR's. I will find time to implement this
finding in the codes and see how it works. I'll send you a new snapshot
when I have one (may take a while though).
you are probably referring to TiddlyWiki5 here, I've heard about this

behaviour of TW5 ("backward incompability"); keep in mind that in
TiddlyWiki Classic double \n *are* rendered as double <br>, so
unfortunately the algorithms should be different for the 2 cases. But for
TWc it should be quite straight-forward, one \n after an ordinary text
block (not table, caption, list item etc) corresponds to one <br>.

Best regards,
Yakov.

[Vincent Yeh]

Yakov,

I changed the behavior with BR, added actions to UP (same action as LEFT)
and DOWN (same as RIGHT) arrow keys, and fixed some bugs. If interested
please try this snapshot:
https://dl.dropboxusercontent.com/u/23745840/twve.pre-pre4.wysiwyg.html

Thanks and have fun!
Vincent

Post by Yakov
Hi Vincent,
I meant the correspondence between a \n character and a BR element. At the
beginning I thought that every BR corresponds to one \n, but did not see
such a correspondence in the rendered tiddlers. That's why I thought it
unpredictable.
These days I played a bit more and found that if "one block element is
immediately following another", then that \n between the wiki text defining
the two block elements is not rendered as a BR. All other cases \n's seem
to have their corresponding BR's. I will find time to implement this
finding in the codes and see how it works. I'll send you a new snapshot
when I have one (may take a while though).
you are probably referring to TiddlyWiki5 here, I've heard about this
behaviour of TW5 ("backward incompability
...

[Leo Staley]

This is great to see! Just for ease of use, would you be able to put this
package together with the full version that has the examples and
documentation, so I can play around with it a bit more easily?

Yakov,
I changed the behavior with BR, added actions to UP (same action as LEFT)
and DOWN (same as RIGHT) arrow keys, and fixed some bugs. If interested
https://dl.dropboxusercontent.com/u/23745840/twve.pre-pre4.wysiwyg.html
Thanks and have fun!
Vincent
Hi Vincent,
I meant the correspondence between a \n character and a BR element. At the
beginning I thought that every BR corresponds to one \n, but did not see
such a correspondence in the rendered tiddlers. That's why I thought it
unpredictable.
These days I played a bit more and found that if "one block element is
immediately following another",
...

[Vincent Yeh]

Leo,

Thanks for your interest in *twve*. I had put activated the current
snapshot in http://twve.tiddlyspot.com/, you are welcome to try and give
comments/suggestions/feedback.

*Note*:

1. This snapshot (v 3.2.6) is still *unstable*, if trying it locally
better make a backup of your tiddlers.
2. For those who want to install the currently released version (v
3.2.5), download the *minimized version* (*grouped under the tag
"Plugins"* in http://twve.tiddlyspot.com).

Have fun!
Vincent

Post by Leo Staley
This is great to see! Just for ease of use, would you be able to put this
package together with the full version that has the examples and
documentation, so I can play around with it a bit more easily?
Yakov,
I changed the behavior with BR, added actions to UP (same action as LEFT)
and DOWN (same as RIGHT) arrow keys, and fixed some bugs. If interested
https://dl.dropboxusercontent.com/u/23745840/twve.pre-pre4.wysiwyg.htm
<https://dl.dropboxusercontent.com/u/23745840/twve.pre-pre4.wysiwyg.html>
...

[Yakov]

Hi Vincent,

first of all, going up/down from block to block implementation is very
cool, much better experience now!

Second, lists are now edited as a whole, not one list item at a time. I
guess, this is some deliberate temporal state, I mention it just in case it
is not and/or you don't know about it.

Next, I'd say that in empty block pressing backspace is expected to cause
a) going to the previous block and b) removing of the empty block.
Likewise, in non-empty block pressing backspace when the cursor is on the
first position should cause a) going to the previous block (end position)
b) concatenate the content to the content of the previous block and c)
removing the block where we were initially. Implementing this feature will
imrove experience much, as this seems to be the last thing that force user
to use mouse during editing.

Now, the "boring" part.

1. create a one-line tiddler with text alpha __beta__ gamma. Click to edit
the only block. Add a new line (enter) and apply (ctrl+enter). Enter the
ordinary edit mode (click "edit"). Press esc to cancel. What is expected:
the changes are already applied, and since I haven't changed anything in
the ordinary edit mode I will just leave. What actually happens: the editor
asks if we should leave without saving changes (as thought as they were
done in the edit mode, not in twve).

2. I've got a ton of weird bugs playing with that tiddler (especially when
adding or removing underline or newline), including more multiplying the
content, separating alpha and __beta__ gamma as blocks and other stuff, but
the behaviour changes very often and in an unpredictable way (seems that it
is *history-depenent*), so for some time I had no luck in reproducing them
(except for the one described above). The point here is you probably should
investigate what can be the source of this history dependence, as it will
probably provide many difficulties in the future.

3. I've got more luck in reproducing bugs when I started to refresh my TW
after each test and close all tiddlers but the test one (for the clear
experiments I used permaview not put anything else to the "history"). Steps
to reproduce one of the bugs: close all tiddlers, open the tiddler with
text alpha __beta__ gamma, permaview, reload TW. Inline-edit it: add a new
line after the end of the first one, ctrl+enter to apply. Inline-open it
again clicking the first line, remove the newline, ctrl+enter to apply.
What I see in the view mode: alpha alpha *beta* gamma; but if I open the
ordinary edit mode, the content is still alpha __beta__ gamma.

Best regards,
Yakov.

[Hegart Dmishiv]

Hi all,

Sorry, to save me from having to read through all 7 pages of this
discussion, can I just quickly ask whether this is for TWC or TW5? In our
*{{DesignWrite}}* semester project, TiddlyCRM
<https://groups.google.com/forum/#!topic/tiddlywiki/9PSw_3OsyyE>, we've
come to the point where we're considering how best to handle editing in the
view mode. We're trying to avoid having our end-user go into TiddlyWiki's
edit more at all. We're using TW5.

Thanks,

Hegart.

Post by Yakov
Hi Vincent,
first of all, going up/down from block to block implementation is very
cool, much better experience now!
Second, lists are now edited as a whole, not one list item at a time. I
guess, this is some deliberate temporal state, I mention it just in case it
is not and/or you don't know about it.
Next, I'd say that in empty block pressing backspace is expected to cause
a) going to the previous block and b) removing of the empty block.
Likewise, in non-empty block pressing backspace when the cursor is on the
first position should cause a) going to the previous block (end position)
b) concatenate the content to the content of the previous block and c)
removing the block where we were initially. Implementing this feature will
imrove experience much, as this seems to be the last thing that force user
to use mouse during editing.
Now, the "boring" part.
1. create a one-line tiddler with text alpha __beta__ gamma. Click to
edit the only block. Add a new line (enter) and apply (ctrl+enter). Enter
the ordinary edit mode (click "edit"). Press esc to cancel. What is
expected: the changes are already applied, and since I haven't changed
anything in the ordinary edit mode I will just leave. What actually
happens: the editor asks if we should leave without saving changes (as
thought as they were done in the edit mode, not in twve).
2. I've got a ton of weird bugs playing with that tiddler (especially when
adding or removing underline or newline), including more multiplying the
content, separating alpha and __beta__ gamma as blocks and other stuff,
but the behaviour changes very often and in an unpredictab
...

['c pa' via TiddlyWiki]

To edit a tiddler you have open in view mode you need to have edit widgets
embedded in the page template. The downside, you can't edit the tiddler's
text in view mode. You can easily change field values in view mode. by
having the template create select and/or edit widgets.
The other option is to edit a Tiddler you don't have open by embedding a
screen of widgets in the body of a different tiddler then linking it to
edit different tiddlers based on a select.

I've created a demo here: http://cpashow.tiddlyspot.com/#crazyListHere

[Vincent Yeh]

Post by 'c pa' via TiddlyWiki
To edit a tiddler you have open in view mode you need to have edit widgets
embedded in the page template. The downside, you can't edit the tiddler's
text in view mode. You can easily change field values in view mode. by
having the template create select and/or edit widgets.
The other option is to edit a Tiddler you don't have open by embedding a
screen of widgets in the body of a different tiddler then linking it to
edit different tiddlers based on a select.

So ... , should I give up the idea of getting *twve* to TW5?

Post by 'c pa' via TiddlyWiki
I've created a demo here: http://cpashow.tiddlyspot.com/#crazyListHere

[Vincent Yeh]

Hello Hegart,

These plugins are currently for TWC and not yet migrated to TW5. I do plan
to go TW5 in the future, but currently

1. I have very limited time on these plugins, and
2. I am spending my limited time on a close-to-WYSIWYG editing mode.

I don't have a clear date for these plugins to go TW5 yet.


Thank you for your interest anyway. Wish you a good success in your project!


Have fun!

Vincent

Post by Hegart Dmishiv
Hi all,
Sorry, to save me from having to read through all 7 pages of this
discussion, can I just quickly ask whether this is for TWC or TW5? In our
*{{DesignWrite}}* semester project, TiddlyCRM
<https://groups.google.com/forum/#!topic/tiddlywiki/9PSw_3OsyyE>, we've
come to the point where we're considering how best to handle editing in the
view mode. We're trying to avoid having our end-user go into TiddlyWiki's
edit mode at all. We're using TW5.
Thanks,
Hegart.
Hi Vincent,
first of all, going up/down from block to block implementation is very
cool, much better experience now!
Second, lists are now edited as a whole, not one list item at a time. I
guess, this is some deliberate temporal state, I mention it just in case it
is not and/or you don't know about it.
Next, I'd say that in empty block pressing backspace is expected to cause
a) going to the previous block and b) removing of the empty block.
Likewise, in non-empty block pressing backspace when the cursor is on the
first position should cause a) going to the previous block (end position)
b) concatenate the content to the content of the previous block and c)
removing the block where we were initially. Implementing this feature will
imrove experience much, as this seems to be the last thing that force user
to use mouse during editing.
...

[Hegart Dmishiv]

Hi *c pa* and *Vincent*,

Thanks for the replies, both of you. I've got two ideas from all of this,
and I'd like to run them both by you all, to see which one you think is
better.

*Option A*

We could copy all the fields from the current tiddler (in our example, it
would be a specific Person, for instance) and copy them to a temporary
system tiddler. We then *delete the current tiddler*, so that we don't end
up with an orphan if the user edits the tiddler title (thereby effectively
creating a new tiddler). Then we copy the values in the fields from the
temporary system tiddler into our "Edit Person" tiddler using *<$vars>*
variables, to basically back up the current state of the Person, in the
event that the user decides to cancel editing half-way through. The tiddler
we deleted can then be re-created from the backed-up values. This "Edit
Person" tiddler contains the *<$edit-text>* widgets and other controls we
need, and they're linked back to the fields in the same temporary system
tiddler. When the user is satisfied with their edits, we just create a new
tiddler based on those fields, exactly as we did from our "Add Person"
tiddler when the old (now deleted) tiddler was created originally.

*Option B*

Similar to Option A above, except we don't need to delete the existing
tiddler, because we don't give the user any opportunity to edit the title
of the tiddler at all. Where currently our tiddler titles are created from
a combination of the Person's first and last names, we would replace this
instead with a GUID at creation time, so *all Person tiddlers would have a
GUID for their tiddler title*. The first and last name fields can then be
edited freely without it affecting the title of the tiddler, and no orphan
is produced. We plan to hide the tiddler title and tags anyway, so the
nasty GUIDs should never be seen by the end-user.

What do you think? Which is the better plan of attack here?

Hegart.

['c pa' via TiddlyWiki]

Hegert,

The techniques that I am using are as follows:

1. Create a defined tag for each object type (person, company, call,
document, etc. ) (tag names are all lower case)
2. Create a tiddler for each object type tag and tag that tiddler with
"object"
3. Edit the object tiddler to create an edit screen for the object type to
allow the user to edit fields of the object

e.g.:
title: person
text:
First Name: <$edit field="firstname" />
Surname: <$edit field="surname" />
Employer: (One tiddler reference allowed) <$select field="employer">
<option value="" > -- </option>
<$list filter="[tag[company]]">
<option value=<<currentTiddler>> ><<currentTiddler>></option>
</$list>
</$select>
Siblings: (One to many relationship) <<listHere siblings>>

4. Create a viewTemplate that displays the object tiddler at the top of the
tiddler (So the user, when directly viewing the tiddler, can edit the
fields) (Note they cannot edit the field: text)
5. In addition I almost always create a navigation tiddler with <<listHere
person>> and an <<editHere person>> widgets so I can manage the objects
from a central point

I've been working on a standardized set of macros for this that I've posted
as the listHere tiddler on cpashow.tiddlyspot.com but I'm still changing
things for wvwey new tiddlywiki I create but I've got lots of code you can
use.

[Hegart Dmishiv]

Hi *c pa*, thanks for that. So, it looks like once your "person" object
tiddler has been created, its title field is inviolate, and cannot be
edited by the user. What is the initial value of the title field at
creation time? If it is a name, say title:Joe Bloggs, what happens when
the user then comes along and uses your *<$edit>* widgets to change the
firstname and surname fields to firstname:Jane and surname:Doe but the title
still shows as title:Joe Bloggs? That is one of the things I'm trying to
avoid having happen.

Hegart.

Post by 'c pa' via TiddlyWiki
Hegert,
1. Create a defined tag for each object type (person, company, call,
document, etc. ) (tag names are all lower case)
2. Create a tiddler for each object type tag and tag that tiddler with
"object"
3. Edit the object tiddler to create an edit screen for the object type to
allow the user to edit fields of the object
title: person
First Name: <$edit field="firstname" />
Surname: <$edit field="surname" />
Employer: (One tiddler reference allowed) <$select field="employer">
<option value="" > -- </option>
<$list filter="[tag[company]]">
<option value=<<currentTiddler>> ><<currentTiddler>></option>
</$list>
</$select>
Siblings: (One to many relationship) <<listHere siblings>>
4. Create a viewTemplate that displays the object tiddler at the top of
the tiddler (So the user, when directly viewing the tiddler, can edit the
fields) (Note they cannot edit the field: text)
5. In addition I almost always create a navigation tiddler with <<listHere
person>> and an <<editHere person>> widgets so I can manage the objects
from a central point
I've been working on a standardized set of macros for this that I've
posted as the listHere tiddler on cpashow.tiddlyspot.com but I'm still
changing things for wvwey new tiddlywiki I create but I've got lots of code
you can use.

['c pa' via TiddlyWiki]

Yes the title is inviolate, meaning if you want to manage first name and
surname as separate fields (make sure to add Middle Initials) and display
the record as {{!!first}} {{!!mi}} {{!!last}} then I would go with the
GUUID idea and hide the title. I'd also store the {{!!first}} {{!!mi}}
{{!!last}} value as the caption in the tiddler so you can display the
fullname in TOCs etc.

I built a little CRM demo here: http://cpashow.tiddlyspot.com/#CRM to show
how I build relationships. What's missing with this is the one to many
relationships (which I'm still working on) (and I didn't create a tiddler
named "call" to provide the edit template for phone calls.

[Hegart Dmishiv]

Hi *c pa*,

Wow, thanks, you've given us much to think about. I like the idea of
populating the caption from the name fields, I hadn't thought about that.
Thanks, we'll pull your demo apart and find out what makes it tick. Lots of
great ideas here!

Hegart.

Post by 'c pa' via TiddlyWiki
Yes the title is inviolate, meaning if you want to manage first name and
surname as separate fields (make sure to add Middle Initials) and display
the record as {{!!first}} {{!!mi}} {{!!last}} then I would go with the
GUUID idea and hide the title. I'd also store the {{!!first}} {{!!mi}}
{{!!last}} value as the caption in the tiddler so you can display the
fullname in TOCs etc.
I built a little CRM demo here: http://cpashow.tiddlyspot.com/#CRM to
show how I build relationships. What's missing with this is the one to many
relationships (which I'm still working on) (and I didn't create a tiddler
named "call" to provide the edit template for phone calls.

[Vincent Yeh]

Yakov,

Post by Yakov
Hi Vincent,
first of all, going up/down from block to block implementation is very
cool, much better experience now!

Thanks.

Post by Yakov
Second, lists are now edited as a whole, not one list item at a time. I
guess, this is some deliberate temporal state, I mention it just in case it
is not and/or you don't know about it.

Yes, this is different from previous versions and it is temporary. The
difference comes from the change in the searching strategy, which I am not
going to talk about here. We can discuss it further if interested.

Post by Yakov
Next, I'd say that in empty block pressing backspace is expected to cause
a) going to the previous block and b) removing of the empty block.
Likewise, in non-empty block pressing backspace when the cursor is on the
first position should cause a) going to the previous block (end position)
b) concatenate the content to the content of the previous block and c)
removing the block where we were initially. Implementing this feature will
imrove experience much, as this seems to be the last thing that force user
to use mouse during editing.

Those are good suggestions indeed. I haven't implemented the backspace
behavior yet, these will certainly be taken into consideration. Thanks a
lot!

Post by Yakov
Now, the "boring" part.
1. create a one-line tiddler with text alpha __beta__ gamma. Click to
edit the only block. Add a new line (enter) and apply (ctrl+enter). Enter
the ordinary edit mode (click "edit"). Press esc to cancel. What is
expected: the changes are already applied, and since I haven't changed
anything in the ordinary edit mode I will just leave. What actually
happens: the editor asks if we should leave without saving changes (as
thought as they were done in the edit mode, not in twve).

I think that's because the tiddler was not saved after the new-line being
added. This behavior is of TiddlyWiki (without AutoSave), not of *twve*.

Post by Yakov
2. I've got a ton of weird bugs playing with that tiddler (especially when
adding or removing underline or newline), including more multiplying the
content, separating alpha and __beta__ gamma as blocks and other stuff,
but the behaviour changes very often and in an unpredi

Sure, that is important. Thanks.

3. I've got more luck in reproducing bugs when I started to refresh my TW
after each test and close all tiddlers but the test one (for the clear
experiments I used permaview not put anything else to the "history"). Steps
to reproduce one of the bugs: close all tiddlers, open the tiddler with
text alpha __beta__ gamma, permaview, reload TW. Inline-edit it: add a new
line after the end of the first one, ctrl+enter to apply. Inline-open it
again clicking the first line, remove the newline, ctrl+enter to apply.
What I see in the view mode: alpha alpha *beta* gamma; but if I open the
ordinary edit mode, the content is still alpha __beta__ gamma.

Good to know! It is very clear and specific, should be fixable. Thank you
very much!

Thanks again for the help. I will have a couple of busy weeks from now and
shall come back to these after that.

Have fun!
Vincent

Post by Yakov
...

[Yakov]

Hi Vincent,

Post by Yakov
Now, the "boring" part.

Post by Yakov
1. create a one-line tiddler with text alpha __beta__ gamma. Click to
edit the only block. Add a new line (enter) and apply (ctrl+enter). Enter
the ordinary edit mode (click "edit"). Press esc to cancel. What is
expected: the changes are already applied, and since I haven't changed
anything in the ordinary edit mode I will just leave. What actually
happens: the editor asks if we should leave without saving changes (as
thought as they were done in the edit mode, not in twve).

I think that's because the tiddler was not saved after the new-line being
added. This behavior is of TiddlyWiki (without AutoSave), not of *twve*.
Not quite. The thing about autosave is what would be on leaving TW, not

the tiddler edit mode. This looks like no store.notify was called (and
hence no store.saveTiddler was called) and because of that no refreshing
was done, though I'm not totally sure.

Recently I've came to an idea how to create a formatter that can create an
editable text and save changes back to wikitext. The main idea is to use
such engine for MathQuill [1] in TWc which I've already implemented to some
extent, but here I'll just show the template for such formatter, may be
you'll find this useful. Now I understand TWc Wikifier relatively well, so
if you have some questions, I'll probably be able to answer. So here's the
text of the tiddler containing a test, the code and some comments:

/***
|Version|0.9|
A simple formatter is implemented here. This formatter creates DOM that can
be "reflexively edited": editing changes not only DOM, but also wikitext
which it was generated from.
|test formatter|<ff>val 3</ff> (was: {{{<ff>val 2</ff>}}})|
* recalcs slices (changes are applied); refreshing doesn't affect
distructively; several consiquent edits via one formatter work correctly
* ''test'' several edits via several formatters; test with transclusion,
including sections (both should work correctly)
***/
//{{{
var reflexiveFormatterTerm =
{
name: "reflexiveFormatterTest2",
openWrapper: "<ff>",
closeWrapper: "</ff>"

};(function($){ // concatenate to reflexiveFormatterTerm ($ = this)

$.match = $.openWrapper;
$.lookaheadRegExp = new RegExp($.openWrapper + "(.*?)" +
$.closeWrapper, "mg");
$.handler = function(w)
{
$.lookaheadRegExp.lastIndex = w.matchStart;
var wholeThingMatch = this.lookaheadRegExp.exec(w.source);
if(!wholeThingMatch) return;
// wikitext "corresponding to the formatter" with wrapper
var wholeThing = wholeThingMatch[0],
// wikitext "corresponding to the formatter" without wrapper
mainThing = wholeThingMatch[1];
w.nextMatch = this.lookaheadRegExp.lastIndex;

var sourceTiddler = w.tiddler,
startPosition = w.matchStart,
initialLength = w.matchLength;

var changeWikiText = function(newText)
{
// prepare texts and positions
var noTiddlerMsg = "changeWikiText: no sourceTiddler detected";
if(!sourceTiddler)
return console.log(noTiddlerMsg);
var endPosition = startPosition + wholeThing.length;
wholeThing = $.openWrapper + newText + $.closeWrapper;
mainThing = newText;

// change wikitext to newText
sourceTiddler.text =
sourceTiddler.text.substr(0,startPosition) +
wholeThing +
sourceTiddler.text.substr(endPosition);
//# any change of sourceTiddler.text outside without refreshing can break
the engine
// (when the length of the text before matchStart is changed)
store.saveTiddler(sourceTiddler); // recalcs slices, notifies
etc

// .oO about "no refresh" approach (change w.nextMatch,
// presumably using the difference between ..; change textNode)
// can search for the wholeThing and replace it
// drawback: will work correctly only if there's no
"duplicates"
// correct approach should probably involve a special
// "backward wikifier" object which remembers where wikitext
// matched by each formatter begins and which we can change
// when we change wikitext corresponding to our formatter
}

// do the DOM stuff
createTiddlyButton(w.output,"click to test","",function(){
changeWikiText(prompt("let's change this!",mainThing));
});
var textNode = createTiddlyText(w.output,mainThing);
}
})(reflexiveFormatterTerm);

config.formatters.push(reflexiveFormatterTerm);
//}}}

If that's interesting, I can share the apply-MathQuill code as well.

Best regards,
Yakov.

[1] http://mathquill.com/ , there's nice demo on the main page

PS Hi *Hegart* and *c pa*, I think, since this thread is used for
discussing *twve* for quite some time, it would be nice if you move the
discussion of another engine to another thread. I mean no offence, it's
just seems too offtopic now.

[Vincent Yeh]

Post by Yakov
Hi Vincent,
Now, the "boring" part.
1. create a one-line tiddler with text alpha __beta__ gamma. Click to
edit the only block. Add a new line (enter) and apply (ctrl+enter). Enter
the ordinary edit mode (click "edit"). Press esc to cancel. What is
expected: the changes are already applied, and since I haven't changed
anything in the ordinary edit mode I will just leave. What actually
happens: the editor asks if we should leave without saving changes (as
thought as they were done in the edit mode, not in twve).
I think that's because the tiddler was not saved after the new-line being
added. This behavior is of TiddlyWiki (without AutoSave), not of *twve*.
Not quite. The thing about autosave is what would be on leaving TW, not
the tiddler edit mode. This looks like no store.notify was called (and
hence no store.saveTiddler was called) and because of that no refreshing
was done, though I'm not totally sure.

The *twve* stores *every* accepted change back to the tiddler text, right
at the time being accepted, even in the case of one single character. You
do not see a whole tiddler refreshing because *twve* avoids it and does
partial refreshing for you. I decided to do partial refreshing because it
improves performance significantly. Technically it avoids whole tiddler
refreshing by using the unrecommended way:

tiddler.set(...the changed text and other necessary info....);

store.setDirty(true);


It is the *store.setDirty(true)* that informs the TiddlyWiki that something
has been changed. I do think it makes sense to do so even after a single
character change.

So, if you disable the *autoSave* option, which is commonly desired
probably, then before you manually save it the tiddler remains *dirty* after
any change, and what you described shall happen naturally.

Thanks a lot for sharing the idea of a formatter, something that I still
can't figure out by myself. I will spend time studying it and see what I
can do. This is really helping and highly appreciated. Thanks again for
sharing.

Have fun!

Vincent

Post by Yakov
Recently I've came to an idea how to create a formatter that can create an
editable text and save changes back to wikitext. The main idea is to use
such engine for MathQuill [1] in TWc which I've already implemented to some
extent, but here I'll just show the template for such formatter, may be
you'll find this useful. Now I understand TWc Wikifier relatively well, so
if you have some questions, I'll probably be able to answer. So here's the
/***
|Version|0.9|
A simple formatter is implemented here. This formatter creates DOM that
can be "reflexively edited": editing changes not only DOM, but also
wikitext which it was generated from.
|test formatter|<ff>val 3</ff> (was: {{{<ff>val 2</ff>}}})|
* recalcs slices (changes are applied); refreshing doesn't affect
distructively; several consiquent edits via one formatter work correctly
* ''test'' several edits via several formatters; test with transclusion,
including sections (both should work correctly)
***/
//{{{
var reflexiveFormatterTerm =
{
name: "reflexiveFormatterTest2",
openWrapper: "<ff>",
closeWrapper: "</ff>"
};(function($){ // concatenate to reflexiveFormatterTerm ($ = this)
$.match = $.openWrapper;
$.lookaheadRegExp = new RegExp($.openWrapper + "(.*?)" +
$.closeWrapper, "mg");
$.handler = function(w)
{
$.lookaheadRegExp.lastIndex = w.matchStart;
var wholeThingMatch = this.lookaheadRegExp.exec(w.source);
if(!wholeThingMatch) return;
// wikitext "corresponding to the formatter" with wrapper
var wholeThing = wholeThingMatch[0],
// wikitext "corresponding to the formatter" without wrapper
mainThing = wholeThingMatch[1];
w.nextMatch = this.lookaheadRegExp.lastIndex;
var sourceTiddler = w.tiddler,
startPosition = w.matchStart,
initialLength = w.matchLength
...

[Yakov]

Hi Vincent,

I have found another very interesting stuff: the contenteditable attribute
[1,2]. Although saving changes to wikitext from DOM is still quite tricky,
this stuff can ease implementing WYSIWYG tremendously. In fact, CKEditor
uses this, although their task is simpler since they save the DOM itself
and in TW we have to either convert it back to wikitext or somehow sync
while editing..

Best regards,
Yakov.

[1] http://html5demos.com/contenteditable
[2] http://stackoverflow.com/questions/1391278/contenteditable-change-events

Post by Yakov
Hi Vincent,
Now, the "boring" part.
1. create a one-line tiddler with text alpha __beta__ gamma. Click to
edit the only block. Add a new line (enter) and apply (ctrl+enter). Enter
the ordinary edit mode (click "edit"). Press esc to cancel. What is
expected: the changes are already applied, and since I haven't changed
anything in the ordinary edit mode I will just leave. What actually
happens: the editor asks if we should leave without saving changes (as
thought as they were done in the edit mode, not in twve).
I think that's because the tiddler was not saved after the new-line being
added. This behavior is of TiddlyWiki (without AutoSave), not of *twve*.
Not quite. The thing about autosave is what would be on leaving TW, not
the tiddler edit mode. This looks like no store.notify was called (and
hence no store.saveTiddler was called) and because of that no refreshing
was done, though I'm not totally sure.
The *twve* stores *every* accepted change back to the tiddler text, right
at the time being accepted, even in the case of one single character. You
do not see a whole tiddler refreshing because *twve* avoids it and does
partial refreshing for you. I decided to do partial refreshing because it
improves performance significantly. Technically it avoids whole tiddler
tiddler.set(...the changed text and other necessary info....);
store.setDirty(true);
It is the *store.setDirty(true)* that informs the TiddlyWiki that
something has been changed. I do think it makes sense to do so even after a
single character change.
So, if you disable the *autoSave* option, which is commonly desired
probably, then before you manually save it the tiddler remains *dirty* after
any change, and what you described shall happen naturally.
Thanks a lot for sharing the idea of a formatter, something that I still
can't figure out by myself. I will spend time studying it and see what I
can do. This is really helping and highly appreciated. Thanks again for
sharing.
Have fun!
Vincent
Recently I've came to an idea how to create a formatter that
...