One feature I was missing from Chrome was Tab Groups. But recently (I don't know when it started) the feature showed up in FireFox too :-)
603 karma · joined August 25, 2011
One feature I was missing from Chrome was Tab Groups. But recently (I don't know when it started) the feature showed up in FireFox too :-)
Obviously one needs to be an Emacs user first
A 'crash' in most other language/ecosystem means likely a catastrophic failure of the application, ending in a core dump.
Erlang's error handling is way more nuanced than that blunt phrase indicates.
I haven't 'got' it yet. I am sure I will after some regular use.
But being a long time Magit user, its hard to move to anything else.
Unfortunately it has no mind-share.
After all this hype, they still can't do text to speech properly. Pause at the wrong part of the sentence all the time.
- They were loud (sonic booms were nasty).
- They were expensive to maintain and operate. Guzzlers. (Britain and France clung to them as a matter of pride/ego)
- They were narrow and uncomfortable. I have seen videos where there is space only for one stewardess to walk. I had been inside of one in Seattle museum. Very cramped.
- As you mentioned, ticket cost was high.
- I suspect people traveled in these mostly for bragging rights.Nobody is perfect :-(
Very subjective. I understand the rite-of-passage impulse to build one's own config. But it is simply too much time/effort investment if you are relatively new. This I say as someone who had my own config for a couple of decades.
When I came across Doom, I threw mine away and just adopted it. I even learned to like VIM/VI style text editing to use Doom effectively.
I also like the GodMode/Leader/Model style of text editing. The keybindings are more intuitive and more discoverable. When I enter a key and wait a bit, doom pops up next available options. I no longer memorize the keybindings. Just use the whichkey integration to find things I use infrequently.
Not to mention that it is well tested with the sets of packages for each release.
Obviously, not for everyone.
But I am a happy user and hope it exists for a long while.
There may not be enough code out there for LLMs to pick it up though.
It is easy to start creating objects in the repl (say if you are testing an API) and work with those created objects in the repl, one step at a time. You are able to observe the behaviour of the objects every step of the way. This gives you a much better idea when you are writing the functions (usually copy-pasting from repl) in the editor.
I am sure it can be done from the editor itself. (say using the 'comment' block in clojure). It is just matter of preference.
Share nothing, green-thread/coroutines also seem popular now a days.
I just close the tab when I realize it is AI. Not sure how long I can do this.
Brings back memories !
What I love about this is the fzf's fuzzy narrow down. You don't have to start at the beginning of command, you don't have to worry about exact spelling. Just a few snippets you remember, it will narrow it down really fast.
I use the same fuzzy search narrow downs in Emacs.
I miss it everywhere else.
As a fan of Hornblower series,I suspect most of the relevant details went over my head because I didn't understand this.
Executing a process and bringing back status, stdout and stderr seem tedious. While in Perl, it is as natural as it is in a bash script (well almost).
Raku on the other hand is _Fun_.
Perl was originally written as an amalgamation of grep,sed,tr, awk and I am sure a few more unix utilities with their own mini languages. The idea was to use one language instead of tying together half a dozen mini-languages in a shell script. And it worked really well. Perl being a demon with text munging didn't hurt.
Raku keeps this heritage but adds so much more (for better or worse :-) ). It inherits ideas from Lisp and functional programming languages. The thing that impressed me was, how easy it was to use concurrency.
With structural editing, no one ever have to match parens or count parens at the end...
YMMV ofcourse.