bug#23053: 25.0.92; error in cc-mode when editing C# file with a generic class inheritance

[Jostein Kjønigsen]

On Sat, Mar 19, 2016, at 12:08 AM, Ingo Lohmar wrote:
> 
> It is quite daring to call out an Emacs bug when you only encounter a
> problem in "random" 3rd-party code :)
> 
> I have used csharp-mode before --- unless something has dramatically
> changed in the last 3 months, it is essentially unmaintained.
> 
> Also, and I hope this does not sound too harsh, the csharp-mode code has
> its fair share of problems to begin with.  For example, it uses faces
> and cc-mode variables in ways that they are not intended for.
> Therefore, it is plagued by more or less subtle font-lock and
> indentation bugs.  It has severe performance problems.  It has not been
> updated to deal w/ recent C# additions.  It is also fairly bloated,
> adding "features" only remotely related to editing C# code.
> 
> About a year ago, I started to strip down the code to the bare
> essentials and tried to make it more robust and play nicely with the
> cc-mode machinery.  While this worked.. hmmm.. ok for the most part, I
> have hesitated to put any of that code out in the open, as some of the
> above problems remain unsolved.  My take-away was that cc-mode is a big
> and complex beast as it stands, and I am not too eager to dive into all
> its details.  If nobody else is doing the dirty work, chances to
> properly support C# in **this** framework are pretty slim, I guess.
> 
> My hope is that the open-sourced Roslyn framework that is now used in
> Omnisharp (haven't tested it) could also be used to do the whole
> font-lock/indentation thing, such that we would not have to try to fit
> C# into the cc-mode shape.

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" :)

With all that said, I don't think you are being overly harsh. The code
does have obvious issue here and there and maybe even everywhere, but I
don't think it's as bad as you paint it out to be.

The only performance-problem I am aware of is with the imenu-indexing,
and that's only for extremely big files not adhering to C# conventions
of one class per file. This is also code which can be disabled and
replaced with a (much better) Omnisharp-based alternative.

All in all its works reasonably well. Especially for being maintained by
someone not particularly well versed in Emacs lisp :)

(self-defensive-mode 0)

So if you feel like there are issues which should be addressed, please
feel free to raise them on the Github issue tracker:

https://github.com/josteink/csharp-mode/issues

I can't address or fix things I'm not aware of needing fixing. :)

I'm all for constructive suggestions to make the code a little less
horrible (and you seem to have a few). Please post them!

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 :)

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).

Now with all that said... And back to the bug. *phew*

This particular code which is now breaking has worked reasonably well
since Emacs 22 without any changes as far as I know.

*If* anyone says this bug is best fixed in csharp-mode, I'm not going to
argue a helluva lot over that, but I would appreciate some leads on how
to avoid tripping up cc-mode after recent changes in git master, while
remaining compatible with older Emacs-versions out there.

So to move the issue forward I guess we need to decide: Are we blaming
cc-mode or csharp-mode?

Anyone with strong opinions on the matter?

-- 
Jostein Kjønigsen
jostein@kjonigsen.net / jostein@secure.kjonigsen.net