Multi server feature

[sfavazza]

The basic feature seems to work. I encourage you at trying it on your side.

Remaining tasks:

• ensure no two servers have the same string in "server" sub-key (otherwise one would be obscured by the last parsed one)
• writing few examples to ease manual test (if would amazing to automate the tests in CI, but I don't see an easy way to automate)
• update documentation

[factyy]

Ok, I'll take a look when I have time. BTW you can try to invite yyoncho since he is the main author of the package and is much more experienced Elisp developer than me :)

[sfavazza]

Sounds good. Invitation sent 😊

[factyy]

Sorry, I haven't forgotten but still don't have time :(

[sfavazza]

Glad you kept me posted 😊

[factyy]

@sfavazza , I just got a look the the implementation: don't remember whether we discussed it before, but what if we don't use a new multi-server key and relied on whether the server key content is an array or a single section?

[factyy]

And one more thing: there was a fix (involving the default config) in the main repo (emacs-lsp#83), pay attention :)

[sfavazza]

@sfavazza , I just got a look the the implementation: don't remember whether we discussed it before, but what if we don't use a new multi-server key and relied on whether the server key content is an array or a single section?

Hello @factyy, I proposed in the past the keyword servers, but then I though it was too similar to server and I opted for multi-server. Though I totally miss the option to have lists in YAML.

That's a clever idea, I will implement it as you suggested (quite busy on my side now 😅)

[sfavazza]

And one more thing: there was a fix (involving the default config) in the main repo (emacs-lsp#83), pay attention :)

If you mean that I should merge it into my branch, sure thing! (or did I miss something?)

[factyy]

Keeping your branches in sync is always a good thing :)

[sfavazza]

Keeping your branches in sync is always a good thing :)

I have just rebased. If you don't have any more comments we could merge it.

@sfavazza , I just got a look the the implementation: don't remember whether we discussed it before, but what if we don't use a new multi-server key and relied on whether the server key content is an array or a single section?

Hello @factyy, I proposed in the past the keyword servers, but then I though it was too similar to server and I opted for multi-server. Though I totally miss the option to have lists in YAML.

That's a clever idea, I will implement it as you suggested (quite busy on my side now 😅)

I will implement this in the origin/multi_server_feature branch. After this there should soon be another MR.

[factyy]

@sfavazza , looks really nice right now! The only thing I wanted to clarify is: do you want to add support for separate per-server mappings?

[sfavazza]

I cannot forseen the need judging from my use cases. I would see if the feature request would come up. In that case it should not that hard to include the feature.

At the moment NO per-server mapping is considered.

For the time being can we merge this into my feature/multiple-servers-support branch?

[factyy]

I think yeah, it looks ok, go ahead. Please don't forget to test old cases (with a single server) so we won't have to deal with regression bugs :)

[sfavazza]

@factyy I am still debugging few issues when starting image-based servers. Hopefully I will manage to work on it in these days.