On Tue, 2003-06-17 at 20:28, Colin Watson wrote: > I think this is very bad. At the moment policy says that my EDITOR and > PAGER variables have priority over what random programs think is a good > idea, which I think is excellent.
Yes...but the idea is if programs have a preferred version for a reason. Integrated environments like GNOME and KDE have very good reasons to prefer a particular editor, namely the one they ship with. You should think of it as part of the program itself. We're not making Emacs invoke vi just because $EDITOR=vi, right? Likewise, when I browse to a file with Nautilus, I don't want to see the file open up in Emacs (which have as $EDITOR). Maybe some people want this behavior, but the problem with this (as opposed to $BROWSER) is that a *lot* of people are going to have $EDITOR set. For other standalone programs though, obviously it makes a lot of sense for them to use $EDITOR and $PAGER. Again, this is simply codifying the status quo. Nothing in Debian should change. > If programs get to pick a default that > overrides my EDITOR and PAGER then it all degenerates into chaos. I think we use common sense here. > If what you really meant was that the order is as follows: > > * EDITOR/PAGER > * program's preferred editor or pager > * /usr/bin/editor or /usr/bin/pager > > ... then that would be slightly better; it dilutes the effectiveness of > the editor and pager alternatives, but that might not be *too* bad. It's > late here so I haven't fully thought it through. The problem again is that unlike BROWSER, a ton of people are going to have EDITOR/PAGER set. Of course I should say I have no statistics to back it up, but I believe it to be true. However, it does feel weird to treat BROWSER differently than EDITOR and PAGER. Maybe we should do the same for BROWSER. We have to face the fact that policy was written before there was anything like an integrated desktop environment. At the time Debian was just a random hodgepodge of unrelated software, and Debian's main task was trying to get it to work together in some sane fashion. But now we have software that's all *designed* to work together from the start. By imposing Debian's own view of how things should be done on it, we're breaking that which gives it value.
