Not consider "input" a python keyword? (#20)

Not consider "input" a python keyword? (#20)

[Endre Bakken Stovner]

[-- Attachment #1: Type: text/plain, Size: 494 bytes --]

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. How do you feel about this? Would you consider changing `snakemake-mode` to not consider `input` a keyword for syntax-highlighting purposes?

-- 
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

[-- Attachment #2: Type: text/html, Size: 2074 bytes --]

Re: Not consider "input" a python keyword? (#20)

[Kyle Meyer]

[-- Attachment #1: Type: text/plain, Size: 1792 bytes --]

> 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

[-- Attachment #2: Type: text/html, Size: 5448 bytes --]

Re: Not consider "input" a python keyword? (#20)

[Kyle Meyer]

[-- Attachment #1: Type: text/plain, Size: 488 bytes --]

> 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.

I've taken the second approach in the `km/rx-builtin` branch, if you
want to test it out and see how you feel about the additional
highlighting.


-- 
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-261402794

[-- Attachment #2: Type: text/html, Size: 2449 bytes --]

Re: Not consider "input" a python keyword? (#20)

[Endre Bakken Stovner]

[-- Attachment #1: Type: text/plain, Size: 949 bytes --]

Thanks! Will do within the next week :)

On Fri, Nov 18, 2016 at 12:27 AM, Kyle Meyer <notifications@github.com>
wrote:

> 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.
>
> I've taken the second approach in the km/rx-builtin branch, if you
> want to test it out and see how you feel about the additional
> highlighting.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/kyleam/snakemake-mode/issues/20#issuecomment-261402794>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AQ9I0rgF7ITdGtWir1O22ylnKaSBl28Iks5q_OLTgaJpZM4K1A3Q>
> .
>


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

[-- Attachment #2: Type: text/html, Size: 3560 bytes --]

Re: Not consider "input" a python keyword? (#20)

[Endre Bakken Stovner]

[-- Attachment #1: Type: text/plain, Size: 351 bytes --]

I guess this is the best way to do it. Since all Snakemake functions now are keywords, I guess perhaps R() should be too. It is an import though, so perhaps a borderline case.

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

[-- Attachment #2: Type: text/html, Size: 2086 bytes --]

Re: Not consider "input" a python keyword? (#20)

[Kyle Meyer]

[-- Attachment #1: Type: text/plain, Size: 389 bytes --]

Thanks for the feedback.

> I guess perhaps R() should be too. It is an import though, so perhaps a borderline case.

Right, because R requires an import, I don't consider it to be a built-in.


-- 
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-262399099

[-- Attachment #2: Type: text/html, Size: 2211 bytes --]

Re: Not consider "input" a python keyword? (#20)

[Kyle Meyer]

[-- Attachment #1: Type: text/plain, Size: 245 bytes --]

Closed #20 via 26bfdfaa76728a906c06b3577c3de08dc79cd4b5.

-- 
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#event-869049717

[-- Attachment #2: Type: text/html, Size: 2204 bytes --]