#1 : score=5189 --------------- i want to use mouse the way it is used in other editors. Right click, select and drag should work like cut-paste. i want org-mode editing to look beautiful like as if I'm using evernote or similar web software for taking notes. #2 : score=3982 --------------- Would be nice if there is a orgmode tutorial focused on note taking and knowledge organising rather than task management. #3 : score=3749 --------------- Make it more welcoming for writers and researchers who don't come from STEM. Emacs is the best tool a writer can have full stop. The way it integrates advanced note taking functionality and writing is unparalleled. If it was packaged in a way that made that obvious, instead of it being a text editor, lots more of my friends in the humanities would use it! #4 : score=3602 --------------- 1. Improve the infrastructure. All Emacs users are expected to write Emacs Lisp. No matter s/he simply copy and paste configs from the web or writing his/her own configs. Therefore, for me, the first thing is to improve the Emacs Lisp since Emacs is built on Emacs Lisp. All popular enough scripting languages should be evolved into a proper programming language, e.g. JavaScript. If Emacs Lisp does not have proper threading support, implement it. If it does not have proper async/await support, implement it. Namespace supports? Also, the API design matters. Please keep improving Emacs Lisp ergonomics for the users. Besides, since there are so many major modes being written over the years, perhaps Emacs can formalise it into a framework such that more major modes can be written more easily in the future. I think this kind of formalising efforts will benefit the entire community and make Emacs the editor for the next 40 years. My ultimate goal is to be able to use Emacs for everything, literally. 2. Has a committee group to foster a stronger community, I like that Rust has its own official blog and can have a call for blogs every year (see: https://blog.rust-lang.org/2019/10/29/A-call-for-blogs-2020.html). It feels coordinated and systematic. It’s good to have a “leader” to stand up for Emacs and promote it. Currently, everything in Emacs likes like a grassroots movement. It’s like “You want something to be done? Do it yourself”. But that doesn’t feel like I’m part of something greater... Have something like Emacs RFCs? See: https://github.com/rust-lang/rfcs. Have an Emacs foundation that I can donate money to? Not FSF group, but Emacs group. So that Emacs group can hired someone to work full time on it? It’s not “just” an editor to me... 3. A guide to contribute to the Emacs community. Something about the copyright issue? What to sign and how? What license should I use for my Emacs package that can benefit the community most? GNU Elpa vs Melpa? How do I report bugs? How do I write patch for Emacs? Prefer a step by step guide. I’m currently most active on Reddit r/Emacs. I don’t know how to use the mailing list. I know I can subscribe to it. But I’m looking for something like a guide, like things that I should pay attention to participating in a mailing list. #5 : score=3546 --------------- Native support for wayland. I have a hidpi screen and use wayland and GUI emacs is always fuzzy in this environment, so I have to use terminal emacs. I would love to use GUI emacs as it would make my notes environment much nicer (rich text / inline latex rendering etc). #6 : score=3081 --------------- - Responsiveness! decoupling UI updates and input from any background tasks would make the user experience so much better. Right now it's way too easy for anything called on a hook to drag down responsiveness of the UI. - Lag detection during input: a tool that allows one to detect and warn when some code is making emacs less responsive. - Solid UI: right now popup frames for tooltips, documentation, completion lists etc behave inconsistently. They sometimes flicker, steal focus, not disappear when they should, randomly slow down and make emacs start lagging... Emacs should provide solid, first class, fast, async GUI elements for this kind of use cases. - first class async/multithread or at least concurrent UI/non-UI. - optional typing to allow for better optimization in gccemacs and easier to understand errors. #7 : score=2922 --------------- I wish the core devs on emacs mailing lists started to talk with the larger community. I know that Eli is browsing r/emacs regularly and Dmitry Gutov is very much in touch with the outside world, but still, every time I browse the mailing list I am gravely disappointed by the general atmosphere of complete indifference to the people who actually try to do modern software development with emacs. Also, I think the current development infrastructure of the project is just miserable. It's ridiculous to continue developing the project like its 1990's. We need a proper gitlab server, pull requests, on-line code reviews, continous integration (yes, we have to start writing tests) and so on. #8 : score=2795 --------------- write notes #9 : score=2780 --------------- This seems less than ideal: https://www.facebook.com/notes/daniel-colascione/buttery-smooth-emacs/10155313440066102/ #10 : score=2760 --------------- Dynamic variables make referential transparency hard, which in turn makes it hard to properly do cooperative threading. It'd be nice to have immutable data types, especially something like Clojure's maps. plists and alists are real pains to work with sometimes. I think the idea of packages takes away from one's sense of personal ownership or responsibility over their dependencies in their Emacs configs. When I used to copy scripts from the Emacs Wiki, I'd adapt the functions to my personal needs. It was clear that I was responsible for any breakage, but this was empowering because I also knew I had the ability to fix any breakage. With packages I usually just complain through Github issues, and I worry a lot more about packages being "abandoned." #11 : score=2729 --------------- Emacs imposes an internal workflow where everything is emacs and emacs is everything. If the text editing was on par with the other solution for the programming languages I use (better integration of predictive completion, or less headaches with local project configuration/dir-config files), it'd probably be closer to the first grade in my *personal* flow. There's still that undiscernable yet felt friction that holds me from going full time on it. #12 : score=2719 --------------- - Having a better bug reporting interface, I still haven't reported my Emacs 27.1 crashes because I don't know how to. - Having better defaults for users out of the box. As it stands, the default Emacs distribution isn't good at anything: not for writing, not for data analysis, not for coding, not even good at Emacs Lisp. As it stands, VSCode is probably a better editor for Emacs Lisp out of the box than Emacs is. At the same time, try to keep things relatively lightweight so people can choose how far along the editor <-> IDE spectrum they want to go. - Having better documentation, the Emacs manual is more of a reference and the EmacsWiki is very copy-paste heavy. I'd like more practical how-to/tutorial docs with information about packages, starter packs, tutorials, etc and I think this requires some cooperation with the Emacs community to publish blog posts and such.