[TW2036] Planning for v5.4.0

#76

Is there a standard, non-Vanilla theme way to have an editor open on a separate basis?

(This is just honestly a thought I had, and so if it’s not “inspired” then it’s not inspired thanks.)

The depth of this issue is that the editing is actually literally a separate temporary Tiddler, and that is not able to change from what I understand.

A side question I have had for a little while is: How easy is it to facilitate a slightly different theme, where the same edit-mode for tiddlers can basically get opened in a different river, or in the sidebar? In this case, there would be no re-opening at all - just 2 separately opened modes.

The two seem to be unnecessarily entangled too intrinsically anyway.

It’s been a while since I have been looking at it, but I think edit mode is a template. In summary: How inconvenient/incompatible is it to program the ability for users to implement a separate edit mode on a separate basis altogether? Plus it could open up more design possibilities than just this aspect of re-opening.

1 Like
#77

Smart ideas @wattahay but the community is ahead of you on this one.

You may find this better as a thread of its own. There are multiple opportunities to do what you want with the current versions, from multiple story rivers, edit in the sidebar, to open for edit in a new window, with or without closing the tiddler in the view template allowing a preview of the edit, this is why some favor wysiwyg, as its both at once.

  • Although such additions to future versions may be good they need not break backwards compatibility which is what 5.4.x is about.
1 Like
#78

You know what, I had searched for almost exactly this before, but couldn’t find anything like it.

However I wonder: with his/her amount of knowledge, would* it not be so easy to use the same template as the regular editor?

edit: By, “would it not” I mean literally perhaps “should it not” be that easy. If it were that easy, then the plugin would probably not have to re-do it for instance. It’s more of a thought about the core for the sake of enabling the community in this regard.

2 Likes
#79

You mean an instance of any use for each of the UNused System tags does not exist in Empty?
Yes?

Taggery in TW is a triple: brilliant, fundamental, and ultra-flexy.

TAG MANAGER

My suggest here is to Enhance The Tag Manager to give it easier powers to … Create Tag Tiddlers for any unused System Tag. And give more options on tag manipulation in general. Should not add much code?

IMO the Tag Manager is underused and with a bit of love could live up to it’s name and become a major way to understand and improve one’s own wikis.

TT

1 Like
#80

My personal solution to missing system tags is a small package that list all system tags known to tiddlywiki, that I have collected in an additional sidebar > more tab. However I also use my Reimagin tags package that adds a lot of additional features to the tag pill dropdown.

The Question is what should move into the core, however none of these are breaking backwards compatibility.

3 Likes
#81

A thing that could be fixed in 5.4 would be implementing the option to close modals by a click outside them.

1 Like
#82

What happens if an older version wiki that has Relink installed as third party plugin will get updated to 5.4.0? Will it be a matter of going to Plugins tiddler, remove Relink and reinstall it from the core plugin library?

In my book, Relink is a strong contender for that one plugin that gets installed first into an empty wiki, and besides it being extremely functionally useful to end users (it does automatically what would be a scary wikitext programming task), if bringing it into the core will also yield speed improvements, I’ll be two times happier, because renaming tiddlers in a 10+MB wiki on a 5 years old smartphone introduces a noticeable lag while typing in the tiddler tittle text field, a lag that is big enough to break the fluidity of working with the wiki.

#83

@JanJo check this

Screenshot_20250606-162004
Screenshot_20250606-1620041080×1793 180 KB

2 Likes
#84

huh, I’d had the same desire for modals and had missed this in the doco originally.

tbh, having this set as a field in the content for the modal feels pretty backwards to me. I expected a per-modal setting to be something set as a parameter to the call of the modal, but more generally, it’s a setting I’d want to be global to the wiki, for consistency (and then be able to toggle to the alternative on a per-modal basis)

2 Likes
#85

We need to get v5.3.7 released before we can properly start merging PRs for v5.4.0. I’ve made a GitHub ticket to collect any suggestions for PRs or fixes that should be included:

2 Likes
#86

Thank you @arunnbabu81 I had missed this.

I also would like the setting to be more general - or to have it set to true by default.
I think there are only some usecases where I might want the user to Click“accept“ explicitly. .

#87

Speaking of modals, having the title of the tiddler in the modal header as a link would also be nice. I am resorting to having <$link>*</$link> be a part of every new tiddler in case I want to open it from a modal.

#88

You could put this into the subtitle-field. I think this is a smart solution - but sometimes on the contrary, I supress the modal title in order to have more space in the modal itself.
I think it would be usefull to have no title at all if there is no subtitle-field. Having a systemtiddeler title displayed there is only distracting for users. (BTW is there a different word for the non-admin and non-programmer users - e.g. the students that just read the texts - Sometimes it would be usefull to have it to think them as an entity ;- )

#89

Nice! I will try that.

#90

I think it is possible to warn if the relink plugin is now redundant if upgrading to a version where the features have being moved into the core. Regarless all that becomes nessasary is to remove the plugin.

#91

There is a proposal at GH

[Proposal] Every List-like wikitext rules shuold be 1 module. That makes it easy to disable them selectively

Since it would be a backwards incompatibility as Saq Imtiaz posted at GH it should be considered for v5.4.0

Crossposted from GitHub

Every List-like wikitext rules shuold be 1 module. That makes it easy to disable them selectively

From GG:

3 - Is a godsend where you to need switch off pragma because of use case. Why? Example: probably the worst pragma to switch-off is the Block Parse Rule for “list” because it disables ALL forms of list construct (*#:;). Example use case: Wiki concerned with posting to social networks where “#” is used all the time you need to switch of processing of “#”. …

Proposal

The /parser/list.js module should be splitted into 4:

  • list-bullet.js
  • list-hash.js
  • list-definition.js
  • list-blockquote.js

This will allow users to disable them 1 by 1 in the Control Panel. … It will probably duplicate some code. … BUT I think it would be worth the convenience. At the moment diabling the “list” rule disables 4 different elements, where 2 of them are really important “>” and “*”

#92

Just for clarity is it not sufficent to use ControlPanel > Advanced > Parsing to alter the state of each seperate parsing rule?

From memory there is also pragma that allows to to selectivly enable/disable rules as well so I dont think there is much reason to introduce such a compatibility break.

#93

It would of they where separated. All of them are list.

#94

Jeremy,

In a related discussion here Using links[] in current tiddler we discovered the value of handling | delimited pairs initialy to parse out pretty|title from [[pretty|title]]and |tblecol|tablecol| so I wonder if a more general solution can be found for other.

  • Handling where | is also found inside shortcut transclusions say to extract a template name etc… could also benifit.

Note:
The features we are discussing here are in someways tiddlywiki script meta issues, ie pertaining to manipulating wikitext as found, making solutions that directly interogate wiki text or text field contents (Before render) rather than simply TiddlyWiki Script and filter operators.

  • By providing methods or defacto standards to support these tiddlywiki from a meta perspective is like turbocharged hackability because a designer can directly interogate TiddlyWikimarkup and script directly.
  • It would be great if for example designers had access to the parsing logic already in TiddlyWiki for rendering wiki text.
    • Eg: the same rules that identify wikitext symbols.
#95

For 5.4.0?

I dont know if it would be a break but could we have a less complex version of the keyboard driven macro or some reusable code to make such methods easier to use?

Similarly a builder for any facility that requires multi-tiddlers to implement such as shortcuts, view and editor toolbar buttons etc… these demand too much cognative load for many uses to benefit from them.