4 ms·

I'be been using Emacs for 17 years mostly for programming-related tasks. My opinions are: - Emacs is an editor for people who think that learning some Lisp sou

I'be been using Emacs for 17 years mostly for programming-related tasks. My opinions are: - Emacs is an editor for people who think that learning some Lisp sounds fun if they don't know some already. - Emacs should not bother trying to appeal to a more general audience; it's not an editor for most people when new to programming, and it's an editor for a very small minority of non-programmers. - Emacs should focus on its strengths: it is the most powerful and extensible editor ever created. As long as it looks after that identity, it will always be highly respected. - The infinite customizability via emacs lisp and the ecosystem of libraries is the only thing that can make Emacs more attractive than other editors. - Emacs should be sleek, minimal, fast, and visually beautiful, by default. - The customize interface is ugly and not a priority; it should be expected that Emacs users will configure things in Emacs Lisp. - The clunky default icons and splash screen should be got rid of: present a blank screen with minimal tooling if a beautiful first impression cannot be created. - Many of the elisp packages that ship with Emacs should be removed from the core, with users installing them as packages (Org-mode, Gnus, etc), leaving a more easily maintainable core.

EsotericAlgo 6y ago
I agree that a leaner core seems intuitively right. However, the discussion on emacs-devel has been in the other direction as of late https://lists.gnu.org/archive/html/emacs-devel/2020-04/msg01421.html https://lists.gnu.org/archive/html/emacs-devel/2020-04/msg01....
- Myrmornis 6y ago
  Thanks I skimmed that thread and the one this HN thread is about. There are so many depressing things. In particular this arrogant and utterly ignorant condemnation of Pull Request-based workflows infuriates me: > A lot of people have not been contaminated by the entitlement that comes with the "I'm sending a PR, please check it in" generated by the Github culture. I don't think the person who wrote that has even looked at the pull request review that goes on in high quality emacs packages on GitHub, let alone participated in it. This sort of thing really makes it clear that some of the people on emacs-devel are hopelessly out of alignment with the majority of the people would would willingly contribute to the emacs and emacs lisp package ecosystem. There are many good reasons not to included packages in core Emacs. A big one is that package authors are working in their own free time and don't want or need to have to prepare an especially bug-free release to coincide with Emacs release cycles. Also they don't want to support users using the old version that is in Emacs.

EsotericAlgo 6y ago

I agree that a leaner core seems intuitively right. However, the discussion on emacs-devel has been in the other direction as of late https://lists.gnu.org/archive/html/emacs-devel/2020-04/msg01421.html https://lists.gnu.org/archive/html/emacs-devel/2020-04/msg01....

Myrmornis 6y ago
Thanks I skimmed that thread and the one this HN thread is about. There are so many depressing things. In particular this arrogant and utterly ignorant condemnation of Pull Request-based workflows infuriates me: > A lot of people have not been contaminated by the entitlement that comes with the "I'm sending a PR, please check it in" generated by the Github culture. I don't think the person who wrote that has even looked at the pull request review that goes on in high quality emacs packages on GitHub, let alone participated in it. This sort of thing really makes it clear that some of the people on emacs-devel are hopelessly out of alignment with the majority of the people would would willingly contribute to the emacs and emacs lisp package ecosystem. There are many good reasons not to included packages in core Emacs. A big one is that package authors are working in their own free time and don't want or need to have to prepare an especially bug-free release to coincide with Emacs release cycles. Also they don't want to support users using the old version that is in Emacs.