Sign Up

Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.

Have an account? Sign In

Have an account? Sign In Now

Sign In

Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.

Sign Up Here

Forgot Password?

Don't have account, Sign Up Here

Forgot Password

Lost your password? Please enter your email address. You will receive a link and will create a new password via email.

Have an account? Sign In Now

You must login to ask a question.

Forgot Password?

Need An Account, Sign Up Here

Please briefly explain why you feel this question should be reported.

Please briefly explain why you feel this answer should be reported.

Please briefly explain why you feel this user should be reported.

Sign InSign Up

The Archive Base

The Archive Base Logo The Archive Base Logo

The Archive Base Navigation

  • SEARCH
  • Home
  • About Us
  • Blog
  • Contact Us
Search
Ask A Question

Mobile menu

Close
Ask a Question
  • Home
  • Add group
  • Groups page
  • Feed
  • User Profile
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Buy Points
  • Users
  • Help
  • Buy Theme
  • SEARCH
Home/ Questions/Q 6124123
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Editorial Team
Asked: May 23, 20262026-05-23T16:05:48+00:00 2026-05-23T16:05:48+00:00

I finally got back to fleshing out a GitCommit message mode that I want

  • 0

I finally got back to fleshing out a GitCommit message mode that I want to add to YI but I seem to missing something basic. I can’t seem to match a single character in a grammar, all my rules only work if they match the entire line. I know this has to be possible because other grammars in YI obviously do this but doing the same thing doesn’t seem to work.

I want to have a commit mode that eventually looks very similar to the one in vim. One of the things that’s useful in vim’s mode is the keyword highlighting inside comments. Git puts a bunch of information inside comments in most everything it does (commit, rebase, etc.) so this is useful. My thinking was match the starting ‘#’ character in git comments and switch to a different context that will match keywords. However I can’t seem to make a rule that matches just the ‘#’, the rule switches to comment style on lines that only contain a ‘#’ but on lines that contain anything after the ‘#’ it does not switch styles.

What I have right now is:

<0> {
\#                             { m (const $ LineComment) Style.commentStyle }
$commitChars*$                 { c Style.defaultStyle }
}

<lineComment> {                                                                                                    
$nl                            { m (const Digest) Style.defaultStyle }                                               
·                              { c Style.regexStyle }                                                                
}      

Details omitted obviously. The idea is to switch to ‘lineComment’ mode when we see a ‘#’ and style things differently until we see the end of the line. According to the documentation and examples there should be a way to do what I want. I’ve tried pretty much every permutation I can think of for the ‘#’ pattern but nothing changes the behavior I’m seeing.
What obvious thing am I missing?

Edit:
The above code is from the implementation inside my YI branch. I have a standalone parser that exhibits the same problem here. If you run alex GitCommit.x && ghc --make GitCommit.hs && ./GitCommit < shortmsg you will see comment lines with content parsed as MessageLine and empty comment lines correctly marked CommentStart.

  • 1 1 Answer
  • 0 Views
  • 0 Followers
  • 0
Share
  • Facebook
  • Report

Leave an answer
Cancel reply

You must login to add an answer.

Forgot Password?

Need An Account, Sign Up Here

1 Answer

  • Voted
  • Oldest
  • Recent
  • Random
  1. Editorial Team
    Editorial Team
    2026-05-23T16:05:49+00:00Added an answer on May 23, 2026 at 4:05 pm

    Okay I finally figured this out. It looks like Alex always takes the longest match, not the first match. The rule for matching commit lines will always be longer since it matches the whole line. This causes Alex to always choose that branch over the comment branch. Quoting from the Alex docs


    When the input stream matches more than one rule, the rule which matches the longest prefix of the input stream wins. If there are still several rules which match an equal number of characters, then the rule which appears earliest in the file wins.

    I guess I should have read the docs more than once. The solution is to remove the ‘#’ from the $commitChars character set.

    • 0
    • Reply
    • Share
      Share
      • Share on Facebook
      • Share on Twitter
      • Share on LinkedIn
      • Share on WhatsApp
      • Report

Sidebar

Related Questions

Ok I've got a dreaded EXC_BAD_ACCESS that I can't seem to track down but
I was given this code a while back. I finally got around to testing
Well, now that I've finally got my stupid ODBC stuff configured, I took a
I've finally got this PHP email script working (didn't work on localhost…), but my
I finally got my code to reference the ruby-alsa library , but I'm stuck
I was working on a different portion of my app and finally got back
I finally got my group to switch from SourceSafe to Subversion. Unfortunately, my manager
I have finally got the green light to use Memcached in our project (after
I've finally got the datepicker to work on my MVC demo site and also
I've have finally got the datepicker to work on my MVC demo site. One

Explore

  • Home
  • Add group
  • Groups page
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Users
  • Help
  • SEARCH

Footer

© 2021 The Archive Base. All Rights Reserved
With Love by The Archive Base

Insert/edit link

Enter the destination URL

Or link to existing content

    No search term specified. Showing recent items. Search or use up and down arrow keys to select an item.