Significance of identifier colors about fstar-mode.el

[cpitclaudel]

Hey Nik,

It probably means that there's a bug somewhere :) Can you post the corresponding source? I'll have a look.

[nikswamy]

https://github.com/mitls/mitls-fstar/blob/master/src/tls/ConnInvariant.fst

I'm using GNU Emacs 24.5.1 (i686-pc-mingw32)

Thanks!

[cpitclaudel]

Thanks Nik. This seems to be due to the heuristic for guessing whether something is a variable or a function; it highlights things as functions if it sees anything looking like an argument before seeing an equal sign after a let-binding. Since syntax highlighting works on a per-line basis in Emacs, it gets confused about the last two definitions, and accidentally highlights the first of the two differently because of the final space.

The indentation code is actually pretty complex, due to having to to look ahead arbitrarily far. I wonder if it wouldn't be better to simplify it and always highlight things after a let the same.

Do we have a quick-reference cheatsheet for F* that we could highlight manually? It would serve as a nice test suite for highlighting code.

[cpitclaudel]

Apparently tuareg mode uses a simple heuristic, in which the name after let is always colored as a function, unless it is immediately followed by an = sign. It breaks with let a \n = 1, but this sounds acceptable.

I'll try implementing that for F* too.

[cpitclaudel]

Also, looking at the highlighting again, I think I was a bit too enthusiastic about highlighting arguments in lets. Maybe I should revisit that too.

[nikswamy]

I think distinguishing function from non-functions is overrated, particularly as only the definition site is (maybe) colored, not the uses also.

Can we color all identifiers uniformly? I wouldn't mind if the definitions were in the orange-ish shade used now and the uses were black.

[cpitclaudel]

Sure, that sounds good!

[cpitclaudel]

Ok, done I think :) The updated package should be on MELPA in a few hours.

I tried to simplify the highlighting and make it more robust. F*'s syntax is not the easiest to parse with regular expressions :)

I'd be interested in experimenting with a way to make highlighting better, through e.g. an external process that actually understands F*'s syntax.