> I know I'm a bit of an emacs user, but for this I've been using visual studio code because of one extension in particular: Cursorless.
Honestly want to know how many people here use Emacs like this? I thought Emacs users live their lives in Emacs. I know people who move more and more of their workflows into Emacs with packages like vterm, EAT, lsp-mode, pdf-tools, etc.
Are there seriously Emacs users who only a "bit of an emacs user". What is your workflow like? How do you decide when to use Emacs and when to use other tools? VSCode and Emacs have a lot of overlap in their purpose. How does this switching in and out of tools that overlap in their purpose feel?
I use emacs like that. When first getting into it, 20 years ago, I was very much as described above - slowly pulling everything in my life into emacs. And then the iPhone arrived, and I started pulling out things that I wanted to do mobile: email, to do lists, and eventually notes, and recipes. Most recently, I’ve started doing JavaScript in VS code, as the LLM assistants are better than what I’ve got in emacs, but I suspect this is temporary.
I find the emacs works best when it does everything, but there’s stuff it just doesn’t do, so I do that stuff elsewhere. I look outside of emacs if I think the task is going to be done mobile, and even then, I generally choose a solution that produces plain text so I can do it inside emacs if required - but sometimes that just doesn’t work out.
I suspect a lot of this is selection bias: the Emacs discussion you see online is often coming from fanatics rather than people who use Emacs without blogging about it.
Exactly and that's why I want to know more from those who don't do everything in Emacs and how they decide when to use Emacs and when to use another editor and how mixing both editors in your life works out for you.
I use Emacs for editing computer programs (and version control, some documentation, etc), as a calculator, and for interacting with R via orgmode. I don’t use it for reading email, editing other documents (gdocs, wiki, jira, etc), browsing the web, or even interacting with shells (I might call sort from Emacs but I don’t use shell-mode or similar.
> A few months ago I started a new job at a company that uses Elixir
> In fact, I might go as far as saying that Elixir gives you a fun language (like Ruby) while leaving out the stateful footguns OOP languages give you.
I don't mean to discount the author's experiences and opinion in this post. It's a nice post with a lot of good food for thought. Likewise I want to share only my own experience here. Two months into any new programming language, it feels like a fun language. Eventually the novelty factor wears off. And then it becomes a boring language. And I say "boring" in a positive sense.
The daily driver languages should be boring. Should present no surprises. Get the job done and get out of my way. When we transistion from the fun phase to that boring phase, what matters more is how good the language is fundamentally designed. As an example in Elixir the pattern matching abilities are great but I don't know if I could justify choosing a language without compile-time type safety in this day and age!
Emacs being Emacs it is possible to change how Emacs behaves for every key you type. Evil mode is a fantastic example of how you can emulate most of Vi within Emacs! But it's not the only game in town.
If you don't want to buy into the whole Vi and modal editing thing there are plethora of packages to have better key bindings. To name a few: god-mode, devil-mode, meow, hydra, general, spacemacs. Pick any from this and you don't have to worry about key chording anymore.
Yes, sooner or later this is going to become the future of GPT in applications. The models are going to be embedded directly within the applications.
I'm hoping for more progress in the performance of vectorized computing so that both model training and usage can become cheaper. If that happens, I am hopeful we are going to see a lot of open source models that can embedded into the applications.
Have you looked at devil-mode? If by Kraken you mean key chords, devil-mode lets you type without key chords but it does not force modal editing on you.
What are some other notable and open formats for notating scores? I'd like to know the what the popular formats are, do a survey and choose one for my own work.
ABC is the other major player in the space besides MusicXML and Lilypond.
The Mutopia project [1] is magnificent but largely abandoned in favor of MuseScore [2] which uses MusicXML. The amount of music available there is staggering but locked in to their backend.
Unfortunately automated translation is difficult because Lilypond is very oriented towards specifics on how the notation is rendered.
And, if you are interested in general archives of music, IMSLP [3] (Internet Music Score Library Project) has to be mentioned as well, but mostly contains scans of existing engraved music.
It's an open JSON format that's being hashed out by members of the music technology community. It's not production-ready yet, but I encourage you to get involved in the discussions! https://github.com/w3c/mnx/
(I lead creation of the format, as one of the co-chairs of the W3C Music Notation Community Group.)
MusicXML is pretty much the game in town as far as open formats go. Lilypond is an open TeX-like format, but it's really a domain-specific programming language for Lilypond itself.
> If so it seems unclear where to draw the line. If not it sounds nonfunctional.
There is no line. It is just one long linear list. An undo operation is an edit to the text after all. So the edit made by the undo operation also goes as a text edit operation in the undo list.
This is the way undo has always been in Emacs. I wouldn't say it is nonfunctional. I use this in Emacs undo, redo (which is undo-of-undo) and it feels okay most of the time. It is good to know that Emacs will never lose any edit even if I have performed a confusing series of undos and redos. But it can get confusing pretty soon if we are undoing and redoing on the same edit too many times.
That is why many people don't like linear undo history and install an undo-tree plugin which makes undos easy to navigate in a tree. Yet another reason to design some computer/software history lessons so that devs can learn from the existing techniques, their adoption, benefits and complaints.
> No, there is no undo "tree", nor any complicated graphical user interface to go with. ... You've got your undos, your redos, and that's it. The underlying data structure is strictly linear, but all edit states are preserved and reachable ...
This is exactly how Emacs works!
Emacs has worked like this since its beginning in 1980s. It was even documented in the first manual (1981):
This might seem to pile one disaster on another, but it doesn't, because vou can always Undo the Undo if it didn’t help. (page 137 of manual)
I think there needs to be some sort of computing and software history lessons. It can offer great value in the current world of software development. It will save you from the trouble of rediscovering techniques that are already in use in classic battle-tested software.
(And really? You need to invent a cheesy acronym for this? If that's what it takes to sell the obvious these days, how about SLUR - Simple Linear Undo Redo?)
Kakoune, like the more logical Vim it is, has both in a sensible arrangement: an undo tree with a current branch, which you can navigate up and down (u/U), and a linear history of the path you took through that tree, which you can navigate backwards and forwards (<a-u>/<a-U>). Unlike a single undo branch, you’re never afraid you’re going to lose your work when you need to go rescue a piece from a previous version; unlike a plain linear history like TFA proposes and Emacs uses, you’re not punished with a quadratic number of undo/redo pairs if you need a point behind several parallel do-overs of the same part. Unfortunately, without any sort of visible representation of all that I frequently find myself getting lost in the whole thing.
(Now that I’m thinking about it, Git’s commit tree and reflog play a similar pair of complementary roles locally.)
It's more of an implementation detail that is available to users. The article's simplification is also available via :earlier and :later, with the added bonus that they can take _time_ as a parameter as well as a simple revision count. “:earlier 1h” has been handy more than once.
In Anathem there were academics who spent their entire lives learning the history of academic scholarship for the express purpose of reminding everyone how often things are reinvented and preventing people from getting too excited when they have discovered something that was already known. I’m drawing a blank on their name, but it was one of the things about the book that I really enjoyed. It really helped to sell the setting, where the scientific method has been known and used continuously for 5,000 years or more.
Cite some of those counter examples. Not being snarky. It would be nice to see what those counterexamples are. Good to see a topic from opposite perspectives.
Can't you download backups regularly, rsync them to your local system that you physically own? If the single-entity business disappears you can just get a new VPS from another business and restore the services from backups, can't you?
Honestly want to know how many people here use Emacs like this? I thought Emacs users live their lives in Emacs. I know people who move more and more of their workflows into Emacs with packages like vterm, EAT, lsp-mode, pdf-tools, etc.
Are there seriously Emacs users who only a "bit of an emacs user". What is your workflow like? How do you decide when to use Emacs and when to use other tools? VSCode and Emacs have a lot of overlap in their purpose. How does this switching in and out of tools that overlap in their purpose feel?