A peculiar PR request

#7

@Mark_S and @TW_Tones here’s the code. So the idea is to navigate back to the tiddler you came from when you either close or delete the current.

If you try it out, you’ll see the “close” works but not the “delete” - because of the empty line at end of delete:

\define remove()
</$button>
\end
\define insert()
<$action-navigate $to={{{ [list[$:/StoryList!!list]before<currentTiddler>] }}} />
</$button>
\end

$:/core/ui/Buttons/delete
$:/core/ui/Buttons/close

<$let subfilter='[get[text]removesuffix<remove>addsuffix<insert>]' >
<$button>
<$action-setfield 
   $tiddler="$:/core/ui/Buttons/delete"
   text={{{ [[$:/core/ui/Buttons/delete]subfilter<subfilter>] }}} />
<$action-setfield 
   $tiddler="$:/core/ui/Buttons/close" 
   text={{{ [[$:/core/ui/Buttons/close]subfilter<subfilter>] }}} />
X
</$button>
</$let>
1 Like
Filter problem: "then...else" but carrying the input
#8

@saqimtiaz and @sukima - thank you! Hm, I guess I was wrong about the level of difficulty in editing code tids vs doc tids (…wasn’t there a big difference previously? I’m almost sure there was?)

But one issue remains in that How the heck do you locate the tiddler in the gh structure? For doc tids, there is the pink ribbon on tw .com but why isn’t there the same for code tids?

I just posted this PR :slight_smile:

#9

The GH directory structure is very intuitive if you spend a few minutes to think about it once.

It would require that someone put in a rather significant amount of work to get that into place, with no tangible and assured pay off.

#10

Never, ever rely on an empty line at the end of anything. The next time someone will handle that tiddler it may have an empty line again.

Some IDEs have a default setting that every file should end with an empty line. … Some IDEs don’t. In reality it shouldn’t matter

#11

Hm… I can give examples for how to get lost there but on the whole it is - of course - just a lot simpler with a direct link (as via the pink ribbon). But so is that how core contributors do it - they manually navigate down in the gh repository tree to locate the tiddler every time?

I’ve kind of assumed the lacking pink ribbon link for code tids was a way to prevent just anyone from making code PR’s - not that it was more difficult to implement such a link. Wouldn’t it be pretty much the same mechanism as for the doc tids (…what’s the difference? Both are links to a location in the gh tree? Or maybe the docs tids are structured in the gh tree so they’re more easily mapped?)

#12

Also worth noting that the POSIX standard actually requires a line break at the end of each line for it to be considered a valid line.

A sequence of zero or more non- characters plus a terminating character.

from: Definitions

#13

Hm, that sounds like a lack in how we handle code contributions then, allowing arbitrary empty lines to be inserted. As Mark noted above, there are quite a few cases where empty rows affect the outcome in TW.

Do you have a suggestion for how I can avoid this problem in the code I posted here above?

#14

I suspect most core contributors use TiddlyWiki on node.js and either edit via TiddlyWiki, or directly in a code editor. As I mentioned, the structure is very intuitive if you have spent a few minutes with it once.

TiddlyWiki on node.js tracks where it loads content tidders from, but shadow tiddlers within plugins are different and there is no mechanism to trace where the component tiddler of a plugin was loaded from.

#15

OK, but then we have a bigger issue because the code is inconsistent with terminating line breaks, compare the mentioned delete and close buttons.

#16

Adding to it, @twMat you can search for a file in Github by using the file finder. Press t and it will open the file finder mode for you.

Another way is to search for a string in the repository. But when you open the file from the result, you must remember to switch to the HEAD version of the file.

Finally, on desktop you can use commands like fd, find, rg or grep to search for files.

2 Likes
#17

You are right. But that is one more argument, that no plugin should rely on a consistent behaviour of the core about whitespace. … Except if there is the \whitespace trim pragma.

There is a lot of whitespace in the core UI which creates redundant P tags. So there are a lot of redundant HTML paragraphs in the core UI, which make styling and theme development problematic.

I want to get rid of them. They are one of my biggest personal pain-points in TW. It is already extremely hard to get rid of them because of Jeremy’s backwards compatibility concerns.

This is also one reason, why I do try to add indentation to the core UI, for human readability and it will define whitespace trim, which introduces the need to define the spacing between HTML elements using CSS and not spaces. …

1 Like
#18

hmm, Back to the code at the OP. … What you want to do here is called monkey patching, which has on inherit and fatal flaw. It 100% relies on the original code, to be always the same.

So in reality not only the trailing whitespace is already a problem for your code, it also relies on </$button> be the last word of that code. There is a good chance, that this assumption is right, for something named: $:/core/ui/Buttons/xxx, if there wouldn’t be Murphy’s Law

“Anything that can go wrong will go wrong, and at the worst possible time.”

I can only suggest: Search for a method to solve the problem in a solid way.

1 Like
#19

Great post. Very informative about some “backroom essentials”

Yeah!! Right-on broheim.

  • The <p> pollution is likely the ONLY thing I dislike in TW.

I guess it is there because @jeremyruston, at creation time, could not foresee the issues on basic layout control it has led to?

This is the ONLY issue where I think TW (@jeremyruston’s concern) should NOT be backwards compatible. Because it it is SILLY not to move on to a cleaner thing.

A comment from me
TT

#20

Not sure how… but here’s an idea - what do you think about it:

In all(?) core buttons, insert an action param and give it an argument that the user can define. For example:

title: $:/core/ui/Buttons/close
text:
<$button actions="{{$:/core/ui/Buttons/close-actions}}">

$:/core/ui/Buttons/close-actions is empty (non-existing) by default but users can then define arbitrary strings of actions.

With that said, I did request this but there was no interest or feedback.

#21

Implementing anything like this is intricately tied with the work of opening up the core to be expressed more so in wikitext and thus hackable. In particular we need to provide affordances to replace the current JavaScript only hooks with equivalent wikitext based affordances. This is a non-trivial amount of work. Parameterized transclusions are the first step in this direction.

Trying to address the expressed needs independently of implementing wikitext affordances for hooks would likely lead to two similar but conflicting mechanisms for customizing core behaviour.

Filter problem: "then...else" but carrying the input
#22

You should see our linter configs. shudder The number of ending new line fights I get into with co-workers is absurd. IIRC POSIX specs attempted to stop the ending new-line holy war by putting it into their specs but it didn’t work and we still to this day have holy wars over a measly 1010 at the end of a file.

1 Like
#23

But you could specify in the plugin which core version it works with, right?

When all you have are monkeys, everything starts to look like a coconut.

1 Like
#24

So you volunteer to maintain the list which UI element works with which core-version and which compatibility requirement needs to be used. … Are you sure? :wink:

1 Like
#25

No, that’s making the problem unnecessarily big. But whoever is distributing the plugin (e.g. Mat), will be aware of whether they need to issue a new plugin for a particular TW release.

#26

I have absolutely no idea what any of that means :upside_down_face: but it gives me a warm feeling that it is a well kosher probe into inevitables.

TT