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="[<em-state>get[template]!match<template>]">
<$action-deletetiddler $tiddler=<<em-state>>/>
</$list>
\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={{{[<q-state>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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/2ca5ed95-d430-4a41-b8bb-aae772989b49o%40googlegroups.com.

Reply via email to