From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 17 Nov 2016 00:47:20 -0800 From: Endre Bakken Stovner Reply-To: kyleam/snakemake-mode Message-ID: Subject: Not consider "input" a python keyword? (#20) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_582d6e988410b_d3a3fa4c56fb1301175c"; charset=UTF-8 Content-Transfer-Encoding: 7bit List-ID: kyleam/snakemake-mode List-Archive: https://github.com/kyleam/snakemake-mode List-Post: List-Unsubscribe: , To: kyleam/snakemake-mode ----==_mimepart_582d6e988410b_d3a3fa4c56fb1301175c 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. 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 ----==_mimepart_582d6e988410b_d3a3fa4c56fb1301175c Content-Type: text/html; 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. 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, view it on GitHub, or mute the thread.

----==_mimepart_582d6e988410b_d3a3fa4c56fb1301175c-- From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 17 Nov 2016 15:05:58 -0800 From: Kyle Meyer Reply-To: kyleam/snakemake-mode Message-ID: In-Reply-To: References: 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 List-Archive: https://github.com/kyleam/snakemake-mode List-Post: List-Unsubscribe: , To: kyleam/snakemake-mode Cc: Kyle Meyer , Your activity ----==_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

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-bui= ltin-face to
"input" because input is a built-in function. Currently, Sn= akemake
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 o= utside
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 pri= ority
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?

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on GitHub= , or mute the thread.

= ----==_mimepart_582e37d6a3da5_70413fd9c8e7d13c68847-- From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 17 Nov 2016 15:27:15 -0800 From: Kyle Meyer Reply-To: kyleam/snakemake-mode Message-ID: In-Reply-To: References: Subject: Re: Not consider "input" a python keyword? (#20) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_582e3cd394479_415e3faf2a9dd140181820"; charset=UTF-8 Content-Transfer-Encoding: 7bit List-ID: kyleam/snakemake-mode List-Archive: https://github.com/kyleam/snakemake-mode List-Post: List-Unsubscribe: , To: kyleam/snakemake-mode Cc: Kyle Meyer , Your activity ----==_mimepart_582e3cd394479_415e3faf2a9dd140181820 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > 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 ----==_mimepart_582e3cd394479_415e3faf2a9dd140181820 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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.

&mda= sh;
You are receiving this because you are subscribed to this thread.<= br />Reply to this email directly, view it on GitHub, or mute the thread.3D""

= ----==_mimepart_582e3cd394479_415e3faf2a9dd140181820-- From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 17 Nov 2016 23:07:09 -0800 From: Endre Bakken Stovner Reply-To: kyleam/snakemake-mode Message-ID: In-Reply-To: References: Subject: Re: Not consider "input" a python keyword? (#20) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_582ea89d21a63_2c6f3f92c5f11138308870"; charset=UTF-8 Content-Transfer-Encoding: 7bit List-ID: kyleam/snakemake-mode List-Archive: https://github.com/kyleam/snakemake-mode List-Post: List-Unsubscribe: , To: kyleam/snakemake-mode Cc: Kyle Meyer , Comment ----==_mimepart_582ea89d21a63_2c6f3f92c5f11138308870 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks! Will do within the next week :) On Fri, Nov 18, 2016 at 12:27 AM, Kyle Meyer 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. > > =E2=80=94 > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > , > or mute the thread > > . > --=20 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= ----==_mimepart_582ea89d21a63_2c6f3f92c5f11138308870 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks! Will do within the next week :)

On Fri, Nov 18, 2016 at 12:27 AM, Kyle Meyer <notifications@github.com&g= t;
wrote:

> I'm OK overriding python-font-lock-keywords and removing the
> highlighting of "input", but I wonder whether it's bette= r 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.
>
> =E2=80=94
> 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-26= 1402794>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AQ9I0rgF7ITdGtWi= r1O22ylnKaSBl28Iks5q_OLTgaJpZM4K1A3Q>
> .
>

&mda= sh;
You are receiving this because you commented.
Reply to this e= mail directly, view it on GitHub, or mute the thread.3D""

= ----==_mimepart_582ea89d21a63_2c6f3f92c5f11138308870-- From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 22 Nov 2016 00:10:17 -0800 From: Endre Bakken Stovner Reply-To: kyleam/snakemake-mode Message-ID: In-Reply-To: References: Subject: Re: Not consider "input" a python keyword? (#20) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5833fd6932d88_41383fe6ccfed13c6403d7"; charset=UTF-8 Content-Transfer-Encoding: 7bit List-ID: kyleam/snakemake-mode List-Archive: https://github.com/kyleam/snakemake-mode List-Post: List-Unsubscribe: , To: kyleam/snakemake-mode Cc: Kyle Meyer , Comment ----==_mimepart_5833fd6932d88_41383fe6ccfed13c6403d7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 ----==_mimepart_5833fd6932d88_41383fe6ccfed13c6403d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

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, view it on GitHub, or mute the thread.

----==_mimepart_5833fd6932d88_41383fe6ccfed13c6403d7-- From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 22 Nov 2016 15:39:49 -0800 From: Kyle Meyer Reply-To: kyleam/snakemake-mode Message-ID: In-Reply-To: References: Subject: Re: Not consider "input" a python keyword? (#20) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5834d74586334_521b3fd03dda7134117344"; charset=UTF-8 Content-Transfer-Encoding: 7bit List-ID: kyleam/snakemake-mode List-Archive: https://github.com/kyleam/snakemake-mode List-Post: List-Unsubscribe: , To: kyleam/snakemake-mode Cc: Kyle Meyer , Your activity ----==_mimepart_5834d74586334_521b3fd03dda7134117344 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 ----==_mimepart_5834d74586334_521b3fd03dda7134117344 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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.

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on GitHub= , or mute the thread.

= ----==_mimepart_5834d74586334_521b3fd03dda7134117344-- From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 22 Nov 2016 15:40:51 -0800 From: Kyle Meyer Reply-To: kyleam/snakemake-mode Message-ID: In-Reply-To: References: Subject: Re: Not consider "input" a python keyword? (#20) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5834d783b8397_41703fe2f182d1381199a0"; charset=UTF-8 Content-Transfer-Encoding: 7bit List-ID: kyleam/snakemake-mode List-Archive: https://github.com/kyleam/snakemake-mode List-Post: List-Unsubscribe: , To: kyleam/snakemake-mode Cc: Kyle Meyer , Your activity ----==_mimepart_5834d783b8397_41703fe2f182d1381199a0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 ----==_mimepart_5834d783b8397_41703fe2f182d1381199a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Closed #20 via 26bfdfa.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_5834d783b8397_41703fe2f182d1381199a0--