Proposal: make list-before and list-after fields accept multiple titles

[Matthew Lauber]

I'm proposing that the list-before and list-after fields be treated as list fields themselves.  i.e. a bracketed space separated list of tiddler titles.  The tiddler is inserted before or after all of the titles from the list-{before,after} field that are in the list currently being manipulated.  I find I'd like to do this because I have times when one tiddler belongs in two lists.  If I've got a item that belongs in two categories, and I tag it with each tag, I cannot set a list-before value that will work for listing each tag.

[Tobias Beer]

Hi Matthew,

Good point. I'm afraid this would be a non backwards-compatible change, though.

The only way to go about it would be new fields, or perhaps some field-value prefix that has TiddlyWiki retroactively interpret fields as list-fields, e.g:

list-before: as-list => foo [[bar baz]]

Best wishes,

Tobias.

[Matthew Lauber]

Yeah, that was my concern.  I thought it would be worth raising though, considering how much additional utility it could provide.  Is there any system or procedure for making backwards incompatible changes like this?  Or is it just "too late, tough luck" (not that I'll be upset, just trying to understand)

[Tobias Beer]

Hi Matthew,

 

Is there any system or procedure for making backwards incompatible changes like this?  Or is it just "too late, tough luck" (not that I'll be upset, just trying to understand)

From what I understand that's a per case decision making process and depends on our ability to either invent acceptably non-backwards compatible ways (the above proposed syntax) or alternative methods (e.g. new fields).

Best wishes,

Tobias.

[Scott Simmons (Secret-HQ)]

Perhaps the core could treat it as a fallback case?

I.e.:

• if the value of "list-before" matches an item in the list field of some tiddler somewhere, then TW handles "list-before" as it always has
• but if it doesn't, TW makes a second pass, treating the contents of "list-before" as a list and stopping when it finds a value that works for its current context.
  

That said:

To me, this seems like a rarefied enough use case that a workaround may be preferable to a core change.  Perhaps using the "list" field of one of the places the item appears to literally specify its position in that list; this would override the list-before field of the item's tiddler and still allow it to be used for ordering/placement in the other list.