No rush.
I already have extraction based on @Mark_S’s code (even if he doesn’t recall writing it 
)
It’s an edge case only when you haven’t considered it 
For extraction and now (for your code) editing, you’ll need a qualifier of some description. Every time I’ve approached this, I’ve backed off. I shamefully didn’t keep notes but it basically boils down to a tension between wanting the common case of rendering/reusing the segments elsewhere and the need to target a specific instance when needed (highlighted by your new case of editing a unique segment). Either way, I think we need @Mark_S to take a look.
Let me try to summarize what I think might be needed (or, at least, useful)…
<mo-section data-id="unique-id">
content
</mo-section>
Or perhaps…
<mo-section><unique-id>
content
</unique-id></mo-section>
The problem domain as I see it is
- generic extraction of each mo-section (e.g. $list).
- extract each unique mo-section and retain the
unique-idso I can work with both it and the content. - And ditto the above for in-place editing purposes.
It’s point 2 that eludes me. I’m not aware of a way to capture back references (regex \1, \2, etc.) and make them usable in wikitext along with the match (afforded by Mark’s regexps js plugin, for example).
But I do wonder if something close is there or almost there already. @Mark_S – can you expand on this taken from your comments at the top of regexps.js
[...] All sub-groups are returned if not global and sub-group hits are found.
The problem is with Tiddlywiki search-replace! I am working to resolve it!
Note the splitregexp works fine!
@pmario - this issue is with search-replace. Consider
<$list filter="[[The quick brown fox jumps over the lazy fox]search-replace[fox],[cat]]"/>
produces
The quick brown cat jumps over the lazy fox
and if you useg' flag then it produces
The quick brown cat jumps over the lazy cat
We need to know which instance shall be replaced! I think @stobot should encounter this in his Sticky Todo (Sticky - A lightweight todo / sticky-note concept)
@Mohammad actually in my case I essentially turned that “bug” into a feature.
As you’re seeing, for a regex based solution I used the text as the ID, the ID of the todo in my case, the name of the section in yours. For me since mine are things like “talk to Bob”, it’s likely that any repetition would all get handled at the same time, and so marking them all done at the same time makes sense. In the case of sections that’s less likely to be the case.
I have been thinking through @saqimtiaz 's challenge programmatically around a single tiddler streams, and there the logical solution around a wikitext version has the same issue as what you’re trying to solve here, in fact in a way they’re almost the same thing entirely, hence why I’m bringing it up here. The best place to get a unique ID generated when you can’t rely on the text seems to be the new counter variable of the 5.2 list widget. So, from a workshop perspective, I think it would look like (as @saqimtiaz suggested):
- Break the tiddler into temp tiddlers, one per section or stream item, title with the counter variable.
- Do the editing
- In the Streams mode, you’d add all the ui around adding, removing and reordering using a list field and listops
- When done editing, reassemble based on the list.
2 Likes
Some quick thoughts:
- refresh performance can get really slow with the counter variable in the list widget, so that may be problematic for larger tiddlers with a lot of sections
- Largely agree with @stobot. If you split it into smaller chunks when editing, and save each in a temp tiddler or field with a unique ID, all you need to remember is the ID of the section being saved and the order in which to save the sections (a list field somewhere). So when saving, you reassemble in that order.
- a simpler though less flexible way to do this is to only allow editing one section at a time and when editing, split and save the content in 3 parts. The preamble, the part being edited, the suffix.
- (If you wanted to you could implement an editing experience very similar to Streams with keyboard shortcuts etc to move between sections, or customize Streams to work as a section editor.)
2 Likes
@saqimtiaz - I don’t want to get too off-topic, but curious about your mention of performance with the counter variable. The alternative that wouldn’t be that would be to generate a unique number off of the <<now>> microseconds or something. Would you say that counter would even be slower than that? Speed is usually near the top of my priority list, so I’m curious if you can say a bit more on that from your experience.
Your idea was so beautifully simple Mohammad, that I hate to see it made complicated just for an edge case!
My thought is this. You already make content tiddlers for editing, right? At the time that you make your first content tiddler, you also make a copy of the entire source tiddler, but with the section replaced by a token.
!! asdf
/%TOKEN202110021054%
Calling this the working source.
Each subsequent section that gets edited will use the working source, and replace it’s own token. The token of course is stored in your content tiddler.
When a section is saved, replace the token with the edited text in the working source.
When the last section being edited is saved, the working source replaces the original source.
The downside of this approach is that the final tiddler isn’t written until ALL edit sessions are complete. The upside is that you don’t have to recreate streams !
And, yes it really is an edge case. You would expect in real life every section will have unique content.
@stobot counter variable performance hit is huge when the number of items in the list changes, like adding and removing sections.
Agree with @Mark_S that Streams is overkill for this. Assuming you want a similar keyboard driven UX, would recommend only using it for inspiration. Most of the complexity in Streams comes from nested hierarchies, which you don’t have as far as I can tell. Or it could be useful as a quick hack to demo/test what that kind of UX applied to your idea might be like.
Edit: here is an extreme example where all the list widgets in a wiki use the counter variable, try switching sidebar tabs.
Thank you all for the great inputs! What I think is:
- Section Editor in current form is quite simple and easy to maintain!
- It is rarely to have such a case in real life
- We can use the same solution as @stobot used in his Sticky todo (use ‘g’ option)!
So, even to use a more sophisticated solution we can keep this version of Section Editor as is!
1 Like
I agree @Mohammad - for this purpose, best not to overcomplicate it as sections probably should have unique names within a single tiddler.
To make it a little bit safer while keeping speed up and complexity lower, rather than the whole complicated workflow I was talking about to handle non-unique section titles, an alternative/additional thing you might consider is to at least prevent the inadvertent section override that @pmario talked about. For example, you could wrap the edit button behind a test to see if that section title was unique within the tiddler. That way, if someone accidentally re-used a section header, they wouldn’t be able to use the edit for that section until they fixed it.
Not saying you need this, depends on your typical use-case, but just a thought to consider.
I know, that it is an edge case and in a real document one would expect the sections to be different. I just wanted to let you know. … We will see
@saqimtiaz - I am a little worry about the counter in $list which is used in current version of Section Editor!
What do you think to use an index like position in the list as below?
<$set name=mylist filter="one two three four">
<$list filter="[enlist<mylist>]" variable=item>
pos: <$text text={{{ [enlist<mylist>allbefore:include<item>count[]] }}}/><br>
</$list>
</$set>
produces:
pos: 1
pos: 2
pos: 3
pos: 4
Dont you think we have better performance compared to <$list counter=pos ...>?
@Mark_S I think we can append an id to each section just by prefixing each section with an id like
id°_° + section content! This is some arbitrary prefix! the id is produced from $list counter=id ...
So, when we edit some section and want to search and replace we can determine which instance should be replaced!
Still I am thinking to ignore such edge case and keep code as simple as possible!
1 Like
I don’t think you will have a problem unless you add affordances to quickly add/delete sections and have very long tiddlers. As long as the number of list items stays constant, there is no performance issue with the counter variable.
1 Like
I like stobot’s idea of blocking editing non-unique sections. That makes it up to the user to create unique content. Not sure what happens if the editing itself creates the non-unique section.
I get why people don’t get these sections can be repeated, but that’s because no one in their right mind is likely to repeat headings – of course that would be crazy… and a pretty dumb document. Unwittingly, there’s an implied mental mapping of H1 --> Section, which, semantically, is a stretch.
But my use-case doesn’t want/need headings. They are both semantically and actually sections – hence my asking @Mohammad to think of the solution in those terms.
<about-thing>
Stuff specifically about thing.
</about-thing>
Stuff somewhat related to thing but not specifically about thing.
<about-thing>
More stuff specifically about thing.
</about-thing>
All of this works fabulously (with code derived from @Mark_S’s extraction-code). What I can’t do is edit them in place. I have to edit the entire document (host tiddler).
It’s okay if section-editor isn’t the solution. I’ve lived with it like it is for half a decade at least.
Some side effects
As while as we use section editor for content tiddlers it works like a charm! But if you have a complex tiddler (one have macro content) then you will get interesting results
For example try this!
\define xx() Hello Denver! Where is Berlin?
! One
<<xx>>
!! Two
<<.lorem>>
1 Like
The local macro doesn’t display because you’re handling the display. You would have to import the macro. Or, just set a global macro tag.
On mine, you can’t see \define nor the button for that part of the tiddler . I think this is because your CSS or formatting is hiding the button. You can make it appear, I think by changing this line on process-sections:
<br/><<toggle-button>>
Part of the reason that you can’t see the button is that \define is “eaten” by TW’s rendering. That moves things out of place. Beyond that … I’m sure there’s a good format tweak.
1 Like