> Rules have an input and an output directive, which are often used by
> name in code. I find it slightly annoying that `input` has the look of
> a Python keyword, while output does not.

Thanks for bringing this up.  It's the result of python.el's
`python-font-lock-keywords`, which assigns `font-lock-builtin-face` to
"input" because `input` is a built-in function.  Currently, Snakemake
mode's `snakemake-font-lock-keywords` only overrides this when it
thinks "input" is being used as a field key (i.e., matches "^ +input *:"),
in which case `font-lock-type-face` is used.

So, if I understand correctly, the main place where you're seeing
"input" highlighted differently than "output" is in the `run:` body,
while "input" in the `shell:` commands and in the `input:` field name
is highlighted the same as "output".  Is that right?

> How do you feel about this?  Would you consider changing
> `snakemake-mode` to not consider `input` a keyword for
> syntax-highlighting purposes?

I agree that "input" and "output" should have the same look.  Although
Python's `input` function works fine in Snakefiles when used outside
of rule blocks, I can't think of any good use-cases for it, so it
doesn't make sense for `python-font-lock-keywords` to have priority
here.

I'm OK overriding `python-font-lock-keywords` and removing the
highlighting of "input", but I wonder whether it's better to go the
other way.  Should output (and other built-in Snakemake objects that
can be accessed in the run block, like "wildcards" and "params") be
highlighted rather than removing the highlighting from input?


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kyleam/snakemake-mode/issues/20#issuecomment-261398558