discussion and development of Emacs Snakemake mode
 help / color / mirror / code / Atom feed
From: Kyle Meyer <notifications@github.com>
To: kyleam/snakemake-mode <snakemake-mode@noreply.github.com>
Cc: Kyle Meyer <kyle@kyleam.com>,
	Your activity <your_activity@noreply.github.com>
Subject: Re: Not consider "input" a python keyword? (#20)
Date: Thu, 17 Nov 2016 15:05:58 -0800	[thread overview]
Message-ID: <kyleam/snakemake-mode/issues/20/261398558@github.com> (raw)
In-Reply-To: <kyleam/snakemake-mode/issues/20@github.com>

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

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:

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

  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:

  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 \
    --in-reply-to=kyleam/snakemake-mode/issues/20/261398558@github.com \
    --to=notifications@github.com \
    --cc=kyle@kyleam.com \
    --cc=reply+0013cd7cca8a96511d73bf9221e449c5bea246edf03d867b92cf000000011445f9d692a169ce0b52d6d3@reply.github.com \
    --cc=snakemake-mode@noreply.github.com \
    --cc=your_activity@noreply.github.com \
    --subject='Re: Not consider "input" a python keyword? (#20)' \


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


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