bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#43559: 28.0.50; [PATCH] Add csharp support to cc-mode


From: Alan Mackenzie
Subject: bug#43559: 28.0.50; [PATCH] Add csharp support to cc-mode
Date: Wed, 23 Sep 2020 10:11:50 +0000

Hello, Theodor.

On Tue, Sep 22, 2020 at 12:37:54 +0200, Theodor Thornhill wrote:


> Hello!

> For some time, I've been a little dissatisfied with the support for C#
> in emacs.  Recently, there has been some breakage in handling of strings
> and fontification, more precisely:

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

The current C# mode uses syntax-propertize-function.  This clashes
nastily with CC Mode's use of the syntax-table text property.  When
syntax-propertize-function is non-nil, Emacs arbitrarily wipes all
syntax-table properties from a region then relies on s-p-f to reapply
all the necessary s-t properties.  However the current C# s-p-f only
applies a restricted subset of the necessary properties.  This will
produce random bugs.

The documentation for syntax-propertize-function didn't used to mention
this problem, but it does now.  (As from Emacs 27.2).

The method used in CC Mode to apply and remove these properties is to
add functions, effectively before- or after-change-functions, to either
or both of c-get-state-before-change-functions and
c-before-font-lock-functions.

> Also, it is using a lot of internal c-mode functions:
>   - https://github.com/josteink/csharp-mode/issues/153

> I've had some discussions with with the current maintainer, Jostein
> Kjønigsen (cc'd) about the future of this mode in
> https://github.com/josteink/csharp-mode/issues/162.

> Some points of note:
>   - It cannot easily be donated to emacs due to paperwork
>   - Jostein does not have time to do it himself
>   - I took upon myself to rewrite it in a separate branch, as an end
>   goal for it to be included in emacs

> While working on this, I realized the easiest way to get something good
> here is to overall reduce the complexity.  As such I created this patch.

CC Mode places a high priority on correctness, hence much of its
complexity.  That priority needn't necessarily be carried over to
derived modes.  ;-)

> It seems to work nicely, removing the need for the external mode
> completely.

You're proposing integrating a new C# Mode directly into CC Mode.  This
goes against CC Mode policy, both because it would swell the already
massive code base, and it would increases the danger of "orphan"
submodes.  We already have IDL Mode and Pike Mode which have remained
entirely and almost entirely unchanged in the last 15 years.  The people
who created them are no longer around.

Also, there is no advantage for an integrated mode over a derived mode
separate from CC Mode.  (If there is, that is a bug in CC Mode.  ;-)
There is a slight effort in using c-add-language, that is all.

> However, I see that including csharp here is most likely a bigger effort
> than just sending this patch, but I wanted to send what I have, and
> hopefully get some pointers.  Or in worst case stop before I go too
> far..

I don't see a reason why there shouldn't be a C# Mode directly in Emacs.

> This patch is written without consulting the current mode, so paperwork
> should not be an issue.

> In addition, the current mode has an implementation of imenu rewritten
> from scratch by Jostein, and as such I think this can be included as
> well.

> I tried not to do too much, since I believe most of the advanced
> functionality should be provided by an lsp mode such as eglot or lsp-mode.

That is a completely different topic.  The amount of work needed to use
one of these is massive.  For what it's worth, somebody familiar with
LSPs opined that they weren't yet sufficiently mature to support
something like CC Mode, but this was some while ago (between 1 and 2
years ago).

> Have a nice day!
> Theodor Thornhill

[ Patch snipped, but briefly scanned. ]

-- 
Alan Mackenzie (Nuremberg, Germany).





reply via email to

[Prev in Thread] Current Thread [Next in Thread]