GNU bug report logs - #43559
28.0.50; [PATCH] Add csharp support to cc-mode

Previous Next

Full log

View this message in rfc822 format

From: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>
To: theo <at> thornhill.no, 43559 <at> debbugs.gnu.org
Cc: acm <at> muc.de
Subject: bug#43559: 28.0.50; [PATCH] Add csharp support to cc-mode
Date: Wed, 23 Sep 2020 10:46:54 +0200

[Message part 1 (text/plain, inline)]

On 22.09.2020 23:15, Theodor Thornhill wrote:
>
> my most recent patch seems to deal with this (attributes) properly, as far
> as I can tell.  I've tested with your example code and also with random
> files in the roslyn repository.  Fontification is still sparse here.
Basic attribute-indentation is confirmed fixed on my end. Still no 
fontification, but I don't think that's critical.
>
>> *Second: Object initializers are not indented properly.*
> This one should be fixed in the attached patch.

It's better, but not quite there. For a simple 1-level nested 
object-initializer, the line containing the closing bracket is still 
incorrectly indented:

>
> I think the recursion case works as well.  I've made an attempt in the
> attached 'test.cs'
I can't reproduce this. Are you sure the attached patch contains all 
your changes?

Looking at your example, your sub-initializer is actually a /collection 
/initializer, which may explain why it seemingly worked on your end.


>
> This (lambdas) one should be fixed in the latest patch.
Confirmed fixed on my end.
>> *Fourth: variable-fontification*
>>
>> Here I have no absolute C# convention to quote for absolute correctness,
>> but it kinda "feels wrong" to me at places.
>> So we'll have to make due with imperfections, make some pragmatical
>> decisions on what we think will be good default/fallback values, and
>> that's OK.
>>
> Agreed
>
>> Right now though, all implicitly typed variables (vars), local variables
>> with method-access and local fields with property-access are shown using
>> /font-lock-constant-face/ and that seems a bit off:
> This case is fixed now.  It was due to the 'var' keyword was put in the
> wrong basket.

Confirmed fixed. This change alone makes things look much better.

In the process of testing this, I've also taken a look at some other 
keywords: const, string, bool, int, async and await.

From what I can tell, they all look proper except for "await".

Looking in the patch, I see it's not mentioned there, so it should 
probably be a quick fix though?

Looking at faces more in depth, I also see annotated functions are not 
getting their function-names fontified.

I guess this goes back to the overall complexity of the attribute-store 
and core cc-mode support?
>
>> As for "_field" and "foo.", I'm not sure what the best fallback would
>> be. Without a language-engine to guide us, this is genuinely hard stuff
>> to get right.
>>
> Yeah, this one is kind of hard, so I've been ignoring it for a little
> while.  The easiest thing should be to remove the highlighting, but not
> sure if that is the best move so far.

I agree this is hard. Even trying to come up with some simple pragmatic 
rules, I'm constantly left thinking about "what ifs"... So we can leave 
it for now.

As for your test-file, I see you've added a multi-line case with a 
ternary operator. That made me look into multi-line statements in 
general. It seems they are not getting indented as expected:

Maybe if you figure out how to fix that, you will also fix the 
ternary-issue at the same time?

-- 
Kind regards
*Jostein Kjønigsen*

jostein <at> kjonigsen.net 🍵 jostein <at> gmail.com
https://jostein.kjønigsen.no

[Message part 2 (text/html, inline)]

[cbdccnkapbnidcfb.png (image/png, inline)]

[dadgfepfdgfigdjo.png (image/png, inline)]

[kgdddfodhnglljmd.png (image/png, inline)]

[oclbllokmkogdccb.png (image/png, inline)]

[nhalblonfacnkbej.png (image/png, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.