emacs-csharp / csharp-mode

A major-mode for editing C# in emacs
GNU General Public License v3.0
155 stars 47 forks source link

Ignore module error from tree-sitter feature #224

Closed jcs090218 closed 3 years ago

jcs090218 commented 3 years ago

This should fix #222

theothornhill commented 3 years ago

How about we just add them to the package-requires to csharp-mode.el? This can get a little messy, though it is a nice effort!

jcs090218 commented 3 years ago

I wonder what's the strategy to the package. Does csharp-mode rely on tree-sitter? Would user have to install extra packages that they don't use? It's always good to decouple each module to module and not to just add another dependency. If csharp-tree-sitter rely on tree-sitter then it should be in different package, so users that don't use tree-sitter can use the clean charp-mode.

For example, see https://github.com/fsharp/emacs-fsharp-mode/pull/253. fsharp-mode is currently reply on eglot yet it is totally unnecessary for a major-mode to operate. And now they are splitting up the package for eglot support.


Of course, you are the author and you have right to do so.

theothornhill commented 3 years ago

In principle I agree. However, the «strategy» is to gradually provide an even more useful csharp-mode.

It seems like I underestimated the interest for this mode, and people seem to not read the «experimental» warnings. Thus it seems natural to just add them as packages. In the end I hope to have the «old» csharp mode as an backwards compatible feature.

So to me, it is natural to add it as a dependency, if that eases adoption for those interested.

The fsharp discussions seems orthogonal from this issue, as that looks more like an eglot/lspmode «war». There is currently no alternative to tree-sitter.

I dont consider myself as the sole decision-maker here, and I am very much open to new ideas, though right now it seems like the simplest fix is to just depend on these packages.

What do you think?

jcs090218 commented 3 years ago

The fsharp discussions seems orthogonal from this issue, as that looks more like an eglot/lspmode «war». There is currently no alternative to tree-sitter.

True, what if another alternative to tree-sitter?

What do you think?

Well, you wrote the package so if you think this is the way to go then... just do it? I am here to provide my own software engineer professional suggestions but it's fine for people doing all kind of crazy stuff. It's an open source world! :D

TBH, this would not effect me since I already have the tree-sitter installed in my config. Lol

josteink commented 3 years ago

Let's avoid all these workarounds and just add tree-sitter as a dependency.

What do we gain by not adding it? (Apart from numerous bug-reports about things not working for anyone anymore 😅 )

jcs090218 commented 3 years ago

Great, glad we have the conclusion here. :)