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.

1 Like

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

2 Likes

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.

I feel a bit silly to admit to this, but! I believe I have found a (admitedly simple) solution to what it was I was looking for. and it only requires a little CSS and a tag.

So! this uses the example from the Custom styles by data-tags tiddler found on the tiddlywiki homepage, modfied to show the following:

[data-tags*="Note Tiddlers"] .tc-tiddler-body,
[data-tags*="Note Tiddlers"] .tc-tiddler-preview-preview {
  display: block;
  word-break: normal;
  word-wrap: break-word;
  white-space: pre-wrap;
}

With the end result showing tabs as they would be shown in the editTemplate, without requiring the need for any wikitext implementation or conflict with preexisting core functionality.

Now, I haven’t fully tested this, so I’m not sure if it will cause issues when using wikitext, but for the time being, it seems to work exactly as I need it to. The only minor inconvience is how i have to keep the text from auto-wikifying using new lines or starting paragraphs with wikitext like !headers.

At the moment, this, in conjunction with my “new note” and “new note here” tiddler buttons (just repurposed copies of the journal tiddler buttons) makes for a pretty nice way to quickly jot down notes that retain indention by still accept wikitext.

Can anyone see any issue with this, by chance?

Edit 1: It appears that I have already found one :sweat_smile: this completely breaks the fold mechanism for the tiddlers. Currently looking for a means to fix this…

Edit 2: Well, I found a fix. I attempted to use :not([hidden]=“true”) in some way to fix it but that didn’t work, and instead I found that ending the css selectors with p.

Fixed ver. :

[data-tags*="Note Tiddlers"] .tc-tiddler-body p,
[data-tags*="Note Tiddlers"] .tc-tiddler-preview-preview p {
  display: block;
  word-break: normal;
  word-wrap: break-word;
  white-space: pre-wrap;
}
1 Like

I’m baffled. I’m not getting any such result — either on my own wikis or on tw-com, and I don’t see what in your code should achieve this result either… Getting out of edit mode doesn’t help (just showing it this way for compactness):

This is behavior I noticed as well!

What is happening from my observations is all whitespace, no matter the word-wrap or word-space, is removed in two circumstances.

  1. at the start of a tiddler that is not in a hard linebreak or isn’t on the following newline to non-wikitext text:

ex. not working

	I am not indented!

I am normal?
	I am not indented!

ex. working

I am normal text
	I am indented!

or

"""
I am normal?
	I am indented!
"""

and 2. if there is any wikitext and it is not in a hard linebreak.

ex. not working

!! Hello There!

	I am not indented!

ex. working

!! Hello Again!
"""
	I am indented!
"""

The reason for this must be apart of how tiddlers are parsing the text, though the exact function I am not aware of. Out of habit I always create hard linebreaks directly after my headers, so didn’t immediately notice this and almost thought it was a bug of some sort.

Here are some test tiddlers that can be imported into My TiddlyWiki — a non-linear personal web notebook for confirmation! tiddlers (1).json (553 Bytes)

Addendum to this, a bit sad there isn’t a core keybind for hard linebreaks, I can’t think of a good keybind to make for it at the moment. I was tempted to use alt p but that is reserved for printing :thinking:

I believe this tiddler (https://tiddlywiki.com/#Hard%20Linebreaks%20with%20CSS) on tiddlywiki.com could have shown this, but it doesn’t, which caused me to overlook it until now :sweat_smile: