unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Chris Marusich <cmmarusich@gmail.com>
To: Oleg Pykhalov <go.wigust@gmail.com>
Cc: guix-devel@gnu.org
Subject: Re: Emacs minor-mode highlight code stages (gexp & sexp)
Date: Fri, 10 Nov 2017 18:34:55 -0800	[thread overview]
Message-ID: <878tfdo84w.fsf@gmail.com> (raw)
In-Reply-To: <87zi7vlrtt.fsf@gmail.com> (Oleg Pykhalov's message of "Thu, 09 Nov 2017 12:33:18 +0300")

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

Oleg Pykhalov <go.wigust@gmail.com> writes:

> Hello Guix,
>
> I found Emacs minor-mode for highlighting stages of code and send a
> request for release a tarball¹, so I could package it properly.
>
>
> Also I made a fork to add a support for G-Expressions and I will wait
> until close a request¹ before sending a patch.  You could try it now:
>
> $ git clone https://github.com/wigust/highlight-stages.git -b gexp
> $ cd CLONED_REPOSITORY_DIRECTORY
> $ guix package --install-from-file=guix.scm
>
>
> ¹ https://github.com/zk-phi/highlight-stages/issues/10
>
> Oleg.

Aw man, that's cool!  I didn't know this was a thing.  I love it
already.

I've only used it for about 5 minutes now, but I have one question: is
it possible to highlight gexps using a different color than other
"staged" code?  For example, it's a little strange that in
gnu/system/vm.scm, in procedure expression->derivation-in-linux-vm, the
quoted module list passed to source-module-closure is highlighted the
same color as the following gexp.  As I understand it,
source-module-closure will take the closure of modules from the host
environment and make it available in the store on the build side, so it
seems to me like this list of modules should not be highlighted as
build-side code.  I like that it highlights quoted expressions in
addition to gexps, but it would be even better if there were two color
"families" here: one for gexps (red, pink, salmon, etc. for different
levels of gexps), and one for regular quotes (blue, light blue, lilac,
etc).  That way, it would be easy to tell different stage levels apart,
and it would also be easy to tell different types of code staging apart.
What do you think?  Too much?

I've also noticed that the highlighting breaks down when using
ungexp-splicing inside of quasiquote inside of gexp.  For example, look
at gnu/tests/install.scm.  In run-install, after the first #~(begin, you
will find the following line:

               `(,(which #$(qemu-command system))

This line introduces a new level (shade) of highlighting.  I do see that
#$(qemu-command system) is correctly highlighted as host-side code (gray
for me, like most of the lines outside the gexp).  However, farther
down, on these lines, the highlighting seems to be incorrect:

                 #$@(cond
                     ((string=? "ext4" installation-disk-image-file-system-type)

Here, I believe that the expression following #$@ (the short form of
ungexp-splicing) should also be highlighted gray, since it is host-side
code.  However, it is highlighted the same color as the rest of the
build-side code in the gexp.  I believe this is happening because it
occurred within the quasiquote form, and the highlighting logic doesn't
realize that #$@ took us back out two levels instead of just one.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  parent reply	other threads:[~2017-11-11  2:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-09  9:33 Emacs minor-mode highlight code stages (gexp & sexp) Oleg Pykhalov
2017-11-10 22:51 ` Ludovic Courtès
2017-11-13 21:33   ` Oleg Pykhalov
2017-11-11  2:34 ` Chris Marusich [this message]
2017-11-11 13:54   ` Ludovic Courtès
2017-11-11 16:58     ` Chris Marusich
2017-11-22  6:21       ` Oleg Pykhalov
2017-11-24 13:23         ` Ludovic Courtès
2017-11-24 21:59           ` Oleg Pykhalov
2017-11-22  6:46       ` Oleg Pykhalov

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://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878tfdo84w.fsf@gmail.com \
    --to=cmmarusich@gmail.com \
    --cc=go.wigust@gmail.com \
    --cc=guix-devel@gnu.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

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