This does look potentially interesting and I hope it takes off and does NOT take 5 years just to become useful and easy to install (seriously, I don't care about build scripts; just put it on a few package managers with the scripts embedded inside and be done with it).
That being said, after 20 years of Emacs I finally gave up and started learning NeoVim with its various nice plugins. It's a drag and a grind but every little thing I learn improves and accelerates my workflow -- the experience is rewarding.
And there always is some issue with Emacs, always and inevitably. I got tired of chasing after it, and I tried a number of "distros" like Spacemacs, Centaur, DOOM and 1-2 others whose names I don't remember.
Suddenly and out of the blue, neither Elixir nor Rust LSP modes can find the root of a project (?!)... whereas NeoVim LSP finds them just fine. I know, I know; it's not "out of the blue", but again, I got tired of pampering a piece of software that's apparently so fragile that every little small movement in the other parts of the system breaks it. It's burning me out.
Never should have started with Emacs and it's on me that it took me so long to finally give up on it, I know, but I'd really expect from programmers and "hackers" something more informative and supportive than "make it your own by tinkering, dummy".
Apparently it doesn't occur to those people that doing full-time programming and tinkering with your editors in off-duty hours is not everyone's dream life.
A good reasonable set of modern features and lack of friction out of the box are important. Emacs people don't value that. Pity. They lost a formerly passionate user.
> Suddenly and out of the blue, neither Elixir nor Rust LSP modes can find the root of a project (?!)
I ran into this exact thing. The solution for me was to use eglot. I just wrote this article describing my config (might need an update soon because some things still needed additional tinkering):
> Apparently it doesn't occur to those people that doing full-time programming and tinkering with your editors in off-duty hours is not everyone's dream life.
> A good reasonable set of modern features and lack of friction out of the box are important. Emacs people don't value that. Pity. They lost a formerly passionate user.
Completely agree. I needed to setup a Rust environment in Emacs for work purposes and it was an awful experience, and even after all that I don't have a great Rust experience. Theoretically Emacs is the best editor, but in practice it takes hundreds of hours of configuration to get going and then you find out it's painfully slow. (To be fair though, I squeeze every drop of Elispy usefulness out of this program that I can.)
My Emacs is at a state where I'm pretty happy with it, and I limit my time trying to improve it more - but it is so hard for me to recommend it to anyone.
Thanks a lot for the link. I enjoyed reading your article and all linked GitHub issues. The `lsp-mode` maintainer showed himself as a bit offended and insecure and that definitely made me lose faith in his project, can't deny.
I might try your setup or might not -- after all, we should not forget that the answer to "Emacs requires constant babysitting" can't be "well, now go do that extra babysitting", right?
> Theoretically Emacs is the best editor, but in practice it takes hundreds of hours of configuration to get going and then you find out it's painfully slow.
Yeah that sums it up for me. And they are taking pride of the fact that they are just starting to work on multithreaded engine... in 2022... {facepalms}
I am still fairly primitive in NeoVim but I already like it more.
Interesting. I've moved to Emacs after 20 years on Vim because Vimscript is horrible and hacky and I've seen so much brokenness in plugins. It's quite refreshing to use an editor with a proper language powering all the bells and whistles.
And course the most valuable thing about Vi(m) is the concept of modal editing, not the implementation. Therefore evil mode is a must.
> But one thing moving collectors can do that non-moving ones can't is generational sequestration, that is, keeping the youngest cohort of Lisp values separated from older ones. This allows fast, intermediary cycles which only scan the "nursery" generation (the rationale being old objects are very likely to still be referenced). A non-moving collector must traverse the full set on each cycle since its allocations are interleaved. This is why Emacs bros are as eager to raise collection thresholds as motherboard jockeys are to overclock their BIOS.
That is untrue. TXR Lisp has a generational GC, over non-moving heaps. The way this works is incredible. Are you sitting down? Okay, here is a pen and sign the non-disclosure agreement. Good!
So, when baby objects are allocated, pointers to these objects are recorded in ... a nursery array. Not the objects themselves, just their pointers.
During a fast garbage collection cycle (in the sweep phase) we just have to sweep through this array to find the unreachable babies all in a bunch, rather than looking for them through all the heap blocks.
Indeed. Emacs actually got a preliminary port to the Boehm generational, incremental, mark-sweep collector many years ago, with a complete lack of interest in pursuing it.
> Indeed. Emacs actually got a preliminary port to the Boehm generational, incremental, mark-sweep collector many years ago, with a complete lack of interest in pursuing it.
Ja have a link? Asking because I've interacted with the devs and they are highly focused on getting emacs better. They would not reject it if it offered solid value.
Also you have a link to this Boehm collector you mention as the only one I know of is the conservative one and I'd like to know more. TIA
You may not believe the history, but you weren't there; I don't know how much is in mail archives. There was, for instance, a bizarre campaign to keep the charset `unification' out of Emacs 22. For some reason rms went along with that even when eval showed the argument was bogus.
That looks like the boehm GC, but Boehm is conservative. In no way is the Boehm GC that I'm aware of is generational or incremental (though it is mark-sweep).
"I was poking at alloc.c recently and realized that the existing conservative GC code is somewhat unsafe. In particular,
1) mark_maybe_pointer looks only for exact matches on object start. It's perfectly legal for the compiler to keep an interior object pointer and discard the pointer to the object start.
2) INTERVAL is GCed, but it's not represented in the memory tree: struct interval isn't a real lisp object and it's allocated as MEM_TYPE_NON_LISP. Even a direct pointer to the start of an interval won't protect it from GC. Shouldn't we treat intervals like conses?
We've been getting by on dumb luck and the magnanimity of the compiler."
I don't have time to go over the thread - conservative seems dodgy. I'll have to take your word for it. As for your main point, much to my surprise, you're right although I don't understand how, it doesn't match what I've read of it. No matter, you're right.
Slow in the same way that the conservative stack scanning was bound to leak. I did actually run Emacs with it after experience elsewhere.
Edit: I wonder how Boehm is somehow "most conservative", compared with, say, the Memory Pool System which I'd also look at these days but wasn't an option then.
I think it's an option, but I admit not one I was aware of. AFAIK the MP is a framework, and this is an option not the only way... but still, you're again!
Object mutating assignments are checked for old -> new direction and handled in one of two ways, let's call them A and B.
Under method A, when a old -> new assignment takes place, the new object is added to a "check" array. At the same time, its generation is changed from 0 to -1, so that this is wastefully not done twice. Objects in the check array are processed during the mark phase; they are marked as reachable (and that will promote them to the mature generation).
Under method B, the new object is not involved. An old object has been mutated and we record it in a "mutated" array. (So that this isn't done twice for the same object, we also change its generation to -1; that gets fixed back during GC.) The "mutated" array is subject to marking in the mark phase (even though mature objects are not), in order that we chase the references from that object to any new object. These (necessarily considered reachable) objects are also processed in the sweep phase to return them to gen 1.
When might you use method B? Say there is a bulk assignment operation, like hundreds of elements of a vector object are set to values, some of which may be new objects. In that situation, it's more efficient to put the aggregate object into the mutated array and not deal with any information about the right hand side objects at all.
So this is a choice made by the user? Or the choice is made automatically using some heuristic? Regardless: I don't really see the point of avoiding moving gc if you have to have barriers. Moving gc will be faster; the only reason I can think of for avoiding it is to avoid mutator overhead, but you are paying barriers anyway.
I don't like some of the moves being made by emacs lately, deprecating libxft for example. It's been fixed but the FreeDesktop people won't take the patches because they're "so over" X11 now.
Could you link to what you’re referencing? I’m not familiar with X development but it looks like libXft had a 2.3.4 release around 10 months ago, which seems relatively active for X-related projects.
I don't really understand what exactly this is. It looks like an open source version of emacs, but I don't understand how it is commercial. Could someone explain more or point to a better description of the project?
The "why" section of the repo explains it, but there may be some missing context. All contributors to Emacs are required to assign copyright to the FSF before their contributions will be accepted. This[1] explains why.
It kind of seems like a pointless middle finger to a situation in which... doing exactly this fork is permitted in the first place. Upstream GNU Emacs is already on a forge, putting it on GitHub doesn't seem to have much point beyond "because I can".
Maybe he doesn't like the copyright assignment requirement? Fair, maybe, but I personally think it's not a big deal.
"Commit rights" sounds like the bad old days of CVS/SVN. Send a pull request to GNU Emacs, get rejected or accepted. It's a lot easier nowadays.
Not sure what you think Emacs does, but it very much uses pull requests. You write/change code, commit it, send emails to a mailing list requesting to incorporate the code.
Just because it's not GitHub doesn't mean it doesn't use pull requests (which predate GitHub, all the way back to Git's first releases in 2005).
It's certainly prolix, but it's a frequent topic of discussion that Emacs contribution is hindered by the patch model and copyright assignment. This gets rid of both at once, and forge[1] is (was?) a fairly common term, though the term may be falling out of use due to the increased popularity of the model. Loosely translated, "everyone talks about putting Emacs on GitHub, and no one does it, so here it is."
FSF has required an assignment since day 0 (I wrote the blanket assignment a few years later when Cygnus was paying people to changed code owned by the FSF).
The base problem is: who has standing to sue if there is a GPL violation. People have sued in this case when it was Linux (which does not require an assignment), but no defendant has yet tried the defense “you don’t have standing to sue me because you are not the copyright holder of the lines of code in question”. Like the FSF, I fear that this could unfortunately be a very effective defense (against being sued for violating the license) in most jurisdictions.
Edit: Case timeline: sued in state court as a contract claim, vizio moved it to federal court saying its a copyright claim, federal judge kicked it back to state court to hear the contract claim.
I feel like the principles used to argue this case are applicable elsewhere too, according to Wikipedia, it sounds like at least in England, Europe and South Africa have the concept of a "third-party beneficiary" to a contract:
I think it intentionally doesn't work in the way you're speculating here. Assigning copyright to FSF means that they can relicense the code in the future. We trust that this future license will be a GPL derivative.
Suppose I don't sign over copyright. Instead I license my code to the world under GPLv3, and you incorporate it into your project. You can use and share my code under the terms of GPLv3, of course. But that doesn't mean you can share it under a future GPL version, say GPLv99, without my permission -- because the terms of those versions may be incompatible.
The linked FSF statement by Eben Moglen is about enforceability, not future GPL licenses.
The normal state of affairs for a GPL'ed project is having mixed copyright. After all, you can't stop anyone from forking to add their own, copyrighted, changes. That's the whole point.
If mixed copyright means the GPL doesn't well enough, then the GPL doesn't work well enough, period. This is not an anti-GPL statement, on the contrary: Most people seem to trust the GPL well enough to not require copyright assignment. The FSF is the odd one out.
If I'm understanding, I don't even get why you would go through the effort.
It sounds like the author wants to add these features to main-line emacs, and expect other people to maintain it while he holds some kind of copyright.
Emacs is one of the last pieces of software people would want to "move fast and break things". And what does copyright or ownership even get you?
They took something existing that's been worked on since probably before he was born, agreed to the license, and added features only they have reviewed and tested. And I guess expected to face little resistance to get his code in to be tested and maintained by everyone else.
It doesn't even sound like it's a big deal to maintain their branch. They said mainline is merged in every hour. The hardest part sounds like adding a different URL in your package manager and dealing with a rare merge conflict (which you could easily put off for a long time if you don't care about bleeding edge).
Its a reference to two things: the whole github is a non-free platform and the fact that if you for a GPL project and make changes you have to rename it as specified in the license so nobody mistakes your version for the original.
I think you highlighted the part I'm referring to and I misinterpreted it long ago. I think the simplest way to emphasize that you've made changes is to re-name your fork, which is kind of standard for projects like this one where they're going to code, do their thing and pull in changes to stay current.
You can edit gigabyte-large files with no trouble vlf.el https://github.com/m00natic/vlfi – though it's a bit of a separate universe, you have to use vlf-occur instead of occur to find matches over all gigabytes of the file
;; To have it offered when opening large files:
;; (require 'vlf-setup)
;; When such files are detected, the command `so-long' is automatically called,
;; overriding certain minor modes and variables with performance implications
;; (all configurable), in order to enhance performance in the buffer.
Tree-sitter highlighting is interesting. I usually find emacs to have slightly worse syntax highlighting than other editors for most languages I use.
When I've mentioned this before someone usually explains why I am wrong and it is actually superior or whatever. I do not care I don't like it as much. It's nowhere near enough to drop emacs over but if this changes it I might prefer it.
I don't know what this fork brings to table, but you could try tree-sitter today with your vanilla Emacs using a package[1] that works via dynamic module.
Personally I am more interested in getting structural selection and navigation reliably working for any language. There is also a package named combobulate[2] to help with that.
Dunno about the overall ceiling of Emacs' syntax highlighting capabilities. But the few times in the past that I've had reason to look at the definition of the highlighting for specific languages, the Lisp code has looked like horrific imperative rats nests.
As with most things Emacs, there is no real ceiling to what you can do, because elisp. But as you observed, there's a reason that using syntax-table rules to write a highlighter has been called "black magic".
The sooner there is anything even remotely grammar-based for creating highlighters in Emacs, the better.
1) highlighting - most unnecessary thing people invented, except values and :things: in ""
2) LSP client provides these things exactly as other programs do.
GNU means do everything different because otherwise it is not GNU, so maybe thats not good thing after all.
This push is so strong even Steve Jobs started to Think Different after cloning BSD in 199x...
Dont really care for the opening quote about the emacs maintainers. Emacs is moving plenty fast. I dont see why they wouldnt contribute upstream. Its added such an insane feature list in the last few years (native compilation???, tree-sitter in progress, PGTK) . Sure this has some nice features but its not like any of them are outside the capabilities of the people making the version of emacs most people actually use, better, given how monumental the improvements that have already been made.
It would be nice to get a better GC in, and the long lines. It just seems like the author is acting as though they are the only ones to be attempting to make real improvements despite the obvious efforts by a good few other people.
Emacs maintainers do an insane amount of work! They know most of the code, write new code, review code submissions, support a bunch of mailing lists and answer numerous stupid questions.
That being said, after 20 years of Emacs I finally gave up and started learning NeoVim with its various nice plugins. It's a drag and a grind but every little thing I learn improves and accelerates my workflow -- the experience is rewarding.
And there always is some issue with Emacs, always and inevitably. I got tired of chasing after it, and I tried a number of "distros" like Spacemacs, Centaur, DOOM and 1-2 others whose names I don't remember.
Suddenly and out of the blue, neither Elixir nor Rust LSP modes can find the root of a project (?!)... whereas NeoVim LSP finds them just fine. I know, I know; it's not "out of the blue", but again, I got tired of pampering a piece of software that's apparently so fragile that every little small movement in the other parts of the system breaks it. It's burning me out.
Never should have started with Emacs and it's on me that it took me so long to finally give up on it, I know, but I'd really expect from programmers and "hackers" something more informative and supportive than "make it your own by tinkering, dummy".
Apparently it doesn't occur to those people that doing full-time programming and tinkering with your editors in off-duty hours is not everyone's dream life.
A good reasonable set of modern features and lack of friction out of the box are important. Emacs people don't value that. Pity. They lost a formerly passionate user.