Twee's "-a author" option

mth

Would anyone be disappointed if I removed the "-a" option from Twee? It allows the author field for the tiddlers to be specified. This is unrelated to StoryAuthor.

As far as I know this information is not used anywhere. It might have had uses in the past, when Twee was used to generate RSS feeds, see this post from Chris Klimas.

TheMadExile

I've actually been meaning to bring something like that up (thought of it the last time I worked on TweeGo).  I'd suggest removing not only that, but all the backing code.  Since absolutely nothing uses the modifier attribute, there's no reason to keep adding it to the compiled HTML.  And, while we're at it, there's no real reason to have two datetime fields either, that's another RSS holdover, so created could also be dropped (modified would be kept).

mth

TheMadExile wrote:

I've actually been meaning to bring something like that up (thought of it the last time I worked on TweeGo).  I'd suggest removing not only that, but all the backing code.  Since absolutely nothing uses the modifier attribute, there's no reason to keep adding it to the compiled HTML.  And, while we're at it, there's no real reason to have two datetime fields either, that's another RSS holdover, so created could also be dropped (modified would be kept).

I agree with removing modifier and created. But why not remove modified as well? Is it used anywhere?

In my opinion, metadata about changes belongs in a version control system, not in the content itself.

TheMadExile

mth wrote:

I agree with removing modifier and created. But why not remove modified as well? Is it used anywhere?

It's used during tiddler generation to determine which of two tiddlers with the same title is kept (tiddlywiki.py:314 in <TiddlyWiki>.addTiddler()).  It's only interesting when decompiling HTML (since Twine and Twee source don't contain datetime stamps, of course) and merging it with Twine/Twee source within the same run.

I certainly wouldn't be opposed to ditching it in favor of something simpler like last-in-wins (that would, at least, be consistent with pure Twine/Twee source compiles).

mth

TheMadExile wrote:

It's used during tiddler generation to determine which of two tiddlers with the same title is kept (tiddlywiki.py:314 in <TiddlyWiki>.addTiddler()).  It's only interesting when decompiling HTML (since Twine and Twee source don't contain datetime stamps, of course) and merging it with Twine/Twee source within the same run.

I certainly wouldn't be opposed to ditching it in favor of something simpler like last-in-wins (that would, at least, be consistent with pure Twine/Twee source compiles).

I agree: last-in-wins is both simpler in implementation and more clear to the user.

By the way, I found these interesting pieces of code in tiddlywiki.py:

The code that checks whether a duplicate tiddler should be replaced:


def addTiddler(self, tiddler):
"""Adds a Tiddler object to this TiddlyWiki."""

if tiddler.title in self.tiddlers:
if (tiddler == self.tiddlers[tiddler.title]) and \
(tiddler.modified > self.tiddlers[tiddler.title].modified):
self.tiddlers[tiddler.title] = tiddler
else:
self.tiddlers[tiddler.title] = tiddler

return tiddler


This seems weird: why replace an older tiddler only if it is identical to the new tiddler? It would be more intuitive to replace non-identical tiddlers...

...but then there is this:


def __cmp__(self, other):
"""Compares a Tiddler to another."""
return hasattr(other, 'text') and self.text == other.text


This returns True on equal and False on unequal. However, __cmp__ is not an equality check: it's used for ordering, similar to C's quicksort argument function, and it should return -1 on smaller, 0 on equal and 1 on greater. Since False is equal to 0 and True is equal to 1, this means that two tiddlers are considered equal if their texts differ. So in the end addTiddler behaves as expected because __cmp__ has a bug.

In any case, this only motivates me more to rip it all out 

TheMadExile

mth wrote:

By the way, I found these interesting pieces of code in tiddlywiki.py:

Yes, that code is/was a bit odd.  I simplified the same check in TweeGo to only compare the modified properties for identically named tiddlers.

mth wrote:

In any case, this only motivates me more to rip it all out 

Works for me.

mth

I removed the author option and the 'created', 'modified' and 'modifer' attributes in this pull request.

TheMadExile

FYI: There appears to be a merge conflict with your PR.

Tangentially, in TweeGo, I've also gone ahead and made the tags attribute optional in compiled HTML (i.e. if there are no tags, nothing is emitted, rather than emitting an empty tags attribute).  Seems like a good change.

mth

TheMadExile wrote:

FYI: There appears to be a merge conflict with your PR.

Thanks for telling me; it seems GitHub doesn't send out notifications about that automatically. I was already wondering why that PR wasn't merged yet while more recent ones were...

Updated pull request.

TheMadExile wrote:

Tangentially, in TweeGo, I've also gone ahead and made the tags attribute optional in compiled HTML (i.e. if there are no tags, nothing is emitted, rather than emitting an empty tags attribute).  Seems like a good change.

How likely is this to break JavaScript code, in either the story formats or in user code? I'm not very good with JavaScript, but in most languages an absent property is very different from an empty string.

TheMadExile

mth wrote:

TheMadExile wrote:

Tangentially, in TweeGo, I've also gone ahead and made the tags attribute optional in compiled HTML (i.e. if there are no tags, nothing is emitted, rather than emitting an empty tags attribute).  Seems like a good change.

How likely is this to break JavaScript code, in either the story formats or in user code? I'm not very good with JavaScript, but in most languages an absent property is very different from an empty string.

All story formats can handle it.  When processed by the Passage constructor, a non-existent tags attribute results in an empty array being assigned to the instance's tags property (which is the same result as if it had existed, but been empty).

User code should be accessing tiddler attributes via the instances of the Passage prototype (held by the Tale prototype instance), either directly via <Passage>.tags or through the tags() utility function (which simply accesses <Passage>.tags).

TL;DR: Shouldn't be an issue.

mth

Thanks for the explanation. I created a pull request for it.

greyelf

mth wrote:

it seems GitHub doesn't send out notifications about that automatically

It can/does display a message containing text about "merge conflicts", or lack there of, when you create your pull request using GitHub.

mth

greyelf wrote:

It can/does display a message containing text about "merge conflicts", or lack there of, when you create your pull request using GitHub.

What happened is that I made 3 pull requests based on the then-current master branch and none of those had conflicts when they were created. However, they did conflict with each other, so after Leon merged the first pull request, the second had a merge conflict with the new state of the master branch. But by that time, I was no longer looking at the web interface.