From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Thu, 17 Nov 2016 15:05:58 -0800
From: Kyle Meyer <notifications@github.com>
Reply-To: kyleam/snakemake-mode <reply+0013cd7cca8a96511d73bf9221e449c5bea246edf03d867b92cf000000011445f9d692a169ce0b52d6d3@reply.github.com>
Message-ID: <kyleam/snakemake-mode/issues/20/261398558@github.com>
In-Reply-To: <kyleam/snakemake-mode/issues/20@github.com>
References: <kyleam/snakemake-mode/issues/20@github.com>
Subject: Re: Not consider "input" a python keyword? (#20)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_582e37d6a3da5_70413fd9c8e7d13c68847";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
List-ID: kyleam/snakemake-mode <snakemake-mode.kyleam.github.com>
List-Archive: https://github.com/kyleam/snakemake-mode
List-Post: <mailto:reply+0013cd7cca8a96511d73bf9221e449c5bea246edf03d867b92cf000000011445f9d692a169ce0b52d6d3@reply.github.com>
List-Unsubscribe: <mailto:unsub+0013cd7cca8a96511d73bf9221e449c5bea246edf03d867b92cf000000011445f9d692a169ce0b52d6d3@reply.github.com>,
 <https://github.com/notifications/unsubscribe/ABPNfD367UkAfSYj1tM6GKnZwVkGd2xZks5q_N3WgaJpZM4K1A3Q>
To: kyleam/snakemake-mode <snakemake-mode@noreply.github.com>
Cc: Kyle Meyer <kyle@kyleam.com>, Your activity <your_activity@noreply.github.com>


----==_mimepart_582e37d6a3da5_70413fd9c8e7d13c68847
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

> 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
----==_mimepart_582e37d6a3da5_70413fd9c8e7d13c68847
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<blockquote>
<p>Rules have an input and an output directive, which are often used by<b=
r>
name in code. I find it slightly annoying that <code>input</code> has the=
 look of<br>
a Python keyword, while output does not.</p>
</blockquote>

<p>Thanks for bringing this up.  It's the result of python.el's<br>
<code>python-font-lock-keywords</code>, which assigns <code>font-lock-bui=
ltin-face</code> to<br>
"input" because <code>input</code> is a built-in function.  Currently, Sn=
akemake<br>
mode's <code>snakemake-font-lock-keywords</code> only overrides this when=
 it<br>
thinks "input" is being used as a field key (i.e., matches "^ +input *:")=
,<br>
in which case <code>font-lock-type-face</code> is used.</p>

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

<blockquote>
<p>How do you feel about this?  Would you consider changing<br>
<code>snakemake-mode</code> to not consider <code>input</code> a keyword =
for<br>
syntax-highlighting purposes?</p>
</blockquote>

<p>I agree that "input" and "output" should have the same look.  Although=
<br>
Python's <code>input</code> function works fine in Snakefiles when used o=
utside<br>
of rule blocks, I can't think of any good use-cases for it, so it<br>
doesn't make sense for <code>python-font-lock-keywords</code> to have pri=
ority<br>
here.</p>

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

<p style=3D"font-size:small;-webkit-text-size-adjust:none;color:#666;">&m=
dash;<br />You are receiving this because you are subscribed to this thre=
ad.<br />Reply to this email directly, <a href=3D"https://github.com/kyle=
am/snakemake-mode/issues/20#issuecomment-261398558">view it on GitHub</a>=
, or <a href=3D"https://github.com/notifications/unsubscribe-auth/ABPNfAG=
OEVVP2lKqHGMgvOtmfCqj8hz2ks5q_N3WgaJpZM4K1A3Q">mute the thread</a>.<img a=
lt=3D"" height=3D"1" src=3D"https://github.com/notifications/beacon/ABPNf=
B6d114JX8uwL6oW6Nw06BI2fQseks5q_N3WgaJpZM4K1A3Q.gif" width=3D"1" /></p>
<div itemscope itemtype=3D"http://schema.org/EmailMessage">
<div itemprop=3D"action" itemscope itemtype=3D"http://schema.org/ViewActi=
on">
  <link itemprop=3D"url" href=3D"https://github.com/kyleam/snakemake-mode=
/issues/20#issuecomment-261398558"></link>
  <meta itemprop=3D"name" content=3D"View Issue"></meta>
</div>
<meta itemprop=3D"description" content=3D"View this Issue on GitHub"></me=
ta>
</div>

<script type=3D"application/json" data-scope=3D"inboxmarkup">{"api_versio=
n":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name"=
:"GitHub"},"entity":{"external_key":"github/kyleam/snakemake-mode","title=
":"kyleam/snakemake-mode","subtitle":"GitHub repository","main_image_url"=
:"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d8=
8-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubuse=
rcontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.=
png","action":{"name":"Open in GitHub","url":"https://github.com/kyleam/s=
nakemake-mode"}},"updates":{"snippets":[{"icon":"PERSON","message":"@kyle=
am in #20: \u003e Rules have an input and an output directive, which are =
often used by\r\n\u003e name in code. I find it slightly annoying that `i=
nput` has the look of\r\n\u003e a Python keyword, while output does not.\=
r\n\r\nThanks for bringing this up.  It's the result of python.el's\r\n`p=
ython-font-lock-keywords`, which assigns `font-lock-builtin-face` to\r\n\=
"input\" because `input` is a built-in function.  Currently, Snakemake\r\=
nmode's `snakemake-font-lock-keywords` only overrides this when it\r\nthi=
nks \"input\" is being used as a field key (i.e., matches \"^ +input *:\"=
),\r\nin which case `font-lock-type-face` is used.\r\n\r\nSo, if I unders=
tand correctly, the main place where you're seeing\r\n\"input\" highlight=
ed differently than \"output\" is in the `run:` body,\r\nwhile \"input\" =
in the `shell:` commands and in the `input:` field name\r\nis highlighted=
 the same as \"output\".  Is that right?\r\n\r\n\u003e How do you feel ab=
out this?  Would you consider changing\r\n\u003e `snakemake-mode` to not =
consider `input` a keyword for\r\n\u003e syntax-highlighting purposes?\r\=
n\r\nI agree that \"input\" and \"output\" should have the same look.  Al=
though\r\nPython's `input` function works fine in Snakefiles when used ou=
tside\r\nof rule blocks, I can't think of any good use-cases for it, so i=
t\r\ndoesn't make sense for `python-font-lock-keywords` to have priority\=
r\nhere.\r\n\r\nI'm OK overriding `python-font-lock-keywords` and removin=
g the\r\nhighlighting of \"input\", but I wonder whether it's better to g=
o the\r\nother way.  Should output (and other built-in Snakemake objects =
that\r\ncan be accessed in the run block, like \"wildcards\" and \"params=
\") be\r\nhighlighted rather than removing the highlighting from input?\r=
\n"}],"action":{"name":"View Issue","url":"https://github.com/kyleam/snak=
emake-mode/issues/20#issuecomment-261398558"}}}</script>=

----==_mimepart_582e37d6a3da5_70413fd9c8e7d13c68847--