| Age | Commit message (Collapse) | Author |
|---|
|
In Emacs 27, specifically 36b64e087e (Add
'font-lock-maximum-decoration' levels for Python, 2018-07-19),
python-font-lock-keywords was changed to a list of symbols that define
different fontification levels, so we can no longer simply tack
snakemake-font-lock-keywords onto it.
Instead define a set of levels that mirrors Python mode's. For
Snakemake mode, the same decoration is used for all levels, but at
least we will honor the level of decoration that the user has set for
Python.
Reported-by: Nicholas Knoblauch <nwknoblauch@gmail.com>
Closes #29.
|
|
This will make it easier to work around a change to
python-font-lock-keywords in Emacs 27.
|
|
snakemake-font-lock-keywords is extended with
python-font-lock-keywords, but the non-keyword bits that python.el
defines for font-lock-defaults are discarded. Keep those too because
python.el sets a value for font-lock-syntactic-face-function.
|
|
|
|
There are few enough entries in each release that this extra structure
isn't really helpful. Plus, some things that are labeled as "new
features", like recognizing keywords for fontification, seem a bit
silly to call a feature, but I can't think of a better heading for
them.
|
|
|
|
|
|
This should have been adjusted in a5f868f (Change 'guix environment'
snippet to use --manifest, 2018-09-01).
|
|
|
|
|
|
With the addition of 'report', the built-in names and command names
are no longer disjoint sets. All occurrences of 'report' are
fontified as a built-in because the built-in regexp is a substring of
the command regexp. Move the command regexp before the built-in
regexp so that the 'report:' command is highlighted as a command.
|
|
|
|
This has been around forever.
|
|
|
|
|
|
|
|
'guix environment' accepts a manifest as of 267379f85 (environment:
Add --manifest option., 2018-02-15). Declaring a set of dependencies
via --manifest is more straightforward than doing so with --load, so
suggest --manifest instead.
|
|
Match the order given in guix-snakemake-environment.
|
|
Using "/usr/bin/env" there is silly. We can rely on "/bin/sh" being
present more than "/usr/bin/env".
|
|
|
|
|
|
|
|
python.el changed its indentation engine in Emacs 24.5. We rely on a
python-indent-calculate-indentation that is specific for the newer
version.
Re: #28
|
|
|
|
|
|
In addition the per-rule singularity field, Snakemake supports a
top-level global directive (since v4.8.0, I think).
|
|
This has been around since Snakemake 3.9.0.
|
|
|
|
|
|
Closes #24.
|
|
|
|
|
|
magit-popup.el is in its own repository as of Magit's 4d5d9bfa
|
|
Subworkflow blocks support a "configfile" field as of Snakemake's
1f02ae9 (Allow to specify configfile for subworkflows., 2016-08-24).
Add "configfile" as a field-key so that the subworkflow variant is
fontified as a key rather than a command. As with "workdir", the
tradeoff is that an indented, non-subworkflow "configfile" is
fontified as a key rather than a command.
Fixes #23.
|
|
|
|
Closes #22.
|
|
Snakemake 4.0.0 requires Python 3.6.
|
|
This function was added in Snakemake v3.10.0.
|
|
|
|
|
|
|
|
To display the graph, snakemake-graph and snakemake-graph-this-file
call image-mode in a buffer with the snakemake graph output. This is
convenient because it works without using an output file, but
displaying the graph fails if Emacs was compiled without ImageMagick
support.
When Emacs doesn't have ImageMagick support, fall back to saving the
file and then displaying it.
|
|
This will allow the graphing commands to save and display the graph
when the user is running an Emacs that was not built with ImageMagick
support.
When the user provides all-blank input or does not confirm an
overwrite, raise a user error so that the caller doesn't have to check
for a nil return value.
|
|
|
|
The primary motivation behind having a terminal interface is that it
works better with tools like Guix because the environment persists
across calls. And the primary reason one would want to use Guix with
Snakemake is so that the dependencies to a workflow/analysis can be
specified and tightly controlled.
However, the user can accidentally step outside of this controlled
environment by running a build command before running
snakemake-term-start. The changes from this mistake can be hard to
confidently reverse and may require a wide removal of output files.
If a user wanted to make sure to only use the Guix-controlled
environment, one approach would be to remove the Snakemake executable
from the environment in which Emacs is started (most likely the
default environment), exposing it only in the workflow environments.
The problem with this is that snakemake.el requires the Snakemake
executable for things like generating lists of targets. Also, it
would be a global change, but a user could reasonably want to control
dependencies with Guix for one project but go through the compile
interface for another.
Add a user option that allows the user to avoid the compile interface
at a global or per-project level.
|
|
|
|
The "-l" flag of "guix environment" doesn't take a manifest; it takes
a file that evaluates to a package or a list of packages.
|
|
|
|
snakemake-build-targets needs to set default-directory to the
Snakefile directory so that snakemake-term-process correctly reports
whether there is an active terminal when the user initiates the call
from a subdirectory.
Conceptually, it also makes sense to handle the directory change in
snakemake-build-targets. The docstrings for the lower-level
snakemake-compile-targets and snakemake-term-build-targets specify
that they correspond to a "snakemake ..." call, which implies that
their caller is responsible for making sure they are called from the
Snakefile directory.
|
|
|