Thanks for clearing that up. With that said: since this change was introduced in cc-mode to fix a c++ issue, at least one bug have been introduced in at least two other cc-mode derived modes: csharp-mode and java-mode. To me it therefore seems that the proper place to fix this is in cc-mode. Anyone have any major objections to that line of reasoning? Am I still daring? :) -- Jostein Kjønigsen jostein@kjonigsen.net - https://jostein.kjonigsen.net On Sat, Mar 19, 2016 at 3:05 AM -0700, "Ingo Lohmar" wrote: On Sat, Mar 19 2016 08:29 (+0100), Jostein Kjønigsen wrote: > Just to ensure all cards ar on the table... Hi. I'm the guy who kinda > involuntarily has been maintaining csharp-mode for a couple of years > now :) > > (self-defensive-mode t) > > Basically Dino Chiesa left csharp-mode unmaintained on Google Code, with > issues unaddressed and breaking bugs unfixed and no work invested after > 2011. > > In 2014, After Emacs 24 broke it, I forked the repo, moved it to Github > and took over ownership. Since then 42 issues have in some way been > addressed or closed, most of them fixed. > > Rather than add features which I can't complete or support, the focus > was on ensuring that the core language-mode code works, and if you want > IDE like features, you just supplement it with Omnisharp. > > Basically its in bug-fix mode, which by no means should be taken as > "unmaintained" :) Hi Jostein, Sorry, I should have done my homework first. It seems your work on the fork started a few months after I started using csharp-mode, and I did not become aware of it. My comments above apply to the version that Dino left at Google Code. From your description, that all seems to me like the right direction to take the code. > If you've tried to do any work or improvements with csharp-mode, I would > love to see what changes you propose. It's not really "my" code, I'm > just trying to keep it in working order, and I have no qualms over > throwing big chunks out :) My own approach was more radical: I threw out everything that I thought did not belong to a bare-bones language major mode, and then tried to clean up the remaining code and get font-locking and indentation right. Besides a few special-case routines, that leaves me with mostly cc-mode variable settings. Incidentally that brings down the main file from more than 200k (Dino) to 36k (mine), compared to 163k (your latest). I will try to find some time to look into your code, but just from the numbers it seems that the differences are substantial. I should put my code into a repo anyway (been meaning to do that) and maybe something good will come from having both. But since I haven't used your version, I cannot reasonably file issues now anymore, sorry. FWIW, I was mostly annoyed by using arbitrary font-lock-faces (I think the function face was used for non-function symbols and so on), incomplete keyword settings and non-elisp formatting conventions. The performance problem came up in buffers with lots of literal strings, as the routines were very wasteful and used a lot of unnecessary regexp searching. > As for more closely aligning the goals of Omnisharp and csharp-mode, I > don't think that is such a far fetched idea. It has been proposed in the > past, but the Omnisharp-guys has (so far) preferred to have csharp-mode > be its own beast, which they supplement, rather than doing a full merge > (and thus taking on core language-mode responsibilities). Yeah, this was more of a general idea. There's an unfair gap in language-specific capabilities between special IDEs and Emacs for "big" languages like Java and C#, caused by the fact that those IDEs use parser and compiler information (or even duplicate their tasks). As has been discussed on this list before, part of the gap can be closed, but it's not clear to me how this would work best for basic things like syntax highlighting.