commercial-emacs

That looks awesome. Will switch and see how it goes.

Can someone explain? Cause I'm feeling a bit good... So is this a non-free emacs fork with some core improvements? And does the motto imply it comes with evil mode by default?

https://shmelpa.commandlinesystems.com/ has a FAQ which explains the motivation. On the one hand, I don't like the idea of fragmenting effort on Emacs, but on the other (and If I recall, this is part of the motivation behind the fork) this does prove the point that despite being on Github, the type of developers that will be able to make meaningful contributions don't suddenly come out of the woodwork.

Wow, big if true: Performant long lines. Tree-sitter font highlighting. 1 Gnus is rewritten to be non-blocking. Process management is rewritten. Tree-sitter replacement of ersatz PPSS syntactic parser. Moving garbage collector rudiments. Wonder what backwards compatibility or other features had to be broken (if any) to get performant long lines.

Wonder in one hand, * in the other. See which one fills up first.

But also big bad because it doesn't go upstream.

I don't think it explains anything. > This is the oft ideated, never sublimated “forge” repository for emacs. I know what the words mean, but this sentence means nothing to me.

I understand what you mean. The author has a brash, affectatious way of communicating. Some of it seems like they're just having fun, some of it seems like they're trying too hard to come off well-read or smart. In any case, I have seen them contribute good work to Emacs. Translation: "This is Emacs hosted, and taking patches, via Github." Does that sum it up, /u/nnreddit-user?

Upstream can always pull the changes in. Nothing is stopping them. This is happening because upstream won't accept commits.

> This is happening because upstream won't accept commits. Disingenuous way of putting it.

I’m not sure this really proves anything. This isn’t emacs proper, it’s a fork which hasn’t been around for long. Until it establishes itself as mainstream, any contribution comes with a big “nobody may ever see this” caveat. That’s a significant amount of friction to overcome, drawing any kind of conclusion is just silly at this point. It may take years for a community to build around a project like this.

I am especially interested in What is being done for the moving collector. How are they determining the stack roots for example? Emacs has traditionally implemented conservative stack scanning, but that is incompatible with a moving collector.

Everything you just said is exactly what it proves. The fact of whether or not Emacs development happens around a forge/PR workflow has little to do with who will contribute. The person who forked has removed the excuse of "but I don't like sending email patches or assigning copyright to the FSF". We'll have to wait and see, but I doubt many will contribute.

No, you’re not addressing the comment I’m actually making here. Contributing to GNU Emacs comes with two barriers: 1. You need to use the mailing list/patch workflow rather than the far more common pull request method. 2. You need to assign attribution for any code you write to another party Both of these can be blockers, and attribution can be literally impossible to assign in some cases. It’s disingenuous to deny that either of these cases presents a barrier for new contributors, which is why I take issue to the “nobody wants to contribute” rhetoric I commonly see. However, *neither* of these are the point I was making above. “Commercial Emacs” provides a *different* barrier to entry: **it is new**. You can’t put something out and a day later say “nobody is contributing so Stallman was right all along and it’s not about emacs”. New projects start *slowly*. You need to prove you’re still going to be around tomorrow before people will start giving you their free labor.

emacs-mac doesn't go upstream. Is it also bad?

> Contributing to GNU Emacs comes with two barriers: First, let me be clear that when I'm talking about "contributions", I mean significant contributions. Tiny changes do not require copyright attribution. e.g. If someone wants to spruce up a docstring, they'll only have to email a patch. When it comes to significant contributions, I'd say the two barriers you've listed are not the top barriers. IMO it's skill, knowledge, and the time/patience/desire to follow through the process of justifying one's patch. These barriers are not unique to Emacs. > attribution can be literally impossible to assign in some cases. The number of cases where copyright attribution is "impossible" seems rare to me. Can you give me some examples of when this is the case? I know some people don't like to bother their employers or see it through if their employer stonewalls them when they've made a request, but I wouldn't call that an "impossibility". I also don't see that issue coming up very often in general. > “nobody wants to contribute” rhetoric I don't espouse that rhetoric or its obverse. > You can’t put something out and a day later say “nobody is contributing so Stallman was right all along and it’s not about emacs”. I'm assuming that's the royal "You", because I haven't done any of that. I'm not associated with Commercial Emacs in any way. The last time the discussion about providing support for forge/PR Emacs development came up, Stallman was pragmatically considerate of the idea (as he and the maintainers are with many ideas that I see pitched on the devel mailing list). The issue of dropping copyright attribution is a separate one and obviously doesn't align with the goals of the FSF. > You need to prove you’re still going to be around tomorrow before people will start giving you their free labor. I understand the sentiment, but I don't agree. Plenty of people dump labor into new projects because the project excites them or they see the potential in it. There's also no way one can "prove" they'll be around tomorrow. There's a little irony to the simultaneously claiming the mailing list workflow is too old, and a github repo is now "too new". By the time the forge workflow is ready, who's to say it won't be too old compared to the new, modern guaranteed-to-multiply-your-devs way? Personally, I contribute to what I want, when I want, and get it over with before the Three Little Bears get home.

Were these changes submitted via proper patches? Obviously, core developers have enough to do anyway, so they won't just browse this code trying to pull in parts of it into the core.

You mean aquaemacs?

It takes a cathedral to replace the cathedral, and that's how you change a cathedral? Isn't the underlying problem a conflation of structures? It shouldn't require a complete change to open the door to making any changes. The unshakeable GNU if anything motivates looking for better ways.

I’m not sure that you’re grasping what I was actually addressing, and are instead cherry picking what you’re willing to discuss. However, before I outright accuse you of sophistry, let’s try again. This is my point of contention: > …this does prove the point that despite being on Github, the type of developers that will be able to make meaningful contributions don’t suddenly come out of the woodwork. This reads as “see, the emacs way isn’t flawed, it’s just that nobody wants to participate **and this is proof of that**”. Please note that you literally stated “proves” here. It is way, way too soon to say “well, end of discussion, we’ve proven the thing”.

> I’m not sure that you’re grasping what I was actually addressing, and are instead cherry picking what you’re willing to discuss. I grasp what you are saying. I just don't agree. I won't accuse you of cherry-picking or sophistry for not addressing every word of my previous comment. > This reads as... No. It reads as I wrote it. We actually are in agreement: I'm saying that moving development to a forge/PR workflow does not make developers appear out of nowhere. That's what I "literally said". > that you literally stated “proves” here. Yes. It proves what I said (that the developers haven't magically appeared), not that they never will or any of the conclusions you've drawn from my words. > It is way, way too soon to say “well, end of discussion, we’ve proven the thing”. Good thing I didn't say any of that, either. I even couched the statement with: > We'll have to wait and see, but I doubt many will contribute. I don't know how that signals "end of discussion", but this should: I'm not really interested in discussing this with you if you're going to put words in my mouth. Best of luck.

This is totally beside the point here and a tangent at best, but… I find this comment to be genuinely interesting. When I was younger “the cathedral and the bazaar” was a fairly common allegory for private/commercial/for-profit vs community built, open source projects. Usually this directly referred to Microsoft (the cathedral, a large project built by a small team of experts) and Linux (the bazaar, a shitload of small contributors creating something together out of small discreet stands). At least in my circles, the cathedral was an accepted bad thing. It gave me a chuckle to think of a GNU project as the cathedral. Thanks for that!

See https://bitbucket.org/mituharu/emacs-mac/src/master/

Cathedral and the Bazaar was always about a highly controlled process versus an ad-hoc organic emergence. It's still kind of funny because Linux emerged while I have never run GNU herd. [GNU](https://www.youtube.com/watch?v=AfEu1A4nPXk). I would not regret if Emacs was not a GNU project. That says uncomfortably too much about what GNU adds to software. On the topic of paid versus unpaid, someone from Ferrous Systems wrote more recently, to paraphrase, that paid development gives depth while open source gives breadth. Neither model claims to be total. They are each just statements describing a single dimension.

It seems that your comment contains 1 or more links that are hard to tap for mobile users. I will extend those so they're easier for our sausage fingers to click! [Here is link number 1 - Previous text "GNU"](https://www.youtube.com/watch?v=AfEu1A4nPXk) ---- ^Please ^PM ^[\/u\/eganwall](http://reddit.com/user/eganwall) ^with ^issues ^or ^feedback! ^| ^[Code](https://github.com/eganwall/FatFingerHelperBot) ^| ^[Delete](https://reddit.com/message/compose/?to=FatFingerHelperBot&subject=delete&message=delete%20ib0rkx3)

Very interesting, I hope this project succeeds -- I have recently been feeling disaffected with mainline Emacs, and would like for there to be an XEmacs successor. I also hope this project would eventually consider a name change. The "noncommercial" aspect of Emacs is something I still value, and I find the "commercial-emacs" name offputting, even if it is tongue-in-cheek.

Wait until it succeeds and then fork it and rename it. What could go wrong?

That's not how development works, you usually just don't pull things in and then fix them.

[deleted]

Is upstream somehow blocked from using these patches? Upstream doesn't care enough to accept some patches then why does it matter if someone else accepts them on a different fork? What difference does it make?

>It's still kind of funny because Linux emerged while I have never run GNU herd. It uses the GNU Compiler Collection and the GNU libc is quite a popular libc implementation. GNU Hurd didn't take off because of its design, not because of anything to do with the GNU project's philosophy. In fact, Linus Torvalds attributes the success of Linux to the GNU General Public License v2 > I would not regret if Emacs was not a GNU project. That says uncomfortably too much about what GNU adds to software. It says nothing about what GNU adds to software. If says something about what you think about GNU. Emacs wouldn't be Emacs without being free software. > On the topic of paid versus unpaid, someone from Ferrous Systems wrote more recently, to paraphrase, that paid development gives depth while open source gives breadth. There is no dichotomy between paid software and free software.

I have a small handful of opinions on this, honestly. First and foremost, this seems quite cool! I'm always a fan of saying fuck you to the FSF/GNU. They've been a shitty organization for ages for anyone but white, cishet neurotypical+abled men, they just used to be the only option so we lived with it. Stallman is a misogynistic, ableist asshole and I've always hesitated to get involved in the GNU contribution process because of it. I'm not necessarily a fan of the tongue-in-cheek nature of this project, but it's not a huge deal in my opinion. Hard to say if it'll gain any kind of critical mass, but I'll consider looking through to see if there's anything I can help with. IMO one of the biggest barriers so far is that I had to read a whole comment thread on Reddit to figure out what the fuck the README was trying to tell me though :p

has anyone tried it? He started uploading regularly videos on YT about it development. This looks amazing [Emacs Ling Lines video demo](https://youtu.be/kflDJ9L4siw)