[TWX] only textreferences to target

[Mat]

[An idea for TWX, i.e an imaginary future remake of TW]

1) Widgets would not have to use field parameters if the tiddler parameter is always a textreference. 

2) If the ## syntax is not used for indices then it could instead be used in textreferences for links internal in the tiddler, to harmonize with the recent discovery that ## can be used for such tiddler-internal links.

I think this means that any part of a tiddler could be designed to be addressable. Even in the url.

<:-)

[Jeremy Ruston]

Hi Mat

1) Widgets would not have to use field parameters if the tiddler parameter is always a textreference. 

The trouble with that is that it makes it impossible to reference a tiddler that has “!!” in its title. We try to use text references in shortcut syntaxes but now prefer separate title/field/index attributes for widgets.

2) If the ## syntax is not used for indices then it could instead be used in textreferences for links internal in the tiddler, to harmonize with the recent discovery that ## can be used for such tiddler-internal links.

The ## used for data tiddler indices is only valid within a text reference. Otherwise it would clash with the use of # for numbered lists.

I think this means that any part of a tiddler could be designed to be addressable. Even in the url.

Ah, are you suggesting that {{HelloThere##mylink}} should return the text of the anchor labelled “mylink”? The problem with that is that you probably don’t want the text of the anchor (because there often won’t be any), you’ll probably want the text from the link up to some landmark (e.g. the next heading). That kind of thing is far too complex to be a low level primitive.

Best wishes

Jeremy.

<:-)

--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikide...@googlegroups.com.
To post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/72b6bad6-813d-4c1d-92c8-fa697053df13%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mat]

Jeremy, thanks for input.

When I use the TWX disclaimer I typically assume a substantial remake like TWC --> TW5, exactly to avoid the limits of the current TW implementation.

We try to use text references in shortcut syntaxes but now prefer separate title/field/index attributes for widgets.

Is this a real preference or a compromise? Are separate attributes better than to have one textreference? We do, after all, use the compact textreference format sometimes in current TW. The point with my proposal was to avoid unnecessary parameters when possible. I also think there is a nice aesthetic, and an opportunity, to treat textreferences as a gradually more fine grained address. A kind of name space.

 

The ## used for data tiddler indices is only valid within a text reference. Otherwise it would clash with the use of # for numbered lists.

So, both the fact that browsers apparently force us to use ##, at least atm, and that TWX ought to feature hashtagging speaks for coming up with something else for numbered lists. 

Side note: One idea could be to use asterisks (*) for all those typed kinds of lists of lists, but specify how it should appear e.g in the first element. I think bullet lists are under used, and we can do much more with them (eg , eg), particularly considering the role lists play in TW.

I think this means that any part of a tiddler could be designed to be addressable. Even in the url.

Ah, are you suggesting that {{HelloThere##mylink}} should return the text of the anchor labelled “mylink”? The problem with that is that you probably don’t want the text of the anchor (because there often won’t be any), you’ll probably want the text from the link up to some landmark (e.g. the next heading). That kind of thing is far too complex to be a low level primitive.

But, we're already doing that with tiddlers (by providing the title), and fields and indices - ??? Why could we not (hypothetically) do it with segments marked out by arbitrarily placed markers? It would be a kind of encapsulation. Other than to use it as an address for navigation, it could be used for styling (I guess, basically converting it to div tags). A more tiddleresque idea is to use it for "auto-excision"to automatically split out such segments that evidently deserve to be separate tiddlers.

(Side note: I read somewhere that browsers will soon introduce something so that you can give an url to a specific point on a webpage.)

<:-)

[Jeremy Ruston]

Hi May

We try to use text references in shortcut syntaxes but now prefer separate title/field/index attributes for widgets.

Is this a real preference or a compromise? Are separate attributes better than to have one textreference?

Yes, because of the point I made above: if an attribute specifies a text reference then it is impossible to refer to a tiddler with !! or ## in its title. That might not matter for end users, but for TW5 itself its a deal-breaker: we really don’t want to have the situation where typing certain characters into a tiddler title causes other things to fail.

We do, after all, use the compact textreference format sometimes in current TW.

Yes, this is a matter of layering:

Top: shortcut syntax

Middle: macros

Bottom: widgets

We have text references at the top layer because they are, after all, a convenient shortcut. But they don’t belong at the bottom layer. As you say, we do have old widgets that accept text references as an attribute but we now offer separate tiddler/field/index attributes alongside.

The point with my proposal was to avoid unnecessary parameters when possible. I also think there is a nice aesthetic, and an opportunity, to treat textreferences as a gradually more fine grained address. A kind of name space.

The shortcomings of text references mean that they are not universal, they can only be a shortcut.

The ## used for data tiddler indices is only valid within a text reference. Otherwise it would clash with the use of # for numbered lists.

So, both the fact that browsers apparently force us to use ##, at least atm,

(It’s not browsers that do that, it’s TW5 that requires the second # — see https://github.com/Jermolene/TiddlyWiki5/issues/3811

and that TWX ought to feature hashtagging speaks for coming up with something else for numbered lists. 

Side note: One idea could be to use asterisks (*) for all those typed kinds of lists of lists, but specify how it should appear e.g in the first element. I think bullet lists are under used, and we can do much more with them (eg , eg), particularly considering the role lists play in TW.

The plan for TWX is that anyone will be able to add/change their own wikitext rules, without using JS.

I think this means that any part of a tiddler could be designed to be addressable. Even in the url.

Ah, are you suggesting that {{HelloThere##mylink}} should return the text of the anchor labelled “mylink”? The problem with that is that you probably don’t want the text of the anchor (because there often won’t be any), you’ll probably want the text from the link up to some landmark (e.g. the next heading). That kind of thing is far too complex to be a low level primitive.

But, we're already doing that with tiddlers (by providing the title), and fields and indices - ???

Because they are directly addressable, while pulling out an anchor requires parsing the text (which is slow).

Why could we not (hypothetically) do it with segments marked out by arbitrarily placed markers? It would be a kind of encapsulation. Other than to use it as an address for navigation, it could be used for styling (I guess, basically converting it to div tags). A more tiddleresque idea is to use it for "auto-excision"to automatically split out such segments that evidently deserve to be separate tiddlers.

Plus there’s the issue I mentioned above that link anchors identify a location within a document, they do not define a run of text.

(Side note: I read somewhere that browsers will soon introduce something so that you can give an url to a specific point on a webpage.)

Every anchor already has a URL. I believe the new proposal is for addressing DOM elements that don’t have an anchor.

Best wishes

Jeremy.

<:-)

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

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/37c39f26-48c4-41c5-981a-56b07944a8bd%40googlegroups.com.

[Mat]

(Side note: I read somewhere that browsers will soon introduce something so that you can give an url to a specific point on a webpage.)

Every anchor already has a URL. I believe the new proposal is for addressing DOM elements that don’t have an anchor.

Without parsing? Might this then be the very thing that would enable what I'm talking about? A thing that does identify the run of a text and is on a low enough level?

Thank you for your replies. Interesting matters.

<:-)

[Jeremy Ruston]

Hi Mat

On 13 Jun 2019, at 21:12, Mat <matia...@gmail.com> wrote:

(Side note: I read somewhere that browsers will soon introduce something so that you can give an url to a specific point on a webpage.)

Every anchor already has a URL. I believe the new proposal is for addressing DOM elements that don’t have an anchor.

Without parsing? Might this then be the very thing that would enable what I'm talking about? A thing that does identify the run of a text and is on a low enough level?

If I’m correct, you’d only be able to address content that was present in the DOM.

Best wishes

Jeremy

Thank you for your replies. Interesting matters.

<:-)

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

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/1fbf7506-a3a7-486a-97ab-499decc645fb%40googlegroups.com.