Closed epruesse closed 4 years ago
Since it's already supported for embedded R, any chance to do this for embedded bash?
Thanks for the suggestion. The thought hadn't occurred to me. (Well, the embedded R fontification didn't occur to me either. @endrebak added that feature.)
The R highlighting depends on finding triple quote markers like
R("""
. I'm not sure if doing that for a shell: ".*
with mmm-mode
would be more complicated to handle or more expensive to process.
Worth looking into.
Alternatively, highlighting the {wildcard} parts of the strings would be neat.
Yeah, I think that'd be nice to add.
This sounds like a good idea, but I do not use the R syntax highlighting anymore since using scripts or wrappers is recommended.
There were some hiccups mixing modes with mmm for me. R indentation in Snakemake buffers became weird for example. If you’ve had no problems using it you should attempt to implement this :)
“It may make sense for not just the shell: field, but for all strings as they are likely to be passed through the shell at some point.”
This I do not understand? Shell highlighting for all strings?
This I do not understand? Shell highlighting for all strings?
Yep :)
I tried implementing this with polymode
a while back -- it sort of worked but was slow enough to be annoying, although that's perhaps my lack of skill with lisp. I eventually got stuck when I realized that the "bash parts" are actually "bash + python format mini language": the curly braces kept messing things up. Deriving a python-string-shell-mode from shell-mode was beyond me.
Perhaps the low hanging fruit - just applying font locks to the python format mini language parts - would suffice. Although that one should probably just be implemented in python-mode? Curious that python-mode doesn't do that already...
This I do not understand? Shell highlighting for all strings?
Yep :)
I tried implementing this with
polymode
a while back -- it sort of worked but was slow enough to be annoying, although that's perhaps my lack of skill with lisp. I eventually got stuck when I realized that the "bash parts" are actually "bash + python format mini language": the curly braces kept messing things up. Deriving a python-string-shell-mode from shell-mode was beyond me.
I share @endrebak's confusion on the "all strings" bit. It doesn't seem like it'd be useful to highlight fields like input/output/threads as bash.
Perhaps the low hanging fruit - just applying font locks to the python format mini language parts - would suffice.
I see them as mostly orthogonal, at least in implementation. The mini-language parts would be highlighted via snakemake-font-lock-keywords; the shell string would need mmm-mode (or or another similar mode). The mini-language parts would be highlighted by default; for the shell string, users would have to install/activate mmm-mode, like they now have to do for R bits, and I believe it'd override any other fontification.
Anyway, I'll plan to add highlighting for at least some mini-language parts. For the shell mmm-mode stuff, I may find time to play around with it (I don't use mmm-mode/wouldn't use this feature personally), but I'd certainly welcome a PR adding it if you get something working nicely.
Although that one should probably just be implemented in python-mode? Curious that python-mode doesn't do that already...
Dunno. I suppose I can't think of any programming modes that have special fontification of formatting specs (e.g., emacs-lisp-mode: (format "all string %s" "font")), but there are of course lots out there, so there may be good examples.
OK, so I've played around with adding the different fontification for the minilanguage parts, and ... I really don't like it! :) I think the thing is, my brain is so used to a break in the string fontfication signaling the end of a string, so all my strings just look broken. Dunno, perhaps it's something I'd get used to.
To try this out yourself, you could do something like (changing font-lock-variable-name-face
to whatever face you'd like):
(add-to-list 'snakemake-font-lock-keywords
'("{[^}]+}" 0 font-lock-variable-name-face t))
What do others think?
Since it's already supported for embedded R, any chance to do this for embedded bash?
It may make sense for not just the
shell:
field, but for all strings as they are likely to be passed through the shell at some point. Although that might be too slow, considering the number of small pieces.Alternatively, highlighting the
{wildcard}
parts of the strings would be neat.