Section Editor - Prototype

#4

@DaveGifford
Hi David,

NO, it is not! I can say it is not even similar to subsume!

It is a section editor! This concept comes from dokuwiki and wikimedia!

It will work later using a simple field value or tag!

Including other tiddlers in a tiddler with an edit/link/button is a common knowledge in Tiddlywiki and you can find it in many user wikis out there!

TW-Scripts has bunch of folding editors, inline editors and tools to include other tiddlers in a master tiddler! BUT none of them can do section editing!

So this is not re-doing subsume! I think you post your opinion before you test the code I shared!

2 Likes
#5

Nice job @Mohammad! I agree that for some of us (like me), the distinction between a single-tiddler storage mechanism vs. a multi-tiddler storage mechanism is a key decision point. Similar philosophy to why I made my “Sticky Todo” thing the way I did (similar pattern, some regex + search-replace). There are some benefits in terms of performance, searchability of topics etc. that are worth it to sometimes use a single-tiddler approach like this. I’ll bookmark this one for later to remember the pattern you used.

Looking forward to seeing it at a later, more polished state - but looks good so far!

1 Like
#6

Thank you @stobot. Your Sticky Todo is actually a great addition! It shows how one can work on the same tiddler and do actions in place! So, I absolutely acknowledge your contribution!

In Commander, we have a search and replace (we is not royal we, here we = BTC, Mark_S, TiddlyTweeter and kookma) . It called SNR and has been published separately! It is very powerful, allows you to search and replace anywhere you think even in title!

1 Like
#7

My apologies, Mohammad, I did not write to offend you or belittle this accomplishment. I was just pointing out the similarities for the end user.

In reading Stobot’s comment and your response, I now understand that this involves sections within the tiddler itself rather than grabbing from other tiddlers. That is a big step forward. Kudos to you, and I look forward to seeing how this develops.

1 Like
#8

Hi David,
You are highly welcome and no need for apology! I have always acknowledged your contributions, ideas and tools! and we (I and other users) benefit from them! Thank you!

#9

I think you should use custom elements

<mo-section>
stuff
</mo-section>

I appreciate you want to use Hn tags (and they’re ready to go in the toolbar) but setting aside your very own elements seems better somehow (gives you a bit more control over their meaning, too).

I’m sure you could add them to the toolbar if you wanted to.

Other than that, great piece of work @Mohammad !

Accessing ts-raw without the slot widget?
#10

@Mohammad good work so far and an important objective. I would still recommend looking into existing solutions for code tricks if you find any barriers.

I support @CodaCoder suggestion of custom tags but simultaneously support your desire to base it on headings because they do represent the HTML “semantic” section.

  • If I may suggest that you try and keep the actual “wiki-markup and or html tags” sections - a configurable element. I can’t voice all the reasons easily but I think this will help in the long run.

Personally I am keen to make a generic solution for extracting multiple and nested content between markup or html tags, which would resemble a core mechanism of the solution you are building. I will see if I can do it in coming days. We can see if it can inform your project.

I understand your in prototype mode but can I suggest one nice approach is rather than place buttons along side content actually display the content from inside a button, then clicking the content triggers edit on the content section. The button widget permits tag=div and with class="tc-btn-invisible" can look like the original wikitext. I think once you move beyond prototype it may be sufficient just to have a tooltip appear to indicate an editable section. Yes once editing have a tick button.

Another suggestion is since clicking to edit a section is a trigger it is important to allow other actions to be triggered. In particular for this solution you could store the section content elsewhere for restore, history and backup.

Good work, I will continue to monitor this work.

#11

Actually there is an HTML section Tag

Good idea.

1 Like
#12

This looks exciting! Have you seen jd’s paragraphs macro? The ui is similar. The state tiddlers containing the section being edited gets deleted upon save.

I tried adding headings while editing a section. It works as expected, that when you save the section, it creates new sections under it. I’ll play around with it more later. Thanks!

1 Like
#13

Paragraph works on other tiddlers! It is kind of inline editor. There are similar tools out there (see TW-Scripts)! the big difference here, you work on the same tiddler.

#14

@TW_Tones - thank you for comments and ideas!

Using html tags like <section>....</section> has been already introduced!
Please see the find-macro from kookma and summary from Tobias Beer!

Example:

<<show-macro "$:/core/macros/toc">>
  • see how find macro split the $:/core/macros/toc into individual sections delimited by \define, \end. It has been used as a tool to explore complex codes created from several macros!

So, using delimiters like start/stop has been already developed!

The core of current solution is to work on pure wiki text without introducing extra tags, … It works on a semantic section. It is an article/essay/homework/… contains natural sections separated by headings!

I think the streams from @saqimtiaz can do this job in the best way! maybe a subplugin can be developed! Streams has beautiful semantic UI, supports shortcut keys, double clicks for edit and many more… I think stream also faster than wikitext script here!

#15

I prefer wikitext headings over <section></section> tags too. It would be more practical for non-coder users, especially those with no html knowledge. Exclamation marks are easier to type too.

The only problem I encountered with your prototype is that when the text starts with 2 linebreaks, it gets treated as a new section and an edit button appears. I think this has something to do with the regexp or the splitting? It’s an unconventional situation though, no one would actually do this, unless by accident.

Text:



! Heading 1
text

Output:

image

This becomes a problem when you erase the contents of the preface section. Erasing the contents of a section leaves two linebreaks behind in the source tiddler. So when you erase the preface section, the two linebreaks are counted as a section.

Maybe there could be an section deleting mechanism in the future?

I, personally, would not need an add section feature. I enjoy the current way of making new sections, which is to add heading markup and some text at the end or at the top. This behavior is a good feature for me.

#16

Thank you @sull-vitsy! I can confirm the bug!
For adding new section, I like your idea, so we keep it as is for simplicity!

#17

@sull-vitsy - this is a simpler solution address the bug (an extra empty line)

\define stateTid() $(stid)$/state/$(cnt)$ 
\define editTid()  $(stid)$/content/$(cnt)$
\define source() Test


\define onactions()
<$action-setfield $tiddler=<<editTid>> $field=text $value=<<currentTiddler>> />
\end
\define offactions()
<$vars for=<<currentTiddler>> with={{{[<editTid>get[text]]}}}>
<$action-setfield $tiddler=<<source>> $field=text $value={{{[<source>get[text]search-replace<for>,<with>]}}} />
</$vars>
search-replace

\end

\define toggle-button()
<$reveal type="nomatch" state=<<stateTid>> text="edit">
<$button set=<<stateTid>>  setTo="edit" actions=<<onactions>> class="float-right">{{$:/core/images/edit-button}}</$button>
</$reveal>
<$reveal type="match" state=<<stateTid>>  text="edit">
<$button set=<<stateTid>>  setTo="show" actions=<<offactions>> class="float-right">{{$:/core/images/done-button}}</$button>
</$reveal>
\end


\define feditor()
<<toggle-button>>
<$reveal state=<<stateTid>> type="nomatch" text="edit">
<$transclude field=title mode="block"/>
</$reveal>
<$reveal state=<<stateTid>> type="match"   text="edit">
<$edit-text tiddler=<<editTid>> field="text" tag=textarea class="w-100"/>
</$reveal>

\end

<style>
.w-100{width:100%}
.float-right{float:right; color:red}
</style>

--- Start

<$vars pattern="\n\!" nonWhitespace="[^\s]"
  src={{{[<source>get[text]]}}}  stid=<<currentTiddler>>>
<$list filter="[<src>splitregexp<pattern>!is[blank]first[]] :filter[get[title]regexp<nonWhitespace>] 
               [<src>splitregexp<pattern>!is[blank]butfirst[]addprefix[!]]" counter=cnt   >
<<feditor>>
</$list>
</$vars>
#18

That removed the bug of picking up the first two linebreaks as a section!

But it doesn’t show a preface anymore, either. :open_mouth:

Text:

Preface of text. Test. Test. Preface text.

! Level one (!)
This is the first part

* Hirad
* Pouri
* Jeremy

!! Level two (!!)
This is the second part

!!! Level three (!!!)
Hello Mohammad. This is third part

Crude test

This some text in the last part

Output:

image

#19

Your prototype makes me think a bit of this demo Streams — single tiddler

One could imagine a customized version of Streams that worked with headings rather than lists. What concerns me with these kinds of approaches is that it requires proper formatting in the text of the tiddler, which can’t be assured and without which the parsing/splitting fails. This may however be a lot easier with headings than with lists.

Similarly it would be completely possible to customize Streams to generate the same end viewing experience as Dave’s Subsume, but with a more fluid writing experience. It just needs for someone to get their hands dirty.

Streams is actually almost entirely wikitext. The only JavaScript sprinklings are in a custom widget for more flexible keyboard shortcuts, or for swiping.

1 Like
#20

Thank Saq!

If it is pure wikitext, then I will give a try!

#21

@sull-vitsy

:filter[get[title]regexp<nonWhitespace>]

change to

:filter[regexp<nonWhitespace>]

and let me know if it works!

1 Like
#23

It works well. Awesome!

#24

Mohammad, thanks for that reference. In fact it is the find macro that is the revelation.

Its taking a little time to digest how it works because its very compact and there are number of nice design tricks there in,

  • Calling itself (Expected for multiple hits)
  • Calling an output macro, in effect providing a named template - very nice.

There remains the issue of if a marker is loaded with additional content, which does not occur in the \define / \end but if we used the aformentions section;

<section>
content
</section>

Would work but not;

<section class="namedclass">
content
</section>

Or

\define macro() single line
\define multiline macro
one extra line
\end

would mess up?

But its almost there! Ta