From: Kyle Meyer <email@example.com> To: kyleam/snakemake-mode <firstname.lastname@example.org> Cc: Kyle Meyer <email@example.com>, Your activity <firstname.lastname@example.org> Subject: Re: Not consider "input" a python keyword? (#20) Date: Thu, 17 Nov 2016 15:05:58 -0800 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> [-- 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 --]
next prev parent reply other threads:[~2016-11-17 23:05 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-11-17 8:47 Endre Bakken Stovner 2016-11-17 23:05 ` Kyle Meyer [this message] 2016-11-17 23:27 ` Kyle Meyer 2016-11-18 7:07 ` Endre Bakken Stovner 2016-11-22 8:10 ` Endre Bakken Stovner 2016-11-22 23:39 ` Kyle Meyer 2016-11-22 23:40 ` Kyle Meyer
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://git.kyleam.com/snakemake-mode * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: Not consider "input" a python keyword? (#20)' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://git.kyleam.com/snakemake-mode/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).