[tw5] Should we prohibit leading and trailing whitespace in field names in 5.2.0?

Google Group (Read Only)
#1

I’ll preface this by saying this probably belongs in a GitHub issue, and I’ll be happy to create one over there if we want one. But wanted to get people’s thoughts first, and ASAP because now is our last chance to do this without breaking backwards compatibility (once 5.2.0 is released, it would be pretty hard to change).

Would it make sense to prohibit leading and trailing whitespace in field names, even though we now allow whitespace elsewhere? In the prerelease, it’s not possible to add such fields within the GUI, but you can import tiddlers that contain such fields, or create them with an action or $edit-text widget. Fields with leading or trailing whitespace are almost impossible to distinguish within the GUI, since there is already whitespace before and after the name when it’s displayed.

In addition, if we continue to prohibit leading and trailing whitespace, I think we would be able to allow whitespace in between filter steps, which is a common annoyance for new users (but maybe I’m missing something there).

I can’t think of any situation in which someone would want leading or trailing whitespace in a field name, except maybe to integrate with another system which allowed it for some reason – as evidenced by the fact that the GUI doesn’t even let you create such a field. At any rate, it seems much more confusing than helpful. Unix filenames have suffered enormously from being overly permissive in what characters they allow, including leading and trailing whitespace; my instinct tells me this is likely to be a continuing irritation.

On the minus side, someone would of course have to implement checks to prevent these fields from being added.

#2

Just realized some people might not be familiar with the term “leading and trailing whitespace”…I mean whitespace at the very beginning or end of the name. In the current prerelease, these are valid and distinct field names (with the quotes removed):

“my field”
" my field"
"my field "
" my field "

#3

I think this won’t happen because of backwards compatibility with 5.1.x. There have been some discussions on github already. The conclusion was, we keep the status quo and live with it.

There has been a discussion recently, where a user needed to be able to add whitespace as needed. And the description of the usecase made sense. So there are usecases. … See: https://groups.google.com/g/tiddlywiki/c/Cjy074MsfzM

-mario

#4

Mario,

I don’t think the thread you linked is relevant. I’m talking about field names, not field values. And I don’t see how it would break backwards compatibility with 5.1.x, because 5.1.x didn’t allow any spaces in field names.

If I’m misunderstanding, please correct me (and can you link the discussions on GitHub?).

#5

That discussion was related to having leading whitespace in a field value, not a field name, and then transcluding that field value into another tiddler.

-e

#6

I am in favor of stripping out leading and trailing whitespace in field Names during field creation and tiddler import.

Best,
Joshua F

#7

Hi Soren,

I absolutely support removing such spaces in the field name! Those spaces are not displayed visually and are a source of error!
I even support trimming field values when they are saved!

I had encountered such cases many times and it took me a lot of time to find the cause of error!

I believe having clear, simple to follow, semantic rules are much better to have a lot of flexibility!

Normally users get confused, these cause errors for advanced users if they do not care enough and are mostly time consuming!

#8

Sorry, I was talking about field values.

You are right, we should trim field names. There is some time left to do so. But this question should be raised as a github issue.

-m

#9

Posted here, thanks everyone.

#10

Trimming values, fieldnames and tiddler titles makes sense, there may however be a rare occasion where this is needed, however I think the hack would be to use a special space character (that is not trimmed) if you really needed.

Of course when possible allow the default to be overridden if needed, with a conscious action to do so. Just follow the standards eg in HTML input fields.

Tones