Bug#197835: [PROPOSAL]: integrated environments are allowed
[Moved discussion to the bug again rather than the -policy list. Set
Mail-Followup-To: in an attempt to ensure that it stays there.]
On Wed, Jun 18, 2003 at 11:11:48PM +0300, Richard Braakman wrote:
> On Wed, Jun 18, 2003 at 02:34:59PM -0400, Colin Walters wrote:
> > I always have EDITOR set, but that doesn't mean I want to use that
> > editor inside GNOME. I mostly have it set for all those terminal apps.
>
> Hmm. Maybe what we really need is a separate XEDITOR variable for
> starting an editor in a graphical environment. I think it's pretty
> common to want different editors in text and graphic modes.
I was going to say much the same when I next got around to looking at
this thread and apologizing for my earlier vehemence. :-) XEDITOR is a
similar idea to the old EDITOR/VISUAL distinction, except that to a
first approximation nobody cares about line-mode editors any more.
However, the terminal/X distinction has become correspondingly more
important.
Having this as an environment variable rather than a piece of gconf
configuration or what-have-you would make it possible for users to state
their preference once in a way that can be applied consistently across
not only GNOME and KDE but also other X applications that don't form
part of an "integrated environment".
I haven't thought very much about Colin Walters' [1] points about
editors as embeddable components yet, but if we had a distinct XEDITOR
then we could probably support that quite sensibly by just using them
when XEDITOR isn't set, since people whose only X applications are
GNOMEish with an integrated editor component (for example) will have
little reason to set it, even if they set EDITOR for terminal programs.
I do take the point that nano in an xterm isn't the prettiest of
defaults, but conversely I want a way to be able to tell all X
applications that I want, say, gvim - or even 'pterm -e vi' - as my
graphical editor without having to jump through hoops to do this for
each desktop environment and each miscellaneous X application
separately.
We would also need a /usr/bin/x-editor alternative, with some scheme for
agreeing priorities, and a sensible-x-editor program in debianutils. The
other approach to the latter would be to modify sensible-editor to look
at $DISPLAY à la sensible-browser, but I think that would be unwise; you
want the condition to be whether an X application is calling the editor,
not whether you happen to be in X, since it's frequent for a user to
want terminal-based programs to spawn terminal-based editors even if
they happen to be running in X (say, mutt in an xterm).
sensible-x-editor keys the decision on the nature of the caller, which
is more appropriate.
Thus, the policy for spawning an X editor could be: (1) check XEDITOR,
(2) use integrated editor if available, (3) run sensible-x-editor (which
might have 'xterm -e $EDITOR' as one of its fallback choices). Would
this keep everyone happy?
It's also worth noting that XEDITOR is not an entirely new idea, so we
wouldn't be trailblazing out of the void here. Google for "XEDITOR
environment variable" for some existing cases: for example, xdvi and ddd
already support it. Or, for previous Debian discussion,
http://lists.debian.org/debian-devel-0111/msg01595.html, where for what
it's worth I disagree with Branden's followup suggestion that a wrapper
that tests DISPLAY is sufficient, for the reasons stated above.
I assume that the policy editors wouldn't be too happy to start
recommending XEDITOR just yet, but if we agreed it informally now we
could start getting it implemented in enough places to standardize it
later. Where would be good places to start? Editor packages,
debianutils, and some vanilla X mail and news programs like knews
perhaps?
[1] Damn, this is confusing. Maybe the two of us should avoid getting
involved in the same discussions in the future. :-)
--
Colin Watson [cjwatson@flatline.org.uk]
Reply to: