Odd results when editing custom fields in TiddlyTools tiddlers

[cmari]

This is really for Eric, and perhaps he'll say it's a feature not a
bug(!), but it's a feature that mystifies me. Try this with, for
example, the HelloWorld tiddler in TiddlyTools:
1. Click "edit" to edit the tiddler.
2. Type some text.
3. Click "fields" on the toolbar.
4. Add a field and its value.
5. Click "ok".
The tiddler switches out of edit mode. The changes made to the
tiddler contents are not saved. The tiddler can't be reopened for
editing, but has to be closed with "abandon changes".

(One further oddity: before I figured out that this problem wasn't
just something I created somehow through a mash-up in my own TW, I got
around it by putting the "edit fields" button on my view toolbar
instead of the edit toolbar (which is a useful place to have it
anyway). But then I found I also needed to add a "refresh" button.
In the best of all possible worlds, of course, I'd like to have the
ability to edit fields in both view and edit modes, with no refreshing
or reopening required....).
Regardless of any of this, custom fields are still really useful!
cmari

[cmari]

One further mystery I just noticed: the <<toolbar fields>> macro
inside a tiddler causes a loop.

[cmari]

I'm sorry for multiple messages; I hit the send button too quickly on
the previous one. To clarify,, the <<toolbar fields>> macro only
causes a loop if it includes a tiddler name. (I have been using it
this way so that I can see tiddler1's fields when using the <<tiddler
tiddler1>> macro inside tiddler2).
cmari

[cmari]

CoreTweaks 609 and 610 affect the toolbar fields macro (but not the
editing behavior). Again, apologies for my inefficiency and I promise
I'll shut up now!
cmari

[Eric Shulman]

> 1. Click "edit" to edit the tiddler.
> 2. Type some text.
> 3. Click "fields" on the toolbar.
> 4. Add a field and its value.
> 5. Click "ok".
> The tiddler switches out of edit mode.  The changes made to the
> tiddler contents are not saved.  The tiddler can't be reopened for
> editing, but has to be closed with "abandon changes".

The FieldsEditorPlugin that provides the 'add a field' ability in the
fields popup display is apparently intended only for use in a *view*
mode toolbar (which is where the standard 'fields' menu item appears
on TiddlyWiki.com). The problem is that, when you press OK from
entering the new field's value, the plugin is always assumes that the
tiddler should be redisplayed using the view template, rather than the
*current* template (which, in this case is the *edit* template). This
leaves the tiddler in an improper state that can only be cleared by
closing and reopening the tiddler (as you noted).

Please note: FieldsEditorPlugin is not a TiddlyTools add-on.
It was written by Collin Pascal and is distributed here:
http://visualtw.ouvaton.org/VisualTW.html
Unfortunately, because this is someone else's code, it is not clear to
me if this particular problem (i.e., use within edit mode) can be
fixed. I'll look into it, but I can't promise anything...

-e

[Eric Shulman]

> the <<toolbar fields>> macro only
> causes a loop if it includes a tiddler name.  (I have been using it
> this way so that I can see tiddler1's fields when using the <<tiddler
> tiddler1>> macro inside tiddler2).

huh?

please explain... are you trying to include a tiddlername as a
parameter for the fields argument? That's not how <<toolbar>>
works... each param in the <<toolbar>> macro is a keyword that
corresponds to a specific toolbar command (or ">" to insert the "more"
command).

TiddlyTools' CoreTweaks #609 and #610 add the ability to insert
arbitrary tiddler content into the toolbar by using a TiddlerName as a
parameter to the <<toolbar>> macro. This allows you to add 'commands'
to the toolbar that are actually just simple links to other tiddlers.

For example, suppose you have a tiddler called [[GetHelp]]. With
tweaks #609/610 installed, you can add a 'help' command to the toolbar
that simply opens the [[GetHelp]] tiddler. First, create a tiddler
called [[GetHelpCommand]] containing just: "[[help|GetHelp]]". Then,
in [[ToolbarCommands]], add "GetHelpCommand" to the list of commands
for one of the toolbars. The result: a 'help' command appears in that
toolbar and, when that command is clicked, it simply opens the
[[GetHelp]] tiddler.

HTH,
-e

[cmari]

> please explain... are you trying to include a tiddlername as a
> parameter for the fields argument?

I was looking for a way to manage the tracking of recurring tasks from
a single tiddler. I took advantage of the fact that the fields of one
tiddler can be edited in another one if the <<toolbar fields>> macro
in the first tiddler actually specifies that first tiddler's name.
You can see what I was doing if you look at the tiddler called
"dailyreminder" at http://cmari.tiddlyspot.com/
Actually, I think what I was trying to do in that case has been
superceded/superseded by ticklers in MonkeyGTD anyway, so it's all now
more of a souvenir of my learning process than anything else. But I
still think that it's useful to be able to edit many other tiddlers'
fields without having to specify their titles (the ListboxPlugin is
very cool, but I couldn't figure out how to use it for editing the
fields of multiple, possibly changing, tiddlers from inside one single
tiddler).
cmari

[Eric Shulman]

On Aug 13, 1:16 pm, cmari <cema...@gmail.com> wrote:
> > please explain... are you trying to include a tiddlername as a
> > parameter for the fields argument?
>

> a single tiddler.  I took advantage of the fact that the fields of one
> tiddler can be edited in another one if the <<toolbar fields>> macro
> in the first tiddler actually specifies that first tiddler's name.
> You can see what I was doing if you look at the tiddler called
> "dailyreminder" athttp://cmari.tiddlyspot.com/

I find this in your document:
<<toolbar fields [[BusTickets]]>>

It seems that you are thinking that the [[BusTickets]] param is
somehow getting passed to the preceding 'fields' param to specify a
'target tiddler' for the fields command.

However, that's not how the <<toolbar>> macro works: rather, each and
every parameter in the <<toolbar >> macro is supposed to specify the
name of a *separate* toolbar command handler, and there is no ability
to pass additional parameterized values to the individual commands
*within* the toolbar.

Try this in your document:
1) create a new tiddler containing: <<toolbar fields [[BusTickets]]>>
2) open the tiddler [[BusTickets]]
3) click on 'fields' in [[NewTiddler]] and note field names/values
4) click on 'fields' in [[BusTickets]] and note *different* field
names/values

This shows that the 'fields' command in [[NewTiddler]] is *not*
referencing the fields defined for [[BusTickets]] as you had thought.
In fact, the [[BusTickets]] reference in your document's <<toolbar>>
macro is actually being completely *ignored* because 'BusTickets' is
does not have a defined command handler.

However... with TiddlyTools' CoreTweaks #609/#610 installed, rather
than being ignored, the reference actually tries to render the entire
[[BusTickets]] tiddler inline within the toolbar... and it wouldn't
surprise me if that produced some very odd results indeed!

-e

[cmari]

> It seems that you are thinking that the [[BusTickets]] param is
> somehow getting passed to the preceding 'fields' param to specify a
> 'target tiddler' for the fields command.

I don't deny that it didn't seem like an "intentional" feature! But
if I understand things right, it's working because of transclusion -
I'm making the change directly to the transcluded tiddler, not the
viewer tiddler. (That's probably not really right, but it's why I
wanted you to see it, because I couldn't explain it).

Try this: make a change to "Last done:" on the BusTickets line in the
dailyreminder tiddler (and hit enter). The result is, in fact, a
change to that field in the BusTickets tiddler. (Look at the fields
for dailyreminder to see that they are not affected).

cmari

[cmari]

or just click the different "fields" buttons in the dailyreminder
tiddler to see that they're showing different fields.