nim-lang / nim-mode

An emacs major mode for the Nim programming language
137 stars 46 forks source link

complexity hit my contributions. #205

Open krux02 opened 5 years ago

krux02 commented 5 years ago

I really try hard to contribute ot nim-mode, but I hit a hard wall of complexity that I can't handle by myself alone. I would like to ask for help to understand the bits and pieces of nim-mode, so that I can help and fix problems.

I want to fix this problem here: https://github.com/nim-lang/nim-mode/issues/193

I tried using different methods, but the biggest problem is that I don't understand many of the libraries that you are using. The cl-lib was already a big hit for me that I had to learn, but now I guess I understand the important parts.

First of all, is it really necessary that flycheck-nimsuggest is in its own project? The fact that this is a separate project has a hit on the development performance of me. So is there a conflict that this backend and the flymake backend can't coexist at the same time, even when they are not used at the same time?

To talk about the problem above, for some reason epc creates a lot of epc connection buffers:

*epc con 3*                    0       Fundamental  (in `/tmp/')
*epc con 5*                    0       Fundamental  (in `/tmp/')
*epc con 7*                    0       Fundamental  (in `/tmp/')
*epc con 9*                    0       Fundamental  (in `/tmp/')
*epc con 11*                   0       Fundamental  (in `/tmp/')
*epc con 13*                   0       Fundamental  (in `/tmp/')
*epc con 15*                   0       Fundamental  (in `/tmp/')
*epc con 17*                   0       Fundamental  (in `/tmp/')
*epc con 19*                   0       Fundamental  (in `/tmp/')

when I run nimsuggest on the terminal, I get the following output:

$ nimsuggest scratch.nim
segmentation fault

I don't know why so many epc connections are opened is the case and I try to figure out how this can happen. To my intuition, there is a timeout that happens when the process doesn't respond and then epc just creates a new process buffer without cleaning up the old process. But that is just a rough guess.

My question is, why was epc chosen for the communication between nimsuggest and emacs? How does it compare to a native library call? What is the advantage/disadvantage.

Can you give me a rough overview on how the communication of nimsuggest from emacs works?

yuutayamada commented 5 years ago

@krux02 if you are asking me to this, sorry I don't really know the detail why EPC was chosen. It was already used when I started to use nim-mode. My guess is due to the parsing speed for Emacs. If I remember correctly author of EPC was mentioning Emacs parse parenthesis faster than Json or something (he is Japanese and sorry I could't show the reference) [EDIT] added 'faster'

krux02 commented 5 years ago

So EPC is there to make the parsing of the nimsuggest result async, not the nimsuggest request itself. So all of this complexity, just for the parsing of messages.

In my opinion it makes a lot more sense to call into a nimsuggest library instead of writing messages on the network stack that need to be serialized and deserialized, but maybe that is just me.

yuutayamada commented 5 years ago

FYI I'm trying to change first nimsuggest call with async #216

krux02 commented 5 years ago

I just wat your edit. I would guess so that emacs lisp has some builtin parsers that are fast for parenthesis expressions, but I don't think that you need epc for that. But that is just a guess. About your recent changes, thank you for coming back for nim-mode.