Hi:
This is my first mail in this list and maybe this is not the right place to ask, but I don't know where to (I don't use twitter or any other social network)
I have been using emacs for around 4 years now, and after all this time me and the the other 3 emacs user in my work have accumulated many question that will be very nice if any experimented user/developer could reply (even if you delete this mail from the list).
- Why does emacs doesn't have a C api to create extensions as almost everything else in the Linux environment? I know Elisp is very powerful, but many functionalities actually requires to start external processes or call shell commands intensively to work (magit, irony) and then parse the oulput when they could use the libraries and the APIs directly with dlopen or maybe with a more simplified/efficient approach. C is also the connection with everything (Python, Ruby, or FORTRAN) and nowadays there are more C/Python developers than Lisp developers, so many extensions could be created or ported. As is happening with vim actually.
- What's the actual status for the emacs-guile integration and why is it abandoned since 2015? This has to do with the previous and the next question because Guile already has a powerful C API, multithreading and many other functionalities that are been duplicated now in emacs. Maybe the future for guile is inside emacs.
- Native compiler? We have seen in the list some people talking about JIT compilation. Isn't it easier and more efficient to create a native code compiler like the one in Guile or maybe something that takes advantage of GCC, or a source to source compiler. Most of the extensions are just functions calls and loops and in this way Emacs could take advantage of the other's project progress and the emacs developers could put their effort in the most emacs's specific tasks? 95% of Emacs users are programmers, so a C compiler dependency shouldn't be an issue ans for sure there will be some performance improvement.
- As there are less developers now, why not to consider to make a cleanup and melt/join/merge projects/modes, for example (vile, evil and equivalent all do the same). This could be very helpful not only for the projects but also for the documentation that is becoming obsolete in emacswiki we suppose because of manpower. The same could apply to melpa projects that are unmaintained for a very long time. Some of them just don't work and have not received any commit in 6 or 8 years, so they probably break newest emacs Releases and nobody knows. You could also get tracks of the downloads.
- I have asked in my work and we are 4 emacs users only (in spite of we are more than 400 programmers) while most of the 3/4 of them are using vim. The main justifications are: "it is there" and "it doesn't require to configure anything". I have seen projects like spacemacs that solves somehow the configuration with a first start menu. Why don't you add a first time startup menu for the basic initial configuration in the default emacs, just to create a readable basic init.el? With use-packages it will be not that hard!!. Times have changed and young users need some hep to discover emacs, they will want to learn configuration details, elisp and the rest with the time. And nobody used the actual default emacs configuration. Spacemacs solves it partially but it makes absurdly complex to add manual configuration latter. And we don't need more abstractions layers. Simple questions like: add melpa? use vi like binds, or ergoemacs or ...? or use emacsserver? and some variable details that can be set very easily to have a functional user-friendly, minimal personalized environment like the the theme, linum, terminal or graphical interface by default). The idea is not only to make it easier, but also to show the power of emacs.
Sorry for the extension, but we prefer one long mail instead of 4 shorter mails.
Very thanks in advance
Ergus