📝❌4267❓ Task: Filter all tiddlers created between 01.09.2019 and 15.09.2019. How/where to find information/documentation to get this task done?

[Cd.K]

For the  past half an hour I have been looking for a solution and also have an idea now how to solve it.
But I think, such a simple task should be solvable in 5 minutes or less.

How would you approach this problem? Where/how would you search and what would you find?

[@TiddlyTweeter]

regular expression filter.

[Cd.K]

@TiddlyTweeter

After this regexp Operator (Examples)

I can do in Tools; Advanced Search; Filter:

[regexp:created[201909]]

and I get a list with all Tiddlers created in September 2019.

But

[regexp:created[201909(0[1-9]|1[0-4])]]

Filter error: Missing [ in filter expression

How do I apply this hint in my case?

<$set name="digit-pattern" value="[0-9]{2}"> <<list-links "[regexp:title<digit-pattern>]">> </$set>

[@TiddlyTweeter]

You can't use square brackets directly in TW filters. You need use them through a variable.

I can't do this now. If not solved by tomorrow I'll help.

TT

On Thursday, 19 September 2019 22:45:56 UTC+2, Cd.K wrote:

@TiddlyTweeter

After this regexp Operator (Examples)

I can do in Tools; Advanced Search; Filter:

[regexp:created[201909]]

and I get a list with all Tiddlers created in September 2019.

But

[regexp:created[201909(0[1-9]|1[0-4])]]

Filter error: Missing [ in filter expression

What's wrong? 4 brackets [ and 4 brackets ].

[coda coder]

You need to set a variable to contain anything that clashes with TW's filter syntax (usually [ ] and { } etc)

<$set name=pattern value="201909(0[1-9]|1[0-4])">
<$list filter="[regexp:created<pattern>]">

</$list>
</$set>

[Cd.K]

coda coder

I use your code

in Tools / Advanced Search / Filter =>

My question was:

How do I apply this hint in my case?

<$set name="digit-pattern" value="[0-9]{2}"> <<list-links "[regexp:title<digit-pattern>]">> </$set>

My case: Tools / Advanced Search / Filter

[coda coder]

Sorry, I should have mentioned, it needs to be a macro. https://tiddlywiki.com/#Macros%20in%20WikiText

At the top of your tiddler:

\define my-macro()

<$set name=pattern value="201909(0[1-9]|1[0-4])">
<$list filter="[regexp:created<pattern>]">

</$list>
</$set>

\end

Then, somewhere lower down (below all other macros if you have more than one) ...

<<my-macro>>

You can rename my-macro to anything that suits you: date-thing, if you want.

[Cd.K]

coda coder

I think we're talking at cross purposes.

I want this regexpr:created as a condition in Tools / Advanced Search / Filter.

Exactly at this point I would like to extend the Advanced Search Filter by the restriction from day 01 inclusive to day 15 exclusive.

[Mohammad]

See the solution here:

https://groups.google.com/d/msg/tiddlywiki/2BmQGW1yv2M/BezFntw6BwAJ

Advanced search cannot handle regexp when special characters are used

--Mohammad

[@TiddlyTweeter]

Cd.K & Mohammad

[regexp:created[(^2019090|^2019091(0|1|2|3|4|5))]] 

Should work in Advanced Search, Filter without the need for a variable to hold the pattern.

^2019090 = 1st to 9th September 2019

^2019091(0|1|2|3|4|5) = 10 to 15th September 2019

 (I have tested it a little. IF you have issues let me know & I'll revise it).

Advanced search cannot handle regexp when special characters are used

I think its ONLY the character class "[...]" that is a problem in the regexp filter. 

I'll comment more in the other thread later.

TT

[Cd.K]

Tiddly Tweeter

Works!

In my TiddlyWiki I compared the number of matches from your solution with the result of the list filter method

<$set name="date_between" value="201909(0[1-9]|1[0-5])">
<<list-links "[regexp:created<date_between>]">>
</$set>

and both techniques return the same number of hits.

Thanks a lot

Cd.K

[Cd.K]

Bottom line:

There was no hint that RegExp does not work completely in Advanced Search and TiddlyWiki issues a wrong error message at this point. 
 

I created issue #4267: here at github.com/Jermolene/TiddlyWiki5/

[@TiddlyTweeter]

Ciao Cd.K

The "brackets problem" is actually documented at https://tiddlywiki.com/#regexp%20Operator

| The filter syntax makes it impossible to directly specify a regular expression that contains square brackets. 

There is also an example at: https://tiddlywiki.com/#regexp%20Operator%20(Examples)

I agree it might be highlighted more like this ...

| The filter syntax makes it impossible to directly specify a regular expression that contains  regex character class  [...]  brackets. 

Best wishes

TT

[Cd.K]

TiddlyTweeter

I don't agree.

I've stumbled across these very places. The problem ist that you can't set up variables in Advanced Search and this hint is missing. For those who know it, it's obvious, but not for newbies.  It's not easy to get used to TiddlyWiki and such things make it unnecessarily difficult.

BTW the use of RegExpr's in Advanced Search is massively restricted. Either a correct error message or a possibility in Advanced Search to set up variable(s) for the RegExpr operator via the interface of the tiddler - not in edit mode. It would also be correct to remove the RegExpr operator from Advanced Search.  But nobody wants that. 

Regards

Cd.K

[@TiddlyTweeter]

Cd.K 

Don't go all Tweedledee on me :-)

I was merely saying its in docs for the regexp operator. Which it is. Though not quite clear enough.

The fact that regex in TW filters is limited in some ways is frustrating. 

Especially to users who understand regular expressions.

I'm not clear how you could improve it regarding input of character class "[...]" in Advanced search.

FYI, an issue of even more importance is that though you can use "capturing groups" in TW regexp filter there is no easy way to return those matches.

TT

[Cd.K]

TiddlyTweeter

Sorry!

I have written my answer because I hope that those who work on the reported bugs will read this post which I linked there. 

Can you modify the core and/or develop plugins?

If so, we could prepare a pull request together to remedy the situation. I'm working on wiki parser rules anyway. But I don't know much about html, css, Tiddly Wiki macros and customization.

I create new URIs to control my most important applications (windows 10) from TiddlyWiki: notepad++, explorer, Visual Studio Code ...
e.g. a click on the link "npp:D:\Dev\test\test.cmd" in TiddlyWiki opens the file "test.cmd" in notepad++.  Therefore I have to extend the wiki parser so that TiddlyWiki formats the URI "npp:" as a link.

Regards 

Cd.K

[@TiddlyTweeter]

Ciao Cd.K

There has been some detailed work done you may want to read up first regarding a possible revised regexp operator: https://github.com/Jermolene/TiddlyWiki5/pull/2963 

Its not going ahead as yet.

Best wishes

TT

[@TiddlyTweeter]

Cd.K

The parser runs are part of render prep process. 

I think the parsers are very useful--and currently wildly underused for customisation--mainly, probably, because they are in JS.

FYI you might want to look at work of BJ http://bjtools.tiddlyspot.com/#Flexitype%20Demos

I particularly like his: http://flexibility.tiddlyspot.com/ which is a pure regular expressions based pre-parser that runs before the main parsers kick in. Its a bit fiddly to set-up but very good if what you need do is all regex based.

TT

[Cd.K]

 TiddlyTweeter

Thanks to your very interesting links I also found this Mod-Loader Plugin from Evan Balster. I quote from his plugin announcement February 2018 in the google TiddlyWikiDev group (here):

... a safer way to change the core ...

This plugin allows shadow tiddlers in a wiki to be patched at boot-time.  This makes it possible to change the TiddlyWiki core without creating conflicts or errors when the wiki is upgraded.  Almost any code in the core can be patched. †  It's also possible to patch other, non-core plugins.  If any conflicts do arise, the patch operation is aborted and the wiki will load without modifications.

I could use this to patch the wiki text parser rules and a few more functions

• mask/escape bad chars like [] {} ... in tiddler titles
• mask/escape nested "[...]" in Advanced Search RegExp
  
• new URIs (this already works in my custom 5.21 edition for "npp:" and "xpp:" see URI demo)
  
• "." rule to force line breaks instead of <br/> (wish from TonyM see leading period wiki parser rule)
• pull request 2693 "Returns text of input selection that matches regexpr"  as plugin
  

Cd.K

[TonyM]

Cd.K

Yes, and alternate regex search tab that permits entry into a variable could overcome this limitation. It could include more regex advice including that which you ask for.

Outside of regex and the inappropriate use of [ ] in title (not recommended) I am not sure many would expose this issue. Perhaps a not can be added in the documentation on tiddlywiki.com. Just edit a tiddler to propose the change.

Regards

Tony

[Cd.K]

TonyM

Advanced Search with regexp:created and nested square brackets:

The solution is surprisingly simple and requires only a few changes in `$:/core/modules/filters.js` (see issue #4267).

Next step is to create the mod for the mod-loader plugin. As so often a link is missing in the description.  

Regards

Cd.K

[TonyM]

Cd.K

Thanks for sharing back. I expect the scheduled solution is the best however;

On returning I had a thought. Place this in a tiddler on tiddlywiki.com

Filter-Var: <$edit-text tiddler="$:/temp/filtervar" tag=input/><br>
Filter: <$edit-text tiddler="$:/temp/filter" tag=input/> can also use `<filter-var>`<br>
<$set name=filter-var value={{$:/temp/filtervar}}>
<$set name=filter value={{$:/temp/filter}}>
<$list filter={{$:/temp/filter}}>

</$list>
</$set>
</$set>

Then enter in filter-var

201909(0[1-9|1[0-5])

And in filter reference filter-var

[regexp:created<filter-var>]

Basically this make possible the introduction of a variable to the filter used in the search, as one has to do when using regex with square brackets in wikt text.

This could also be used to test the use of subfilters

Filter-var

title text modified modifier created creator tags type list caption

Filter

[fields[]!subfilter<filter-var>]

So I wonder if there was a way to allow the setting of a variable in the advanced search filter tab would be useful. It would only work if included in the filter.

Or alternatively use {$:/temp/filtervar} in the advanced search filter

[fields[]!subfilter{$:/temp/filtervar}]

Or in the original example

Enter in filter-var

201909(0[1-9|1[0-5])

And in advanced search filter reference filter-var tiddler

[regexp:created{$:/temp/filtervar}]

And there is yet another option:

in a tiddler tagged $:/tags/Macro

Place

\define varname() 201909(0[1-9|1[0-5])

and use <varname> in your advanced filter

[regexp:created<varname>]

I have tested all of the above and they work

Regards

Tony

[@TiddlyTweeter]

Ciao Cd. K

Regex is one of a few things in TW that I think are maybe "under potentiated". 

That is likely because I'm a very long term user of regex. And personally like its economy.

Though I'm NOT fully sure how many users have my enthusiasm for it, or knowledge of it.

But I think its very good, especially since you have skill with JS, to raise these issues and suggest solutions as at https://github.com/Jermolene/TiddlyWiki5/issues/4267.

I commented ...

https://github.com/Jermolene/TiddlyWiki5/issues/4267#issuecomment-534023115

&

https://github.com/CarpeDiemKopi/TiddlyWiki5/commit/14f03e085e97624c85ccea09eb852dcfb5182f3e#commitcomment-35190780

Best wishes

TT

[@TiddlyTweeter]

Ciao Cd.K & TonyM 

You may not be aware there is already a DIRECT way to use "[...]", without a variable in TW.

It emerged, I think, for the older field operator that is not, possibly, fully documented? 

I discovered what it can do by accident. 

I assume it still works that way for backwards compatibility.

Here is an example you can test in the latest online TiddlyWiki version Advanced Search ...

[field:created/^201909[2]/]

... equivalent to ...

[regexp:created[^201909(2)]]

or ...

[search:created:regexp[^201909(2)]]

Result for all three is ...

Best wishes

TT

[@TiddlyTweeter]

Ciao Tony M.

Excellent post opening up the variety of approaches!

I'll comment a bit later to try illustrate one of them in a bit more detail.

Best wishes

TT

[@TiddlyTweeter]

Cd.K & TonyM,

Further to my last on field operator ...

Actually these work too in Advanced Search: Filter.

[created/^201909[2]/]

[my-totally-nonexistent-operator:created/^201909[2]/]

lol!

Bug, or feature?

I have NOT tested if it functions in a "run" of operators.

TT

On Monday, 23 September 2019 12:40:15 UTC+2, @TiddlyTweeter wrote:

Ciao Cd.K & TonyM 

You may not be aware there is already a DIRECT way to use "[...]", without a variable in TW.

It emerged, I think, for the older field operator that is not, possibly, fully documented? 

I discovered what it can do by accident. 

I assume it still works that way for backwards compatibility.

Here is an example you can test in the latest online TiddlyWiki version Advanced Search ...

[field:created/^201909[2]/]

... equivalent to ...

[regexp:created[^201909(2)]]

Result for either ...

[@TiddlyTweeter]

This posted has been updated to cover three ways of using regular expressions to match in a field in the Advanced Search: Filter

TT

On Monday, 23 September 2019 12:40:15 UTC+2, @TiddlyTweeter wrote:

[Cd.K]

Ciao @TiddlyTweeter

see my new comment issue #4267.

The new solutions presented here recently are very interesting.

Regards

Cd.K

[Cd.K]

Ciao @TiddlyTweeter & TonyM

And now we should create a documentation or extend/revise the existing one.

Regards

Cd.K

[Cd.K]

TonyM

On Monday, September 23, 2019 at 6:48:18 AM UTC+2, TonyM wrote:

Filter-Var: <$edit-text tiddler="$:/temp/filtervar" tag=input/><br>
Filter: <$edit-text tiddler="$:/temp/filter" tag=input/> can also use `<filter-var>`<br>
<$set name=filter-var value={{$:/temp/filtervar}}>
<$set name=filter value={{$:/temp/filter}}>
<$list filter={{$:/temp/filter}}>

</$list>
</$set>
</$set>

That's awesome!

And it's the answer to my (sub-) question in this thread here above: How to use a variable in Advanced Search: How do I apply this hint in my case?

Do you think you could extend this approach in the following way?

- in a tiddler (e.g. titled: "automation task") with

- your Filter-Var & Filter code, optically separated in its own frame

- this frame/section contains in addition a button labled"execute/run"

- and you click the button

- to open the Advanced Search tiddler

- to jump to the tab/register "Filter"

- to insert `[fields[]!subfilter{$:/temp/filtervar}]`


- and as result the Advanced Search lists the matches 

Is something like this possible with WikiText?

Regards

Cd.K

[TonyM]

Cd.K

What you ask is possible, but I am not so sure if its the best way, in some ways you want to drive a special search and make it be used in the standard search?

Here are some tips that could lead to your suggested solution or a better one

• $:/core/ui/AdvancedSearch/Filter is the tiddler containing the filtered search

• In you look inside you notice

• The Search String is stored in 

  $:/temp/advancedsearch (Get a button to set this)
• $:/tags/Filter is used to store saved filters such as $:/core/Filters/RecentSystemTiddlers (Clone and Make your own)
  
• The Tag $:/tags/AdvancedSearch adds a tiddler to the advanced search menu

Or create a tiddler called "My Search" tag it with $:/tags/AdvancedSearch set the caption field to My Search

Filter-Var: <$edit-text tiddler="$:/temp/filtervar" tag=input/><br>
Filter: <$edit-text tiddler="$:/temp/filter" tag=input/> can also use `<filter-var>`<br>
<$set name=filter-var value={{$:/temp/filtervar}}>
<$set name=filter value={{$:/temp/filter}}>
<$list filter={{$:/temp/filter}}>


</$list>
</$set>
</$set>

This will appear as a tab in advanced search

However you can open this directly after setting the values you want, so in another tiddler create a button

This will set the values then open "My Search"

<$button to="My Search">
<$action-setfield $tiddler="$:/temp/filtervar" text="[is[current]fields[]]"/>
<$action-setfield $tiddler="$:/temp/filter" text="[fields[]!subfilter{$:/temp/filtervar}]"/>
Go
</$button>

Changes the text= values as needed

You can use 

{$:/temp/filtervar}
or
<filter-var>

in your filter

Regards

Tony

[Cd.K]

TonyM

I was able to implement the "." rule as a modification of the list rule. 

If I have understood it correctly, it is about the following functionality:

Without leading dots it would render to "line1 test hello".

I've enhanced `core\modules\parsers\wikiparser\rules\rules\list.js`and it renders:

But I think it's better to have a new rule `linebreak` that reacts on leading point or trailing 2 or more spaces. For each trigger I want to append a different style, because I use `<br/>` to reduce the line spacing.

I haven't quite figured out how to introduce a new rule yet and I haven't got any further with the mod-loader plugin.

Regards

Cd.K

On Saturday, September 21, 2019 at 3:52:36 AM UTC+2, TonyM wrote:

[TonyM]

Cd.K

Great work, do share (in time). I do not understand your used case for 

But I think it's better to have a new rule `linebreak` that reacts on leading point or trailing 2 or more spaces. For each trigger I want to append a different style, because I use `<br/>` to reduce the line spacing.

I was able to make a toolbar button to add period to selected lines but it seems to demand adding a space after the period, which is not a problem, just less impactful.

<$action-sendmessage $message="tm-edit-text-operation" $param="prefix-lines" character="." count="1" />

I would also like a button that removes the period.

Regards

Tony

[Mark S.]

Oh, wouldn't you like four ?

BTW, I think it's pretty amazing if /.../ works.

For the original use case at the top of the thread, you could make a global macro ($:/tags/Macro) with:

\define halfmonth() 201909(0[1-9]|1[0-5])

and then use this in the advanced search filter:

[regexp:create<halfmonth>]

You could obviously modify this "halfmonth" to just look for 01 thru 15, and then use a regexp preceding it to look for the year and month. So you could use it throughout the year.

[@TiddlyTweeter]

Mark S. wrote:

Oh, wouldn't you like four ?

Lol!! I would. And I know they exist. But patience in working out what is going on in variants is a virtue too :-). They differ somewhat.

 

BTW, I think it's pretty amazing if /.../ works.

It does for the Field Operator.

I'll write later in another thread (not wanting to hijack this one) on some of the variants.

UPDATE: link to examples https://groups.google.com/d/msg/tiddlywiki/l-OSoKg4j4E/MMJenY3WCAAJ

TT

[@TiddlyTweeter]

Cd. K

What you looking for is HOW to define a NEW independent parser for the scenario? And integrate it in standard TW? Yes?

Cd, K

But I think it's better to have a new rule `linebreak` that reacts on leading point or trailing 2 or more spaces. For each trigger I want to append a different style, because I use `<br/>` to reduce the line spacing.

I haven't quite figured out how to introduce a new rule yet and I haven't got any further with the mod-loader plugin. 

This is something that a worked through example would help a lot of people a lot. 

I do NOT think its ever been publicly done yet.

Best wishes

TT

[@TiddlyTweeter]

Updated post for email users ...

[Cd.K]

TonyM

First of all:

/*\
title: $:/core/modules/parsers/wikiparser/rules/list.js
type: application/javascript
module-type: wikirule

Wiki text block rule for lists. For example:

```
* This is an unordered list
* It has two items

# This is a numbered list
## With a subitem
# And a third item

; This is a term that is being defined
: This is the definition of that term
```

Note that lists can be nested arbitrarily:

```
#** One
#* Two
#** Three
#**** Four
#**# Five
#**## Six
## Seven
### Eight
## Nine
```

A CSS class can be applied to a list item as follows:

```
* List item one
*.active List item two has the class `active`
* List item three
```

\*/
(function(){

/*jslint node: true, browser: true */
/*global $tw: false */
"use strict";

exports.name = "list";
exports.types = {block: true};

exports.init = function(parser) {
    this.parser = parser;
    // Regexp to match
    this.matchRegExp = /([\*#;:>\.]+)|([ ]{2,}$)/mg; // Cd.K dot, double blank
};

var listTypes = {
    "*": {listTag: "ul", itemTag: "li"},
    "#": {listTag: "ol", itemTag: "li"},
    ";": {listTag: "dl", itemTag: "dt"},
    ":": {listTag: "dl", itemTag: "dd"},
    ">": {listTag: "blockquote", itemTag: "p"},
    ".": {listTag: "p", itemTag: "p"}, // Cd.K dot
    " ": {listTag: "p", itemTag: "p"} // Cd.K blank
};

/*
Parse the most recent match
*/
exports.parse = function() {
    // Array of parse tree nodes for the previous row of the list
    var listStack = [];
    // Cycle through the items in the list
    while(true) {
        // Match the list marker
        var reMatch = /([\*#;:>\.]+)|([ ]{2,}$)/mg; // Cd.K dot, double blank
        reMatch.lastIndex = this.parser.pos;
        var match = reMatch.exec(this.parser.source);
        if(!match || match.index !== this.parser.pos) {
            break;
        }
        // Check whether the list type of the top level matches
        var listInfo = listTypes[match[0].charAt(0)];
        // Cd.K
        if (match[0].charAt(0) == ".") {
            console.log("Cd.K wikparser/rules/list.js 87 found leading '.' case")
        }
        if (match[0].charAt(0) == " ") {
            console.log("Cd.K wikparser/rules/list.js 90 found trailing blank case")
        }
        if(listStack.length > 0 && listStack[0].tag !== listInfo.listTag) {
            break;
        }
        // Move past the list marker
        this.parser.pos = match.index + match[0].length;
        // Walk through the list markers for the current row
        for(var t=0; t<match[0].length; t++) {
            listInfo = listTypes[match[0].charAt(t)];
            // Remove any stacked up element if we can't re-use it because the list type doesn't match
            if(listStack.length > t && listStack[t].tag !== listInfo.listTag) {
                listStack.splice(t,listStack.length - t);
            }
            // Construct the list element or reuse the previous one at this level
            if(listStack.length <= t) {
                var listElement = {type: "element", tag: listInfo.listTag, children: [
                    {type: "element", tag: listInfo.itemTag, children: []}
                ]};
                // Link this list element into the last child item of the parent list item
                if(t) {
                    var prevListItem = listStack[t-1].children[listStack[t-1].children.length-1];
                    prevListItem.children.push(listElement);
                }
                // Save this element in the stack
                listStack[t] = listElement;
            } else if(t === (match[0].length - 1)) {
                listStack[t].children.push({type: "element", tag: listInfo.itemTag, children: []});
            }
        }
        if(listStack.length > match[0].length) {
            listStack.splice(match[0].length,listStack.length - match[0].length);
        }
        // Process the body of the list item into the last list item
        var lastListChildren = listStack[listStack.length-1].children,
            lastListItem = lastListChildren[lastListChildren.length-1],
            classes = this.parser.parseClasses();
        this.parser.skipWhitespace({treatNewlinesAsNonWhitespace: true});
        var tree = this.parser.parseInlineRun(/(\r?\n)/mg);
        lastListItem.children.push.apply(lastListItem.children,tree);
        if(classes.length > 0) {
            $tw.utils.addClassToParseTreeNode(lastListItem,classes.join(" "));
        }
        // Consume any whitespace following the list item
        this.parser.skipWhitespace();
    }
    // Return the root element of the list
    return [listStack[0]];
};

})();

I marked all my modifications with `Cd.K`.

I am now in the process of turning these changes above into a plugin named "linebreak".

My use case:

I write flow text and want to insert a line break inside the paragraph at the cursor position. With my modification, I just need to insert blank blank Enter instead of <br/> Enter.

To make or delete leading points:

You can use the TiddlyWiki CodeMirror Editor plugin. This editor has a column mode, so you can select the column before your text with alt + mouse dragging.

vertical or block selection in codemirror 

Regards

Cd.K

On Wednesday, September 25, 2019 at 2:20:57 AM UTC+2, TonyM wrote:

Cd.K

[TonyM]

CdK

Thanks so much for that. I will test today. I started to modify this tiddler myself in an attempt to achieve this but did not succeed.

I am keen to test your trailing blank idea. I presume this means a space just before a line break. Or a space at the end of a paragraph results in a forced line break?

With a working example perhaps we can put an argument to include it in the standard distribution even if they were rules that are off by default.

Regards
Tony

[@TiddlyTweeter]

TonyM wrote:

CdK

Thanks so much for that. I will test today. I started to modify this tiddler myself in an attempt to achieve this but did not succeed.

I am keen to test your trailing blank idea. I presume this means a space just before a line break. Or a space at the end of a paragraph results in a forced line break?

But WHY? Help me understand that because I cannot see the reason for adding end spaces. Isn't a break enough? What is the advantage of adding end spaces?

 

With a working example perhaps we can put an argument to include it in the standard distribution even if they were rules that are off by default.

Unlikely. 

What is interesting here is opening up parser editing. That is graet if we could see how to do that better.

 

TT

[Cd.K]

TonyM,  @TiddlyTweeter: second paragraph

I'm about to finish the whole plugin. There's only one little thing left to do with the mod-Loader plugin, but tomorrow I'll probably make it.

I created an issue here: #23, but I think I'll can manage it by myself tomorrow.

In the process of writing it is much easier to type two blanks than <br/>. And you will see nothing. The two blanks will be replaced by <br/> inside the paragraph.

Regards

Cd.K

On Thursday, September 26,

[coda coder]

Leading period = ok

Trailing space-space = bad.

Reasoning: When copy-pasting external text, now I have to police the text at the character level to watch for innocent sloppy spaces which will "break" the flow. HTML deals with sloppy spaces itself - something that's been around for what... >25 years? This idea breaks that.

[TonyM]

TT,

But WHY? Help me understand that because I cannot see the reason for adding end spaces. Isn't a break enough? What is the advantage of adding end spaces?

Ask Cd.K This is his desire, I too want to understand his motivation.

 

 

With a working example perhaps we can put an argument to include it in the standard distribution even if they were rules that are off by default.

Unlikely. 

At least with my desired leading period, wikitext markup change is serves a very valuable service. It helps when note taking and also when improving text which has being imported. It is an extension of ";" and ":" which I use every day. basically it is the equivalent of ";" without bold which makes it a header. It is effectively an auto wrap line with html P tag - or paragraph. It ensures a line break between paragraphs without needing to placing two BR tags at the end of every paragraph. And multiple empty lines will collapse into one, clearing surplus line breaks (Common in text pasting.

I find it hard to think markup that permits the use of a very basic html structure such as the paragraph would not be invaluable.

It is unlikely to have a high overhead, and if Popular will I believe be one of the first things many activate given the common complaint about needing extra line breaks to separate paragraphs lots of new users make.

On one hand - I only stated a "perhaps", if the solution we propose is popular, as I expect it will be for, me at least. On the other hand  if "on opening up parser editing" becomes a dial on demand option" it need not be provided in the standard distribution unless by popular demand.

Regards

Tony

[TonyM]

Coda Coda,

Both leading Period, and trailing spaces are proposed as an optional parser rule for people who want it. My experience is when copying text you are more likely to come across sloppy line feeds than a double space at the end, in fact in a lot of copy situations leading and trailing spaces can be "removed" against your will.

The leading period wrapping a line in html p tags is actually leveraging html's break handling not fighting against it.

Regards

Tony

[Cd.K]

TonyM

I have attached a mod tiddler with the point rule.

You take an empty TiddlyWiki, install the Mod-Loader Plugin, follow the instructions, import the mod tiddler, reload the TiddlyWiki to activate the mod and it will work.

But only the point rule and not the blanks rule.

I have found an error in the "Mod-Loader Plugin", so I can't publish a draggable plugin currently yet.

I have noticed that 5.1.21 pre-release handles empty trailing periods differently than my 5.1.19 TiddlyWiki:

Test case:

.test
.test
.test
.test

5.1.19 

.test .test .test .test

5.1.21

testtesttesttest

That's weird, isn't it?

And I come up with the case of a trailing period alone in a line. Should this render a blank line, i.e. a paragraph?

Regards

Cd.K

[TonyM]

CdK,

I love the operation of the leading period on a 5.1.20 Scratch wiki but I am not so happy with some of the changes the mod loader added. Big link icons on every tab, can't set fluid story.

Unless there is a clash in my wiki there has to be a better way to distribute your patch?

5.1.22-prerelease is doing the same as your 5.1.19 example ".text .text" - this is with nothing loaded ie no modloader patch?

Thanks so much, nice job

This results in two nice separate paragraphs and all it took was 1 leading period

.Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Pellentesque dignissim enim sit amet venenatis urna cursus eget. Eu tincidunt tortor aliquam nulla. Sapien pellentesque habitant morbi tristique senectus et netus et. Dignissim sodales ut eu sem integer vitae justo eget magna. Ut enim blandit volutpat maecenas. Bibendum neque egestas congue quisque. Proin fermentum leo vel orci porta non. Congue quisque egestas diam in. Magna eget est lorem ipsum dolor sit amet consectetur. Pellentesque habitant morbi tristique senectus et. Ipsum suspendisse ultrices gravida dictum fusce. Volutpat odio facilisis mauris sit. Cursus euismod quis viverra nibh cras pulvinar mattis nunc. Nec sagittis aliquam malesuada bibendum arcu vitae elementum curabitur. Dui id ornare arcu odio. Libero id faucibus nisl tincidunt. Mattis nunc sed blandit libero volutpat sed cras ornare.
Dui vivamus arcu felis bibendum. Fames ac turpis egestas maecenas. Mauris in aliquam sem fringilla ut morbi tincidunt augue interdum. Laoreet non curabitur gravida arcu ac tortor dignissim. Enim diam vulputate ut pharetra sit. Diam maecenas ultricies mi eget mauris pharetra et ultrices neque. Eu turpis egestas pretium aenean. Risus in hendrerit gravida rutrum. A erat nam at lectus urna. Enim lobortis scelerisque fermentum dui. At ultrices mi tempus imperdiet nulla malesuada pellentesque elit eget. In ante metus dictum at tempor commodo ullamcorper. Orci dapibus ultrices in iaculis nunc. Tellus elementum sagittis vitae et. Vel pretium lectus quam id. Dictum varius duis at consectetur lorem donec. Porttitor rhoncus dolor purus non enim praesent elementum.

[Cd.K]

TonyM

I love the operation of the leading period on a 5.1.20 Scratch wiki but I am not so happy with some of the changes the mod loader added. Big link icons on every tab, can't set fluid story.

This happens without my mod, only the mod-loader plugin added? If it can't come from my modification, please create an issue here: issue git mod-loader plugin .

Unless there is a clash in my wiki there has to be a better way to distribute your patch?

Work in progress.

5.1.22-prerelease is doing the same as your 5.1.19 example ".text .text" - this is with nothing loaded ie no modloader patch?

See my tested configuration:

Regards

Cd.K

[Cd.K]

TonyM

I discovered the following error in the period rule:

.test
test
test
.test

renders as

test

test test .test

expected:

test


test test


test

Do you agree?

Regards

Cd.K

On Friday, September 27, 2019 at 8:40:16 AM UTC+2, TonyM wrote:

[TonyM]

CdK

Yes that is happening and this is what we would expect. If rather than use period, I do this myself we get the expected result.

<p>test</p>
test
test
<p>test</p>

I assume your fix is only adding the paragraph tags?

If I use the developer tools inspect I see this in the erroneous results

<p>  
  <p>test</p>
</p>
<p>test test .test</p>

I think what is happening is a result of the Wiki text and html see here https://tiddlywiki.com/#HTML%20in%20WikiText

Block mode versus Inline mode

To get the content of an HTML element to be parsed in block mode, the opening tag must be followed by two linebreaks.

Without the two linebreaks, the tag content will be parsed in inline mode which means that block mode formatting such as wikitext tables, lists and headings is not recognised.

If you alter our test case as follows it behaves as expected.

.test
test
test

.test

Perhaps we need to force block mode

This demonstrates what I mean

.test
test
test
.test
<hr>
<p style="display: block">test</p>
test
test
<p style="display: block">test</p>

So in support of this and as an extension I suggested earlier we could use a class 

<style>
.parra {display: block}
</style>

<p class="parra">test</p>
test
test
<p class="parra">test</p>

Of course the style would be in a stylesheet.

And the designer could change the way our "period" paragraphs are styled.

Additional reference https://www.w3schools.com/css/css_inline-block.asp

Regards

Tony

[coda coder]

Tony,

A p-element is already styled display:block automatically. Constructing a style attribute or a class with display:block to be applied to a p-element is redundant (i.e. it does nothing).

Using your reference site, check for P here: https://www.w3schools.com/cssref/css_default_values.asp

[TonyM]

Perhaps my reasoning was wrong but my fix awas correct.

This works as expected

<style>
.parra {display: block}
</style>

<p class="parra">test</p>
test
test
<p class="parra">test</p>

[@TiddlyTweeter]

Ciao TonyM & Cd.K

This thread has been very interesting!

I think something that is too muted in it is the RELATION between any new parser rule you add and what the existing parsers do with any "residue"--text between text you marking-up.

I think some of the confusion/complications about the behaviour of <p> arise from this. 

Longer term more detailed understanding of the order in render and the role of parsers in this may help clarify the issue.

Just MHO

TT

[coda coder]

On Saturday, September 28, 2019 at 1:56:01 AM UTC-5, TonyM wrote:

Perhaps my reasoning was wrong but my fix awas correct.

This works as expected

<style>
.parra {display: block}
</style>

<p class="parra">test</p>
test
test
<p class="parra">test</p>

So does this - try it on tiddlywiki.com

<style>
.parra {display: block}
</style>

<p class="parra">test</p>
test
test
<p class="parra">test</p>

<p class="Xparra">test</p>
test
test
<p class="Xparra">test</p>

[@TiddlyTweeter]

Coda & TonyM

Interested ... What happens to bits in pale violet ...?

<p>test</p>
test
test
<p>test</p>

... in render??

TT

[Cd.K]

 @TiddlyTweeter wrote

 

I think something that is too muted in ... is the RELATION between any new parser rule you add and what the existing parsers do with any "residue"--text between text you marking-up.

  

For this reason I want to capsulate the period- and blanks-rule in a separate linebreak parser module. At the moment it is an extension of the list parser.
 

Regards

Cd.K

 

[coda coder]

On Saturday, September 28, 2019 at 9:15:11 AM UTC-5, @TiddlyTweeter wrote:

Coda & TonyM

Interested ... What happens to bits in pale violet ...?

<p>test</p>
test
test
<p>test</p>

[@TiddlyTweeter]

VERY interesting.

How does that LOOK on Boogie Street?

https://www.youtube.com/watch?v=_MAvo5ztmJ4

TT

[Cd.K]

coda coder wrote

 

... innocent sloppy spaces which will "break" the flow. HTML deals with sloppy spaces itself - something that's been around for what... >25 years? This idea breaks that.

 

Have you ever heard of DARING FIREBALL Markdown?

Because I'm following the official Markdown syntax reference page from the creator of the markdown language: John Gruber (DARING FIREBALL). According to this Wikipedia Markdown page, it was first specified with version 1.0.1 in 2004.

The detail that interests us here can be found under `Syntax`, `Block Elements`, `Paragraphs and Line Breaks` in the 3rd paragraph,  see the following excerpt - especially my cursor:

And in HTML there is a tag to preserve white spaces: <pre> ... </pre>

<pre>Text in a pre element
is displayed in a fixed-width
font, and it preserves
both      spaces and
line breaks</pre>

(w3schools.com)

coda coder wrote

 

 Reasoning: When copy-pasting external text, now I have to police the text at the character level to watch for ...

 

Which objects do you use in Jermolene/TiddlyWiki5 for your policing?

I'm trying to find the location in TiddlyWiki where the white spaces characters are removed from the <pre> tag. This happens before parsing. I found this while debugging so far: `$tw.Wiki.prototype.deserializeTiddlers`.


But even here one space is missing. But this space is definitely present in the HTML file and also in the tiddler in edit mode.

Either e does not contain the correct DOM node here, namely the pre-tag, or it happens even earlier in the code.

Can you help me out here too?

Regards

Cd.K

[coda coder]

On Saturday, September 28, 2019 at 4:26:24 PM UTC-5, Cd.K wrote:

coda coder wrote

... innocent sloppy spaces which will "break" the flow. HTML deals with sloppy spaces itself - something that's been around for what... >25 years? This idea breaks that.

 

Have you ever heard of DARING FIREBALL Markdown?

No.

I think you think I didn't understand? I do understand your proposition. The leading-period I *like*. The trailing space-space I don't like so much (for the reasons I gave).

And in HTML there is a tag to preserve white spaces: <pre> ... </pre>

<pre>Text in a pre element
is displayed in a fixed-width
font, and it preserves
both      spaces and
line breaks</pre>

(w3schools.com)

You might also want to try this css interactive demo: https://developer.mozilla.org/en-US/docs/Web/CSS/white-space

 

coda coder wrote

 

 Reasoning: When copy-pasting external text, now I have to police the text at the character level to watch for

 

Which objects do you use in Jermolene/TiddlyWiki5 for your policing?

My eyes. My cursor. Looking for space-space that (if your proposal were adopted) would mess up my pasted external text. Admittedly, if it were a 'mode" of some kind, I could choose not to use it, of course. But really, I was just pointing out a potential downside. There's nothing intrinsically "wrong" with it.

I'm trying to find the location in TiddlyWiki where the white spaces characters are removed from the <pre> tag. This happens before parsing. I found this while debugging so far: `$tw.Wiki.prototype.deserializeTiddlers`.


But even here one space is missing. But this space is definitely present in the html file and also in the tiddler in edit mode.

Can you help me out here too?

Sorry, I know nothing about tw internals or its implementation details. Maybe "one day", when I have time ;)

[Cd.K]

coda coder wrote

 

... (if your proposal were adopted) would mess up my pasted external text ....

 

 

Thanks for your answer.

It's just a plugin and doesn't worry, I plan to use separately on/off mode switches for the period- and blanks-rule in the plugin.

It would even be thinkable to switch these rules on or off after a tag or a field in the respective tiddler.

And my plugin could also be extended to take over your police work and remove innocent sloppy spaces before a line break. That would be another rule, also configurable.

Should I include this feature?

Regards

Cd.K 

[TonyM]

Just to keep thing a little clearer. Typing into a text field it is easy to use ; and : and now the complimentary . as you type to define headings indents an paragraphs. If I have a large block of imported text zi often wrap in triple quotes """

however adding these leading characters is quick and easy. Testing also shows an edit toolbar button that prefixes every line produces a nice out put. Ensuring paragraphs are clear and line breaks / empty lines collapse.

Regards
Tony

[Mohammad]

Hi Tony,

The title of this thread is misleading!

I would recommend to start a new thread on period case!

--Mohammad

[TonyM]

We did wander.

I will open a new thread with the help of CdK when back at a desktop. Thanks
Tony

[Mohammad]

Thanks Tony!

I think the discussion if fruitful and it worth to have a dedicated thread for later reference!

--Mohammad

[Cd.K]

Hi TonyM,

I'm back.

Regards

Cd.K

[Cd.K]

TonyM

Enough for today.

I'm finally getting on with the blanks-rule. I stumbled across a bug in the firefox debugger that cost me a lot of time.

But my understanding of the inner workings of TiddlyWiki has grown.

Regards

Cd.K