[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: virtual package (x-)editor ?



On 24-Nov-01, 13:19 (CST), Tomas Pospisek <tpo2@spin.ch> wrote: 
> * Now that the defacto-virtual package "editor" is handled by the
>   alternatives mechanism [1],

"Now that..."?!? It's been 5 *years*.

>                              is there any reason not to include "editor"
>   in the virtual packages?

Because there's no standard interface? The best you can hope for is that
'editor foo' tries to open file foo.

> * I require a program that opens up an editor under X. Right now I am
>   using:
> 
> 	Suggests: editor, x-terminal-emulator
              ^^^^^

No such virtual package. Therefore, a violation of policy.



>   and then I do a:
> 
>  	/etc/alternatives/x-terminal-emulator -e /etc/alternatives/editor

That's wrong. The correct thing to do is check for the environment
variables VISUAL and EDITOR, and then fall back on /usr/bin/editor (Not
/etc/alternatives/editor -- nothing is supposed to use that except the
update-alternatives stuff.) Or just call /usr/bin/sensible-editor, which
will do the checks for you. All this is in Debian Policy 12.4. In particular,
the last sentence of that section is 

    It is not required for a package to depend on editor and pager, nor
    is it required for a package to provide such virtual packages.

(For much the same reason that packages don't need to "Suggests: ls" -
it's part of the base system. Yes, you can, with some effort, remove all
the "editors" from your system. But someone that has gone to that effort
is likely to be annoyed by your "Suggests".)

Now, admittedly, this doesn't deal well with X editors. But you need
to integrate into this solution, because the mere existence of an
X-based editor on the system, providing a hypothetical /usr/bin/x-editor
alternative, doesn't mean that you should call that editor. I,
personally, would much rather have vi in a terminal than some lame
notepad clone. That's why I set EDITOR in my .profile. A Unix program
that starts a text editor yet ignores EDITOR is *broken*.

It sounds like what we could really use is something like
'sensible-x-editor' and an associated XEDITOR environment variable,
which would fall back on starting $EDITOR in a terminal window.

For that matter, your code could do something like

	if ((exec("/usr/bin/sensible-editor") == FAILED) {
	    exec("/usr/bin/x-terminal-emulator -e /usr/bin/sensible-editor")
    }

   (Yes, I know that's not real C code...) 

so that if the user had defined EDITOR to something X-based, the first
exec succeeds, otherwise try again in an terminal.

Or avoid the whole problem by just bringing up a text-edit widget.
If the task is such that a widget isn't sufficient, that's even more
evidence that you shouldn't be ignoring the user's stated editor
preference.

In any case:

- Stop using the /etc/alternatives links, use the correct link in
/usr/bin.

- There's no need for an editor (or xeditor) virtual package. 

Steve

-- 
Steve Greenland <steveg@moregruel.net>



Reply to: