HN user
https://maxxk.me/
Thanks! I'll correct myself: lack of interactive global search, discussed here: https://github.com/helix-editor/helix/issues/196
Maybe it's kind of niche feature, but that's how I navigate my code, and that's what would work even greater with helix performance.
I test-drived helix for a couple of months, and it is really fast. My major pain points compared to Neovim:
- lack of global search (like ripgrep integration) and something like dumb-jump/anyjump — it's faster and less resource-intensive than running LSP
- I encountered a couple of panics losing my unsaved changes after 24.03 update, most recently yesterday. Looks related to this bug: https://github.com/helix-editor/helix/issues/3501
I can live with no global search, but not with data loss. Probably will stop using it for now.
Interesting approach. But for me the main disadvantage of SQL code embedded in other language is lack of syntax highlighting/checking.
I've had the best experience with embrace-sql which translates sql-files with magic comment-delimited parametrized queries to python-callable modules: https://pypi.org/project/embrace/
I think that the ultimate result (sqlite-wasm) is better than what Web SQL database could provide. Today you can bundle your own version with your own set of native extensions. In case of standard Web SQL you would be forced to check the version and figure out, is it finally possible to use RETURNING in queries.
Two years ago I moved back to paper for my productivity and notetaking after about 7 years going fully digital. There are a lot of advantages for me. Some of those may apply to others:
- Tactile feeling and aesthetics. My writing is not very beautiful, but a stack of papers filled with my notes and diagrams is very inspiring.
- Paper is an offline, distraction-free medium. I think better with paper. Maybe it is a cultural habit.
- Paper won't disappear one day due to bad battery, untested OS update, malware, EOL for cloud service etc. Losing a couple of sheets of paper is easier than electronic device. But when speaking about losing a bulk of notes, it is much easier to lose it electronically than physically.
- Paper is forgiving. I can draw quick-and-dirty diagram in a minute and move on. It is hard to draw quick-and-dirty diagram on a computer. I will spend at least a couple of minutes deciding which app will be more convenient to draw this diagram, about ten minutes fighting an app, and up to an hour fighting my perfectionism, placing all shapes in proper places in grid.
- A sheet of paper is bounded, which helps with internal distractions. If I need to make a TODO list, I will take a smaller sheet, and fit all important things there.
- When you have large desk, you can spread a lot of paper sheets on it and see it all at the same time. Rearrange it, put it in stacks by some criterion, and so on. And neither scrolling nor list of thumbnails work as good as flipping through a paper book.
Disadvantages are:
- Lack of search function. I didn't try Apple Notes document scanning recently, maybe some kind of handwriting recognition is there and it will be enough to just take photos of all my notes.
- Portability: I need a desk with enough free space for both laptop and papers (so, mostly in terms of depth - probably a problem for open space offices).
I have some hopes for Apple Vision Pro (maybe in V2 or V3). I think it has a potential to bring some of these advantages to digital world :)
Is it a known behavior? Considering SQLite developers approach to reliability, I think it would count as a critical bug worth fixing.
git, for all its issues, is not bundling the kitchen sink.
It doesn't bundle the kitchen sink in its native *nix environment, but for Windows it does. Git installer is > 50 MB, including (if I remember correctly) even a terminal.
While you can download Fossil as a 3.3 MB standalone binary for any supported platform.
13B uses about 9GB on my MacBook Air. If you have another machine (x86) with enough RAM to convert the original LLaMA representation to GGML, you can give it a try. But quantization step must be done on MacBook.
Maybe it is more feasible for you to use 7B with larger context. For some "autocompletion" experiments with Python code I had to extend context to 2048 tokens (+1-1.5GB).
Maybe it's me personally, but with M1 / M2 Macs the quality of a product (hardware + software) is far ahead of anything I could get with GNU/Linux, unfortunately. macOS quality isn't as great as it was, but (from my most recent "coming home to M1 Mac" after 4 years on GNU/Linux) sound settings with various configurations including microphones, AirPods, external and internal speakers do work, and OS "automagically" remembers settings for each combination. External displays with different DPI just work (and, again OS does remember all display settings). AirDrop and AirPlay, Keychain and Notes sync (with OCR search) etc just work, not even speaking about famous Mac "instant DHCP". And, as a bonus, kernel upgrades don't randomly break GPU or WiFi drivers.
So, it's really great it works for you, but, sadly, for me a lot of things on macOS "just work", both essential and unessential, while in GNU/Linux many essential things "just won't work", even considering its much better developer experience.
However, these 100 LOC probably could be split into an internal library function which won't change until necessary. If you use an external library (especially in JS and especially in frontend), you or your successor will have to update all these 5 LOC entries all over the code every 1-1.5 years in a non-trivial way when a new major version arrives.
For example, the migration guide for react-query: https://tanstack.com/query/v4/docs/guides/migrating-to-react...
On Linux I used Astroid for offline mail access (notmuch + lieer for gmail and mbsync, I think, for other mailboxes - it worked so good that I don’t remember exactly). For me it is the best offline email setup.
On macOS, unfortunately, I haven’t found anything better than Apple Mail, considering the integration with OS. There are downsides, though. Offline format is incompatible with everything else, it’s hard to do rsync backups of ~/Library/Mail, and I don’t think all mail is accessible offline. It is slow, and it mangled non-latin attachment names for Gmail letters. On positive side, there is a great support for drag&drop, Spotlight integration, multiple account handling.
I know of least three approaches:
1. For per-user configuration there is home-manager which symlinks dotfiles to Nix store based on a single "home.nix" derivation (state). Home-manager is usable outside of NixOS and, in my opinion, it is better than most dotfiles managers. https://github.com/nix-community/home-manager
2. In NixOS /etc is composed in the same way from the system derivation.
3. Outside of NixOS, I think, one can build systemd units which refer directly to configuration files in Nix store. Probably one can add config paths into wrappers, but it will be very fragile and won't scale.
I play games very infrequently, but my anecdata is the opposite: games usually have laggy UI with an inconsistent reaction to input events, noticeable latency, frequent breakage and generally worse user experience (and of course mostly without the ability to resize anything, to compare with browser), even when compared to browsers and Electron apps.
I moved around a bit. I started using Gentoo around 2008, then migrated to macOS on hackintosh in 2010, macOS on MacBook in 2015, NixOS on MacBook in 2017, NixOS on ThinkPad in 2019 and, most recently, back to macOS on M1 MacBook (just this week, actually).
Last month I did rage quit GNU/Linux because of iwlwifi bug [1]. It was moderately bad until the middle of July (fortunately it didn't occur under the load, like in videoconferences), but after another kernel update I got the same behavior as in comment 269 there: connection dropping every minute. Then I found out about new hackintosh intel wifi drivers, tried installing it on my Thinkpad and was surprised how smoothly everything worked.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=203709
Of course, there are another annoying points besides the WiFi bug. macOS sets pretty high bar for GUI convenience:
- consistent cmd-shortcuts - I tried reproducing it with some luck using custom xkeyboard-config file
- MathUnicode.keylayout - tried reproducing with XCompose, with recent sway it was rather close experience
- consistent clipboard support - with Wayland it became much worse, e.g. between Firefox and LibreOffice
- not having to hold a dozen of terminal windows open because I don't remember from which window did I open this program so it won't be killed with terminal - I know about "disown", but I tend to forget to use it
- Preview, Spotlight
- as others already said, Apple devices have the best touchpad including OS support, and great hardware in general
- WiFi connection speed after wakeup
- for me - less ability to tinker around and more focus on actual work :)
I sincerely tried to use only a free software, to spread a word in my close community, to find alternatives, to scratch my own itches a bit (probably not so much as I should), but I believe now my watch is ended. I'm back to macOS as long as the current hardware will be enough for me.
All that said, NixOS is a fantastic distribution which I still use on my servers and still would recommend to any advanced Linux user, and Nix is an excellent package manager. A lot of my project environments didn't require any changes from Linux to macOS at M1. Also, I'd like to mention great software projects which I used a lot: sway display manager; astroid email client with notmuch indexer, lieer for gmail sync and mbsync for other providers; howl - minimalist GUI text editor; alacritty terminal.
It would be interesting to compare this representation with Haiku vector image format described in post [0] and discussed a couple of times here [1, 2].
0: 500 Byte Images: The Haiku Vector Icon Format http://blog.leahhanson.us/post/recursecenter2016/haiku_icons...
I think, in Plan9 philosophy, if the desktop has a driver and it is started in the current namespace, it is represented as a file too (like /dev/my-printer/print-pdf). But it quickly becomes confusing for me:
1. Nowadays we can represent the essence of this approach with FUSE and SSH/SSHFS. Sadly, nobody does: local servers (i3, dbus, ..., vscode) use domain sockets and client executables, probably due to the lack of private namespace support by default.
2. The difference between hypothetical "/dev/my-printer/print-pdf" and almost-like-real-world "my-printer-print-pdf /dev/my-printer" looks similar to binding the first argument in OOP-style vs the explicit C-like call syntax.
Consistent cmd+x/c/v is great.
I've tried replicating this experience in Linux in many different ways over the years, but the best approach was to add `altwin(ctrl_alt_win)` to xkeyboard preferences together with custom `ctrl_space_toggle` for layout toggle. It achieves almost the same effect as Kinto without an additional daemon: physical Alt maps to Ctrl (Cmd in terms of Mac layout), Ctrl works as Super and Super/Win works as Alt — the closest, I think, to Apple keyboard layout. It event works fine in Wayland (sway).
Considering the terminal, remap your favorite terminal emulator to send control codes via Super+A..Z (physical Ctrl+A..Z), and unmap/remap to the required action Ctrl+A..Z (physical "Cmd"+A..Z). It works fine in Konsole and great in Alacritty. (unfortunately, I also have to add a second set of mappings for my native non-latin keyboard layout, because at toolkit-level keys are translated to latin layout, but remapping works only for a single layout).
Of course, it's only a half of the equation. Another part is Option/Compose. On Mac I used MathUnicode.keylayout. It was great, and it was a pleasure to tweak it for my needs. Xkeyboard with .XCompose (e.g. [1]) has two disadvantages: you can't use a key as both Multi key and e.g. Alt modifier simultaneously, and you don't see the composition preview. On Lenovo at least you can use `compose(prsc)` to make your left Win key an «Option-modifier» and its right PrtSc counterpart an «Option-compose». [1]: https://github.com/kragen/xcompose
Maybe one day I will buy another Mac... but shall we prefer comfort to freedom?
Language support is tricky. Libraries and services implementing it will have bugs, memory leaks, etc. ultimately leading to crashes. I'd prefer my text editor not to crash erasing my unsaved changes. So probably the language support should be isolated in a process separate from the editor.
Of course, an LSP client will also have bugs. When I tried LSP support in Kate editor last year, it crashed together with the language server. Emacs at some point (could be after a language server crash too) locked its UI. However, the client code has a limited scope; the editor developers can and will fix bugs there, in contrast with dozens of exotic language support libraries in dozens of different languages.
Probably we could think of better editor design (isolate the core and let the other things crash — like in Xi editor, or something Acme-like with most tooling being external), but we already have a lot of editors. It is also definitely possible to design a better IPC protocol than JSON-RPC, but compared to the idea of isolating plugins (for me, it is one of the primary advantages of VSCode over any other editor with plugins I've used: it almost never crashes, and when it does, it preserves the state), and considering the resource-intensity of the language support itself, I think, JSON-RPC overhead is not as large as it looks.
Finally, I'd like to agree with the sibling comment: unfortunately, C FFI interface to a library is probably not easier to implement nowadays than JSON-RPC interface to a service in most languages, excluding C/C++, assembly and so Forth :)
Yeah, I used GUI emacs on and off for more than a decade, most recently — for a couple of months as a primary editor and email client. Emacs with gcc+pgtk patches feels great. Unfortunatley, due to scrolling and, most importantly, C-x/C-c vs cua-bindings (which was non-issue on OS X ⌘ but is an issue in X11 and Wayland) I never feel myself completely comfortable using emacs.
For me the most important benefits of GUI text editor are:
1. Selection and system clipboard integration. 2. Ability to quickly scroll to look something without moving the cursor, then return where I was by pressing an arrow key (one of the largest pain points of emacs for me). 3. Proportional fonts with proper text rendering, especially for notes.
I use 1 and 2 almost on a subconscious level, and it's hard for me to be productive in an editor which doesn't support these features. I'm sure, vim users can relate.
In this case better solution would be to use this single line (which works for >80% of clients) with try-catch in core and maybe load polyfills from exception handler via "bloat dispatcher".
Actually there is built-in GTK Inspector [0] and I used it successfully with gtk-rs before.
GTK_DEBUG=interactive your-app
I don't have experience with non-alphabetic writing systems, but I was under impression that for simple written communication nowadays plain text is good enough for every language supported by Unicode. I've heard e.g. about Han unification, but is it bad enough even for non-linguistic purposes?
Which features, in your opinion, are required for decent non-alphabetic language compatibility on top of plain Unicode text?
Well, Gemini can have links to pictures and clients may render pictures — inline, in separate "graphics" column etc. No one does it yet, as far as I know, but we will see.
Table and math bring more problems. Probably SVG or other images can solve them, but it is a pain for authors. In my opinion, no plain-text markup language today has tables with features even remotely close to HTML (at least colspan, rowspan and alignment) while remaining convenient to both write and read. AsciiDoc is fine in terms of features, but not in terms of syntax:
It is arguable whether 2x LOC reduction is worth it. But 5x LOC reduction on the same technology stack kind of changes the complexity category of the code base. 2kLOC (borderline trivial application) is almost always easier to maintain than 12kLOC (small application) — as 60kLOC would be easier to maintain than 12kLOC.
This is valid, of course, only for comparable code, not taking into account obfuscation, complete removal of tests, etc.
And also because of function overloading in, say, C++. To link code two functions with the same identifier which differ only in signature (e.g. types of arguments), we need to pass them to linker as two different functions with different identifiers.
It looks like at some point in last 7 hours CNN closed lite.cnn.io. Now it shows a single "Main story": "Please update to the latest version of the CNN app".