On Thu, Aug 16, 2018 at 05:15:49PM +0300, Eli Zaretskii wrote:
>
>It does, since Emacs 26.1. See the emacs-modules feature.
This is an incredibly good new. The documentation maybe does not follow the common format, but it is perfectly fine for me. The sooner you include this in the tutorial the projects/collaborators will use it. Because I was looking around and I couldn't find anything.
>
>> - What's the actual status for the emacs-guile integration and why is it abandoned since 2015?
>
>AFAIK, no one is actively working on Guile Emacs. (And Guile itself
>is developed much slower than Emacs is.)
>
Opposite to the previous one this is a terribly sad new. But at least the C API could work for what I wanted.
>
>We just got a JIT branch a few days ago, please take a look and help
>work towards eventually landing it.
>
I will try it specially for benchmarking. I'm so tired of listening Vim users talking about how fast it is. Hope this could help to reduce the gap.
I would prefer that packages could compile to native code with gcc or so, (not only because of the expected speedup, but also for debugging facilities already available); maybe giving to the user the option to choose between bytecode/JIT/gcc and they will give live to the most successful one, but I understand that this requires a manpower unavailable now.
>
>I'm not sure I understand what you suggest in practical terms here.
>
I just suggest a cleanup/deletion/ deprecation advice in Elpa/Melpa. It is not a programming suggestion, but almost a logistical one. Because for new users it is confusing which package to install and the suggestions in the Wiki are usually the older options. So basically I have the feeling we have a volume of packages unmaintainable for the number of active developers I see. For example most of the documentation suggests to use smex while it is abandoned and the "successor" is amx fully functional and maintained. New users will install smex facing the already solved bugs. But also some new packages will use the old one for new purposes. Younger people need to know emacs from scratch as they grow with other completely different tools.
>
>Emacs is much more flexible, and different people have different
>needs.
>
Yes, but someone who opens emacs for the first time will open it to edit text and very probably to program, he should have color preferences and for sure he doesn't know how to add packages and the elpa repository (maybe don't even know about about something called elpa), so, the most basic customization options. If comes from vim/nano/gedit he will need some assistance that emacs can bring (not only the tutorial, but evile, bindkeys), but he don't know how get there. Maybe he prefers to use always the terminal version instead of the graphical one, or he will read the manual and something keybinds doesn't work, and blame emacs when tmux was the guilty.
>
>But that doesn't mean people cannot come up with such proposals.
>Please do propose practical changes, and they will be reviewed.
I really want to, sadly I am totally inexpert using elisp out of my personal configuration. I just started reading the elisp documentation like 2 months ago, and after this I will need to start with the coding styles and so on. So it will take a while before I could contribute in the adult league :( . BTW: Whats the best documentation (from scratch) to learn elisp and the emacs developement environment? Do you have anything like for example: "The Linux Programming Interface" from "Michael Kerrisk" but for Emacs?
Very thanks for your previous reply.
Ergus