Is using the Tab character a bad choice when wanting to indent text?

#1

To be more specific, I’m only talking about using the character (0x09)

inside of the editor, rather than applying indention on the viewer. (unfortunately I cannot type the actual character here.)

I use a shortcut to add a Tab character with every time I press the tab key, and was curious if these would cause any sort of issues down the road, even though they are space characters.

#2

It won’t cause any issues using space for indentation wouldn’t have caused. Macros and other TiddlyWiki-specific syntax doesn’t usually care about spacing, and most of the time HTML will collapse multiple spaces into a single one and remove excess whitespace from the start and the end of a section of content.

In my experience the worst that can happen is additional space between elements of the layout or buttons or such, most of them don’t make much of a difference.

Why do posts need to be 20 characters?
#3

Ah ok, thats good to know, i just remember always being told to not use tabs when coding :\

#4

FYI Code mirror allows you to insert tabs in code. I have not checked but there are places where it may effect the output when it’s part of a string, template or value that is to be rendered, however in wiki text it should just be ignored like leading spaces etc… Needs confirmation but that my experience.

#5

Does it do so using the character or using css?

#6

Ah, the good old tabs vs. space war.

#7

TW actually uses tabs for indentation. We use a tab setting for 4 chars. So 1 tab creates a 4 character wide whitespace.

In JS code TW ships with plain text source code, because it is easier to handle, if new users want to go down the rabbit hole.

Using tabs instead of spaces actually does make a difference in TW file size.

#8

In TiddlyWiki wikitext it does cause problems, that’s why if you use whitespace for indented macro code you should use the \whitespace trim pragma. eg:

The right way to do it for TW core code is the second example

\define button-text-01()
<$let a=1 b=2>
    <$button>some text</$button> some more text
</$let>
\end

\define button-text-02()
\whitespace trim
<$let a=1 b=2>
    <$button class="tc-tiny-gap-right">some text</$button> some more text
</$let>
\end

<<button-text-01>>

<<button-text-02>>

While the visual HTML output is the same, the HTML code is different. The first paragraph can create all sort of subtle copy paste problems if used in the TW UI

<p>
    <button class="">some text</button> some more text</p><p><button class="tc-tiny-gap-right">some text</button>some more text</p>
#9

True but I’d argue it’s very uncommon for the actual HTML structure having those spaces to matter. At least it was almost never (or maybe just never) a case that the spaces in the structure were an issue other than the rare cases where it does result in some additional undesirable spaces being added, and I don’t recall ever encountering anyone ever having an issue with that.

#10

A post was split to a new topic: Why do posts need to be 20 characters?

#11
  • The first example does not close the button widget
  • As @pmario points out it uses characters
    • The use of the \t and \n can not be seen in the Internals Plugin HTML preview, they are however “honoured” , but do appear in the Parse Tree and Widget Tree views.
  • You can also see the tab character “⇥” using the “diff view” against modified shadows - in this case I inserted the tab with codemirror.

Other notes,

  • tabs die if using code mirror plus the very useful Editor Auto List of @saqimtiaz - perhaps a compatible version could be developed to insert tab if no bullet wikitext is present.
  • Install codemirror and look at Control Panel > Settings > Code Mirror multiple settings are available.
#12

In wikitext tiddlers, any HTML is being processed by TiddlyWiki’s parser to create widgets, which then create the necessary HTML elements using the $element widget (which does not have any user facing affordances). That is, it is not the browser parsing the HTML but TW.

The TW parser has special handling for whitespace, in particular for paragraph generation, and this is something we are currently tied to because of the backwards compatibility commitment. This backwards compatibility commitment includes making sure that any changes to the code do not introduce any layout changes including extra blank space.

#13

Trust me, there have been very frustrating problems.

We fixed them. There has been a super tricky to find and super annoying bug, where users did use the tag-pill to copy paste a tag from the pill to the tag-field of a new tiddler. …

The tag-pill did contain a leading space which was used for styling. The problem was that a new tag created that way did contain a leading space. Exactly those type of problems are extremely hard to reproduce and very frustrating for the users.

To avoid that problem we did remove the whitspace in the tag pill (TW5.1.23 or so) and we did change the CSS for the tag pill, so leading or trailing spaces in tags will be visible now.(TW v5.2.4)

#14

huh, I didn’t know that. I’m guessing because of the character difference adding up?

Would this break anything for older wiki users? I’d imagine functionality with the tags would be afterwords

#15

Thanks for the example, I was very curious what the actual encountered issues were.
I also think a good solution here would be to always trim all names in general, even if someone could come up with a good individual use case for them I’d think in almost every other case they’re an unwelcome problem.

#16

Yes. When TW is created we also remove the CR character so only LF is used on windows. This has 2 advantages. 1st it is smaller. 2nd the builds are identical. Which imo is important

1 Like
#17

I wanted to enforce whitespace timing on core level. But This behaviour was rejected in favour of developer freedom.