When "New Tiddler" already exists

[Simon Baird]

This is just a little usability suggestion.

 

If you create a new tiddler and a tiddler called 'New Tiddler' already exists then what happens is you open the existing tiddler called New Tiddler for editing. Similar with New Journal, and (if you are rolling your own newTiddler buttons) New Task, New Contact, etc, etc.

 

This is confusing I think because the user expects a new tiddler and doesn't get one. A similar situation exists in other places, eg Microsoft Word you get Document1 Document2 etc, in windows explorer if you say File, New, Text Document, then you don't just open the existing "New Text Document.txt" if it already exists. It's pretty clear to me that TW should follow this convention.

 

There is a small argument in favour of the current new journal behaviour if you are accustomed to reopening today's journal for example but this minor issue should be either ignored or addressed in another way. Perhaps with an 'openJournal' macro?

 

http://trac.tiddlywiki.org/ticket/311
 

I made a ticket about this and also I wrote some code for it, see below:

Index: js/Macros.js
===================================================================
--- js/Macros.js        (revision 2135)
+++ js/Macros.js        (working copy)
@@ -469,6 +469,24 @@
        return btn;
 };

+String.prototype.getNextFreeName = function() {
+       var numberRegExp = / \(([0-9]+)\)$/;
+       var match = numberRegExp.exec(this);
+       if (match) {
+               var num = parseInt(match[1]) + 1;
+               return this.replace(numberRegExp," ("+num+")");
+       }
+       else {
+               return this + " (1)";
+       }
+}
+
+config.macros.newTiddler.getName = function(newName) {
+       while (store.getTiddler(newName))
+               newName = newName.getNextFreeName();
+       return newName;
+}
+
 config.macros.newTiddler.onClickNewTiddler = function()
 {
        var title = this.getAttribute("newTitle");
@@ -476,6 +494,7 @@
                var now = new Date();
                title = now.formatString(title.trim());
        }
+       title = config.macros.newTiddler.getName (title);
        var params = this.getAttribute("params").split("|");
        var focus = this.getAttribute("newFocus");
        var template = this.getAttribute("newTemplate");

 

[Simon Baird]

Here is a demo:

 

http://simonbaird.com/twbeta/empty.html#readOnly:no

 

Click new tiddler, done a few times to see what it does.
 

[Jon]

Hi Simon,

What would happen in this case if you created a new tiddler named
something other than the default 'New Tiddler'? I have a few commands
for creating new tiddlers from user entered names and here is the
scenario I am wondering if would still work in this case:

User creates a new tiddler called say 'test tiddler'. One of my
commands creates a new tiddler and puts a link to it from the tiddler
the command was run from. So, user runs the command, enters name
'test tiddler' in order to create a link to an already existing
tiddler and the current page. In this case would an entirely new
tiddler named 'test tiddler (1)' be created or would the already
existing tiddler be opened as is the case at the moment? I would also
need the current funtionality to continue where say the user does not
realise a tiddler of the chosen name already exists and creates a new
one. I would rather have the already existing tiddler open rather
than new duplicates of that tiddler being created suffixed by (1)
etc. So I guess what I mean is, if this only effects new tiddlers
named the default 'New Tiddler', good plan, otherwise perhaps it needs
a bit of conditional coding built into it to cover these types of
scenarios. But still good plan :)

Cheers

Jon

[Simon Baird]

On 5/5/07, Jon <joh...@moving-picture.com> wrote:

What would happen in this case if you created a new tiddler named
something other than the default 'New Tiddler'?  I have a few commands
for creating new tiddlers from user entered names and here is the
scenario I am wondering if would still work in this case:

User creates a new tiddler called say 'test tiddler'.  One of my
commands creates a new tiddler and puts a link to it from the tiddler
the command was run from.  So, user runs the command, enters name
'test tiddler' in order to create a link to an already existing
tiddler and the current page.  In this case would an entirely new

You are taking advantage of the current "broken" behaviour. So I guess your command would need some small adjustment to continue to work like it works now.

tiddler named 'test tiddler (1)' be created or would the already
existing tiddler be opened as is the case at the moment?  I would also
need the current funtionality to continue where say the user does not
realise a tiddler of the chosen name already exists and creates a new
one.  I would rather have the already existing tiddler open rather
than new duplicates of that tiddler being created suffixed by (1)
etc.  So I guess what I mean is, if this only effects new tiddlers
named the default 'New Tiddler', good plan, otherwise perhaps it needs
a bit of conditional coding built into it to cover these types of
scenarios.  But still good plan  :)

Well it would be trivial to create another param to newTiddler, eg this might work the new way:
<<newTiddler title:'My Thing'>>

and this might work the new way for the case like yours when you actually want that peculiar behaviour:
<<newTiddler title:'My Thing' openExisting:yes>>

[Paco Rivière]

I think your approach is correct Simon. I've seen often users
surprised with the current behaviour in my TW classes.
I think users are used that where ever they paste a file named File
and File(copy) already exist, the new copy is renamed as File(another
copy) or File (2nd copy) or anything similar, depending on the
language.

On May 5, 7:45 am, "Simon Baird" <simon.ba...@gmail.com> wrote:

[Jon]

I guess I just accepted the way newTiddler worked and wrote my command
around that. Personally I find it sensible and it hinders the
duplication of entries in a tiddlywiki that is extensive (I guess
however you still get an indication due to the presence of the (1)
etc). I think perhaps part of the issue for me is that fact that the
tiddlywiki I have built is very specific to its use. Our department
uses it as an error log of the various equipment we support around the
building, and so there are various sections and subsections covering
these areas. As people will be adding to the log entries and on
occasion adding to the sections (I've built a kind of contents page on
the side) as we get new equipment etc dupication of the pages logging
entries for each area would be detramental. When we need to reference
a fault when something goes down, we want to be able to get to the
relevant section quickly and review previous problems and solutions.
However, with a less very specific use of the tiddlywiki, I can see
that others find this behaviour odd and I certainly would not have a
problem with it changing should it be deemed appropriate, as you say I
can always edit my command in order to continue my madcap command
scheme.

Jon

[Jeremy Ruston]

I also think that the current behaviour is counter-intuitive, but
agree that we have to maintain equivalent functionality for backwards
compatibility.

I've been thinking about a slightly different approach that gives a
bit more flexibility: adding a new parameter to <<newTiddler>> called
something "titleExists" like this:

<<newTiddler title:"Notes" titleExists:"Notes (%c)">>

The idea would be that if the titleExists parameter were specified it
would be used to generate a unique name if the specified title already
exists (by replacing %c with 0,1,2,3... etc. until an unused title is
found). Also, if 'title' were omitted then 'titleExists' would also be
used to generate the initial title.

What do you reckon? In any event, I propose to defer this until after
2.2. In the meantime, I've updated the ticket with a pointer to this
discussion.

Cheers

Jeremy.

--
Jeremy Ruston
mailto:jer...@osmosoft.com
http://www.tiddlywiki.com

[Jon]

Hi Jeremy,

Sounds sensible to me, so just defining title would effectively result
in the current behaviour whilst title and titleExists would result in
the behaviour being requested here. With just titleExists, the
initial tiddler name generated would have the superceeding (%c) from
the outset, have I got that right?

Cheers

Jon

On May 9, 3:42 pm, "Jeremy Ruston" <jeremy.rus...@gmail.com> wrote:
> I also think that the current behaviour is counter-intuitive, but
> agree that we have to maintain equivalent functionality for backwards
> compatibility.
>
> I've been thinking about a slightly different approach that gives a
> bit more flexibility: adding a new parameter to <<newTiddler>> called
> something "titleExists" like this:
>
> <<newTiddler title:"Notes" titleExists:"Notes (%c)">>
>
> The idea would be that if the titleExists parameter were specified it
> would be used to generate a unique name if the specified title already
> exists (by replacing %c with 0,1,2,3... etc. until an unused title is
> found). Also, if 'title' were omitted then 'titleExists' would also be
> used to generate the initial title.
>
> What do you reckon? In any event, I propose to defer this until after
> 2.2. In the meantime, I've updated the ticket with a pointer to this
> discussion.
>
> Cheers
>
> Jeremy.
>

[Jeremy Ruston]

> Sounds sensible to me, so just defining title would effectively result
> in the current behaviour whilst title and titleExists would result in
> the behaviour being requested here. With just titleExists, the
> initial tiddler name generated would have the superceeding (%c) from
> the outset, have I got that right?

That's correct. The design supports the following scenarios:

<<newTiddler title:"Notes">> - generates a single tiddler called "Notes"
<<newTiddler titleExists:"Notes %c">> generates a sequence of tiddler
titles "Notes 1", "Notes 2", "Notes 3" etc...
<<newTiddler title:"Notes" titleExists:"Notes %c">> generates a
sequence of tiddler titles starting with "Notes", and then "Notes 1",
"Notes 2", "Notes 3" etc...

Cheers

Jeremy

[Simon Baird]

I think this is the wrong approach. The only time this matters is if you accidentally create a new tiddler called "New Tiddler" and forget to give it a proper name. No one will be actually using this to create a string of New Tiddlers 1 to 10.

I suggest that titleExists should have a default value of the one you've suggested. So it's on by default. Those who need to preserve the old behaviour can set titleExists=ignore (special meaning for ignore). And arguably titleExists could be defaulted to ignore for newJournal.

Simon.

> > mailto:jer...@osmosoft .comhttp://www.tiddlywiki.com

[Jeremy Ruston]

OK, I think you were right the first time; my suggestion is more
elaborate than needed. A backwards compatibility switch on your
original patch is a reasonable way to go.

Cheers

Jeremy.

[Simon Baird]

Having it configurable via lingo string is a good idea. Eg, maybe this can work perhaps?

config.macros.newTiddler.titleExists = "%0 (%1)";

though (at least in my version of the code) there is the regexp that must correspond to it

config.macros.newTiddler.titleExistsRegExp = / \(([0-9]+)\)$/;

so perhaps that extra complexity to making in config'able means it's not worth the effort.

Instead we could just say it's configurable via a plugin which I guess would appear on TiddlyTools shortly after someone asks for it here. :)