(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={{{ [<text>splitbefore{!!em-trigger}] }}}
    before-length={{{ [<text>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.

<:-)

 

[Saq Imtiaz]

Try this for the body/editor:

\whitespace trim

\define em-showPopup()

<$action-popupcaret $state=<<em-state>>/>

<$action-setfield

   $tiddler=<<em-state>>

   template=<<matchedTemplate>>

   fragment=<<matchedFragment>>

/>

<$action-setfield $tiddler="test" state=<<em-state>>  />

\end

\define em-updatePopupState()

<$list filter="[<matched>match[false]]">

<$action-deletetiddler $tiddler=<<em-state>>/>

</$list>

<$list filter="[<matched>match[true]]">

<<em-showPopup>>

</$list>

\end

\define em-checkNextTrigger()

<$list filter="""[all[tiddlers]tag[$:/tags/EditorMagic]!has[draft.of]after<template>]""" emptyMessage=<<em-updatePopupState>>>

<<em-checkTrigger>>

</$list>

\end

\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={{{ [<text>splitbefore{!!em-trigger}] }}}

   before-length={{{ [<text>splitbefore{!!em-trigger}length[]] }}}

   trigger-length={{{[{!!em-trigger}length[]]}}}

   em-itemfilter = {{!!em-itemfilter}}

>

<$action-log $message=<<template>>/>

<$list filter="""[<text>search<trigger>] +[splitregexp<triggexp>] +[!prefix[ ]!search::regexp<triggendexp>] +[last[]]""" emptyMessage=<<em-checkNextTrigger>> variable="em-fragment">

<$vars before-length={{{[<text>splitregexp<triggexp>butlast[]join<trigger>length[]]}}}>

<$action-log $message={{{[[detected: ]addsuffix<template>]}}}/>

<$list filter="[<template>!has[em-itemfilter]] ~[subfilter<em-itemfilter>]" variable="_NULL" emptyMessage=<<em-checkNextTrigger>>>

<$list filter="[<em-fragment>length[]add<before-length>add<trigger-length>match<selectionEnd>]" variable="_NULL" emptyMessage=<<em-checkNextTrigger>>>

<$list filter="[<em-fragment>length[]compare:number:lt<fragmentLength>]" variable="_NULL" emptyMessage=<<em-checkNextTrigger>>>

<$vars matched="true" fragmentLength={{{[<em-fragment>length[]]}}} matchedFragment=<<em-fragment>> matchedTemplate=<<template>> >

<<em-checkNextTrigger>>

</$vars>

</$list>

</$list>

</$list>

</$vars>

</$list>

</$vars>

\end

\define em-checkAllTriggers()

<$vars text={{{ [{!!text}split[]first<selectionEnd>join[]] }}} >

<$list filter="""[all[tiddlers]tag[$:/tags/EditorMagic]!has[draft.of]first[]]""">

<$vars matched="false" fragmentLength="9999999">

<<em-checkTrigger>>

</$vars>

</$list>

</$vars>

\end

\define em-inputActions()

<$action-withselection actions=<<em-checkAllTriggers>> />

\end

<$set name=em-state value=<<qualify $:/state/EditorMagicPopupState>>>

<$edit

  field="text"

  class="tc-edit-texteditor tc-edit-texteditor-body"

  placeholder={{$:/language/EditTemplate/Body/Placeholder}}

  tabindex={{$:/config/EditTabIndex}}

  focus={{{ [{$:/config/AutoFocus}match[text]then[true]] ~[[false]] }}}

  cancelPopups="yes"

inputActions=<<em-inputActions>>

>

<$set

  name="targetTiddler"

  value=<<currentTiddler>>

><$list

  filter="[all[shadows+tiddlers]tag[$:/tags/EditorToolbar]!has[draft.of]]"

><$reveal

  type="nomatch"

  state=<<config-visibility-title>>

  text="hide"

  class="tc-text-editor-toolbar-item-wrapper"

><$transclude

  tiddler="$:/core/ui/EditTemplate/body/toolbar/button"

  mode="inline"

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

<$reveal type="popup" state=<<em-state>>  class="editormagic-popup tc-popup-keep">

<div>

<$set name="selectionEnd" filter="[<em-state>get[selection-end]]" select="0"> 

{{||EditorMagic/_Popup}}

</$set></div>

</$reveal>

</$edit>

</$set>

Lots of room for clean up and optimizations, but I am pressed for time today and that should get you going.

[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/

<:-)

[Saq Imtiaz]

Unless there is some kind of caching issue, your link does not have the updated copy of body/editor that I provided in my last post.

[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.

<:-)

[TonyM]

Mat,

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?

Keep up the good work.

Tony

[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.

<:-)

[TonyM]

Mat,

The transclusion tool looks fab. I especially love the image insert.

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.

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

Regards

Tony

[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<em-fragment>]

...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.

<:-)

[TonyM]

Mat,

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

Love your work, this is seriously exciting.

Regards

Tony

[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 ;-)

<:-)

[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.

<:-)

[Saq Imtiaz]

Hi Mat,

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.

Right, there is definitely room for optimization here. I can try to investigate but this week is very busy on my end. Also, I have new desktop machines at home and the office since January and in a strange but annoying twist, they are so powerful that I can't perceive some of the performance issues that others experience. 

A few things for you to consider/try.

• 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
• 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.

\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={{{ [<text>splitbefore{!!em-trigger}] }}}

   before-length={{{ [<text>splitbefore{!!em-trigger}length[]] }}}

   trigger-length={{{[{!!em-trigger}length[]]}}}

   em-itemfilter = {{!!em-itemfilter}}

>

<$action-log $message=<<template>>/>

<$list filter="""[<text>search<trigger>] +[splitregexp<triggexp>] +[!prefix[ ]!search::regexp<triggendexp>] +[last[]]""" emptyMessage=<<em-checkNextTrigger>> variable="em-fragment">

<$vars before-length={{{[<text>splitregexp<triggexp>butlast[]join<trigger>length[]]}}}>

<$action-log $message={{{[[detected: ]addsuffix<template>]}}}/>

<$list filter="[<em-fragment>length[]add<before-length>add<trigger-length>match<selectionEnd>]" variable="_NULL" emptyMessage=<<em-checkNextTrigger>>>

<$list filter="[<em-fragment>length[]compare:number:lt<fragmentLength>]" variable="_NULL" emptyMessage=<<em-checkNextTrigger>>>

<$list filter="[<template>!has[em-itemfilter]] ~[subfilter<em-itemfilter>]" variable="_NULL" emptyMessage=<<em-checkNextTrigger>>>

<$vars matched="true" fragmentLength={{{[<em-fragment>length[]]}}} matchedFragment=<<em-fragment>> matchedTemplate=<<template>> >

<<em-checkNextTrigger>>

</$vars>

</$list>

</$list>

</$list>

</$vars>

</$list>

</$vars>

\end

• I am also unsure if we need this list anymore (after introducing em-itemfilter):

• 
  <$list filter="[<em-fragment>length[]add<before-length>add<trigger-length>match<selectionEnd>]" variable="_NULL" emptyMessage=<<em-checkNextTrigger>>>
  

• 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.

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 addressing.

I would also add that it is best to think of this entire dev process as a proof of concept or prototype. The aim is to understand what kind of code structure works best, what the potential issues are and what the best user experience is. If it needs a rewrite later to get it right or fix performance issues, that is a part of the process. 

In short: don't be in a hurry to have something "final" and publish it. Dev work this extensive and complex with wikitext is a bit harder to plan in advance and get right (compared to working with established programming languages). 

Cheers,
Saq

[TonyM]

Mat,

I do understand the work in progress nature of this. 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.

I have being frustrated with poor and nonstandard syntax examples on Tiddlywiki.com and figure rather than build my own library of resources build a reusable one.

Where I am thinking with the widgets is writing a set of widget template variations. These should be at home in tiddlywiki.com examples with a copy to clipboard as much as in your tool or someone instructional documentation. I am also keen to have a sidebar with such templates that I can drop in an editing session. To me I see that this is content that can be used in many ways. Thus I was proposing the development of such a database, with a view to you refactoring it if needed for editorMagic.

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.

Of course I can use all the tricks in the book to extract such widget content from tiddlywiki.com to build such a list.

Yes, Saq is a machine of productivity.

Regards

Tony

[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="[<em-fragment>length[]add<before-length>add<trigger-length>match<selectionEnd>]" variable="_NULL" emptyMessage=<<em-checkNextTrigger>>>
  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.

<:-)

[Saq Imtiaz]

@Mat

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 :-)

Naturally, The point about treating it as a prototype is that you can make large changes, try things and if they don't work as anticipated, try something else. Part of the question mark over this entire effort has been: how much can you get done with wikitext? The performance issues are a part of the answer.

 

Tests definitely imply it's the detection code. No visible difference when popup runs or doesn't run filters.

One possibility here is for the filter used in the detection code not to be the same as used in the popup tools. That actually never was my intention.

The filter for titlepicker has to match the fragment against every tiddler in the wiki, that is expensive.

How about a filter that that just detects whether the fragment for titlepicker has disallowed characters? 

Or we just live the performance issues.

Naturally its far from ideal that the filter for title picker runs 3 times:

- once in detection

- twice in popup

Note that I refer to title picker as an example

• I am also unsure if we need this list anymore (after introducing em-itemfilter):
  <$list filter="[<em-fragment>length[]add<before-length>add<trigger-length>match<selectionEnd>]" variable="_NULL" emptyMessage=<<em-checkNextTrigger>>>
  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.

If you are sure about this, we can remove this list and the variables that are there just for its sake.

 

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. 

 <$vars foo={{{ [{!!foo}] }}}>

content

</$vars>

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

</$list>

[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="[<em-fragment>length[]add<before-length>add<trigger-length>match<selectionEnd>]" variable="_NULL" emptyMessage=<<em-checkNextTrigger>>>
  

• ...

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

</$vars>

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

</$list>

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 :-)

<:-)

[Saq Imtiaz]

@Mat

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...)

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.

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 am also unsure if we need this list anymore (after introducing em-itemfilter):
  <$list filter="[<em-fragment>length[]add<before-length>add<trigger-length>match<selectionEnd>]" variable="_NULL" emptyMessage=<<em-checkNextTrigger>>>
  ...

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 ;-) 

You removed the correct list, other than that I am not sure what I should be looking at or what has changed. Do go through all the variables declared in body/editor and make sure that we are still actually using them.

 

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?

No. The attempt at paraphrasing completely looses the original meaning. Explaining this properly would require explaining the widget tree and refresh mechanism.. something I don't have time to get into now. Feel free to bring it up in a separate thread at a different occasion.

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.

Saq

[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.

<:-) 

[Saq Imtiaz]

Personally I think focusing on performance right now is premature. I would recommend getting the functionality as you want it before switching focus to performance. Even then a good place to start would be actually using this with a larger tiddlywiki, like tiddlywiki.com, to understand what if any real usage issues there are.

[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?

<:-)

[Saq Imtiaz]

On Monday, July 27, 2020 at 11:30:59 AM UTC+2, Mat wrote:

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?

Yes, or anything else that needs work. My focus has been the triggering of the popup so I cannot currently comment on whether everything else is already as you wanted.

Saq

[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).

<:-)

[Saq Imtiaz]

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

[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.

<:-)