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: Theodor Thornhill
Subject: bug#43559: 28.0.50; [PATCH] Add csharp support to cc-mode
Date: Wed, 23 Sep 2020 20:38:22 +0200

Alan Mackenzie <acm@muc.de> writes:

> Hello, Theodor.
>

Hello, and thanks for responding!

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

Thanks for this information.  It will help me investigate further.

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

[...]

>> 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.  ;-)
>
Hehe, yeah - it is my hope to leverage more what is already there.

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

I see your point here.  I guess I wrongly assumed this should be the
main way to include new cc-mode based modes.

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

That is good to hear.  I guess I'll try to reimplement this patch using
this api, rather than convince you to pollute CC Mode.

>> 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.
>
Good. I'll start working on csharp-mode.el, rather than integrating
things.

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

Yeah, I wasn't really suggesting to integrate CC Mode with eglot.  I was
merely commenting on reducing the scope of this potential mode.

Thanks for taking your time so far.  I think I'll for the time being
leave this bug, take it back to github, and create a standalone mode. 

(@Jostein - I'll respond to your comments on GitHub)

Have a nice day/evening,

--
Theodor Thornhill





reply via email to

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