On 6/28/10, R… Kumar [email protected] wrote:
Does Highline or Thor/Facets/ActiveSupport etc have a method for when
you want user to edit multiline text using the $EDITOR value?
Ok, this was a week ago now, but no one else has responded.
Commander has but it does not work with vim.
This code is wrong. EDITOR is supposed to be set to a text-mode
editor, which runs inside a text terminal environment. If the user has
a graphical editor he wants to use, such as gvim, gnotepad, or
textmate, he should set the VISUAL environment variable instead.
ask_editor or equivalent code should look for VISUAL first and then
EDITOR only if VISUAL is not set.
A gui editor needs to be called in a different way than a text-mode
editor is called. A gui editor needs no controlling text-mode
terminal, whereas a text-mode editor requires one. A gui editor should
be called asynchronously whereas a text-mode editor must be called
synchronously. A gui editor doesn’t (really) use stdin/stdout/stderr
whereas a text-mode editor must use them.
The code above is designed to be used with a gui editor, even tho it
consults the EDITOR environment variable. It starts the editor process
asynchronously. It captures the subprocess’s stdin and uses it for a
different purpose, which prevents vim from ever getting any input from
These factors sccount for the problems you observed, I believe.
ENV[‘EDITOR’] in that method should be replaced with ENV[‘VISUAL’].
(And it should be expanded to use EDITOR if that is set as well…)
So i wrote a method, if
anyone has time please give it a look and give me feedback. Is it
correct to pass back a nil if user does not edit, or should I pass a
Thanks. (File attached).
I’d like to know why the developer of commander used this instead of a
“system” command. In what way is this superior ? Why does it fail with
Your code looks pretty good to me. You really ought to check for
VISUAL as well, as I outlined above. If VISUAL is set, do something
like what the ask_editor code you posted above is doing. Except I
don’t think you should assume you can use stdin and stdout to
communicate with a gui editor; that sounds too textmate specific to
me. Working with temp files like you have for the EDITOR case is the
most portable and general plan.
Some other minor nits:
quote all words on the command line, to handle spaces in filenames
better. Better yet, break the command line up into words, or rather
don’t join them together in one line. So, replace
I’d just read the whole file in one big slirp instead of line by
line. (Unless you think you’re user is really going to write a whole
lot of stuff… in which case you need to rewrite anyway.)