Spliff
04-19-2023, 05:06 AM
In the web, there are some comments on UR, more or less saying that it's an excellent data repository, but that for notetaking, almost anything else is suited better, UR not being "responsive" enough; wordings vary, but it more or less comes down to the response time after "create new sib" / "create new child", since in-between, UR has to create a new record; response times should also vary with the user's ssd/hdd (my UR installation is on an ssd but my data is on an hdd).
I think it's worthwhile to do something about it, internally (along the lines of what I've done, externally, or/and even by creating some new records "on hold", ready to be filled up then, and then only to be shifted to the right position? i.e. by splitting (!) the functionalities "show at current entering position", and "create (at current entering position)"),
since many prospects then say they don't accept UR as their PIM, since they want both functionalities in just ONE tool, and they don't accept the "wait", again and again - I personally had accepted that second-or-some, UR being THAT good a data repository indeed!
But lately, I tried to overcome this "wait" by my AHK means, and I succeeded:
First of all, both shift-enter +{enter} and {ins}, for new sib and new child, respectively, are invariable in UR, which means the user might try to reassign other shortcuts, but then those won't work; on the other hand, the user is free of course to use something like AHK, and trigger the +{enter} and {ins}, from key assignments in AHK (or any other such tool), or, as below, the user leaves the native UR assignments unchanged, but enhances them.
Then, I suggest 2 additional code lines, and the user might change my "sleep" (or "wait", in other tools) span, according to what works best, on their respective system:
$+enter:: ; works UR-natively just from within the tree
sendevent, +{enter}
sendevent, {backspace}
sleep, 650
return
$ins:: ; works UR-natively also from the UR-content-pane
sendevent, {ins}
sendevent, {backspace}
sleep, 350
return
The "sleep" in these is counter-intuitive, since it seems to cause even more "wait", but in fact, and obviously thanks to the Windows keyboard buffer, the user can safely start to type at once, without any wait now!
I think it's worthwhile to do something about it, internally (along the lines of what I've done, externally, or/and even by creating some new records "on hold", ready to be filled up then, and then only to be shifted to the right position? i.e. by splitting (!) the functionalities "show at current entering position", and "create (at current entering position)"),
since many prospects then say they don't accept UR as their PIM, since they want both functionalities in just ONE tool, and they don't accept the "wait", again and again - I personally had accepted that second-or-some, UR being THAT good a data repository indeed!
But lately, I tried to overcome this "wait" by my AHK means, and I succeeded:
First of all, both shift-enter +{enter} and {ins}, for new sib and new child, respectively, are invariable in UR, which means the user might try to reassign other shortcuts, but then those won't work; on the other hand, the user is free of course to use something like AHK, and trigger the +{enter} and {ins}, from key assignments in AHK (or any other such tool), or, as below, the user leaves the native UR assignments unchanged, but enhances them.
Then, I suggest 2 additional code lines, and the user might change my "sleep" (or "wait", in other tools) span, according to what works best, on their respective system:
$+enter:: ; works UR-natively just from within the tree
sendevent, +{enter}
sendevent, {backspace}
sleep, 650
return
$ins:: ; works UR-natively also from the UR-content-pane
sendevent, {ins}
sendevent, {backspace}
sleep, 350
return
The "sleep" in these is counter-intuitive, since it seems to cause even more "wait", but in fact, and obviously thanks to the Windows keyboard buffer, the user can safely start to type at once, without any wait now!