zyedidia / micro

A modern and intuitive terminal-based text editor
https://micro-editor.github.io
MIT License
25.06k stars 1.17k forks source link

Syntax highlighting rules containing `^` conflict with section rules #1872

Open LyricLy opened 4 years ago

LyricLy commented 4 years ago

Description of the problem or steps to reproduce

When a syntax highlighting rule contains the character ^, even escaped, that rule will fail to work if written after a section rule on the same line. An example highlighting syntax that causes this behaviour is as follows:

filetype: test

detect:
    filename: "\\.test$"

rules:
    - symbol.operator: "[+\\-*/^]"
    - constant.string:
        start: "\""
        end: "\""
        skip: "\\\\."
        rules: []

This causes situations like this: Image of issue

I believe that this is caused by the following logic in /pkg/highlight/highlighter.go:

    if strings.Contains(regexStr, "^") {
        if !canMatchStart {
            return nil
        }
    }
    if strings.Contains(regexStr, "$") {
        if !canMatchEnd {
            return nil
        }
    }

The code assumes that ^ and $ are referring to the special regex characters, without any regard for whether they are being escaped. I am unfamiliar with Go, and am unsure what the best way to fix this would be.

(Because of this, I thought that this would also happen with $ and things written before a section rule, but while trying to create an example showing this, I noticed that I didn't seem to be able to get rules containing $ to match anything at all, not just when paired with a section rule. I am unsure if this is related to the problem with ^.)

Specifications

Commit hash: 49786cf8 OS: Arch Linux Terminal: alacritty 0.5.0

ghost commented 4 years ago

Related to #1457?

MasFlam commented 4 years ago

I encountered this too recently, but with $, when I was writing the syntax highlighting file for Groovy. My workaround was to use \\x23, which escapes the \ in yaml and is understood by the regex parser as a hexadecimal character escape for for the $ sign, although the regex string that micro would see would not have a $ inside. Nevertheless, you might have found the cause of this, which is great

sparques commented 3 years ago

You can use single quotes with yaml declarations--results in a lot less escaping.