[twdev] Re: New backend for TiddlyWiki5 based on Firebase

[Mat]

Hi Peter

The zero response you're getting is probably because this group has been 
replaced; TW dev discussions are held 
at https://github.com/Jermolene/TiddlyWiki5/discussions

Your project looks interesting and you've certainly made an impressive 
presentation! Forgive me for asking the stupid question but, what benefit 
does it bring? (I did say my question was stupid). It seems to make TW into 
an app... so why is that better than just having vanilla TW? Your comments 
here imply login featuers for multi user collaboration (that's of course a 
big deal). It seems one has to accept some kind of payment plan for Blaze 
upon which it is based?

(Maybe better reply, and repost, in the new dev forum?)

Thank you!

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/94cd3c45-be6d-4a73-8025-e38400fd8163n%40googlegroups.com.

[twdev] Re: Custom markup (continued 2)

[Mat]

PMario - thanks for replies. Some questions and thoughts:

So, if the CSS is defined elsewhere, do I understand it right that the user 
has to insert the following bit in every tiddler that he wants to make such 
styled notes in?

\customize angel="note" _element="div" 
> _params=".note.notop.cbox.cbox-primary.hard-linebreaks"  open _mode=block 
> _endString="--"
> \customize tick="page" _params=".margin-init.page" 
>

For real world I think this needs to be a template of some kind. E.g any 
tiddler tagged "book" has this automatically applied, i.e triggered via 
someting intuitive that the user probably already does (e.g tag). It is 
unrealistic to think that a user would manually add this even via a stamp 
unless he is totally into it and working with a dedicated book-note-taking 
wiki. The wiki user who occasionally wants to make a "book notes tiddler" 
would otherwise need to dig this out, which it just unlikely IMO. Or do I 
misunderstand something?

»note ´page [[book]] 30-5
>

How is the above to be interpreted? Style it with "note", yes, but then 
there's also "page" style? But [[book]] 30-5 are "headlines" seen in the 
text, right?

Thanks

<:-) 

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/f06411bf-52dc-42dc-abba-7d1fc58e11b5n%40googlegroups.com.

[twdev] Re: Custom markup (continued 2)

[Mat]

TonyM wrote:

> For the minute a macro seems the best.
>

Sorry, missed this point.
The problem with a macro is that it is too finicky to use for quick note 
taking. It demands too many characters.

<> 

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/33813f8d-578a-4fc6-ba8a-d4db1e9ab023n%40googlegroups.com.

[twdev] Re: Custom markup (continued 2)

[Mat]

Thanks for reply Tony. OK, so there are actually some more nuances and bits 
but what I noted above is a "base case":

Here is the most simple example from my own notes. It is an arbitrary snip 
from a tiddler named "The Thomas Sowell Reader, Sowell" :

pp336 When people put up dogmatic ideas, ask "Suppose you are wrong? How 
would you know? How would you test for that possibility?"

The quoted part is from the book but the preceding explanation are my own 
words. Because they're just my private notes, I can mistreat quotes freely, 
but I typically still want to separate the original from my own meta notes. 
Obviously, academic papers or public work would require separating original 
quotes and personal notes properly. When I add my fully own thoughts (e.g a 
conclusion) I sometimes add a prefixing "mg:" (my initials).

Another variant when there are several snip/notes from one page and the 
"pp" is used as a heading. Here I'm using a definition list to show how I 
currently do it with native TW:

;pp338
:When people put up dogmatic ideas, ask "Suppose you are wrong? How would 
you know? How would you test for that possibility?".
:...campaings for a longer school day are farcical. If a lack of time is 
the problem, why are schools wasting so much time on innumerable 
non-academic activities?

A problem here is that it is not clear if the last sentence is a quote or 
something from me. In reality I write my thoughts in Swedish (and most of 
my book sources are in English) so this is rarely a problem. But/and if I'm 
note-taking from a Swedish source, I'm unstructured and sometimes use 
quotation marks, sometime add my "mg" prefix, sometimes add a new line, 
etc. Kinda' depends. On mood, I guess. Or lack of having thought it through 
and established a best practice.

Regardless of all, it has to be simple. The simplest solution that TW 
already has is probably:

;.pp 338 Lorem ipsum

this could be a defined style. Maybe the first word, i.e the 338 could be 
styled but there is no :first-word pseudo element (!). That'd be useful (here's 
<https://webdesignerhut.com/style-first-letter-word-line-and-paragraph-with-css-and-jquery/>supposedly
 
a solution).

;.pp 338 is decent but it is definitely more intricate/errorprone to type 
than pp338 so it is not optimal.


OK, hope this clarifies a bit. Thanks.

<:-)

On Tuesday, September 22, 2020 at 12:11:10 PM UTC+2 TonyM wrote:

> Mat,
>
> Can you give me a quick sample of what details you will give and how you 
> want it to appear.
>
> For the minute a macro seems the best.
>
> Regards
> Tony
>
> On Tuesday, 22 September 2020 at 20:04:52 UTC+10 Mat wrote:
>
>> I'm unfortunately swamped with work, thus my absence here. Sorry for that.
>>
>> However, as part of my work I found a use case that I figured is worth 
>> reporting because it should be a rather common one:
>>
>> I have to go through several books and in doing so I take out notes and 
>> quotes. I want to refer to these snips by the page they can be found at. It 
>> is common practice to refer to a page using the abbreviation "p." or "pp." 
>> (not sure what pp stands for?).
>>
>> It would thus be convenient if one can someone use this for the markup. 
>> I'm not sure about the latest developments here but the natural way to 
>> document such snips would be either of e.g:
>>
>> pp30 Subsequent text
>> p30 Subsequent text
>> pp.30 Subsequent text
>> p.30 Subsequent text
>>
>> - or for multiple pages -
>>
>> pp30-35 Subsequent text
>> p30-35 Subsequent text
>> ...etc
>>
>> The "output" needs to display the Subsequent text but also the page 
>> number/s. 
>>
>> Maybe the current implementation in this thread is spot on, I don't know 
>> because I have lost track (again, sorry). I'm just reporting this because 
>> it is a use case we can expect. Because it is note-taking, it has to be 
>> really smooth and minimally distracting to make the actual note.
>>
>> (Some may argue that such snips ought to be individual tiddlers. Not only 
>> is that another discussion so let's not get in to it - but the (native) UI 
>> for creating individual tiddlers is definitely not smooth enough for live 
>> note taking.)
>>
>> OK, just a report from IRL.
>>
>> <:-)
>> On Tuesday, September 22, 2020 at 1:31:33 AM UTC+2 TonyM wrote:
>>
>>> TT,
>>>
>>> I understand your concern, its correct to raise it. I think you need a 
>>> explanation from me who is pushing this capacity, is warranted.
>>>
>>>- What I am doing is pushing the solution to its logical 
>

[twdev] Re: Custom markup (continued 2)

[Mat]

I'm unfortunately swamped with work, thus my absence here. Sorry for that.

However, as part of my work I found a use case that I figured is worth 
reporting because it should be a rather common one:

I have to go through several books and in doing so I take out notes and 
quotes. I want to refer to these snips by the page they can be found at. It 
is common practice to refer to a page using the abbreviation "p." or "pp." 
(not sure what pp stands for?).

It would thus be convenient if one can someone use this for the markup. I'm 
not sure about the latest developments here but the natural way to document 
such snips would be either of e.g:

pp30 Subsequent text
p30 Subsequent text
pp.30 Subsequent text
p.30 Subsequent text

- or for multiple pages -

pp30-35 Subsequent text
p30-35 Subsequent text
...etc

The "output" needs to display the Subsequent text but also the page 
number/s. 

Maybe the current implementation in this thread is spot on, I don't know 
because I have lost track (again, sorry). I'm just reporting this because 
it is a use case we can expect. Because it is note-taking, it has to be 
really smooth and minimally distracting to make the actual note.

(Some may argue that such snips ought to be individual tiddlers. Not only 
is that another discussion so let's not get in to it - but the (native) UI 
for creating individual tiddlers is definitely not smooth enough for live 
note taking.)

OK, just a report from IRL.

<:-)
On Tuesday, September 22, 2020 at 1:31:33 AM UTC+2 TonyM wrote:

> TT,
>
> I understand your concern, its correct to raise it. I think you need a 
> explanation from me who is pushing this capacity, is warranted.
>
>- What I am doing is pushing the solution to its logical conclusions, 
>not to necessarily expand the features (although that is good), but 
> explore 
>its consequences.
>-  We are not offering macros here, we are offering customised wiki 
>text. If we keep its documentation clear and concise it will be written in 
>a systematic way.
>   - The result of a concise systematic solution will be designers 
>   will abstract and experiment. I am running down these paths to test the 
>   validity.
>  - I am also doing this for issues that I perceive to be existing 
>  limitations, 
>   - By voicing these Mario looks at the "what if's", now if he 
>   discovers with a tweak they can be made to work, we do not need to 
> document 
>   exceptions, exceptions make a solution more complex
>   - To me to exclude macros, perhaps even transclusions (not raised 
>   yet) will actually add exceptions and complicate the solution.
>   - users and designers bring with them a complex set of assumptions.
>- We may need to document some warnings, what are the warnings if we 
>do not discover them?
>- This solution is by its nature is handed to us by our Yogic teacher, 
>the Yoggy is empowering us to explore all the branches of our being. 
>
> Not withstanding this desire, "not to limit" the possibilities (unless 
> identified as necessary)
>
>- I expect customised wiki text is going to be a method to an end, 
>basically with small group of designer and users actually writing 
> customise 
>pragmas for themselves
>   - A common use may be just the defaults
>- I expect for example a writers wiki to be designed, with this plugin 
>and a set of prepared customisations to be included.
>   - The writer's wiki will not document the customisation plugin so 
>   much, but the resultant set of custom markup that the writer will use.
>   - That is, there will often be an abstraction layer introduced, 
>   between the specific implementation and the customise pragma.
>- If however if someone goes down the customise pragma writing 
>themselves, the more they can leverage this commitment to a sophisticated 
>solution, and the more they will care about the capabilities.
>
> In short, the use of the customise pragma will be as complex as the user 
> wishes to make it. As is already the case for standard wiki text.
>
> Regards
> Tony
> On Tuesday, 22 September 2020 at 03:42:38 UTC+10 @TiddlyTweeter wrote:
>
>> PMario wrote:
>>>
>>> @TiddlyTweeter wrote:

 The more I hear about "macros" in this the worse I feel.

>>>
>>> Why? ... It works now, which is a big win.
>>>
>>
>> Right. More power to you.
>>
>> BUT are we seeing a version of Advanced Yoga (bloke was able to twist his 
>> leg behind his head)?
>>
>> My concern is it will confuse adding macros. Let's see. The issue is you 
>> will have to find a way to document BOTH major layout change AND the 
>> indefinable scope of macros (not all though) elegantly.
>> I'm concerned its getting too complicated. BUT let us see.
>>
>> TT
>>
>>  
>>>
 I don't care if the device lets you skip over the moon. I DO care that 
 mortals can understand it. OR totally avoid it.

>>>
>>> If you don't 

[twdev] Re: Custom markup (continued 2)

[Mat]

Annoyingly I can't "reply privately to author" anymore so must post this 
publicly:

@PMario - could you edit the first post in this thread to include the main 
link you recommend for testing things?
Tx

<:-)
On Wednesday, September 16, 2020 at 12:22:05 PM UTC+2 PMario wrote:

> Hi folks,
>
> This is the continuation of Custom markup 
>  
> [1] and Custom markup (continued) [2]
> 
>
> Let's start a new one before [2] starts to use pagination. 
> Have a closer look at link [1] it's possible to show all the topics in 1 
> page
>
> have fun!
> mario
>
>

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/a422dbe8-3d37-4352-b359-5dd93cfa6536n%40googlegroups.com.

[twdev] Re: Custom markup (continued)

[Mat]

PMario - thanks for updates. I just tested the latest. When clicking 
something in the dropdown, e.g "Colorbox danger" there's a "Copied to 
clipboard" message but no visible change in the edited text. I was 
expecting some prefixing ticks with classnames, and no "Copied to 
clipboard" message.

If I recall, the tick was to make a div and the angle quote to make a 
... so what do the other characters do? Or maybe the fact that there is 
a double pipe in the dropdown is meant to separate the optional "div 
characters" from the optional "p characters"? If they in deed are options 
for the same thing, I'd suggest a selectbox instead of radio buttons. The 
select box is uglier but I would not think people change their chosen 
indicators much so there's no reason to have them permanently exposed. 

For the docs, it would make sense with a very first tiddler to read that 
that gives a quick overview. Currently the "Basics" tiddlers are 
alphabetically sorted so it is not clear if there's an order to them.

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/9a06a5c4-0093-4e2f-8a25-6ef0a4dce9a6o%40googlegroups.com.

[twdev] Re: Custom markup (continued)

[Mat]

Hi guys. I've lost track of this discussion. Is there documentation now? 
What's the best demo (perma-)link, if any?
Is there any issue where my input could contribute value?
Thanks!

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/32a617f2-960c-437a-9354-14abc480a46ao%40googlegroups.com.

[twdev] Re: Custom markup (continued)

[Mat]

Widgets? What is this? @PMario, could you please show some example using 
native widgets?

What does it actually *do*? Style the output from the widget?

Very interesting nonetheless!

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/3f7ed504-09fc-493e-b7ee-33bf93102f9do%40googlegroups.com.

[twdev] Re: Custom markup (continued)

[Mat]

Interesting developments.

\customize is the perfect name for this pragma!

A critical question (which kind of brings back things I stated in the very 
beginning of this thread/discussion): Who should use this? 
As noted, there's a distinction between tiddlyfiddling/coding vs. 
notetakeing/authoring. But even for the former, those are very complex 
pragmas and if one is even supposed to add multiple of them... hmmm. Maybe 
the whole construct should be a stamp? (But, there's already four from 
this!)

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/1d10c1ac-a1f0-400e-8ad4-02ddc939b783o%40googlegroups.com.

[twdev] Re: Custom markup (continued)

[Mat]

PMario wrote:
>
> Hi, help requested
>

LOL! I didn't see your post before posting mine!
 

> I'm searching for a new name for \tickblock and \tickinline
>

So as noted \customblock or \indicatorblock, possibly \iblock

Q: Will it ever only concern styling? If yes, then possibly \stylesection 
or even just \style (... "apply a style pragma")

I'm not happy with 
>
> \tickblock tick=  and \tickblock angel=
>

So, yeah, IMO indicator is the right name and one that turned up naturally 
in our discussions.
 
<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/e77dbf1c-644a-4770-96ac-5982d8fcb60do%40googlegroups.com.

[twdev] Re: Custom markup (continued)

[Mat]

@PMario

First, I just have to agree with Tony: You're a rare developer, doing 
fantastic stuff! :-D

Regarding

\tickblock tick= tag= endString= 
> mode= use=
>

May I suggest the following parameter name changes:

\tickblock  change to \customblock or \indicatorblock (the word tick is 
too specific IMO and also ignores anglequotes)
tick  change to indicator
tag - change to htmlTag

Just my opinions.

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/9226e885-9ede-40d2-a26b-c2238d7e74d5o%40googlegroups.com.

[twdev] Custom markup (continued)

[Mat]

Last thread paginated.

Apropos what character is appropriate for PMarios construction, PMario 
wrote:

I'll be happy to change it, if someone has a good idea.


I think proper keyboards should be prioritized here, not "screen keyboards" 
because presumably *most *people do their full blown wiki editing on real 
keyboards, not on their their phones.

The generic currency symbol 
 i.e  ¤  can be 
found on a few keyboards, including both Swedish and the 
Tastaturbelegung_E2 ;-)

<:-)




-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/ba19c479-de90-4fa5-9866-0043b12d711do%40googlegroups.com.

[twdev] Re: Custom markup?

[Mat]

PMario wrote:
>
> @Mat
> V 0.0.8 contains a tick-inlie rule. ... BUT it will only work within text. 
> It breaks at the start of the line. 
> See example. I'm pretty sure, this will cause problems.
>

I need to sleep so can't test it today but wonderful that you're working on 
it!

What do you think?  #1 or #2?


Assuming the text in red here: ´name.classname does not refer to a 
classname, then #2 for sure. IMO the dot should only be before classnames 
here. Also, starting to type next to a classname without a space, like in 
#1, is weird and possibly error-prone.

Thank you PMario!

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/8e745449-8469-486b-995c-8a3c3d570d0eo%40googlegroups.com.

[twdev] Re: Custom markup?

[Mat]

PMario wrote:
>
> And here we are. ... hijacking an other thread ;) 
>

Haha, things are definitely on topic.

PS: I've updated to V 0.0.7 at: 
> https://wikilabs.github.io/editions/tick-text/ - No docs yet - sorry - 
> I'm starting it now. 
>

Maybe it'll clarify once there are docs but I'm testing the double tick you 
mentioned, attempting to get ´´.mid sentence styling´´ but I don't succeed 
in producing any.

<:-)


-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/3a76d2cf-d17c-48e3-85cf-e40388103129o%40googlegroups.com.

[twdev] Re: Custom markup?

[Mat]

PMario wrote:
>
> ... misusing the DD element  can completely mess up screen readers 
>
> The "angle quote" will allow you to fix this. 
>

OK... if it was only a more accessible character. The tick is OK (with my 
keyboard)... but the anglequote and toolbarbuttons etc... not good IMO... 
Can't instead ; and : be redefined into divs with the current dt/dd default 
styling - but so that they can also be user customized freely?


1) It doesn't work in the middle of a sentence. The @@ can. 
>>
>
> Till now. I was thinking about the possibility to create a "tick-tick" 
> start: ´´and end-marker´´. I think they are much prettier to read in plain 
> text then @@ 
>

I agree that's pretty. Cool with mid-sentence possibility!


2) Do more than merely styling, like for example the pipe characters do to 
>> build tables.
>>
>
> Building tables in wikitext is THE most complicated parser logic in TW. 
> I'm not sure, if the tick definitions can handle it. .. But I'll have a 
> closer look.
>

My mention of tables/pipechars was ONLY to give a concrete *example* of 
wikitext markup that does more than mere styling. What I'm after is a 
general ability to trigger "functionality" (macros? js?) via markup to 
operate on the text, i.e something that does more than mere applying of a 
html tag and styles.

So, as I now comment on your table idea, please don't forget that my 
mention of markup tables was only an example.

´.table ´.caption Some caption text
».row
´.th.text-align-center header 1
´.th.tac header 2
´.th.tac header 3

1)
Pipe characters are very pretty but also very intuitive for tables. This is 
missed out here.

2)
I guess your variant would solve this issue: 
https://github.com/Jermolene/TiddlyWiki5/issues/2941 
 
3)
Could it be possible to use the fact that 

´.table
... 
\n\n

is a "micro environment" so that you don't need more ticks inside there? 
I.e .row without anglequote and .td without tick. The environment already 
makes it clear what it is. I guess this means that ´.table would need to be 
parsed as a predefined unit.

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/b38abcbc-7425-4416-a708-ae89dbf95bd1o%40googlegroups.com.

[twdev] Re: Custom markup?

[Mat]

@TiddlyTweeter wrote:
>
>
> Mat:
>>
>  What would additional html elements enable in wikitext that you can't do 
>> already?
>
>
> For example, writing structured articles these elements work well...
>

Help me understand:
If you're going to write HTML-structured articles why would you use 
wikitext to begin with? Is the idea to somehow export the text after the 
wiki markup is converted into html tags? Then why not use the *actual *html 
tags?

What you ask for would require one special wikitext indicator per html-tag, 
right?, but your list is a totally arbitrary fraction of all html tags. Why 
does it not make more sense to, as I noted, just use the existing TW 
markdown and concatenate classes to achieve the styles of "main, article, 
header, etc"? *Possibly *introduce indicators for, div and span, but 
nothing else. Beyond that... why?

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/7541ed44-3483-4ee6-a339-7dbc41554f9fo%40googlegroups.com.

[twdev] Re: Custom markup?

[Mat]

@TiddlyTweeter wrote:
>
> No. It isn't. :-) Because the thread is also *concerned with inserting 
> HTML too*. Its the combination of insertion of HTML elements and classes 
> where it really adds to WikiText IMO.
>

Which additional html elements do you need inserted? I.e beyond the ones 
inserted already by existing wikitext markup.

What would additional html elements enable in wikitext that you can't do 
already?

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/f8373f0c-9ed2-40d9-807d-9c92de0373ebo%40googlegroups.com.

[twdev] Re: Custom markup?

[Mat]

By the way - of possible interest:

https://mathiasbynens.be/demo/crazy-class

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/295c17c8-bd22-43ef-bc5d-128974434731o%40googlegroups.com.

[twdev] Re: Custom markup?

[Mat]

With the insight I got from Tonys earlier reply that our existing 
indicators can already be concatenated with further classes, I'm starting 
to wonder if this whole idea/discussion might be unnecessary, i.e:

Why is tick or angle quote better than merely using for example the :  i.e 
a colon, the  element? This particular element is both pretty and 
totally accessible and only styled by the browser (right?) into:

display: block
margin-inline-start: 40px; 

We can instead write an explict class to override these values (to set 
identical values) but so that an end user easily can locate and modify them.

Just like with tick or angle quote, concatenating further classes to colon 
requires "dot-class-space" - so what would the advantage be with tick or 
angle quote?

Two things that tick/anglequote nor colon cannot do:

1) It doesn't work in the middle of a sentence. The @@ can. 

2) Do more than merely styling, like for example the pipe characters do to 
build tables.


So maybe the aim should be to address this instead?


<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/7c376592-d0d0-4b27-8ba0-52c0b483c053o%40googlegroups.com.

[twdev] Re: Custom markup?

[Mat]

TonyM wrote:
>
> I can confirm this "chain atomic styles" already works 
>

I did not realize this worked beyond @@ in native TW. Thank you!

However note the gap we are addressing here is allowing such cascaded 
> classnames to be placed at the front of any line


Yes, I have to assume we're all clear on that point. My main point, in the 
latter posts, are that if the "indicator" can be a distinctive string 
rather than only a single character, then we don't need ticks or angle 
quotes. My interpretation is that the system *can *deal with 
multi-character indicators such as @@.

Possibly relevant is that *tags in HTML5 can be arbitrary *e.g  
which is then styled like other tags, i.e no prefixing dot, e.g

pretty {background:red}

 ...and my interpretation is that TW converts e.g an asterisk * into  
which in turn applies natively defined styling ...so shouldn't it be 
possible to turn, say, "_P" or "_PRETTY" into  which can apply 
other styling? I.e we don't have to adapt to the limited set of predefined 
HTML tags.

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/fb647e07-ff87-482e-8914-94e79f4089eao%40googlegroups.com.

[twdev] Re: Custom markup?

[Mat]

Adding to my post above (containing the clarification to make the indicator 
be a string rather than a character)

PMario wrote:
>
>
> `.justify.indent1.right-margin.cbox.cbox-primary your text goes here. 
>
> That's pretty close the "Tailwind 
> " 
> approach, that you brought up here in the group. ... 
>

In deed, and I like this possibility to chain atomic styles very much. Of 
course, if one authors e.g a book or other coherent text, there will 
probably be a very limited set that is needed (hence my point about a few 
ready made indicators that each bring their own style).
 

> I did probably write it 2 times here. The DOT is _not_ possible. It will 
> clash with tiddlers tagged $:/tags/Stylesheets ... Every class name starts 
> with a dot. 
>

Thanks, I missed this. I'm surprised though because I assumed the 
stylesheets tag was a *prerequisite *for the dot-classname to be 
interpreted as class names by the system - and if there was no stylesheet 
tag then this syntax didn't mean anything special...


<:-) 

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/410ae586-3958-4d08-9a24-abd690a9fc76o%40googlegroups.com.

[twdev] Re: Custom markup?

[Mat]

PMario wrote:

You *have to start* the line with a "tick" or an "angel" quote, except 
> someone comes up with a better character that we don't use already! The 
> parser needs it.


My point was not to use dot as the indicator but instead use *the full 
string* (that includes the dot) as indicator. And it doesn't have to be a 
dot prefix, it can be some other keyboard-accessible prefix (maybe _ or - 
). The point with the prefix character is ONLY to make it "stick out" so 
the user (not the parser) doesn't mistake it for regular text. In other 
words, the indicator would not be one indicator but *several* indicators 
such as

_D or _DETAILS or _details
_S or _SUMMARY or _summary

...or, for that matter...

-§

These indicator strings would bring with them, i.e cause, a *default* 
styling (which, if I understand it right, the tick char or angle quote do 
not, by themselves). The default styles can be overwritten by the user, 
just like any other styles. *Only a few such indicators are needed* assuming 
they trigger a styling which can also be user customized. But I guess it is 
also neat if one can chain on additional suffixing classes like in your 
examples. The simple case though, comparable to adding a bullet, is only a 
single "_D" or "-§" indicator because these are directly available on 
everyones keyboard.

Do I misunderstand something? Is this not possible? You have to agree this 
would be superiorly simple to use.

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/6c5827a2-476e-4e70-b741-37fe8cd8e3fao%40googlegroups.com.

[twdev] Re: Custom markup?

[Mat]

We need to make a distinction between two major use cases:

   1. tiddly fiddling
   2. taking notes / authoring

For tiddly fiddling such as coding or working on a website etc, it is OK 
with intricate constructions and looking up commands etc.
For note taking or topic-focused authoring it is not reasonable to force 
the author interrupt his topical flow with "system things". It is this 
latter case that I'm concerned about.

The complexity of things have to "take place" somewhere. The difference 
between the two use cases is that #1 can have complexity at front and be 
exposed to it but for #2 it MUST be hidden. IMO your prevous demo with 
syntax

´.i.r.j.c.cp

...is "pretty close to good" for user #2: Now, I'm assuming he can create 
custom classes (when he eventually switches over to fiddling). When taking 
notes or authroing you only need a few recurring classes, so they can be 
directly named e.g "details" and "summary" etc.

BUT for user #2 the indicator (´) has to be as easy to type as most other 
things. I guess tick is OK but having to use a sepate tool for it is IMO a 
no-go because it totally hijacks your attention. SO what are the options 
for indicators? I've asked if a single period (.) could work but I take the 
silence to mean "no". How about a *period AND some other standard 
character, even a letter or a word*, e.g:

.D My text
-or-
.DETAILS My text

This make things very clear both when authoring and when reading the code. 
It is fairly close to markdown. *And the specific indicator can itself 
bring default styling!* In other words, there would be multiple indicators, 
but one would likely only need very few. One could potentially add actual 
style classes to it like so:

.DETAILS.red My text

The first period doesn't mean anything by itself. The *second *period means 
the same as the periods in your .c.cp.foo cases. ()

Again, this is *very *clear and there's minimal hijacking of brain compared 
to defining pragmas, clicking buttons, or adding multiple classes.

As for breaking at newline vs space-space-linebreak, if it is not already 
baked into the command, this could also be commanded here:

.DETAILS.NEWLINE 
vs
.DETAILS.PARAGRAPH

(or some abbreviations)

The user must take care to not define class names that overlap with these 
"command names". One could argue for using some other prefixing symbol than 
the period, so to not confuse the commands with the classes BUT, again, an 
author or note-taker is only likely to use a few such commands and there is 
*less 
*distraction precisely because it uses the very same character, i.e the 
period. The author should not spend brain power on thinking about such 
technical distinctions.

Thoughts?

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/667ea1c5-0d48-4aec-98a8-4ee4a6ec756ao%40googlegroups.com.

[twdev] Re: Custom markup?

[Mat]

>
> The global settings are the default settings. ... pragmas are for special 
> usecases and they have to be part of the tiddler, to make export import 
> possible. Otherwise users will always forget, what to export. 


OK, so the pragmas will be to add to, or overwrite, the global settings 
then?

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/5c9b3cc2-d72f-41c9-a4b8-8ef74a964b2fo%40googlegroups.com.

[twdev] Re: [TWX] some syntactical bits and stuff

[Mat]

Mat wrote:
>
>
>- Filtered transclusion: Replace the syntax {{{[...]}}} with 
>[evaluate[...]] i.e an "evaluate" operator. In case of space 
>separation, use single or triple quotes. This would visually harmonize 
>filtered transclusion with how filters look overall. It would also make 
>"fitered translcusion as argument" look better, e.g <$vars 
>foo="[evaluate[...]]">
>
>
   - Alternatively, but not quite as slick: Replace the syntax {{{...}}} 
   with {{ ... }} i.e one bracket pair is replaced with space characters. 
   (There is already a silent consensus to use such surrounding space 
   characters in filtered transclusion, presumably for clarity.)


<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/ef700910-418b-4b58-8638-2dc88918fd9bo%40googlegroups.com.

[twdev] Re: Custom markup?

[Mat]

TonyM wrote:
>
>
>- this tiddler has no $":/plugins/wikilabs/tick-text/styles"
>
> (that's likely a trick to make it appear in the lists, while still making 
it very easy to turn it into a system tid at any time)


>- 
>   - » .cb does nothing?
>
> Careful, you must not have a blank space there! 

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/7f6cdd95-d6a1-4292-83a4-690f1642e63bo%40googlegroups.com.

[twdev] Re: Custom markup?

[Mat]

TonyM wrote:
>
> Mat,
>
> you can't get the \n to show up anyway
>
>
> I noticed in the HTML preview tabs are actually displayed,  I recall 
> earlier word processes allowing you to display symbols in the page such as 
> tabs, new lines and paragraphs. Perhaps a special preview that did would be 
> useful?
>

I'm not talking about a visual representation of the end of line character. 
I meant that neither the angle quote nor the tick results in a rendered 
line break when the text contains a newline. I.e the angle quote simply 
disregards a newline just like wikitext normally does and the tick ends 
from a newline (thus resulting in a visual brake with an empty row). So you 
can't get a new line by inserting \n (i.e by breaking the line and continue 
to type on the new row). 

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/1eb6d5b0-bdfb-476d-8d7d-52146ef0c539o%40googlegroups.com.

[twdev] Re: Custom markup?

[Mat]

PMario wrote:
>
> \ticktext default end="---"
> \ticktext name=x tag=p start=´ params=".c.cp" end=eee
> \ticktext name=y tag=div 
> ...
>
> @Mat
> IMO this will be very close to the OP ?
>

If the above is a *global* setting then it is possibly practical enough, 
yes. There's little chance a user will remember this syntax so maybe it 
would need a little UI to hide the parameter names etc. (Idea, that I did't 
think through: Maybe local tiddler custom fields could be used somehow, 
comparable to the class field?)

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/7a046df5-4578-4c1c-863d-15ca38e566b1o%40googlegroups.com.

[twdev] Re: Custom markup?

[Mat]

@PMario

OK, so I'm testing things directly on your site. As noted, this is super 
cool and could become very useful.


I did publish an EXPERIMENTAL wiki [1] at wikilabs, that contains 3 new 
> wikitext elements. 
>

I understand these three to be

´ = tick
» = angle quotes
space-space-newline

That last one is independent of the former, yes? However, this code does 
not render line break between 111 and 222:

».aaa 111   (ends with space space newline)
222


.aaa {background:red; display:inline-block; max-width:133px;}


 ...and using tick instead also shows no difference between 
space-space-newline and just newline.


The "*tick*" will create a *DIV *element _and_ stopps at the first *\n *newline 
> it finds
>
> The "*angle*" will create *P *element, stopps at the first *\n\n* 
> double-newline it finds. 
>

So, the point here is presumably that one is allowed to do \n and still 
keep the styling after. But, as noted, what is the point in allowing a \n 
when such a single linebreak is not seen in the rendered text anyway? I 
still cannot use one "command" to style two paragraphs (i.e separated by an 
empty row). Or can you give an example where ´ is insufficient but » saves 
the situation?
...or maybe you mean one also *has *to use your .h class that you bring up 
below, for the linebreaks?
 

´.r.j.c.cp Some test text 
>
will create 
>
> Some test text 
>

So do tick and anglequote add extra classes beyond what the user specifies 
(wltc-11 etc)?
 

There are 5 new edit-toolbar-buttons: Only 3 have shortcuts atm. You can 
> assign them at the Control Panel
>
>
>
>
IMO this is a pretty expensive compromise for not using more accessile 
markers. It is expensive in real estate and visually (*four*!). Note also 
that there's a Controlpanel setting to Show/hide the toolbar. I, for one, 
prefer it hidden. More cricitally I stand by my opinion that we should aim 
for Grubers goal as much as possible in that the authoring process should 
be minimally distracted and adding the marker should be as non-distracting 
as adding a list-bullet or a heading exclamation mark.

...or no marker; I don't think anyone answered why there needs to be a 
marker at all beyond just starting the line directly with 

.class My text
 
BTW, it is worth noting that all options also require an empty preceding 
row (except the very first line in editor). This is not a complaint, just a 
fact.



>  - space-space-newline  or
>  - space-space-backslash
>
> There are  2 tiddlers 
>
>  -  test-hard-linebreak-and-transclusion
>  -  nl-is-hard-linebreak
>
> That test a different way to crate hard linebreaks. NO plugin involved!!
>

Nice! So that is done by adding the .h class if I understand. It works for 
angle quotes but not tick so, as noted above, maybe this is the practical 
outcome difference between angle quotes and tick?
 

Planned: 
>
>  - test if it's possible to use ---  aka HR instead of \n\n as a 
> stop-indicator. 
>

(Advantage: Visible in edit mode.)
 

>  - test if it's possible to use pragmas to use different HTML tags instead 
> of DIV and P
>

So would this mean one would *also *have to add pragmas as soon as one 
wants to use, say, ´.foo ?
 

>  - test if it's possible to use a pragma to define the stop-indicator
>

Locally?
 

>  - test if it is possible to create a wrapper element and call a macro 
> using the text as the ONLY parameter
>

I'm kneeling in prayer.
 

PS: Yea I know my page has a typo. I named it "angel bracket" .. and I'm 
> not sure if I'll fix it ;)
>

Angels are more interesting than angles so keep it ;-)


<:-) 

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/15596c44-3466-4f5f-bf35-e1d2d887eb79o%40googlegroups.com.

[twdev] Re: Custom markup?

[Mat]

PMario, I'm looking at it right now. (I wrote a private message to you 
earlier today via the board about looking at it tomorrow, did you not get 
it?) I will look at it more closely tomorrow when I'm not so tired but a 
first glance looks *really *cool!!! Here are some very quick thoughts:

The class names there are of course cryptic but I note I can easily create 
my own.
I note the difference between the tick and the quote e.g for this text

aaa  
bbb

...but since that single linebreak disappears when I use the quote, what's 
the point in making a distinction between if it stops at \n or \n\n? I 
mean, you can't get the \n to show up anyway so why would one use it?

More tomorrow. This is a great start!

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/5df9f138-65bc-440e-959a-b7d927f90394o%40googlegroups.com.

[twdev] Re: Custom markup?

[Mat]

@PMario and @Tony

I'm really looking forward to your plugin. Some questions:

As PMario notes, the "indicator" characters are problematic especially the » 
which doesn't even exist on many keyboards, including mine. So then... how 
is that simpler than using e.g @@.class ? 

I take it that the style defs are customizable but would it be possible to 
make the indicator character customizable? This would solve everything 
since the user knows his own habits and keyboard. Even "Joe the Finger", 
whos hacker career totally tanked after the accident (but he did get ever 
so popuplar among the ladies), even he will be able to use your plugin 
comfortably then.

Maybe one could make a user modifiable dictionary like so

» : 
i : 
ii : 
asdf : 

(or even style definitinos directly instead of the classnames)

Also, @Tony did briefly mention a dot classname syntax, i.e:

.class My text/n

without any other prefixing indicator. I didn't quite understand why this 
is not possible, could someone explain?


\n will be recognized as a hard linebreak with a second 
> plugin.


When manipulating text in filters, can  be retained or do I 
remember right that filters often trim space chars?

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/3fd00170-2989-47ba-a58e-5027a57a3cc1o%40googlegroups.com.

[twdev] Re: Custom markup?

[Mat]

As noted, I think a key question for this discussion is what the purpose is:

To (merely) control the styling of text snips, one can use common HTML. So, 
for a TW solution to be *meaningful*, it has to improve something. Using 
@@.foo ...@@ achieves the identical styling outcome, so no improvement in *that 
*regard. And *semantically* the difference between @@.foo ...@@ and ... is very small - it takes almost as much typing and it 
is almost as visually distracting when reading the code, so almost no 
benefit in that regard either. But, in contrast to pragma rules, both 
alternatives have the "plus" that they manipulate the "very current" text 
part that one is authoring.

@PMario/Tony , I really like your idea to apply style with

X.classname My text here\n

...and, even nicer, directly:

.classname My text here\n

...because it *significantly* simplifies applying styes for the author, and 
readibility is superior to html or @@ (at least if the classnames are not 
confused with the text itself).

This jives perfectly with the styling aspects of my OP (tho not any 
"programmatic functionality" like pipe chars). And if the class is 
undefined then, just like usual with css, the result is "no effect".

Are you saying your approach works or did you hit some problem?

Have you considered syntax for styling bigger text portions, i.e that 
contains multiple \n ? I.e how to specify an end marker?

@TiddlyTweeter

I am not the least fond of the pragma route for the reason I hinted in this 
post, i.e that it breaks the authoring workflow. Imagine if you were forced 
to add a pragma every time you wanted bullet lists? It is distracting and 
bad UX, IMO. Pragmas definitely have their place, for instance for macros 
where the pragma is part of what actually constitutes the thing. Another 
case is a pragma that implies "this tiddler should have this special 
functionality" but my OP here is for something mundane and comparable to * 
for bullet lists - it's just that the user himself can make up what the 
effect should be.

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/3d4626e4-ba0f-43a8-a267-8bfee6c3d8e5o%40googlegroups.com.

[twdev] Re: Custom markup?

[Mat]

Eric Shulman wrote:
>
> Using this code to control formatting would preclude using it as a 
> printable character in legal texts.
>

Good then that my proposal is for "custom markup", as defined by the user, 
and not predefined markup. As noted in the OP, if no styling etc is defined 
then using the character doesn't "do" anything. 

Any thoughts on the OP (with the goal of simplifying authoring)? 

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/3a786f16-e842-4228-a154-ce71f0213053o%40googlegroups.com.

[twdev] Re: Custom markup?

[Mat]

PMario wrote:
>
> The problem is, that we don't have enough unique "indicators" left. 
>

For one I'd think specifically § does occur on all western keyboards but, 
regardless, if the OP is made fully general in the sense that the user can 
define *his own* indicators then he can use whichever indicator he wants. 
This should be particularly appealing for those that don't even use western 
keyboards at all. 

 

> The point is to access ones own look/behaviour as smoothly as with e.g *
>>
>
> eg: I'm working on a new plugin that will allow us to style paragraphs. It 
> uses the "accent" aka "Tick"
>

(Are you really working on that or are you just making example? How would 
it be different from simply styling bullets instead of requiring a new 
indicator? But if you do want a special indicator, then why not go with § 
which was *literally* created to define paragraphs?)

 

> 


Your second example is
>
> @@.custom-class
> * element 1
> * element 2
> @@
>

First, you're only talking about styling. As I mention, I envision that the 
indicator could also be a macro/code (like what I assume is done with pipe 
characters to create tables).

But more cricitally you misunderstand the point with my proposal. The point 
is *not *to achieve a specific visual end result. That can be done with @@ 
or with html. Rather, the point is (1) to *simplify authoring,* and 
(2) quoting Gruber:

“The idea is that a Markdown-formatted document should be publishable 
as-is, as plain text, without looking like it’s been marked up with tags or 
formatting instructions.”

Surely, you must agree it is both friendlier for the eye and much simpler 
to type:

§ So this is a "special" paragraph
§ This one also

..than e.g:

@@.myclass So this is a "special" paragraph@@
@@.myclass This one also@@

...and, again, that even only looks to the styling aspects. Really, it 
should be:

<>
<>

...but this would cause further problems with other wikitext like

<> paragraph">>

...and so we'd need to go full wikitext coding on it, leaving pretty markup 
all together.

Things like * and : and | and > are very useful and elegant. My proposal is 
about extending this.

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/1338e460-33ec-4a34-beac-530f0d71ff79o%40googlegroups.com.

[twdev] Re: Custom markup?

[Mat]

@pmario

As noted, *if no style is defined*, then it appears just like a regular 
character. The idea is that it is user controlled. (But I actually chose 
the specific § character because it is *not *unlikely that people will want 
it to style "paragraphs" - also in law related texts, e.g indented or 
monospace etc.)

An alternative character might be to extend the wiki markup for quotations, 
i.e the > or <<<  Particularly the latter, which requires an otherwise 
empty line, should be doable (<<<3 to trigger some third styling). The 
single > character might be trickier.


IMO it will be very similar or the same as: 
> https://tiddlywiki.com/#Styles%20and%20Classes%20in%20WikiText 
> 
>  
>

Really? Do you feel the same about the * and : markup? Might as well do it 
with @@... instead?

The point is to access ones own look/behaviour as smoothly as with e.g *

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/ea31c191-9a0c-4ba2-8d82-534833a3e657o%40googlegroups.com.

[twdev] Custom markup?

[Mat]

It would be useful if TW could work as a custom markup 
constructor+interpretator.

I.e that it featured "*potential* wikitext markdown" that people can 
CSS-style freely. For example, we currently have the list elements * and : 
that give predefined  and  with specific styling. It would 
be neat if e.g § or other characters would trigger custom styling IF the 
user choses to define such styles. If no style is defined then, I guess, 
the characters and subsequent content displays as usual.

Notably, HTML has this built in i.e it allows custom tags like Lorem 
ipsum, but the requred angle brackets and possibly closing tags 
make this too verbose. I want a smooth wikitext markdown command.

I identify two "base cases"; one with a opening and a closing mark (compare 
to a div). And the other as list element marker with only an explicit 
opening mark and an implied closing mark consisting of newline or similar.

One idea would be to use the aforementioned § character. IF a row is 
prefixed with § and has a subsequent empty row (or end of tiddler) then it 
is interpreted as a list element. If the row instead is encapsulated with a 
§ and a suffixing § then it is interpreted as a div. For example the first 
case could be interpreted as  and the second case as 
.

We'd get infinite options if one could use §1, §2, ...

(Possibly the character should trigger more than mere CSS. I would guess 
pipe characters, when creating wikitext tables, do this, right? In that 
case, § could trigger some user defined *macro*, perhaps titled § ...or §1, 
§2... to operate on the text snippet in question.)

Thoughts?

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/5903cfa3-a73d-475c-8762-876adb903d16o%40googlegroups.com.

[twdev] Re: (cont) EditorMagic

[Mat]

Saq Imtiaz wrote:
>
> Do feel free to remove the $action-log widgets if you don't find them 
> useful or think they are no longer needed.
>

Gotcha. Thanks.

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/dd4c33b4-1cdb-4dda-8291-e72b566f0d84o%40googlegroups.com.

[twdev] Re: (cont) EditorMagic

[Mat]

I'll shift my attention to the popup and tools (which, incidentally, will 
be significantly easier for me than to work on the body/editor).

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/cddff760-968b-4031-991d-7edb8e0b97f4o%40googlegroups.com.

[twdev] Re: (cont) EditorMagic

[Mat]

Saq Imtiaz wrote:
>
> [...] I would recommend getting the functionality as you want it before 
> switching focus to performance.
>
 
Oh!? Do you mean building/polishing tools instead? Or what other 
functionality is there.. I mean, the popup already functions as expected, 
don't you think?

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/06ef2f06-f95b-40ab-b115-3489d549a052o%40googlegroups.com.

[twdev] Re: (cont) EditorMagic

[Mat]

Thanks for replying Saq

It was a suggestion that if you find the peformance slowdown unacceptable, 
> then you could replace the title matching filter in the detection code with 
> one that just rejects fragments with disallowed characters. It would be 
> faster though far less accurate.
>

OK. I assume the slowdown will increase with increased number of tiddlers 
so yes, it's worth testing. Do you you think it would work well (and does 
it make sense) to reject fragments that have any of all the triggers and 
trigger ends? A $set to save them in a listvariable which is matched 
against.


There are other options that could be explored via refactoring to try and 
> get around the performance issues, but it would be a fair bit of work that 
> may or may not yield results.
>

I'll try the "reject fragments etc" before asking about this.


Are you saying filtered transclusion {{{...}}} is evaluated for each stroke 
>> but $list is not? [...]
>>
>
> No. [...] However, I did say that this is only an issue if its the display 
> code causing the performance issues. So based on what you are reporting, I 
> am unsure why you are focusing on this at the moment.
>

You're right. Thanks.

If you agree it makes sense to have the detection code match against a list 
with the triggers and triggerends, that's what I'll try next.

Thank you Saq.

<:-) 

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/b2b7e1c9-0005-4cce-95e6-a5b9c8f97957o%40googlegroups.com.

[twdev] Re: (cont) EditorMagic

[Mat]

@Saq
 

> Tests definitely imply it's the detection code. No visible difference when 
>> popup runs or doesn't run filters.
>>
> ...
> How about a filter that that just detects whether the fragment for 
> titlepicker has disallowed characters?
>

Hm, since it is always matched against existing strings (e.g titles) is 
that not enough? I mean the fragment "Editox" is as disallowed as e.g 
"Edito]]" , is it not? (But I have to admit this logic of mine it feels 
like I'm stepping back to how it was when before you stepped in when I 
couldn't tell where the end of the fragment was...)


>>>- I am also unsure if we need this list anymore (after introducing 
>>>em-itemfilter):
>>><$list 
>>>
>>> filter="[length[]addaddmatch]"
>>>  
>>>variable="_NULL" emptyMessage=<>>
>>>...
>>>
>>> No discernible difference in a side by side.
>>
>
> If you are sure about this, we can remove this list and the variables that 
> are there just for its sake.
>

As sure as my primitive test is, yes ;-) 


[...] forces the entire popup to redraw itself from scratch on every 
> keystroke, rather than say a title list that just updates itself. 


>  <$vars foo={{{ [{!!foo}] }}}>
> content
> 
>
> If the value of "foo" in the vars widget changes, the entire widget is 
> destroyed and re-created, which means so is everything inside it.
>
> If however you do something like the following, the list updates itself 
> instead of re-drawing from scratch. This is much faster:
> <$list filter=[prefix{!!fo}]>
> content
> 
>

Are you saying filtered transclusion {{{...}}} is evaluated for each stroke 
but $list is not? That sounds like great but I also don't understand how 
that is possible since listwidgets do update when their filter changes 
don't they?

But, regardless, how the hey would I exchange the $vars for $list in the 
_Popup? There'd be big number of nested lists and... I just don't 
understand.

Here is one of several testing wikis where I have implemented what you say, 
except for this last vars--->list thing. 

http://editormagicny5.tiddlyspot.com/  

This is not the regular editormagic2 wiki where I try to keep the latest 
advancements that I show to you but the dabbles I made now are not ready 
for editormagic2 but it would be kind if you could take a look to see if I 
understood your points here above. BTW, I removed the keyboard shortcut in 
TitlePicker to not get distracted from this.

Thank you Saq :-)

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/ce7b5b2c-216a-4b1e-a917-add5828857feo%40googlegroups.com.

[twdev] Re: [TWX] some syntactical bits and stuff

[Mat]

>
>
>- Let the widget name serve as the "main attribute":
>
> Ah, I now note that I already posted very similar thoughts to this bullet.

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/e01a2a06-2891-4fc8-b004-9d31a95f2fbfo%40googlegroups.com.

[twdev] Re: [TWX] some syntactical bits and stuff

[Mat]

Further sugar for TWX and mind:

   - Let the widget name serve as the "main attribute":

<$set name=x value=...>   →   <$set=x value=...>
<$tiddler tiddler=x ...>  →   <$tiddler=x ...>
<$list filter=...>→   <$list=...>
(Not everything has a "main attribute")


   - Filtered transclusion: Replace the syntax {{{[...]}}} with 
   [evaluate[...]] i.e an "evaluate" operator. In case of space separation, 
   use single or triple quotes. This would visually harmonize filtered 
   transclusion with how filters look overall. It would also make "fitered 
   translcusion as argument" look better, e.g <$vars foo="[evaluate[...]]">
   
<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/b1441efc-ffef-4221-a604-6bde9b3b1a2fo%40googlegroups.com.

[twdev] Re: (cont) EditorMagic

[Mat]

@Saq

First, again, I really appreciate your help. Even if you say we should just 
treat it as prototype, I think it is desirable that it at least works 
fairly OK - and it feels like it is close to doing that :-)

Okidok, tests done:

>
>- is the delay coming from the detection code or the display code? For 
>example for [[ just set the popup code to not run any filters and display 
> a 
>static message like "TitlePicker" and see if the delay is still there. If 
>its significantly reduced then we know the delay is mostly from display 
>code, and vice versa
>
> Tests definitely imply it's the detection code. No visible difference when 
popup runs or doesn't run filters.
 

>
>- For the detection code, see if swapping the list with the 
>item-filter to be the innermost one helps with performance. Simple cut and 
>paste.
>
> That did not show any discernible difference.
 

>
>- I am also unsure if we need this list anymore (after introducing 
>em-itemfilter):
><$list 
>
> filter="[length[]addaddmatch]"
>  
>variable="_NULL" emptyMessage=<>>
>I recommend doing a side by side comparison with and without this in 
>some complex text with a lot of unclosed triggers, and see if the 
> behaviour 
>is identical. If it helps avoid even a few false matches it is worth 
>keeping as the filter it runs is a fast one.
>
> No discernible difference in a side by side.

It is striking however, in all tests, how the detection is much slower for 
the first letters of the fragment than the later. (This is of course to be 
expected.)

 

> I had a quick look at _Popup and TitlePicker. I think they look OK. One 
> potential issue with the vars we set up in _Popup is going to be that they 
> will force the entire popup to redraw itself from scratch on every 
> keystroke, rather than say a title list that just updates itself. Let's see 
> if the display code is causing any performance issues before deciding 
> whether that is worth adressing
>

Please elaborate. 

 

> In short: don't be in a hurry to have something "final" and publish it 
> [...]
>

Thank you for your calm and experienced words in process Saq.

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/ba3ba2f0-2d19-4482-8f98-3b296158f3d5o%40googlegroups.com.

[twdev] Parallel projects for EditorMagic

[Mat]

To not diverge the thread where Saq and I work on the "EditorMagic core" 
I'm starting this parallel thread for "other" EditorMagic matters.


TonyM wrote:
>
> [...] I am just wondering if I can support the effort by commencing a 
> parallel project that produces the content you need to feed into it later 
> whist supporting a broader application.
>

Appreciated. If you're OK with the answer "I can't guarantee that it will 
be used in the end" then, sure, here are a couple of needs ranging from 
semi advanced to "I have no clue" stuff. As you note, they mainly concern 
the EditorMagic popup *content *so chances are big that it can be used 
because the idea is that anyone should be able to create popup content... 
so it is "kind of" safe that it will not be wasted efforts:

OK; there's need for "engines" to extract

   - macro titles and their parameters. From a practical point, I guess 
   this would be limited to user defined macros. Should it be only macros from 
   macro tiddlers or also locally defined macros - I'm not sure.
   - widget titles and their parameters
   - documentation from tw.com. Currently things are just showing in an 
   iframe but if things could e.g be scraped then things could be presented in 
   superior way. Way beyond me how to do this. Or push for a different 
   standardization of the docs on tw.com so things could be more specifically 
   extracted. That is probably an even harder task ;-) Possibly there could be 
   a docs plugin from which the popup tools could fetch structured data... 
   that might be the best solution actually and a pretty cool task and sounds 
   like it jives with your frustration over tw.com's current doc format.

Some other popup tool ideas, some perhaps over the top:

   - site specific search engines, e.g wikipedia, caniuse etc. This one is 
   not very difficult. The approach would be to make it general so that people 
   can add their own specific site.
   - google or duckduckgo image search. I made a plugin for this 
    (don't think I published it) but 
   testing it now it seems not to work.
   - accessing the forum
   - accessing github... for posting issue or pr. To name one use case, 

 
Another angle is to see how/if the current *editor toolbar *can be made 
superfluous. This would be along the lines of Saq's floating editor 
toolbar. Like him, I don't like the UX with the current editor tools - 
tools should be where I'm at right now i.e by the caret! 

You ask specifically about the dictionary tiddler that has "widget 
skeletons": 

I can see in the dictionary you have the name of the widget: widgetname and 
> parameters including the widget close, I presume there is no multi-line 
> widget layouts? 
>
So I wonder if I build a tiddler for each widget and one or more parameter 
> variations, perhaps one with a multi-line layout and a field containing a 
> single line layout then you could pick and choose what content you want to 
> load into EditorMagic? Ideally you could just tap into a library of widgets 
> that can be shared with other solutions and systematically improved by the 
> community.
>

Sure, maybe that's a good idea, I haven't put much thought into it. I 
propose you also test to build the popup tool that will use it. If you want 
to I'll describe how. It is not difficult.

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/06fb1ce1-8b65-4333-86e9-7acd99d9fb80o%40googlegroups.com.

[twdev] Re: (cont) EditorMagic

[Mat]

TonyM wrote:
>
> Perhaps you missed it, but I offered to start populating widget snipits 
> for insertion with your instructions on how to.
>

You did and that is excellent! There are two "angles" to that; one is the 
construction of popup tools which can be somewhat intricate. But the other 
is stuff like:

http://editormagic2.tiddlyspot.com/#EditorMagic%2FWidgetPicker%2Fdic

which clearly needs a lot of work. BUT it is too early to do this because 
Saq (or even I) might come up with some approach that is better than using 
such a dictionary. That specific dictionary is currently intended to stamp 
a widget call with all parameters. A better approach might be to automate 
what the parameters are, perhaps by scraping them from the widget 
definitions. Or maybe that's a bad approach, I hope Saq can tell :-)

Love your work, this is seriously exciting.
>

Yes it certainly is! It is somewhat frustrating for me that it would be 
totally impossible without Saq, but we're (all) really lucky he's both so 
knowledgeable and so generous.

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/0c0b6efb-d4ea-4c96-8e74-8d8e354478c4o%40googlegroups.com.

[twdev] Re: (cont) EditorMagic

[Mat]

TonyM wrote:
>
> I would however be keen to be able to provide my own subtiddler title 
> generator. For example tiddlername - n, tiddlername/something N or behind 
> system $:/namespace/tiddlername(n), even a supplied title. This would allow 
> the transcluded tiddlers be part of other solutions.
>

I'm guessing that you with "subtiddler" refer to a child tiddler? 
Regardless, as I noted in previous post, you can modify the tools or make 
up new ones. 

But, please note even more that we have still not really polished things. 
Saq hasn't even looked at the tools code yet and I'm pretty sure he'll have 
some opinions about what I've concocted. So it is too early to come with 
that type of feedback.

Note: If I enter [[ol and highlight the choice it goes white, unlike a few 
> mins ago.
>

Yeah, I still haven't done much with the styling. Same situation as just 
mentioned in last sentence ;-)

<:-)


-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/c5b59c16-9612-4a42-814e-3aa9996bc4e1o%40googlegroups.com.

[twdev] Re: (cont) EditorMagic

[Mat]

TonyM wrote:
>
> Just a quick look at http://editormagic2.tiddlyspot.com/ and I notice its 
> case sensitive can it be insensitive on input, sensitive on the result?
>

Spontaneously; yes and no. Starting with yes: The concept premise is "a 
popup that you can fill with anything" and which is triggered by some 
trigger that you define. I.e you decide what goes into the popup and if it 
should be, for example, case sensitive or not.

That said, the ambition is also to seed it with a few tools to make it 
useful right away. For the tools where case insensitivity could be relevant 
then, yeah, I think it would be possible. Isn't it just a filter, perhaps a 
regexp? I'm not fully sure though; we just introduced a kind of qualifying 
subfilter in each tool that relies on "fragments" (i.e the string after the 
trigger like [[this.) This filter tests if the fragment matches a prefix of 
whatever it is the tool should match, e.g titles. A typical such filter 
looks like this:

[all[tiddlers]prefix]

...so if you can come up with a some magic operators to inject into this to 
make things case insensitive, then maybe it's possible. I'm not sure this 
is possible, but maybe. Another approach would of course be to rebuild it 
more fundamentally, which I think would be at "a later stage" and assuming 
the plugin gets traction.

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/36c36655-0349-4820-977d-3b2a7c480e4fo%40googlegroups.com.

[twdev] Re: (cont) EditorMagic

[Mat]

@Saq

The itemfilter stuff works. There is a noticeable delay which I estimate to 
be proportional to the number of items i.e the list of items is much longer 
for [[ than for << or <$ ... or perhaps more correctly expressed, it's 
probably proportional to the complexity of the itemfilter.

---

An observation (or is it faulty reasoning?): the itemfilter is only 
relevant if the popup tool also has a fragment ("??tr" does not use a 
fragment, to name one example). And, it is only if it has a fragment that 
it needs a triggerend. ...but if it has a fragment that *must *match some 
condition (e.g match a predefined string), then the triggerend becomes 
superfluous. 

Might this mean we could skip the use of triggerends all together? The 
general question is: Will the user want to construct a popup tool that 
produces a picklist where the item names are allowed to contain the very 
closing string for what triggers the tool? I think it might be fair to 
simply not allow this, or can you think of some case? ...Or is the premise 
of my reasoning flawed?

---

Amusing observation, if one is easily amused: If you type e.g [[Ed and move 
the caret with the arrow keys and then pick a title, the insert will be at 
the new place. Yes, that is "the point" but I hadn't considered this case 
:-)

---

Check out the new transclusion tool! It is super fun!!! Even for those who 
are not easily amused! Styling is totally messed up, but never mind.


<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/6a4852ca-7452-4c76-a50f-02e841a8d382o%40googlegroups.com.

[twdev] Re: (cont) EditorMagic

[Mat]

@Saq

The itemfilter stuff works. There is a noticeable delay which I estimate to 
be proportional to the number of items i.e the list of items is much longer 
for [[ than for << or <$ ... or perhaps more correctly expressed, it's 
probably proportional to the complexity of the itemfilter.

---

An observation (or is it faulty reasoning?): the itemfilter is only 
relevant if the popup tool also has a fragment ("??tr" does not use a 
fragment, to name one example). And, it is only if it has a fragment that 
it needs a triggerend. ...but if it has a fragment that *must *match some 
condition (e.g match a predefined string), then the triggerend becomes 
superfluous. 

Might this mean we could skip the use of triggerends all together? The 
general question is: Will the user want to construct a popup tool that 
produces a picklist where the item names are allowed to contain the very 
closing string for what triggers the tool? I think it might be fair to 
simply not allow this, or can you think of some case? ...Or is the premise 
of my reasoning flawed?

---

Amusing observation, if one is easily amused: If you type e.g [[Ed and move 
the caret with the arrow keys and then pick a title, the insert will be at 
the new place. Yes, that is "the point" but I hadn't considered this case 
:-)

---

Check out the new transclusion tool! It is super fun!!! Even for those who 
are not easily amused! Styling is totally messed up, but never mind.


<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/546f7924-6fb9-4451-8359-d897531b706do%40googlegroups.com.

[twdev] Re: (cont) EditorMagic

[Mat]

One would think I should be used to presenting myself as an idiot after all 
these years but, no, I constantly outdo myself.

You're absolutely right, somehow I failed to insert your code. Having now 
done so, it does work. Thank you! I'll continue with the other stuff.

<:-)


-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/2bf6e5f9-d99e-4b93-ba18-685c6e1dd061o%40googlegroups.com.

[twdev] Re: (cont) EditorMagic

[Mat]

Saq, thanks, but AFAICT it does not work as intended; If you type [[xxx you 
have the popup firing all the time (the artifact). Unless I misunderstand 
you, there should be no popup unless the em-itemfilter is fulfilled - ?

This has your new body/editor code installed: 
http://editormagic2.tiddlyspot.com/

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/e6249ad4-fef8-4369-a433-8a59fcf176e7o%40googlegroups.com.

[twdev] (cont) EditorMagic

[Mat]

Continued from Caret position - take 2 
  
(direct link to last page here: link 

)

@Saq:

http://editormagic2.tiddlyspot.com/

This works. I did still have to modify body/editor to make its vars pick up 
the correct fields from the template:

\define em-checkTrigger() 
<$vars
   template={{!!title}}
   trigger={{!!em-trigger}}
   trigger-end={{!!em-triggerend}}
   triggexp={{{ [{!!em-trigger}escaperegexp[]] }}}
   triggendexp={{{ [enlist{!!em-triggerend}escaperegexp[]join[|]
addprefix[(]addsuffix[)+]split[\/]join[/]trim[]] }}} 
before={{{ [splitbefore{!!em-trigger}] }}}
before-length={{{ [splitbefore{!!em-trigger}length[]] }}}
trigger-length={{{[{!!em-trigger}length[]]}}}
>
...

also note that $:/plugins/EditorMagic/styles is modified so the class 
assignment of "editormagic-popup" at bottom of body/editor is superfluous.

Please tell me if anything is not as expected.

<:-)
 




-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/1a573ead-cb5a-4bf5-a087-e28583801ff0o%40googlegroups.com.

Re: [twdev] Re: Caret position - Take 2

[Mat]

>
> Or even the version where only variables have been renamed would do the 
> trick.
>

OK, I'll fiddle a bit. 
BTW, google groups now split this thread into multiple pages which I hate. 
Let's start a new thread.

<:-) 

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/478596bf-f51a-4951-9a44-c6f84fcd3fc6o%40googlegroups.com.

Re: [twdev] Re: Caret position - Take 2

[Mat]

>
> No I mean the latest version where everything worked as it should. I 
> assume there was a time where you had renamed variables, and introduced 
> em-filter in popuptools but not yet in body/editor... and everything was 
> working as it should. That's the file I would like a copy of.
>

I'll make a new version fulfilling this as good as I can. (If I recall, I 
found that I had to make modifications to body/editor because there were 
dependencies but I'll see what I can do.) I'll get to this right away.

<:-)


-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/00f75c4f-118b-45a4-93f7-2f6858e68d9bo%40googlegroups.com.

Re: [twdev] Re: Caret position - Take 2

[Mat]

@Saq

OK... I can't tell if I'm on the right way. I might be. Typing e.g [[Edito 
shows populated popup as intended. Typing in e.g [[asdf seems to 
erroneously trigger the popup (i.e showing the artifact) but then leaves it 
hanging at a static position as one types the second letter and onwards. 
But if [[asdf is left there and focus is changed to elsewhere and one 
returns to continue typing e.g [[asdf then there is no recurrence of 
the popup.

I'm thinking this might be correct behaviour and that the very initial 
firing, giving cause to the empty popup, is because of a first and single 
call to emptyMessage=<> and then the artifact lingers 
because... I dunno... because there is no other instruction?

...and that might also be what causes this: If you type [[Edi]] the (full) 
popup lingers in spite of the closing brackets. And if typing e.g [[asdf << 
then the macro popup does not show.

Could you give it a test? http://editormagic2.tiddlyspot.com/

Yes, the current code inelegantly has two repeated blocks; one for 
has[em-itemfilter] and one for !has[em-itemfilter].
Also, only TitlePicker has the itemfilter so far.

For showing diffs, is gh the only way?

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/edc36821-3063-4391-90c9-333d3fcb8cbbo%40googlegroups.com.

Re: [twdev] Re: Caret position - Take 2

[Mat]

Yes the filter now works! (The problem were due to a totally other mistake 
on my side that surprisingly had not shown effects previously.)  
I'll get to the detection filter testing tomorrow. Head is too slow now.

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/b190f1c0-2725-4e5b-ac6d-8c68eca4b604o%40googlegroups.com.

Re: [twdev] Re: Caret position - Take 2

[Mat]

I'm afraid I don't get [subfilter{!!em-itemfilter}] to work.
In http://editormagic2.tiddlyspot.com/ 
 there are now two title pickers, 
for testing: the regular and one with em-trigger XX (and em-triggerend YY)

The regular one uses [subfilter{!!em-itemfilter}]
where that field is [all[tiddlers]prefix]

The XX version uses [subfilter] 
where the variable is defined in the popup as <$wikify name=em-itemfilter 
text={{!!em-itemfilter}}>

...but neither works. It seems that once it gets into the subfilter it 
becomes [all[tiddlers]prefix] i.e the  is lost.

You write:

> You may have to make sure the em-fragment variable is defined in the 
> detection code as well.
>

...but that can't be a problem for the above, right?, since reinstating the 
filter from the field into the code is how it was previously when the 
filter worked.

When you have time, please take a look - no rush, of course. Maybe I am 
using subfilter the wrong way but I don't think so...

Thank you!

<:-)
 

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/ac3f03a8-731d-4f9e-919d-f4d024bfd906o%40googlegroups.com.

Re: [twdev] Re: Caret position - Take 2

[Mat]

Initial tests fail. I posted a question here 
which I 
think describes the problem. Do take a look if you have time.

Expressed for our use case it is: putting  (now actually 
) in a field is, as far as I find, evaluated to be nothing 
once the field is called into any filter.

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/52a9d83b-5c5d-4dd6-871d-419e09ed3760o%40googlegroups.com.

Re: [twdev] Re: Caret position - Take 2

[Mat]

Calling it an "algo" was a bit pretentious of me. Upon inspection, the 
macros are just extracted by: 

[tag[$:/tags/Macro]search[\define]get[text]splitregexp[\n]removeprefix[\define]trim[]prefix]

and the widgets were indeed a static list. I did some experiments earlier 
to generate them dynamically from the core (which is preferable) but they 
are currently a plain list.

Anyway, are you saying filters like the above should be in a separate field?

<:-)



On Saturday, July 18, 2020 at 7:11:05 PM UTC+2, Mat wrote:
>
> Aha, a field, that's an interesting idea. So this should be used both in 
> the tools local code and in the /body/editor?
>
> Do consider that [all[tiddlers]prefix.. is not relevant for 
> anything but tiddler titles though. For e.g macros, at least in the current 
> macro picker incarnation, the macro names are "calculated" in the tool (i.e 
> extracted by going through all $:/tags/Macro tiddlers). Basically the same 
> for widget names. My point is that at detection code stage (presumably in 
> /body/editor) these things are unknown, except for tiddler titles and 
> unless we calculate everything already there or have the macro and widget 
> lists hard coded.
>
> ...possibly the full algo to generate "the list of whatever items" could 
> be put in a field?
>
> <:-)
>

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/191c267d-9768-4299-8d7d-cd9486c435e7o%40googlegroups.com.

Re: [twdev] Re: Caret position - Take 2

[Mat]

Aha, a field, that's an interesting idea. So this should be used both in 
the tools local code and in the /body/editor?

Do consider that [all[tiddlers]prefix.. is not relevant for 
anything but tiddler titles though. For e.g macros, at least in the current 
macro picker incarnation, the macro names are "calculated" in the tool (i.e 
extracted by going through all $:/tags/Macro tiddlers). Basically the same 
for widget names. My point is that at detection code stage (presumably in 
/body/editor) these things are unknown, except for tiddler titles and 
unless we calculate everything already there or have the macro and widget 
lists hard coded.

...possibly the full algo to generate "the list of whatever items" could be 
put in a field?

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/903b100e-3f9b-4125-b62c-6bfbcebbd8e9o%40googlegroups.com.

Re: [twdev] Re: Caret position - Take 2

[Mat]

Hm, that's already in place in the tools, but maybe you mean move it from 
the tools upstreams into the popup tiddler?

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/3b1e1a3d-f951-4190-805e-a733e619661co%40googlegroups.com.

Re: [twdev] Re: Caret position - Take 2

[Mat]

OK, so I've fiddled on with minor tweaks. Do take a look when you have time 
and tell if you think I should change something.

http://editormagic2.tiddlyspot.com/

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/90c21fd7-8de3-4705-a595-a7f41bd3cd7eo%40googlegroups.com.

[twdev] Re: [Dev][Visual Studio Code] Announcing Syntax Highlighting and Intellisense Plugin for TW5

[Mat]

Ah, what a great idea. This should be a most wonderful contribution for the 
VS users!
Thanks for sharing great stuff Joshua!

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/c354fde1-75d5-49bb-81e4-f31aec8577d3o%40googlegroups.com.

Re: [twdev] Re: Caret position - Take 2

[Mat]

Saq,
 

>  Perhaps targetTiddler instead of editedTiddler?


Will change.
 

>  I think a user you expect to write regular expressions, can also be 
> expected to read docs and use em-trigger instead of trigger.
>

:P I'll change it. 

$:/plugins/EditorMagic/styles


OK, so my point was more if I can modify the styles you added - which I now 
interpret as "yes".
 

> Arrow keys do not change the content.
>>
> I already wrote JS that resolves this some days ago, but the downside is 
> it makes the action-popupcaret widget much less generic.
>

Ah, I mistook the mere pressing of a key to be what fired the action. 
Anyway, could perhaps your JS be an "addon" *to* the action-popupcaret 
widget, so it doesn't modify it? Maybe if there are hooks in the widget 
(I'm probably using the term 'hooks' wrong).
 

>  
>
>> 3) The recursive macro and what it solves:
>>
> As far as I know we don't have any other easier and efficient way to save 
> variables for every step of a list widget run, have them persist and 
> update, and compare them afterwards.
>

(JS?)

I don't see an issue with complexity here as users of the tool would not 
> need to tinker with this, unless you don't feel comfortable enough with it 
> to maintain the code?
>

OK, I think it'll be fine. 

Thank you!

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/cb7749ba-0971-4c5c-ad1b-e06b5bb0d4e0o%40googlegroups.com.

Re: [twdev] Re: Caret position - Take 2

[Mat]

@Saq http://editormagic2.tiddlyspot.com/

First, unless you object, I will hereon refer to the end user popup content 
templates as "popup tools" or, if the context allows, just "tools". And we 
can now call the /_Popup tiddler simply "the popup".

The popup is now fully reworked. It has two groups of variables. See if you 
think any of them should be moved upstreams into /body/editor. It feels 
like the popup ought not have anything to do with the state tiddler. BTW, 
the editedTiddler variable refers to the viewtemplate tiddler of a tiddler 
being edited; in our case it'd be "RikerIpsum", and this variable is used 
in e.g transclude tools.

Changing variable names is not as obvious as I thought: The system 
variables should be prefixed with em-. But IMO variables that the user is 
in direct contact with should be as friendly as possible. For example, when 
he creates a popup tool I think it is better if he creates the "trigger" 
field as opposed to the "em-trigger" field. Yes/no?
And "fragment"... I guess it could be changed into "nameprefix" or 
"em-nameprefix" but I'm not sure that is more informative. It must not be 
"titleprefix" because it is not always titles.)

3) The "false fragment problem" i.e that  <$ or < [...] leave it alone for now, but be prepared to have to deal with it.
>
OK.


Q's for you

1) The styling you've put in $:/plugins/EditorMagic/styles - mess up e.g 
buttons inside the popup (e.g the 100% width). Were these styles added to 
e.g harmonize with your floating editor tools, or why were they added?

2) Merely stepping with the arrows is not sufficient to trigger anything. 
Eg, if it says <$ it is not merely enough to arrow ones way to after to $ 
to fire popup. It would be nice if it were, because currently one needs to 
e.g insert some character and delete it to trigger the popup. Do arrow keys 
not fire actions like other keys?

3) The recursive macro and what it solves:

> We want to test all definition tiddlers for matches, and at the end decide 
> what to do. 
>

I have this nagging feeling it could be made simpler than with the 
recursive macro by using some kind of external state value that is changed 
for each match. Maybe each match could append the title to a list. At the 
end we just extract the first title?
I actually like recursions (except their binary behaviour to fully work or 
absolutely not ;-) but because it is part of the wikitext I feel it is 
advantageous to keep it as simple as possible for others reading it. 

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/73bebfb6-bf22-4fd0-8119-470a51ce2dafo%40googlegroups.com.

[twdev] Re: Could gh host TW for multi user?

[Mat]

Jed Carty wrote:
>
> Unless GitHub had added new features I don't know about no, it couldn't be 
> hosted on GitHub. What would GitHub add in this instance? it is just 
> another moving part to handle.
> The backend could do whatever you want it to do, so yes you could do timed 
> fetches.
> And yes, that is what I meant when I said that having the back-end server 
> would take care of https-vs-http 
>

So, the admin-host-wiki has to be updated *manually* if TWederation is to 
work on GitHub*.* As we know this doesn't work very well.
And the admin-host-wiki can be updated automatically if TWederation is 
hosted on another service. Could work IF there is such a service.

Jed, you've generously offered your Ooktec server to the community for TW 
projects previously, even if I'm not aware of anyone picking up on it. Does 
this still stand? (*Fully *understandable if it doesn't. It would also be 
understandable if you said you needed to charge for it, even if involving 
money has side effects of course, or any other condition.)

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/8031e4e9-dddb-4988-a4b2-01b7d1139092o%40googlegroups.com.

Re: [twdev] Re: Caret position - Take 2

[Mat]

Just noted something; typing e.g [[xx will trigger the popup (i.e the 
mere artifact) in spite of no tiddler prefixed such. Is this a problem? If 
it is, I'm thinking some "late" filter is needed, i.e after the mechanism 
knows "thing" is looked at (i.e is it a title or a macroname, etc) ...so it 
if we want to keep the separation of concerns between /body/editor and 
/Popup, I guess this should also go into /body/editor somewhere... IFF this 
all is a problem. 

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/9fe35ea2-2464-4ea0-9d09-be36ddf66c5do%40googlegroups.com.

Re: [twdev] Re: Caret position - Take 2

[Mat]

Saq Imtiaz wrote:
>
> The only changes while our messages crossed where renaming macros and 
> removing unused variables
>

Excellent. Will look closer tomorrow and polish up on things. 

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/0bdc3096-83cd-473b-8df0-73e1a55bdcbao%40googlegroups.com.

Re: [twdev] Re: Caret position - Take 2

[Mat]

Saq Imtiaz wrote:
>
> Mat: I've renamed the macros to facilitate comprehension. Beyond that I 
> will wait for you to verify that the behaviour is correct before cleaning 
> up the code further.
>

OK, as you see in my previous post I did fool around a bit with it and I 
think it works correctly (except the iframe but I guess that's not what 
we're dealing with right now). 

Note that I've tried to address both the issue with deleting the popup 
> state when there are no matches, as well as making sure it is the last 
> match (closest to the caret) that triggers the popup, rather than it being 
> based on tag order as it was before.
>

Yes, this is very good. Looks great to delete one character at a time in 
that string with triggers and have a new pop up show with the correct 
content and at correct location - and no green artifact if there is no 
trigger :-D

BTW, I'll also polish the popup and the popup content tomorrw.

Now another forum alert about new message. We're posting past eachothers.

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/8a51d7bf-3ada-4a5b-af19-0d9f868e0bdao%40googlegroups.com.

Re: [twdev] Re: Caret position - Take 2

[Mat]

@Saq, thank you. 

First regarading:

Also, if you look at the Browser Developer tools console (ctrl+shift+I on 
> chrome), there is some additonal debugging going on. 
>

If I interpret it correctly, that's why the iframe for WidgetDocs doesn't 
work.

I'm guessing the above does not have anything to do with the fact that 
typing <$ now only shows one popup content, as opposed to two contents 
previously i.e both WidgetDocs and the WidgetPicker that use the same 
trigger. I.e can a trigger now only trigger a single content in the popup? 
(namely thei first title, alphabetically). This is not a problem (one can 
modify the popup content to feature multiple things if one wants to.)

About ../body/editor 

That's some pretty advanced coding now. Lots of levels - which might not be 
desirable per se but I'm impressed how/that you seem to have solved it. I 
don't understand how you realized you should do a recursive popping back 
and forth between processM..A..T and processNext.. but well done.
BTW, I think magic-actions-tiddler variable is unused.
...and $action-log is that for testing?


+1 to what you did with the test tiddler, I always do that sort of thing to 
> help debug actions.
>

Yeah, it was needed. Side note: May I ask if you use any particular tools 
for your dev? For one thing, I assume you don't develop directly in TW as I 
do (in the SideEditor) but I never understood how it can be effective to 
not see the results directly. Or do you, somehow see the results live?

Tomorrow I will implement the bit about:

 I wonder if would be helpful to set 
currentTiddler={{{[get[template]]}}} 
> at the beginning of the popup, allowing you to access trigger as 
> {{!!trigger}} etc. This is more a question of coding style and preference 
> though.


What other things can you think of that I can do? 

Now I see a forum note about a new message here, so I'll post this before 
writing further.

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/9bc60b1a-0348-4771-814c-cda88e63041do%40googlegroups.com.

[twdev] Re: Could gh host TW for multi user?

[Mat]

Jed Carty wrote:
>
> To make the equivalent thing to what you describe each participant just 
> needs to fetch from whoever has the administrator role. the admin would 
> have to fetch from each contributor wiki but if that becomes an issue the 
> admin wiki gets a node backend like Bob that can handle the workload better 
> than a browser. 
>

Could an admin host a Bob on gh?
And could this be set up to handle fetching automatically? E.g at timed 
intervals?

...and...
 

> A back-end for the admin would also handle the problems with http vs https 
> as long as the admin was on a server with https.
>

...so it could fetch from tiddlyspots? (http) 

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/c23b6422-fdc8-4cb1-a1cd-b3d35024394co%40googlegroups.com.

[twdev] Re: Could gh host TW for multi user?

[Mat]

To put it totally plainly:

@Jed, if possible, could you please make is so that only the fetching side 
is required to have the plugin?

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/b71d53ef-b8b2-48de-8b13-17141588d374o%40googlegroups.com.

Re: [twdev] Re: Caret position - Take 2

[Mat]

Saq Imtiaz wrote:
>
> @Mat do not test the code I posted yesterday, I did some more tinkering 
> late last night. Just need to find time to look through it carefully and 
> test.
>

Thanks Saq, including thanks for the "warning". Looking forward to whenever 
it comes.

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/3fd2fee5-06dc-4e3f-b5c0-fdcb6ed14116o%40googlegroups.com.

Re: [twdev] Re: Caret position - Take 2

[Mat]

@Saq, I'm really looking forward to try it out but I'm afraid this will at 
earliest be done tomorrow night.

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/5598b248-ecba-47f5-a1e2-177566550a46o%40googlegroups.com.

[twdev] Re: Could gh host TW for multi user?

[Mat]

Jed Carty wrote:
>
> I think that something like twederation would be a much easier thing and a 
> lot of the work is already done.
>

Forgive me, but what is the status with twederation? 

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/28be191b-4333-4bea-9a5f-5c0226ff6e45o%40googlegroups.com.

[twdev] Re: Could gh host TW for multi user?

[Mat]

Jed Carty wrote:
>
> Magically taking care of conflicts is going to be the big sticking point.
>

But not if the repo owner handles it right? (Just so I don't misunderstand).
Does gh otherwise have a 'conflict handler' or does it fully rely on manual 
handling for this?

We may be able to do something like you are describing that lets you see 
> the conflicts and handle them manually with a reasonable interface, but 
> that is a very significant project by itself.
>

Yes, but it would open up a LOT of possibilities for the community and also 
outside of it.

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/0e0d0e9a-b329-43ec-8948-e41dccefd7d9o%40googlegroups.com.

[twdev] Re: Could gh host TW for multi user?

[Mat]

Thanks for replying PMario.

This would mean, that TW would have to be a "full blown" Git-client with a 
> lot of "magic". ... I'm not sure if we want to go that route.


Why?

My main point was if it is possible to eliminate the need for the user to 
face gh - other than possibly the initiator/owner of the repo (but ideally 
not even that person). For example, the steps currently required for making 
PRs for the TW docs (as opposed to code) is "too much gh" for what I'm 
asking about.

It would not be a problem that a "full blown Git-client" has a lot of magic 
because the intended user (i.e the vast majority of TW users) would not 
need to understand nor fiddle with the internals of it anyway. The user is 
reasonably presumed to be interested in TW and the collaboration project he 
takes part in, nothing else.

<:-)



-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/649add0f-c865-47ad-add1-475cf5cf33beo%40googlegroups.com.

Re: [twdev] Re: Caret position - Take 2

[Mat]

Saq Imtiaz wrote:
>
> I'll try to find time to investigate this weekend.
>

Excellent. 

Part of my goal here is to make sure you are comfortable with the wikitext 
> portion of the code, so that if this does get into shape for release you 
> are able to maintain it and provide support. 
>

Even more excellent.

 the popup content tiddlers. When I find the time I'll have a look to see 
> what can be done in terms of simplifying them.


Thanks. I didn't add all of them yet and they're not very polished even if 
the structure of them is valid.

github

I will write up instructions for using the web interface when I get the 
> chance, and I'll encourage you to give it a go at that time. 
>

Thanks, that's really kind of you and should be of benefit also for others. 
I understand the frustration it's causing you.

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/d0417504-4c3f-48f1-bdfc-14a93a79fac7o%40googlegroups.com.

[twdev] Could gh host TW for multi user?

[Mat]

Is this even hypothetically possible with the current version of gh:

To host a TW on gh, i.e in the way so it is presented as a usable wiki (not 
as merely files), and multiple users can have user rights to make 
contributions (i.e modifications) directly to it... but there's also some 
way to restore stuff if misused?
...and to have a native TW gh saver - the existing one or another - be what 
"uploads" the modification?
...from a single file vanilla TW?

I.e the goal would be that someone can put up a TW and other users (with 
enough rights) can really use any TW with the right saver to upload stuff 
to it. Conflicts magically handled by gh. And the other users are NOT 
familiar with gh other than that they have registered as a user there.

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/9e6e10a6-83ae-45ee-acf0-a0160c85130co%40googlegroups.com.

Re: [twdev] Re: Caret position - Take 2

[Mat]

Saq Imtiaz wrote:
>
> This is probably because you are inside a list widget, so for every type 
> of autocomplete defintion (eg widget, macro, etc) that doesn't match, you 
> end up deleting the state tiddler even if there was a match in another type 
> of autocomplete defintion.
>

Aaah, of course.
 

> The logic needs to be:
> - loop through all autocomplete definitions
> - if any of them match -> trigger popup
> - if none of them match -> delete state tiddler
>

I had a go using another logic. It *almost* works:

\define deletePopState()
<$list filter="[get[template]!match]">
<$action-deletetiddler $tiddler=<>/>

\end

I.e only delete if what is currently investigated does not match the 
template in use. Problem is, there is no "template in use" until one has 
been set. But if we could set a faux template value in em-state to begin 
then nothing will match this, until the template in use is set, upon which 
no subsequent investigation will match that either. I think it could 
work... but it would also mean there'd be a state tiddler with the faux, 
then real value, hanging around, perhaps until deleted when tiddler closed. 
Not a good solution but I'm mentioning it in case it gives you ideas.

As you note I also followed your advice and introduced an "em-state" 
variable instead of calling the qualify macro all the time.

By the way, how do we determine priority? I mean if we have an incomplete 
> [[ and <$ how is it determined which is being completed? Should be the one 
> closest to the caret, not sure if that is how it is already and if so, how 
> that is ensured.
>

That sounds like my original problem in trying to decide where a string 
ended and which was seemingly magically solved once you stepped in. But... 
yeah, isn't it automatically the one closest to the left of the last key 
stroke?


Overall I think it's definitely headed in the correct direction and you've 
> done a good job with the refactoring.
>

That's encouraging to hear. Your instructions are, obviously, indispensible.


- When the popup is shown, it reads info from the state tiddler to 
determine what content to show. All the wikitext related to WHAT to 
 show 
stays here.

 It is almost like the popup is just a template now that shows 
> information based on what is in the state tiddler, by transcluding other 
> tiddlers. A very TW approach in my opinion.
>

Yes. Interestingly, the popup content tiddlers are also basically 
templates. As I've mentioned, one hope is for users to be able to create 
these "end templates" themselves, since we probably can't predict what 
they'll want access to, so I'm wondering what can be moved upstream into 
the popup. They're a bit too complex now, I feel, but I'm not sure what is 
general enough to move.

 I wonder if would be helpful to set 
> currentTiddler={{{[get[template]]}}} at the beginning of the 
> popup, allowing you to access trigger as {{!!trigger}} etc. This is more a 
> question of coding style and preference though.
>

Yes, this is exactly one of those things, assuming I understand you right. 
A user constructing his own template will be very confused if {{!!trigger}} 
does not access the templates trigger value.

 

> git saver
>>
>> I took a quick look and did get it working. 
>

I can tell you didn't see my reply before I re-edited my post ;-) As for 
seeing diffs, isn't there a plugin with this feature? Maybe it's only for 
TW on node. 

But if there was some kind of git saver that made it possible to use a TW 
as a proper multi user wiki, that would make it very worthwhile for me to 
grab the bull by the horns and study this properly. (As I indicated in my 
deleted text; I have tried, quite a lot actually). Do you think that would 
be possible - i.e a published wiki on gh that many people can edit... 
including some checkin/out or versioning...?


Note that the patch which adds inputActions to the edit widget has been 
> merged as is now part of the latest pre-release.
>

Yay!

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/2ca5ed95-d430-4a41-b8bb-aae772989b49o%40googlegroups.com.

Re: [twdev] Re: Caret position - Take 2

[Mat]

Saq Imtiaz wrote:
>
> Have you made trigger-end available as a variable in the popup?
>

Doh! Now added and it works.

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/7815b89a-6086-4695-9432-628a5cf7a4b2o%40googlegroups.com.

Re: [twdev] Re: Caret position - Take 2

[Mat]

Thanx, it was indeed misplaced outside of the button. It now works but no 
trigger-end is appended. I'm leaving it for your to look at.

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/7e613690-764c-423f-abda-ea7d2c4dfd80o%40googlegroups.com.

Re: [twdev] Re: Caret position - Take 2

[Mat]

Saq, no rush whatsoever.

I just also updated the TitlePicker to include that keyboard shortcut code. 
It doesn't do anything so I'm guessing something more is needed.

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/81e899d6-843e-4f52-8016-0f230232fc0ao%40googlegroups.com.

Re: [twdev] Re: Caret position - Take 2

[Mat]

OK, updated http://editormagic2.tiddlyspot.com/

I think I've now managed to separate concerns between the /body/editor and 
/_Popup. It is worth noting that what exact data, and which exact values 
that should be stored in the state tiddler or which variables that should 
be defined in /_Popup can depend on what the end popup content tools need. 
Currently, the only defined variables in _Popup are "tid" and "text" (not 
ideal variable names btw).


>>>- If there is no match, we cancel any already shown popups.
>>>
>>> I'm not sure how to handle this, see previous comment.
>


 Things are getting really to look pretty darn cool!!!

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/06b0d97b-35bd-416c-bae9-b660948e4ffdo%40googlegroups.com.

Re: [twdev] Re: Caret position - Take 2

[Mat]

OK, complex stuff. Status for  http://editormagic2.tiddlyspot.com/  is 
described here:

All noteworthy changes is in /body/editor - in effect I've transferred 
everything from /_Popup , effectively integrating the $action-popupcaret 
call with the other popup stuff. This may be a mistake and you suggest 
another route which I will attempt tomorrow.

I intentionally put a green border on the popup to get the artefact to 
indicate that the popup is active and where it is.

Other:

>
>>- User types in *edit* widget 
>>
>>
>>- for *every keystroke* edit widget invokes *actions* 
>>
>> (check, check)

>
>>- in these actions in *$:/core/ui/EditTemplate/body/editor* we have 
>>our wikitext code from EditorMagic/_Popup which checks IF there is a 
>>trigger-start that should prompt the showing of a popup. 
>>
>> check 

>
>>- Only *if* there is a match, do we invoke action-popup-caret.
>>
>> check 

>
>>- We can also save extra information to the state tiddler, like what 
>>text triggered the match, what kind of popup to show (link, widget etc)
>>
>> check for which popup content to show

>
>>- If there is no match, we cancel any already shown popups.
>>
>> failed attempt - I made a "deletePopState" macro but calling it gives 
RSOE Uncaught TypeError: Cannot read property 'left' of undefined
(to locate the call: it's in editorMagicActions in the inner ListWidgets 
emptyMessage )


>>- When the popup is shown, it reads info from the state tiddler to 
>>determine what content to show. All the wikitext related to WHAT to show 
>>stays here.
>>
>> not done yet 


Either you need to extend trigger definitions with a "type", eg widget, 
> links etc. Or, be able to use the <> (<< or <$ etc) for the 
> purpose of knowing what display logic to use. 
>

I just save the popup tool name (ref to as "template" in the code) in the 
statetiddler.
 

git saver
>>>
>> I would hope its as simple as, set up a github repo to use github pages, 
> upload file via web interface. Then load it via web URL and save as you 
> would on tiddlyspot.
>

Well it certainly isn't simple for me... the TW docs 
 say "password of 
which *one *type is a personal token", but the TW ctrlpanel seems to 
require, specifically, a token... and getting a token on gh is filling out 
a long form where I'm supposed to select which scope it is to have, but I 
have no clue. And even if I did, the next step in the TW Ctrlpanel is 
specifying a repository... but when creating one in gh, I'm supposed to do 
it via the command line and ...gaaah. And even if I would magically 
succeed, based on my experience from contributing to the TW5 repo, I fail 
to do it even when things are set up. I can make doc contribs but that's 
it, and even doing that is totally magical in the negative sense. I've had 
it shown to me, explained to me, etc etc so I get that I'm at fault since 
everyone else thinks it's so self evident. Sorry for the rant.

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/09371123-7a24-4fce-a573-f13032381083o%40googlegroups.com.

Re: [twdev] Re: Caret position - Take 2

[Mat]

Appreciated. It wasn't really selectionEnd that I wondered about but more 
that full filter construct and split[] that didn't quite make sense... but 
now it seems obvious ;-) But, yeah, I should probably check back even more 
in your posts regardless. Thanks for being so detailed. And patient!

Give this a go and see if it works:
> https://saqimtiaz.github.io/sq-tw/editormagic2.html
>

IF these changes are also supposed to deal with the move-with-arrow-keys 
issue, then that aspect does not seem to work fully yet. But, yes, it does 
show the popup and I'll continue with the wikitext. (My *first *tests 
indicate I must keep the trigger controls etc in _Popup anyway, making for 
such checks both there and around the $action-popupcaret.)
 

I wonder if it would make things easier if you used a TW file hosted on 
> github with the git saver, so I could easily see what had changed in each 
> file. I haven't used the git saver but it should in theory be as easy as 
> using tiddlyspot.
>

I have not used it either. I'll do a quick investigation but given my 
failing adventures with gh at large, I kind of doubt it will be as simple 
to use as tiddlyspot.

Thank you.

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/bc69cb1e-a6c9-4df0-9ca6-5597fd163db4o%40googlegroups.com.

Re: [twdev] Re: Caret position - Take 2

[Mat]

OK thanks, I'll see if I can just get it working, even if inconsistently, 
in which case I can instead work on _Popup.

What exactly does this do: "[{!!text}split[]firstjoin[]]"  - 
maybe discard everything in the full text after the fragment? I need to 
know in order to replace selectionEnd with something, so to say.

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/4a89324d-9505-47c7-905c-c0acaf750920o%40googlegroups.com.

Re: [twdev] Re: Caret position - Take 2

[Mat]

>
> 1) How much stuff can actually be put in editorMagicActions() without 
> overloading the poor inputActions parameter? A simpler filter surrounding 
> the $action-popupcaret call did work.
>

Better phrased: What are the rules for what is allowed as an attribute 
argument - and in what way am I breaking them in my attempt?

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/5456aa56-a9f4-472d-9a00-f528f7269045o%40googlegroups.com.

Re: [twdev] Re: Caret position - Take 2

[Mat]

OK, so I made this which does not work: http://editormagic2.tiddlyspot.com/

1) How much stuff can actually be put in editorMagicActions() without 
overloading the poor inputActions parameter? A simpler filter surrounding 
the $action-popupcaret call did work.

2) Any idea for how to put in flags in the inputActions parameter argument 
that somehow comes thorough so they can be seen? I don't expect there to be 
a way, it would just simplify tests if there is.

3) Is my attempt just totally off? Perhaps I shouldn't put stuff directly 
in the inputActions parameter at all. Maybe the mechanism should be used to 
decide if that whole editor call should be used or if a fallback editor 
should be used?
 
P.S I'm aware the _Popup will also need mods but I don't think that is why 
no popup shows with the above attempt.

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/02463c7a-cb21-43d2-b9ba-003fea23178fo%40googlegroups.com.

Re: [twdev] Re: Caret position - Take 2

[Mat]

>
> I can help but I wont have much time until the weekend at the earliest to 
> do any real coding on this. If you do decide to work on this yourself, 
> questions I can try to answer more promptly.
>

I'll start and we'll see how it goes :-)
 

> Also note that I have no real knowledge of the internals of your wikitext 
> code beyond the title picker, so there would be a learning curve there for 
> me as well. So I would need a chunk of uninterrupted and focused time to 
> get started.
>

Haha, the only thing that would be challenging is to understand the errors 
I make.

 

> It was only meant as an idea for stop-gap kb shortcuts until proper ones 
> for arrow keys can be implemented, not an alternative. 


OK, I'll put it in the titlepicker to see how it performs.


I would think that any list of results (at least for tiddler titles) should 
> be capped to say the first 10 or so, and the user expected to type more to 
> narrow down choices. '


That only works if you know the name of what you're looking for though, so 
you can at least type its initial.
I'm thinking maybe the standard search mechanism could be hijacked in some 
cases, so to find e.g a title you can type a tag. Only relevant for some of 
the tools, and I haven't thought it through.

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/bf28d452-287f-48d5-89bf-efd880eaab20o%40googlegroups.com.

Re: [twdev] Re: Caret position - Take 2

[Mat]

If you say that's a good idea then I believe you.

Given that it's all wikitext changes, are you requesting that I implement 
it? I can probably do that given enough time but I'm sure there will be 
several missteps along the way.

Regarding the keyboard numbers your write:

But since it would be better to add proper support for keys like arrow keys 
> for up and down, enter key etc, don't spend too much time on this.


I do think there should eventually be "regular" arrow key support so, at 
least for now, I'll put these numbers only in the title picker to try it 
out. Needing to locate, say, 7 on the keyboard doesn't quite feel like a 
work saver instead of arrowing through. Perhaps locating 77 on keyboard is 
easier but then I think it would make more sense with some key that makes 
the arrow jump 10 steps at a time instead.

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/97b0d6f1-b8b1-4958-b81e-96361ca3de59o%40googlegroups.com.

Re: [twdev] Re: Caret position - Take 2

[Mat]

Q: Does a text with many "unused triggers" tax the system? Or, for that 
matter, also used triggers, i.e that are closed? For example, are there 
"event listeners" constantly pinging the system in any of the non wikitext 
code you made? (I only know the term "event listener" so I don't know what 
to look for in the code.)

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/6ef44a18-1bb0-4e81-9559-2bd6aacba1e0o%40googlegroups.com.

Re: [twdev] Re: Caret position - Take 2

[Mat]

This adds an index:
 
<$vars count={{{ myfilter +[count[]] }}}>
<$list filter="[range]" variable=n>
<$list filter="myfilter +[nth]">
<> <>




Do you suggest I put this into each popup-content-tool that shows a 
list? (BTW, calling them popup-content-tools sucks. We need a real name.)

Off topic: I requested an array feature in the listwidget not long ago but 
@Jeremy explained the listwidget is already very complex. Maybe there could 
be an arraywidget that takes a filter and binds each item to a position. 
The array could be treated like a "composit variable" (yes, I just made up 
that term) so to call it and access a specific item one would write 
<> or <> or even <>. 
I'm thinking the latter would not clash with dic tids since the latter are 
invoked via transclusions. A filter operator could be 
array. 

Back on topic:
Just a note - I think it is your $:/core/ui/EditTemplate/body/editor that's 
missing the $:/EditorMagic tag. I'm only mentioning this to save you from 
possible confusion later if you e.g tag-drag'n-drop.

<:-)



-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/c2db033e-07fa-44d8-9cb2-3c11fcee147co%40googlegroups.com.

Re: [twdev] Re: Caret position - Take 2

[Mat]

OK, I put in tc-popup-keep and it works perfectly. I'm not even sure what 
the downside is supposed to be. 

Can we find a way to make it:
> <$text text=<> /> X
> where X represents the position in the list, i.e. 1, 2, 3


If it is only a matter of visuals, I can do with with CSS. I suspect you 
want something more with it - ?

Next, I'll re-read your previous explanations here and keep on introducing 
a few other tools for testing. 

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/1bf5e323-921e-4b8c-8f30-7441185f61cbo%40googlegroups.com.

Re: [twdev] Re: Caret position - Take 2

[Mat]

Sorry for confusion. I did write that "Having now tried it I'm finding it 
is not an issue." so I only asked out of curiosity and I now understand 
that the replace code doesn't bother with the trigger-end, which is what I 
misunderstood.

[...] I have my fingers in too many pies already and releasing plugins 
> comes with a maintenance commitment.
> The intention behind the demos I share is to hopefully inspire/provide 
> ideas and techniques for others to follow.
>

Fair enuff and your contributions and demos are appreciated!
 

> [...] the popup *loses focus* as soon as the selectwidget or editor is 
>> touched. Any ideas for this?
>>
> [...] give it the class tc-popup-keep.
>

Thanks. I find no mention of RevealWidget (i.e reveal) in the tiddlers 
tagged $:/EditorMagic, Maybe it is invoked in 
$:/plugins/EditorMagic/reveal-widget-tweak which I dare not touch - ?


Note that  the ??tr present at the beginning of the tiddler adds a 
> transclusion portion to every other popup created. This seems to not be an 
> issue with an incomplete link or widget, but with ??tr so perhaps its 
> limited to those with no end-trigger? 
>

Interestingly (and luckily), it seems to be the other way around: I had 
mistakely kept a faux trigger-end in the tool for ??tr (i.e 
EditorMagic/TransINclude) and have now removed it, which also removed the 
undesired popup content.


> This is related to the next issue you bring up.
 

> Looks like you missed some bits when integrating my code from 
> https://saqimtiaz.github.io/sq-tw/editormagic-popup.html#EditorMagic%2F_Popup
>
> <$list filter="""[searchremoveprefix]
> +[!prefix[ ]splitregexp]
> +[!search::regexp]
> +[last[]]""">
>  <$set name=fragment filter="""[]""" select="0">
>  <$list filter="[minlength[1]]">
>  <$list filter="[all[tiddlers]prefixcount[]!match[0]]" 
> variable="_NULL">
>  
>
>
The thing is, not every tool requires a minlength of one. The TitlePicker 
does because there are so many titles, but it would be a mistake to demand 
it for e.g widgets or macros where you might not have any idea what the 
initial letter is until you see it. So I moved the yellow text into the 
TitlePicker. Not to mention triggers like ??tr that don't have a fragment 
(the trigger is those four characters).

Apropos the arteface in the image you posted: This is caused from the code 
below the yellow, specifically the border which I've now changed to be an 
outline with an outline-offset:-1px to solve it.

There are some changes I think we need to make next, to the order of the 
> wikitext code that controls triggering the popup. However, I will wait for 
> you to work out the issues discussed in this post and properly integrate my 
> previous changes before I get into that.
>

Terrific. I've updated according to my comments - which means tc-popup-keep 
has not been resolved and the yellow is not re-introduced but still found 
in TitlePicker.  By the way, I'm sorry if I seem very slow in everything 
but every little thing takes a lot of looking up and testing etc. Just 
replying to this took over an hour. *I don't mind that*, it is very 
constructive and your help is super valuable, I'm just a little stressed 
that you might think I'm not doing anything.

Again, thank you!

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/0733816e-2831-4750-acb4-015bfea8930bo%40googlegroups.com.

[twdev] Re: Another Caret issue?

[Mat]

Well, putting the caret at correct position in the editor is what I was 
talking about too. But i figure the position in the editor needs to map the 
position you're clicking at in view mode - so you need a way to decide 
where that is. Anyway, I obviously don't know anything about this.

using a custom view template on tiddlers that contain macros etc but viewed 
> as we view in edit mode, unrendered.
>

A viewtemplate that show the wikitext code... OK so for it to be useful, 
how do you go from normal edit view into this view? And is that 
simpler/faster than to just find the location the manual old fashioned way? 
Because that is the goal, right?, to quickly access a specific position in 
the editor.

<:-)

>

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/530cf0be-9cc3-4511-b85f-38631ff926f2o%40googlegroups.com.

[twdev] Re: Another Caret issue?

[Mat]

[This is beyond me but anyway]

I'm thinking each "special rendering" such as a list, a transclusions etc 
will have to be identified as one unit when clicked on. So even if the 
caret position in view mode is calculated, this position - say 200 - could 
be after a few transclusions meaning that it in the code is really only 
position 20. To know that 180 has to be deducted, means one has to identify 
and calculate the character lengths of those transclusions. Including 
possible transclusions inside those transclusions, etc.

But maybe one can go the other way; start by peeking into the wikitext in 
the editor. There could be a "faux caret character" (for lack of better 
term) set inside the wikitext that shows up in view mode. If this caret 
could be steered, e.g via arrow keys (to type/delete it as it "steps") one 
could manually move it to where one wants to edit and "click enter" to 
switch to edit view - and with a positioned caret. Bt positioning the 
faux caret like that sounds like more work than just entering edit mode and 
searching up the correct position. So steering the faux caret would need a 
better way, perhaps ideally by having it "follow the mouse". And that's 
where I've twaddled enough ;-)

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/14073e17-666f-469d-b351-e230225782a7o%40googlegroups.com.

Re: [twdev] Re: Caret position - Take 2

[Mat]

I must say: This is just so much fun!

Right. This is actually the same bug as the one we discussed before [...]
>

Good.
 

> Regarding different trigger-end options: I have to admit I am not familiar 
> with your code beyond what was in the simplified demo at the beginning of 
> this thread. I think your approach should be OK though I am not clear on 
> workflow, do users get to choose which ending to use? Anyway, best way to 
> figure it out is to try it.
>

I'll detail my various findings below, but yes; one of the main ideas is 
that users should fairly easily be able to create their own popup tools. 
Having now tried it I'm finding it is not an issue.

But I'm curious: even for pre-made popup tools, the system will still have 
to know if <$widget foo> is closed or not. So how is the fragment end 
detected? In the EditorMagic/_Popup it is defined to be the "whole string" 
after the trigger until a trigger-end... but it seems your code defines the 
fragment as after trigger until caret. Is that correct? ...in which case I 
should remove the trigger-end check... but then, "until caret" can mean the 
*rest 
of the whole tiddler text*...? 

 

> Personally I think autocompletion makes sense for some things, like links. 
> For others, like widgets, just detecting which widget the user is trying to 
> type and showing the relevant docs in the popup might be a better approach.
>

IMO widgets are so very ubiquitous so their use should be simplified as 
much as possible. Plus they look scary for newcomers so a popup could be a 
kind of wizard. I also think it were better if I could make a popup tool 
where there isn't such separation between docs and picking - i.e, the 
current popup docs approach is an iframed tw.com but this is just a 
compromise and it brings with it a lot of redundant/distracting stuff and 
it is not ideally presented. A more useful popup would perhaps show 
pickable parameters for each widget and info about the parameter. E.g each 
listed widget title could be a revealwidget to show further stuff. (Of 
course how to extract or rewrite the docs to fit that is a totally 
different matter.)

I could also imagine a popup triggered by a specific character, say "|" 
> that lets you choose to insert a transclusion, link or image etc though 
> this might be more on my mind because of the work on the floating editor 
> toolbar and the non-selection related buttons.
>

Definitely a great idea. In the (full) EditorMagic demo 
 I use "??tr" and "??dr" for 
transclusions where the latter opens a drawing canvas which I think is 
pretty neat. (In native TW, to spontaneously create and insert a sketch in 
the middle of a tiddler is totally impractical.) But your idea to use a 
common trigger, possibly even a single character as you say, is more 
elegant than my cryptic abbreviations.

BTW, is there something more that can be done to align EditorMagic with 
your floating editor toolbar? There's obvious conceptual overlap so it 
makes sense if they harmonize where possible. If I understand your floating 
editor toolbar right it is currently only triggered by selecting text. It 
would be cool if, for example, the user can select text which, if it is 
some particular string, triggers docs or something else for it that string. 
For example if the user, in the middle of a listwidget, selects the string 
$list he gets info about this, or selecting a word in some arbitrary text 
gives e.g a translation.

(BTW, needless to say, if there's anything in what I've created that you 
can use for your things I'd be incredibly flattered.)

...

OK, here's the current status: http://editormagic2.tiddlyspot.com/
(never mind the mini "quicklinks" popup unless you use the SideEditor)

It is a joy to see things pop up :-)

One problem is for EditorMagi/WidgetDocs - wich uses a selectwidget - and 
for EditorMagic/TransINclude - which shows an editor - the popup *loses 
focus* as soon as the selectwidget or editor is touched. Any ideas for this?

(There are still more tools I did not yet adapt.)

Thank you Saq!!!

<:-)

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/2e69e4ea-9aaa-405e-9046-1308e60433fao%40googlegroups.com.