Commercial-Emacs
github.com
github.com
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.
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):
https://www.bytedude.com/setting-up-rust-support-in-emacs/
> 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.
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.
And course the most valuable thing about Vi(m) is the concept of modal editing, not the implementation. Therefore evil mode is a must.
I've never used NeoVim though.
I agree VimScript is awful. When I learned about the first stable release of NeoVim I was immediately sold.
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.
Also, Emacs conservative stack scanning came from SIOD via SCM https://people.delphiforums.com/gjc//siod.html#garbage
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
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.
https://en.wikipedia.org/wiki/Boehm_garbage_collector
https://en.wikipedia.org/wiki/Tracing_garbage_collection#Pre...
"GC uncooperative programs using conservative collection" https://www.ravenbrook.com/project/mps/
I think it's a Bartlett-style "mostly-copying" collector, as in Scheme->C, but you can read the code and documentation.
I'll do some reading, thanks.
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.
Start of long thread:
https://mail.gnu.org/archive/html/emacs-devel/2016-11/msg005...
"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."
Boehm was dropped for good reason.
Boehm disagrees: https://www.hboehm.info/gc/#details
That thread isn't talking about the same thing, which it says no-one volunteered to write.
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.
Let's help it live up to its name, and submit a pull request that adds advertising banners and tracking code.
Performant long lines
Tree-sitter font highlighting
Gnus is rewritten to be non-blocking
Process management is rewritten
Tree-sitter replacement of ersatz PPSS syntactic parser
Moving garbage collector rudiments
[1] https://www.reddit.com/r/emacs/comments/v3iqdv/commercialema...
which would be a massive winner IMO.
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.
GNU Emacs doesn't use pull requests.
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).
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.
It's rarer to encounter projects that remove that language (most importantly, Linux kernel)
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.
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).
So weird is extremely accurate.
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.
The idea is at least that the FSF can update a buttload of code to GPL 4, 5, 900, etc if a flaw in GPL is discovered.
https://sfconservancy.org/copyleft-compliance/vizio.html
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.
https://sfconservancy.org/news/2022/may/16/vizio-remand-win/
In the U.S. . The GPL tries to match different international law systems.
have to rename it as specified in the license The work must carry prominent notices stating that you modified it, and giving a relevant date.
The FSF have a list of issues. At least GitLab (even EE) has freely licensed JavaScript
I dread scrolling through a mysqldump in Emacs.
;; 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.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.
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.
The sooner there is anything even remotely grammar-based for creating highlighters in Emacs, the better.
It's still very much a WIP, but the fact that it's there at all is promising.
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.
those people are there more then few years. so this improvement has nothing to do with these people ( except managerial role ).
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.
What's next? Cats you have to walk outside every day and pick up after?