I don’t know why it doesn’t do this for them. It does for me…
What version of snapd are they on?
The problem seems to be specific to mailspring… tab autocomplete works for chromium (which I also have installed, so autocomplete works for installed snaps…), telegram-sergiusens…does it take a while for autocomplete to work for recently-released snaps for some reason?
$ snap version
snap 2.29.3
snapd 2.29.3
series 16
ubuntu 17.10
kernel 4.13.0-16-generic
Hi. forteller here.
Good to know. I just tried again, and it still does not autocomplete Mailspring (which I now have installed), but it does autocomplete other packages. Interestingly enough I had to press tab twice after writing “chro” before I got suggestions, but I’ve tried pressing tab many times on “mail” or “mailspr” etc now, with no result other than the “nope sound” 
Note that Joe over on OMG said he has the same issue.
Ah!
The list of snaps is downloaded once a day. If the snap came out that very same day, it won’t be in the list!
Before we used to query the store directly, but that was too slow, which is why we’re doing it this way now.
We could look at making the window smaller, though that would use more bandwidth and might pummel the server a bit. What do you think?
For what it’s worth my current position is that once a day is a reasonable trade-off – if you try to install something on the day it’s made public, presumably you’ll know the name of the thing so while slightly less convenient it shouldn’t block you.
But it was an unexpected behavior. It might hit the server more but perhaps the window should be reduced to 2 hours (just an idea) or something. Presumably it doesn’t take up much bandwidth to ping the server for a small text file? There is a performance trade-off of course…would be best if there were some way to customize small things like this but that would introduce code complexity…
I think that sounds reasonable. The only thing is that I got a bit uncertain about whether I was doing things right or if I had to read the article more closely to find that I had to download a snap-file manually or something instead. And I did end up going back up the page to see if I had missed something like that. But this is a really minor issue for an extremely small minority, I would think, and I don’t think it’s worth adding extra server costs to fix this.
The only thing is if it’s possible to find a more resource efficient way of checking and downloading the list (only checking a hash, only downloading the difference, not the whole list? I have no idea, I’m not a coder in any stretch of the definition, and I’m sure you do these things already), then maybe it could happen twice a day instead of once.
They are probably doing something like passing If-Modified-Since from the last Last-Modified they got and that helps a lot with not downloading the same thing over and over again but it is still a network request and for something like pressing <TAB> and having it take at least a second to show a result (due to having made a network request to refresh the cache) is very user unfriendly.
Over here, that latency for refreshing before this cache was implemented was around 3 seconds, I would have rather typed the whole thing by then.
FWIW, once a day seems fine to me too for end users. I wonder if it would make sense to expose a command to force a refresh now (if it doesn’t already exist). If this was documented somewhere prominently in developer documentation, this might avoid developer confusion.
good idea. I’ll propose a strawman snap refresh --catalog or something like that.