Better always use triple quotes around filters?

[Mat]

The quotation marks in a tiddler title caused a filter to freak out. (Or is that perhaps the listwidget freaking out?) It was solved by encapsulating the filter in triple quotes like so:

<$list filter="""[...]""">

This makes me wonder if it's not best to simply always use triple quotes instead of single ones?

...and, if "yes", then couldn't the code behind the filter (-widget? or what are actually filters?) simply use this as default?

Thanx

<:-)

[Jeremy Ruston]

Hi Mat

The quotation marks in a tiddler title caused a filter to freak out. (Or is that perhaps the listwidget freaking out?)

It's the parsing of the attribute value that freaks out due to the ambiguity of whether the embedded double quote is part of the attribute value, or marks the end of it.

It was solved by encapsulating the filter in triple quotes like so:

<$list filter="""[...]""">

This makes me wonder if it's not best to simply always use triple quotes instead of single ones?

I generally only use triple double quotes when necessary so as to save typing.

...and, if "yes", then couldn't the code behind the filter (-widget? or what are actually filters?) simply use this as default?

What would that mean? If the default were triple double quotes how would that stop a user trying to use single double quotes like ordinary HTML?

Best wishes

Jeremy

Thanx

<:-)

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/274b54df-c95c-4dc7-99fc-889b789b302a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mat]

Thanks for reply Jeremy,

I generally only use triple double quotes when necessary so as to save typing.

Ok so I then take it that always works with triple even if it is often superfluous.

...and, if "yes", then couldn't the code behind the filter (-widget? or what are actually filters?) simply use this as default?

What would that mean? If the default were triple double quotes how would that stop a user trying to use single double quotes like ordinary HTML?

I mean if the code implementing the argument, presumably some TW js code for filters, always wraps the argument in extra quotations - then user would never have to bother with the issue of potentially missing quotes and can always use a single pair. No?

<:-)

[Jeremy Ruston]

Hi Mat

...and, if "yes", then couldn't the code behind the filter (-widget? or what are actually filters?) simply use this as default?

What would that mean? If the default were triple double quotes how would that stop a user trying to use single double quotes like ordinary HTML?

I mean if the code implementing the argument, presumably some TW js code for filters, always wraps the argument in extra quotations - then user would never have to bother with the issue of potentially missing quotes and can always use a single pair. No?

But the code that parses the filters doesn’t get the opportunity to wrap the argument in extra double quotes; it’s up to the user to decide how many double quotes they type. Or am I missing what you mean?

Best wishes

Jeremy

<:-)

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/bf402533-1db6-4aa8-85b1-d3095ba8d1b5%40googlegroups.com.

[Mat]

But the code that parses the filters doesn’t get the opportunity to wrap the argument in extra double quotes;

Obviously, you 'da expert here, but with my naive understanding; can't some intermediary code simply append+prepend quote characters to the whole filter before it reaches whatever code it is that parses the filter...?

<:-)

[PMario]

On Tuesday, April 12, 2016 at 12:12:39 PM UTC+2, Mat wrote:

But the code that parses the filters doesn’t get the opportunity to wrap the argument in extra double quotes;

Obviously, you 'da expert here, but with my naive understanding; can't some intermediary code simply append+prepend quote characters to the whole filter before it reaches whatever code it is that parses the filter...?

IMO not really. To do that, it would mean, that you need to parse it first, to know where you need to append the additional quotes. ... But that's the exact same problem, that existing parser has.
-m

[Mat]

PMario wrote:

IMO not really. To do that, it would mean, that you need to parse it first, to know where you need to append the additional quotes. ... But that's the exact same problem, that existing parser has.

How actually does the parser go about things? Does it go rigidly and linearly from left to right? Or does it first look up html start and end tags and then evaluate the expression within these? And for TW specfics, does the parser know where the start and end is of the widget (typically a ListWidget or SetWidget) before it knows where the start and end is for the filter?

<:-)

[Jeremy Ruston]

Hi Mat

How actually does the parser go about things? Does it go rigidly and linearly from left to right? Or does it first look up html start and end tags and then evaluate the expression within these? And for TW specfics, does the parser know where the start and end is of the widget (typically a ListWidget or SetWidget) before it knows where the start and end is for the filter?

This thread is speculating on ways to improve the parsing behaviour of the system. There’s certainly scope for improvements, but I think you'd really need to understand the code itself in order to understand the impact of changes you’re exploring. Working with a metaphorical description of how the parser works won’t be sufficient to make meaningful proposals.

Anyhow, the wikitext parser is pretty simple. Each “parse rule” requires it to look out for a certain pattern; for example, the pattern for the start of a widget might be `<$`. When the parser spots such a pattern it then checks the following characters to see if they match the full rule. For widgets, that means that it looks for the widget name, optional attributes and the closing `>`. It looks for the attributes without regard for the content of the attribute strings; it’s just looking for a sequence of letters/digits, an equals signs, an opening quote, the attribute content, and a closing quote. It’s only later that the content of the attribute might be parsed as a filter.

Best wishes

Jeremy.

<:-)

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/071e9675-600f-495d-af6f-92c701199c37%40googlegroups.com.

[Mat]

Jeremy, thanks for input
 

[...]you'd really need to understand the code itself in order to understand the impact of changes you’re exploring.

You're right. I'll just post the following and then not more on the matter. No need to reply if my reasoning is just totally off (quote possible).

Anyhow, the wikitext parser is pretty simple. Each “parse rule” requires it to look out for a certain pattern; for example, the pattern for the start of a widget might be `<$`. When the parser spots such a pattern it then checks the following characters to see if they match the full rule. For widgets, that means that it looks for the widget name, optional attributes and the closing `>`. It looks for the attributes without regard for the content of the attribute strings; it’s just looking for a sequence of letters/digits, an equals signs, an opening quote, the attribute content, and a closing quote. It’s only later that the content of the attribute might be parsed as a filter.

This is what I hoping for and as far as I can tell, it even omits the need for triple quotes as long as one can identify exactly what is the end of the filter attribute. I.e, if I understand, the filter start is merely to identify this string, right? -

 filter="

But I figure the end quotemark of the filter can be identified by taking advantage of string-segments from the other attributes, like so;

*" />
*" >
*" variable=
*" emptyMessage=
...and some more

Or mabe even pattern search the "widget string" backwards to not deal with the filter content at all and again look for a single quotation mark but that doesn't belong to any of the other attributes. I mean, those other attributes typically have friendly arguments without interfering quote marks so skipping past these woudl be easy... and if - in this backward search - every secont quotemark should be followed by an equal sign and an attribute name or that second quotemark is not the one.

Ok, that was all. It would just save time and repeated trouble if users don't hvae to deal with this. If my understanding is just off, then... well, I'll be back eventually with more understanding.

<:-)

[Jeremy Ruston]

Hi Mat

This is what I hoping for and as far as I can tell, it even omits the need for triple quotes as long as one can identify exactly what is the end of the filter attribute. I.e, if I understand, the filter start is merely to identify this string, right? -

 filter="

But I figure the end quotemark of the filter can be identified by taking advantage of string-segments from the other attributes, like so;

*" />
*" >
*" variable=
*" emptyMessage=
...and some more

The syntax could be defined in that way, but it would be an unusual approach; the closing quote is sufficient to mark the end of the attribute, so there’s generally no need for checking the additional characters.

Or mabe even pattern search the "widget string" backwards to not deal with the filter content at all and again look for a single quotation mark but that doesn't belong to any of the other attributes. I mean, those other attributes typically have friendly arguments without interfering quote marks so skipping past these woudl be easy... and if - in this backward search - every secont quotemark should be followed by an equal sign and an attribute name or that second quotemark is not the one.

The trouble with “clever” parsers that try to save the user from typos is that they end up introducing even more complex rules, and there will be occasions where the user has to have those rules in their head. One sees the same thing over and again in languages like XML/JSON, wikitext, markup like HTML: the principle is to have simple syntax rules that lead to predictable results.

Ok, that was all. It would just save time and repeated trouble if users don't hvae to deal with this. If my understanding is just off, then... well, I'll be back eventually with more understanding.

If you’re really interested in this stuff you’ll have to become a coder (as FND did before you); I’m sure you’ll find it pretty easy after the intricacies of your work with TW,

Best wishes

Jeremy.

<:-)

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/6b152a0f-c748-4ef4-9bcc-595bc946ee57%40googlegroups.com.

[Mat]

[...] the closing quote is sufficient to mark the end of the attribute [...] the principle is to have simple syntax rules that lead to predictable results.

Well, my whole point is that that a single closing quote is not sufficient to keep the syntax rules simple for the user. But the code is clearer of course :-)

 

If you’re really interested in this stuff you’ll have to become a coder (as FND did before you); I’m sure you’ll find it pretty easy after the intricacies of your work with TW,

Happy to say I'm actually in the process!  My TW background definitely gives an edge... but I dunno about "pretty easy"... ;-)

Thanks for your input Jeremy.

<:-)