Leading/trailing whitespace in passage names are invisible in the editor view

[LarkDiet]

Describe the bug.

Recently, I experienced an issue similar to #359, where any leading/trailing whitespace in the link syntax creates passages with those spaces included in the title. This leads to unexpected routing where the following examples:

[[My Passage]] [[ My Passage ]] [[ Number 3 | My Passage ]] [[Number 4 -> My Passage]] [[My Passage <- Number 5]]

would all create unique passages in the same story that appear to be identically named "My Passage". The main issue, however, is that there's no visual evidence of extra whitespace in the name value itself unless the reader opens the passage editor and clicks "Rename".

Appearance in the web editor:

Excerpt of output from Twison:

    "passages": [
        {
            "text": "This could be troublesome.\n\n[[My Passage]]\n[[     My Passage     ]]\n[[ Number 3 | My Passage ]]\n[[Number 4 -> My Passage]]\n[[My Passage <- Number 5]]",
            "links": [
                {
                    "name": "My Passage",
                    "link": "My Passage",
                    "pid": "2"
                },
                {
                    "name": "     My Passage     ",
                    "link": "     My Passage     ",
                    "pid": "6"
                },
                {
                    "name": " Number 3 | My Passage ",
                    "link": " Number 3 | My Passage ",
                    "broken": true
                },
                {
                    "name": "Number 4 ",
                    "link": " My Passage",
                    "pid": "4"
                },
                {
                    "name": "My Passage <- Number 5",
                    "link": "My Passage <- Number 5",
                    "broken": true
                }
            ],
            "name": "Start",
            "pid": "1",
            "position": {
                "x": "300",
                "y": "425"
            }
        },
        {
            "text": "",
            "name": "My Passage",
            "pid": "2",
            "position": {
                "x": "100",
                "y": "675"
            }
        },
        {
            "text": "",
            "name": " My Passage ",
            "pid": "3",
            "position": {
                "x": "200",
                "y": "675"
            }
        },
        {
            "text": "",
            "name": " My Passage",
            "pid": "4",
            "position": {
                "x": "300",
                "y": "675"
            }
        },
        {
            "text": "",
            "name": "My Passage ",
            "pid": "5",
            "position": {
                "x": "400",
                "y": "675"
            }
        },
        {
            "text": "",
            "name": "     My Passage     ",
            "pid": "6",
            "position": {
                "x": "500",
                "y": "675"
            }
        }
    ]
}

Steps to reproduce:

1. Create a new story passage in the Twine web editor.
2. Paste the links from the description above.

Expected behavior:

Creation/link to a single passage, "My Passage" - or the leading/trailing whitespace visually present in each passage name.

Additional context on this problem.

Admittedly, the cookbook demonstrates linking passages without the extra whitespace, but does not explicitly discourage adding it. Imo this should be allowed for better readability.

Twine version number

2.5.1

Does this problem occur with the web version of Twine or the desktop app?

Web

What operating system does this problem occur on?

Windows

If this problem is occurring with the web version of Twine, what browser does it occur on?

Chrome/Chromium

Presubmission checklist

• [X] I am interested in working on code that would fix this bug. (This is not required to submit a bug report.)
• [X] I have done a search and believe that an issue does not already exist for this bug in the GitHub repository.
• [X] I have read and agree to abide by this project's Code of Conduct.

[klembot]

I think but I'm not 100% sure that a lot of what you're describing is caused by HTML eating whitespace, e.g. <div> whatever </div> will render as whatever with no leading/trailing space.

You checked the box saying you'd like to contribute code to fix this... what approach are you thinking about here?

[webbedspace]

I was about to wonder if you couldn't just add white-space:pre to passage editor window titles, but then again, would the spaces be prominent enough that it'd be obvious what's going on? Maybe what's called for here is to display the passage name in monospace, with a special background. Considering these are string values used as primary keys in all story formats, this level of unambiguous display probably is called for.

Crude mockup below.

[K8fractal]

I really like @webbedspace's mockup!

This is a common sticking point for new Twine/Harlowe users, as I've seen from teaching Twine/Harlowe to several hundred students.

[klembot]

I think I prefer borrowing the convention from word processors of showing whitespace as a lighter dot. To me, it has the advantage of being clearer as to exactly how many spaces are involved, and it's invisible to users who haven't added extraneous whitespace. Rough mockup of my thought, the alignment/spacing isn't right:

[LarkDiet]

I think I prefer borrowing the convention from word processors of showing whitespace as a lighter dot. To me, it has the advantage of being clearer as to exactly how many spaces are involved, and it's invisible to users who haven't added extraneous whitespace.

I agree with this approach - even better if paired with some warning text (e.g. "This passage name has extra spaces at the beginning/end") when the passage is opened in the editor.

You checked the box saying you'd like to contribute code to fix this... what approach are you thinking about here?

This idea was more intended as an enhancement, but would it necessarily be a breaking change to allow link syntax like [[ this ]] alongside [[this]] and still get a passage named "this"? Imo it doesn't seem to offer much benefit over confusion to the user to allow leading/trailing whitespace in the passage name unless they are also using the CSS white-space:pre rule to style their links, and even that would be irrelevant to links with alternate display text.

Assuming the parseLinks() function is part of the logic behind this name determination, what if the link name strings returned by it were also trimmed? (This could also eliminate the (minor) bug where passages with whitespace-only names could be created by the automatic parser - even though it is not normally allowed when renaming passages manually.)

let result = uniq(
	extractLinkTags(text)
		.map(removeEnclosingBrackets)
		.map(removeSetters)
		.map(extractLink)
      		.map(s => s.trim())
		.filter(nonEmptyLinks)
);

[greyelf]

but would it necessarily be a breaking change to allow link syntax like [[ this ]] alongside [[this]] and still get a passage named "this"?

Yes.

Because the JavaScript engine of the specific Story Format the Author has selected for their project will still treat the [[ this ]] and [[this]] mark-up bases links as if they are referencing two different Passages , one named " this " and the other named "this", when the generated Story HTML file is opened in a web-browser. And if the project only contains a single Passage (named either " this " or "this") instead of two Passages (named " this " and "this") then one of those example mark-up based links will be considered "broken" when the contents the Passage it is in is proceed.

Simply put, the Letter Casing and Punctuation of a Passage Name matters when the Story Format's engine is looking for which Passage to show when a Passage Transition occurs,

[LarkDiet]

:pensive: about that but Understandable

I also realized I have overlooked this section of the Cookbook, which technically did address my comment about whether it was clear how links are parsed:

The simplest way to connect passages is through adding two opening and closing brackets around any collection of letters, numbers, or punctuation. If a passage exists with those exact characters in the same ordering and combination, the passages will be linked together.

So uh, that one's on me.