[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 [EMAIL PROTECTED]
