From: "Jostein Kjønigsen" <jostein@secure.kjonigsen.net>
To: theo@thornhill.no, 43559@debbugs.gnu.org
Cc: acm@muc.de
Subject: bug#43559: 28.0.50; [PATCH] Add csharp support to cc-mode
Date: Wed, 23 Sep 2020 10:46:54 +0200 [thread overview]
Message-ID: <3b523279-b05b-427b-7aeb-0e970d787704@secure.kjonigsen.net> (raw)
In-Reply-To: <87r1qt4ip3.fsf@thornhill.no>
[-- Attachment #1: Type: text/plain, Size: 3194 bytes --]
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@kjonigsen.net 🍵 jostein@gmail.com
https://jostein.kjønigsen.no
[-- Attachment #2.1: Type: text/html, Size: 5788 bytes --]
[-- Attachment #2.2: cbdccnkapbnidcfb.png --]
[-- Type: image/png, Size: 5798 bytes --]
[-- Attachment #2.3: dadgfepfdgfigdjo.png --]
[-- Type: image/png, Size: 9718 bytes --]
[-- Attachment #2.4: kgdddfodhnglljmd.png --]
[-- Type: image/png, Size: 8819 bytes --]
[-- Attachment #2.5: oclbllokmkogdccb.png --]
[-- Type: image/png, Size: 11134 bytes --]
[-- Attachment #2.6: nhalblonfacnkbej.png --]
[-- Type: image/png, Size: 4844 bytes --]
next prev parent reply other threads:[~2020-09-23 8:46 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-22 10:37 bug#43559: 28.0.50; [PATCH] Add csharp support to cc-mode Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-22 12:51 ` Jostein Kjønigsen
2020-09-22 13:10 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-22 14:26 ` Jostein Kjønigsen
2020-09-22 21:15 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-23 8:46 ` Jostein Kjønigsen [this message]
2020-09-23 10:11 ` Alan Mackenzie
2020-09-23 18:38 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-28 19:52 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-07-21 12:19 ` Lars Ingebrigtsen
2021-07-21 12:36 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-07-21 12:58 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-07-21 13:18 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
[not found] ` <jwvim13zo90.fsf-monnier+emacs@gnu.org>
[not found] ` <35791e76-b783-4856-a4e4-adf7996b5a45@www.fastmail.com>
[not found] ` <jwv5yx3zisf.fsf-monnier+emacs@gnu.org>
[not found] ` <jwvsg07y0jc.fsf-monnier+emacs@gnu.org>
[not found] ` <m1a6mf4fs0.fsf@Frende-MacBook.lan>
[not found] ` <jwvtuknwi87.fsf-monnier+emacs@gnu.org>
[not found] ` <m17dhj4bwo.fsf@Frende-MacBook.lan>
[not found] ` <jwvh7gkrcrw.fsf-monnier+emacs@gnu.org>
[not found] ` <m1mtpcouwb.fsf@Frende-MacBook.lan>
[not found] ` <jwveeamohsz.fsf-monnier+emacs@gnu.org>
[not found] ` <325FA529-DED9-4061-8536-39168D18A504@thornhill.no>
2021-08-25 16:07 ` Lars Ingebrigtsen
2021-07-21 14:05 ` Jostein Kjønigsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3b523279-b05b-427b-7aeb-0e970d787704@secure.kjonigsen.net \
--to=jostein@secure.kjonigsen.net \
--cc=43559@debbugs.gnu.org \
--cc=acm@muc.de \
--cc=theo@thornhill.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).