Re: Editor Priorities
On Thu, May 09, 2002 at 04:34:56PM +0900, Tomohiro KUBOTA wrote:
> > > However, in this case, priority in Debian alternative system is
> > > completely Debian's problem, not upstream problem.
> > Yeah, but mandating a particular preference to fuel somebody's agenda is
> > wrong. Just like mandating that all emacs packages have a higher priority
> > than vi packages, or something else equally inane. The package is there,
> > after all, and while integration is an issue, mandating priorities is not
> > the solution.
> I don't understand your point. Then how do you justify other terms
> (such as "online manuals", "redo/undo support", and so on) ? What
> is the difference between these terms and my terms?
This list doesn't guarantee features mandatory to certain people will be
there; it just prioritizes packages which have more features. If you
*really* need something, this really isn't of much use.
> Please read my previous mail. I don't want to be bothered by the
> need to choose text editors, text viewers, web browsers, terminal
> emulators, mp3 players (which display title of songs), window managers,
> word processors, and so on so on, in order only to use my mother
> tongue. Such work needs experts' knowledge, because the user has
> to know which text editors are multilingual, which text viewers are
> multilingual, which web browsers are multilingual, and so on. Thus
> I wrote I had to buy books which cost about 100 dollars in total.
> My motivation is to reduce this "non-European tax" which most Linux/BSD
> users have to pay, just like "Windows tax" which most PC users have
> to pay.
I don't doubt that you managed to find this much text, but I don't see
how it's necessary. Why isn't a simple web page, showing packages and
which languages they're suitable for? Index by language and you have a
list of packages useful for a given language.
> It is relative problem. Why *mandatory* item is less scored than,
> for example, redo/undo feature which I agree is useful but not
If a user *needs* Japanese support, this won't help him. This won't
guarantee the editor has that support; it just makes it more likely to
be there, which really isn't good enough. It's also editor-specific.
Someone needing Japanese support needs it in *all* of his applications,
not just editors. (It's a little more complicated than that, of course--JP
users don't need bidi--in the end, I don't think this helps that at all.)
For people who don't need it, this will just shift priorities around and
possibly make a lesser choice for them, especially with the features as
highly rated as you put them.
> Because multi-language is a mandatory feature for a certain amount
> of users. Yes, task package helps a lot. However, when a task package
> installs an alternative multilingual software, it should have higher
> priority than standard softwares or otherwise the task package doesn't
> have effects.
That's getting at a real problem. However, if such a package is
installed on its own, it shouldn't necessarily have higher priority just
because of that support.
If there's a "Japanese-supporting applications" task, it shouldn't
necessarily also boost priorities; I might want to install it for a Japanese
user on my system, without it also making all of my alternatives Japanese-
Perhaps it'd be a better idea, for this problem, to allow boosting priorities
selectively? Some simple way to tell my system to, for example, give +1000
priority to applications with some set of i18n features ("Japanese",
"Arabic", "UTF-8", etc.)
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org