Yeah I didn't really get that... PubSub is more of a design pattern... you still have to get the data transported to the browser (via WebSockets, SSE, etc.)
Along with figuring out the typing, don't underestimate how powerful voice transcription has become with apps like superwhisper https://superwhisper.com/
An interesting variant of space-filling curves + dimensionality reduction is Geohash (https://en.wikipedia.org/wiki/Geohash, http://geohash.org/) which takes a lon/lat and uses a Z-curve approach to produce a hash such as `u4pruydqqvj` representing the location. This hash value is basically "how far along the space-filling curve is the lon/lat located". You're reducing two dimensions (lon/lat) into one dimension (how far along the space-filling curve).
There's a unique side-effect to Geohashes in that the value (`u4pruydqqvj`) can have it's end "lopped off" (i.e. cut down to `u4pru`) and it still represents a less precise, but generally accurate representation of the original lon/lat in most cases (when the curve isn't near the edge of the 2d map!). This allows you to index locations (lat/lon) using a string ('u4pru') which opens you up to doing b-tree, range queries, etc. in traditional database, with one field.
Just a rad math quirk! I'm not an expert, and it's a very dense book, but if someone really wants to get into this kind of stuff the "Bible" is "Foundations of Multidimensional and Metric Data Structures" by Hanan Samet.
> [I]t's a very dense book, but if someone really wants to get into this kind of stuff the "Bible" is "Foundations of Multidimensional and Metric Data Structures" by Hanan Samet.
You're not Kidding! 1022 pages, with a TOC that nests 4 layers deep. In particular, section 2.1.1.2 "Ordering Space" covers space-filling curves, and true to your description it covers every point brought up in the comments so far:
- Peano-Hilbert curve of OP
- Z-order curve mentioned
- "Reverse locality" issues
- Performance considerations of the mapping function
The thing about SFC addressing is that two places near each other always share a prefix, and the closer they are, the longer the common prefix. It's sort of like Gray coding. Quadtree addressing, for example, also has the property that you mentioned (as do, of course, normal lat/long coordinates!) but two adjacent locations may not have similar addresses at all if they happen to straddle a subdivision boundary. (Again, compare to "normal" numbers where, say, |2000-1999| = 1 but there's no common prefix at all!)
The same happens, in fact, for space-filling curves. Sure, in _most_ of the area covered by the curve, closeness of points means closeness on the curve. But in this Hilbert curve:
Consider the two points on the curve straddling the middle of the top edge of the square. They are very close together, but their 1D addresses on the curve are very far apart (one close-ish to the beginning, and one close-ish to the end)!
The boustrophedonic version of Rosenberg-Strong function is my favorite because it doesn't have any such jumps and has better locality preserving qualities than most alternatives.
I keep trying VS Code, but I hate how when I split the screen three wide ("splits") it wants to open "editors" in each of the columns, even if it's the same file. I want a "buffer" like Emacs has that can be called up into any of the "splits" without reopening the file.
I disable the tabs display, but when I visit a file in each of the three columns (i.e. what in Emacs would be calling a buffer into a window) I end up with the same file open three different times, once for each split. Then the fast switcher just gets full of dupes. BLAH!
I really wish VS Code used the Emacs model of completely disjoined (a) buffers, (b) windows, (c) frames, but instead there's a hierarchical approach of Splits -> Editors.
I've dug into VS Code issues about this, and it seems the hierarchy between Splits -> Editors is a strong parent-child relationship embedded deeply within VS Code's model and is unlikely to change.
While Emacs is opinionated in its own way, it is extremely configurable, programmable, modifiable, customizable to ones needs. I guess it will take a long long time, until vscode is as modifiable as Emacs, if ever. And maybe that is not vscode's goal anyway.
VS Code's goal is to get the low-effort 30% of devs who want something that will just work right out of the box, while providing enough functionality/customization to attract a significant fraction of the remaining 70%. And given that, it's pretty good.
But I'm skeptical it will ever be as good for someone who does want to make the investment in something like Emacs.
This is my final quibble with VSCode as well - except I'm coming from Vim. I've hunted high and low through the settings - if anyone from the VSCode team is reading this, there's not another feature that's more vital to match vim/Emacs utility!
