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" <i.lohmar@gmail.com> 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.