By my understanding Hook doesn’t do any searching of your file system when invoked (I’m not one of the developers though). When you invoke Hook, it first runs the scripts for the current context to get the context’s address (and name). This address (by my understanding) is then looked up in the Hook database to find related contexts.
It sounds like, for whatever reason, HoudahSpot keeps taking the focus, so the HoudahSpot script is being run which is accessing the file system.
Could you try temporarily disabling HoudahSpot and see if the problems you’re having go away? (I’m not suggesting the solution is to not use HoudahSpot, but it helps find a solution)
I apologize if I have not made my meaning clear. I only mentioned HoudahSpot as an example of what Hooks developer might choose to look into for a future update with Hook.
My suggestion does not have anything to do with HoudahSpot. I mentioned HoudahSpot only as an example, because when a HoudahSpot search is triggered and it is looking for files that I know I have on an external, sleeping, drive, I can see that in approximately the same amount of time that Hook is delaying populating my menus, that no HoudahSpot search results will appear before any external drive is awakened.
I also noticed that when I trigger a Hook menu to appear, if my external drive is mounted and if it is asleep, I can hear the drive spinning up that is, awakening, before my Hook menus populate.
With HoudahSpot, I can tell each search what the limits of that search will be, local drive, all drives mounted, or an online repository of my files such as Dropbox.
As I am not using Dropbox and I am not storing any of my Hook linked files anywhere but on my local drive, my suggestion was that it might be helpful if at some future point in time the developer adds the option to not have Hook look all over the place for my linked files, but only where I want it to look.
I can see three options here; 1. Dismount any external drive when I am not using it, 2. Wait out the time that Hook will take to spin up my external drive each time I use Hook, or, 3. Hope that the developer also considers this idea, and implements it, so that I no longer have to be concerned about seeing unpopulated Hook menus or my lack of patience in not wanting to wait for Hook to check everywhere before it populates my Hook menus.
Thanks for reporting and investigating this, @levelbest. If this occurs again, could you please wait longer to see if the links appear? This would tell us whether we are truly dealing with missing links (as your topic title suggests), or a performance issue (as your description suggestions).
It would not do that.
Hook should not try to access a drive to which you do not have any links. I’ve asked our dev team to look at whether/how this could be triggered as a side-effect. And if so we would of course try to prevent this.
If, rather than missing links, this is a performance issue related to Hook interacting with a slow external drive, then a different title for this forum topic (report) would be more accurate, such as “Hook slow to populate list of links when external hard disk drive (non SSD) is connected”, because the current title makes it sound like the Hook links are altogether missing.
Inspired by Apple’s very fine example of performance optimization in successive versions of OS X and macOS, throughout the development of Hook we have optimized its performance. It may be that the focal resource in relation to which you are invoking Hook has link targets on a very slow external disk that Hook is verifying are still there. (I’m not referring to speed of sustained access but of lookup). In any event, we certainly want to find and respond to significant opportunities for further optimization. We will look at whether what you’ve described is such an opportunity. And we will continue to ensure performance remains a priority as we roll out new features along Hook’s product road map.
If this is a performance issue related to Hook interacting with a slow external drive, then a different title for this forum topic (report) might be better, such as “Hook slow to populate list of links when external hard disk drive (non SSD)”.
We have always valued performance and will continue to ensure performance is a priority as we roll out new features along Hook’s product road map.
I understand that there are two issues here. But please understand that one of the issues is that, on my main document that I had spent the previous day rearranging its links and setting up an archived document to keep my current linked set updates to the projects current progression, the links entirely disappeared. This was true several hours later so it does not seem to be related to my other question, of why I can hit the Hook hot key and not see a populated Hook menu until an external disk has spun up (awakened).
As I had noticed the sound of the external drive spinning up, I remembered that another app (HoudahSpot), can also take a short time to target an external drive for a search if that is what it has been asked to do.
I can say with certainty that it has been a frustration to me for some time that for whatever reason, hitting the Hook hot key will often bring up an empty Hook link window. Sometimes this happens a few times in a row. Then, hitting the hot key again, will show a populated window.
What is going on in every instance I cannot say. Figuring out a way to systematically problem solve this would be helpful. Let me know if you have any suggestions toward this end.
When you get the empty list, does copying the markdown link work as expected — does the title match the context you expect to be interacting with, and does the link work to take you to that context?
The Copy as Markdown suggestion was just because it’s easier to check that both Get Title and Get Address are working as expected (and helping diagnostic if they’re not). If Copy Address works, then they both are.
sorry to belabor the issue here but I just want to have a clear understanding of the issue. Are you saying that there is a specific resource that you access via nvALT that had been previously linked with the Hook window (i.e., using “Link to Copied Address” or menu bar icon), and now any time you invoke the Hook window on that resource again, even if there is no external drive connected and even if you wait a long time (let’s say 20 seconds, which is much longer than should be required), you never see the associated links? Or is this a matter of inconsistent behavior on the same resource: sometimes the links show up in the Hook window, sometimes they don’t?
Could you please copy the link obtained from this resource (using Copy as Markdown Link), and paste it here (or in a PIM to me , for privacy) between triple ticks ```` so that we or I can see the entire Markdown link? Could you please also paste the actual pathname of the file. (You can obtain the pathname of a file by dragging it from Finder and dropping it into a Terminal window. Depending on the characters in the pathname you may need to put it between tripple ticks too, to “escape” special characters from Discourse.)
To clarify, only one time did all my links disappear.
Sometimes, I notice that there is an empty Hook menu that should have a half dozen or more links in it.
When I notice that there is a completely empty Hook menu that should have links in it, I have noticed that if there is an external drive mounted, the time it takes for this external drive to awaken (assuming it has gone to sleep) is approximately the same amount of time that I continue to trigger the Hook menu with nothing at all showing in the menu.
On other occasions, I will trigger the Hook menu, that should be showing links, and it is completely empty. That is, at such times, there is a completely empty Hook menu as if there never were any links set to that document.
It appears that Hook will not always recognize in its Hook menu that it has links. Most of the time, except for the one incident I have already mentioned, if I continue to trigger and dismiss the empty Hook menu, eventually I will see a fully populated Hook menu again.
I have written this off to an annoying glitch that is somehow wired into my system and the way that Hook goes about the recognition of a set of links. It does not happen every time. But it does happen fairly often. I am now being alert for this condition without any external drive being mounted. I will post again as this condition occurs.
At no time am I saying that there are missing individual links in the Hook menu. I am saying that the entire Hook menu will show as an empty menu as if there were no links in that documents links - even though there are - or there should be, links in that documents Hook menu.
Thanks for clarifying, @levelbest. Hook should consistently give the same result when invoked on the same resource if the file-link targets remain available.
I’m wondering whether for some unexplained reason on your system nvALT’s Copy URL function does not always return the same result. Copying/pasting the “Get Address” Script into Script Editor and running it while nvALT is running might provide an indication of that, but given that the problem is intermittent, it might take a while for the problem to show up if it does happen there.
The successor of nvUltra (currently in public beta) has AppleScript support, which is more reliable than screen scripting, used by the current script.
If this happens in an app that provides a direct AppleScript method for getting the address of the current item (such as Pages), it would suggest a different line of inquiry.
@levelbest, has the missing links issue happened in the context of other apps than nvALT (excluding the external drive access case, for isolation purposes) ?
Yes. I have experienced hitting the Hook hot key combo many times and, instead of a populated Hook window, I get an empty Hook window.
I don’t believe this is specific to NVAlt - although I can’t say for sure. After making all this fuss about it, it is now up to me to start logging occurrences and taking screen shots.
The last couple of days I had to tend to other problems. As soon as get back to my project and I start using Hook heavily again, I should know something.
Post Script: It occurs to me to mention that I have two key applications which monitor keystroke activity and therefore, monitor system resources at all times.
One is Keyboard Maestro, used for creating macros, and the other is Typinator, the best text expansion tool on the market as far as I am concerned. I wouldn’t do without either one of them. I thought it might be worth mentioning in case it helps someone understand why I am sometimes getting a blank Hook window when I press my hot key trigger.
Post Post Script: I observe that even in the best of times there is about a quarter to a half second pause when I trigger the Hook menu via the hot key combo. That is, when the hot keys are pressed I get a blank Hook menu for about a quarter second or so, followed immediately by the populated Hook window.
I find it a bit disconcerting that there is such a pause when Hook is triggered. I assume that this is a normal condition and not something that I alone am experiencing but, I thought it worth mentioning - in case it helps.
Hook needs to verify that the file link targets are still there before displaying them to you. Hook presents th links gradually rather than waiting for every one to be checked, which is more productive for the user (users can scan tand use the list). Normally, with SSD the latency is imperceptible, but sometimes it is.
If you have an older Mac model with spinning hard disk (rather than SSD), this could be perceptible. And is the external drive connected when it’s slow?
My main drive is SSD so this is not slowing it down.
I only keep the rotating drives for backups and for movie files - for entertainment. This is partially due to practicality as they work fine for non critical tasks. But, this is also due to the fact that DiskWarrior, my go to application for maintaining a healthy system, has still not been updated to work on SSD drives. Therefore, at least my backed up copies of my system can have DiskWarrior run on them as they are not SSD drives.
To sum up, based on everything in this topic, the current hypotheses for investigation (things to rule out) related to your experience of slower or non-display of links:
the presence of an external drive, even if you don’t hear the access.
the context of nvALT (or other apps controlled via AppleScript)
interaction with specific utilities you mentioned.
another background process ( background processes can interact with any application)
an interaction of the above.
A common thread is timing.
Thank you. An investigation goal would be to exclude as many of the above as possible.
I am not seeing odd behavior in any app but NVAlt so far - other than one I will address in a separate Scrivener post. But, nothing other than what I have noted with NVAlt according to this thread.
Thu. Aug 29, 2019 10:03 AM: I went to NVAlt. I hit the Hook hot key. I got an empty Hook window. At the same time, I heard my external drive, now asleep, spin up. In the time it takes to spin up the external drive the Hook menu remained blank. This was approximately 5 - 10 seconds. Then, when the drive finished being accessible, the Hook menu suddenly became populated.
Sat. Aug 31, 2019 07:29 AM: I just opened NVAlt. Ran Hook first thing in the morning. More than 40 seconds, empty menu. Click again an NVAlt and triggered Hook, 35 seconds and the list populated.
If the address of the original nvALT file matches the address of the nvALT file as you currently see it, then Hook should be able to find all the links.
If you do “Copy as Link” on the file in nvALT (as you see it now), it should match one or more entries in the database. However, the database is rather opaque to non programmers.
There is also a Hook log file in ~/Library/Application\ Support/com.cogsciapps.hook/ log.csv. This file is not currently read by Hook, but it can be examined by the user (in a text editor) to review their linking history. It’s just a text file. (It can also be imported in a spreadsheet.) If you were to search for the address of the current file, it should match a previous entry (a “log event”) in that file. If it does not, that suggests that somehow the address of the file has changed. I have not experienced this myself with nvALT (except in appearance, as noted above, with Dropbox; but in that case it is Dropbox moving files.) But it would be something to look at.
I don’t have a problem with my disk slowing down. This has only been an issue between Hook and NVAlt.
I already use an internal SSD. External non SSD drives are still quite important since DiskWarrior has still not updated their app to work with SSD drives.
I have resolved the problem with NVAlt by moving away from using NVAlt and Hook together and instead I am making good use of Curio. Curio is great for what I am doing so I have no regrets.
I will continue to watch what is happening in the development of Hook. And who can say what the eventual release of the NVAlt successor will bring?