Questions about creating a custom inline wikitext to indent text?

If I wanted to say, piggyback off of the $:/core/modules/parsers/wikiparser/rules/list.js tiddler to create a custom parsing for indented text where adding (Char9), ,(&tab;) in the editor, as if you were adding a * to the start of a new line for a bulleted list item, to add the below text, would it be possible for the ul to have a custom class or style applied?

Also I can see in the JS that it consumes whitespace before returning the root element and so, I’m unsure if its possible to use the &tab; character since it is classified as a whitespace character…

I’d really prefer using the tab character since that is whats most visually appealing when editing a tiddler, having to type something like <&tab/> or something isn’t appealing at all.

-EditTemplate-

This is text.

	This is indented text.
-ViewTemplate-

<p>This is text.</p>
<ul class="tw-indent"> /* .tw-indent having list-style-type: none;*/
	<li>This is indented text.</li>
</ul>

The reason for this is because I often indent my text and my code, and would enjoy seeing this directly show in the ViewTemplate for normal text, outside of needing to use preformatted text / code blocks.

The end result I have in mind is behavior like Obsidian.md, where indented text can be arbitrarily nested and even have border-left applied to it.

TL:DR Is it possible to use a whitespace character in making a custom parser similar to the list-bullet wikitext, if so is it possible to have it generate a ul HTML element with a css class including the li element?

Thank you in advance for any input ^^

No JS code needed. The STYLE tag is only there for testing. It needs to be in a proper stylesheet tiddler for production.

The indented test semantically creates an UL HTML element. So do not use it for indented paragraphs.

<style>
.i {
  list-style-type: none;
}
</style>

This is some text

*.i This is indented text


1 Like

Yep! that does have the right outcome in the viewtemplate, but I would need to type out *.i text inplace of (&tab; here, talk.tiddlywiki doesn't render the character) text

That is the main thing I am asking about, sorry if I wasn’t clear enough about that.

right now I am experimenting with:

var listTypes = {
	"	": {listTag: "ul", itemTag: "li"},
	"*": {listTag: "ul", itemTag: "li"},
	"#": {listTag: "ol", itemTag: "li"},
	";": {listTag: "dl", itemTag: "dt"},
	":": {listTag: "dl", itemTag: "dd"},
	">": {listTag: "blockquote", itemTag: "div"}
};

But I think I need to use \t instead. not sure yet.

What should the resulting HTML be? I think using p tag with a class is better, like @@ will create span tag with a class.

And you can write a new parsing rule for it, matching the leading spaces or tabs, and create a custom type of ast node, and render this ast node with a new widget node that is “indented-paragraph”.

Why not try adding this to the core? We should have basic features that Obsidian and Notion have. I think this is a very basic feature.

1 Like

I know what you want, but using the TAB whitespace for something else than whitespace in TW wikitext will have some nasty side effects.

We do already use TAB indents for better readability in TW UI template code. If you modify the “list” wikitext rule in the core JS code you will also change the default behaviour for all the existing TW UI templates.


As you described the expected HTML output in your OP the only valid way to do it, is the one I did suggest.


I did experiment with some custom markup using » as a default indicator for indented HTML P tags (paragraphs).

But the whole thing is probably overkill for what you want to achieve and using TAB will also be not possible with the custom markup pluigin.

I guess I hadn’t fully considered how it would impact the rest of the TW core. I assumed that the wikitext would only be parsed when being shown in the viewtemplate, and would not impact stylesheets, indexes, etc. since it appears to not cause any conflict when other characters such as astericks are used.

I’m guessing this would result from the fact that it is a whitespace character rather than a normal one, which is a bummer.

I’m actually a bit curious about what sort of issues would occur as a result of it.

For ease of typing, it sounds like you might just want to run with Charlie’s recent suggestion of hijacking the colon wikitext shortcut for <dd> item since

: line-of-text

turns into <dd>line-of-text</dd> html, and thus gives you

line-of-text

as output.

And if you want your edit to show the indent effect, you can always add spaces before:

:line-of-text

renders the same, but gives you the indent effect (for the first line, at least) at left margin…

(As noted in that thread, there could be situations where in a public-facing wiki the repurposing of semantic tags like <dd> could be misleading for folks with screenreaders. But apparently even that’s not a realistic concern…)

3 Likes

@Justin_H have you tried @Springer’s suggestion of the ; and :? including multiples

eg;

;Top
: this
: that
:: the other

Something

: without dt
:: double

2024-12-21_11-10-10

resulting html

<dl><dt>Top</dt><dd>this</dd><dd>that<dl><dd>the other</dd></dl></dd></dl><p>Something</p><dl><dd>without dt<dl><dd>double</dd></dl></dd></dl>

One advantage of this is you can use the aformentioned .classname on the “Top” and the class will apply to the whole list. This was discussed recently when someone made a note class for this see link below.

Personally I also hacked the autolist plugin to also treat : like * on enter.

Of note is using * or # does something very similar, to the dt and dt tags and wraps it all in <ul> or <ol>

  • It would be great if we could apply a classname to <ul> or <ol> like we can <dl>
  • This would be more semantic than using ; and :.

See here Example: Repurposing HTML "Definition" lists for "Note" blocks

1 Like

I have not yet, but this does look actually very usable!

I think for the mean time using this will suit me, since my wiki wont be public facing and its syntax that I don’t use anywhere else.

But I am still continuing my search for a means to achieve my original goal :yum:

2 Likes

on revisiting this have you use code mirror because it does permit tabs in code. there may be a need to extend the handling of tabs in the tiddler view mechanisms.

well its not an issue with or without using tabs in code, as there are some great methods to already add tab functionality to TW, its that I am looking for the ability to have the tab unicode character itself act as a valid character to use in wikitext.

so that when it is used in non-code text (<p> for instance), it would be parsed as something to indent the text body over like if you were to use two asterisks for bulletpoints, or gave the paragraph element (<p>) a css class that applied margin-right.

naturally, I would only want this to display for non <pre> and non <code> html elements in the viewTemplate of a tiddler, probably just in the normal content types and not the image or code types, as to avoid any issues when it came to stylesheets, javascript tiddlers, etc.

unfortunately I have not had any luck in achieving this on my own, and was warned against doing so in concern for bugs earlier in the thread.

@TW_Tones … It’s the same problem we discussed for custom-markup, where you wanted to start paragraphs with a “dot”. In your case you wanted to use a “dot” – Now Justin wants to use a “tab”.

The problem with the TAB is, that it is already used in the default parser, where it is “whitespace” which is ignored.

If we would create a new rule, that TAB at the beginning of the line will create a <p class="indent", it would have unwanted side effects in eg: stylesheet tiddlers with type: text/vnd.tiddlywiki, because it would create P tags in stylesheets, whenever there is a TAB character.

The problem would be, that browsers will completely ignore CSS code within P tags.

EG: If the following code would be created by the TW parser, there will be no blue text

<style>
.red {color: red;}
<p class="indent">
.blue {color: blue;}
</p>
</style>

*.red some red text
*.blue some blue text

image

EG: The following code works just fine.

<style>
.red {color: red;}
	.blue {color: blue;}
</style>

*.red some red text
*.blue some blue text


This is only 1 edge case that will happen.


There are some 10 years old discussion at GitHub

1 Like

thank you for the explanation to this, it’s helping me think about the process.

if you don’t mind humouring my questions, what prevents situations where you type an asterisk or pound / hashtag in a stylesheet from causing rendering or processing issues?

I know in CSS terms, using an asterisk as a selector results in a selection of all elements, i.e.

* {
border: solid 1px #00ff0050;
}

Of course we just use a custom type and have it treated differently. I did create a dot · paragraph here https://dot-paragraph.tiddlyhost.com/ and elsewhere another line based wikitext.

This works at the above site;

<style>
.red {color: red;}
.blue {color: blue; text-indent: 50px; }
</style>

·.blue Line with blue/indent applied 

and the html becomes;

<p class="blue">Line with blue/indent applied </p>

Basically I am saying given tiddlywiki parses many things without a wiki text character into a paragraph <p></p> an additional wikitext symbol that would simply allow us to address the paragraph, just as we have ones for <li>, <dl>, <dt> etc…

  • Force the use of the p tag
  • Allow a .classname to be applied to that p tag

It would then be a simple matter of some supporting tools/css.

  • just insist on a different type if we need to “sandbox this behaviour to selected tiddlers”

Of note

I loved the power of the custom markup work, but perhaps it can be reevaluated in light of recent TiddlyWiki releases, and idealy have a solution that allows users to introduce their own unicode characters as needed. By setting the type we can make it clear one needs additional “handlers” for the new custom type if the tiddlers are to be shared.

  • I have long felt it would be better to introduce wiki text character definition hackability and let the designer deal with the consequences.

Very good question.

Most core stylesheets use these pragmas at the beginning

\rules only filteredtranscludeinline transcludeinline macrodef macrocallinline macrocallblock
1 Like

I did have a version with custom glyphs. But it was too slow.