Arc Forumnew | comments | leaders | submitlogin
3 points by fallintothis 4005 days ago | link | parent

Not to clutter my own thread, but these are some issues that I wasn't smart enough to solve before publication. I felt only one of them qualified as a bug, so I posted it to a bitbucket issue tracker: http://bitbucket.org/fallintothis/arc-vim/issues/

Known Issues:

1. The way numbers are highlighted is mostly a hack. Arc, built atop mzscheme, currently inherits the Scheme reader. As such, numbers comply with R5RS syntax, plus some mz extensions. Highlighting is somewhat complicated: reals, rationals, complex numbers, binary, octal, hexadecimal, exponentiation, etc. The way I do it is to programmatically piece together giant, naively-built regular expressions from the R5RS EBNF grammar (modified slightly for mz). Then, each RE is noisier because I wrap them in delimiter REs so that numbers won't highlight when they're in names (like foldl1, 1up, or p2p).

This might make rendering slower versus simpler, naive alternatives (see Scheme & CL highlighting); I've not noticed anything terrible, myself. Having complex numbers & such highlight correctly is awesome, so I'm inclined to stick with the grammar route, if there aren't any major issues. There could be bugs in the way I generate the RE, which would be noticeable if valid numbers didn't highlight. Again, I've not noticed any (save for the ssyntax issue discussed later), but please tell me if you do.

2. I make overzealous use of display in the Vimscript, guessing at when it should be okay to use (the documentation isn't that clear). Not sure if there are bugs here, though they might also be mitigated with different synchronization methods. You'd notice this issue if, while scrolling through a file, Vim suddenly "runs out of colors" -- highlighting everything like a string or a comment, even though the region ended somewhere above your cursor. It's an easily overlooked problem (once you jar Vim into highlighting correctly), but one I don't like much: it's hard to replicate or know what's wrong. I've not noticed any problems like this for awhile, though.

3. There are some difficult edge-cases for highlighting ssyntax vs valid numbers. See http://bitbucket.org/fallintothis/arc-vim/issue/1/highlighti... for the full explanation.

4. The g:arc_bodops option requires that Vim is compiled with Python support because I couldn't figure out a way that wasn't convoluted to iterate through regular expression matches in a buffer. Seems gross to rely on Python, but I don't know how you can beat

  for line in vim.current.buffer:
      m = re.match(regex, line)
with Vimscript. Suggestions are welcome.

After this, it's worth noting that number (and ssyntax) highlighting is still pretty accurate. It correctly highlights the following, even though you might not be able to tell at first glance what the right behavior is supposed to be:

  #e#x+e#s+e@-e#l-e                                                         ; a
  16140901064495857664-50176i.#e#x+e#s+e@-e#l-e                             ; b
  #b#e101010101111101010101201010101010000010101                            ; c
  127.0.0.1                                                                 ; d
  +inf.0@3+4i                                                               ; e
  +inf.0                                                                    ; f
  1.+i                                                                      ; g
  _.1.3                                                                     ; h
  16140901064495857664-50176.0i!#e#x+e#s+e@-e#l-e:+inf.0@1/1###.##0e4/2i+hi ; i

Whereas with the Scheme highlighter: (a) incorrectly rejects, (b) incorrectly accepts, (c) rejects for the wrong reason (more than one # mark), (d) incorrectly accepts, (e) rejects for the wrong reason (doesn't recognize mz inf constants), (f) rejects (doesn't recognize mz inf constants), (g) correctly accepts, (h & i) doesn't have ssyntax, unfair comparison.

These are just some of the tests I've run (many ripped off of mzscheme tests).