Off-by-one issue in left-word for #region text

[Zastai]

Given a buffer with csharp-mode active, containing

#region Hello World

#endregion

// < cursor is at start of this line

Pressing C-left (i.e. left-word) will move point to the e of endregion, then the W of World, but then to the e of Hello, instead of the H. (Maybe it's trying to avoid going to the #?)

C-right has no issues and seems to always put point after each word like it should.

[josteink]

Hmmm. This one is a bit tricky.

I was initially not able to reproduce this bug, but I just pasted your example inside a class definition. Typing it out in a bare file however, I could reproduce the behaviour you describe.

But then I noticed some difference in fontification...

Immediately after pasting the content from here, the region's description is fontified using default, but after making some changes around it, fontified with font-lock-comment-face.

Now here's the tricky bit: The behaviour you describe only seems to occur after fontification has happened (making it a comment, not regular string).

Could it be that since syntax-wise Emacs considers this region a comment, that it assumes the first letter of a comment-statement should be skipped and introduces this off-by-one behaviour?

I have no idea, but so far that's my best guess.

@wasamasa: Do you think that sounds plausable?

[wasamasa]

Why, yes, it does. Behold the existing directives highlighting code:

(while (re-search-forward "^\\s-*#\\(region\\|pragma\\) " end t)
  (when (looking-at "\\w")
    (put-text-property (point) (1+ (point))
                       'syntax-table (string-to-syntax "< b"))))

In case you didn't know, < b is a comment starter of the b type, similar to # in many scripting languages. Apparently such a comment starter is hardcoded in syntax.c to not ever be a word start, causing the aforementioned behavior. Perhaps it would suffice to not mark the first letter following #region this way, but rather the space separating the directive from the remaining text. I'll have to experiment a bit to know for sure. This shit isn't even close to being properly documented.

[Zastai]

Hmm. Then perhaps instead of switching the syntax over, you could just use a regex to highlight the text after region/pragma using font-lock-comment face?
As an aside, I'm fairly sure whitespace is allowed between the # and the directive.

[wasamasa]

You pretty much have to use syntax tables to get both movement and highlighting of strings and comments right in major modes, so recognizing the case of a directive followed by a space (as opposed of a directive not followed by space which can't have a comment after it) is good enough to mark it as comment. Please test whether the change in the linked PR fixes things for you.

edit: Too tired, mixed up text properties for syntax tables with text properties in general...

[josteink]

Then perhaps instead of switching the syntax over, you could just use a regex to highlight the text after region/pragma using font-lock-comment face?

Not really. The current code is there quite intentionally. We had a bug in the past where applying this syntax was the only solution:

#42

[josteink]

Perhaps it would suffice to not mark the first letter following #region this way, but rather the space separating the directive from the remaining text

That's a ingenious yet simple solution. Love it. Totally approve.

[Zastai]

Aha, that makes sense (and bleeding string literals is something I've seen in other major modes too).

Anyway, yes I can confirm this fixes the issue I had.

I'll be logging a separate issue (with PR) for the issue that several places fail to handle whitespace after the # (e.g. with # region It's Johnny!, #42 reappears).

[josteink]

I just checked in Visual Studio. Seemingly that's a legal syntax too. Today I learned :)