Re: Editor Priorities
At Thu, 9 May 2002 02:27:38 -0500,
Branden Robinson wrote:
> > In case of visual/motor impairments, I completely agree it is
> > important to support these users. If there are any easy
> > technical way to improve usability for them without spoil our
> > usability, it should be adopted. Unfortunately, I am not an
> > expert of this field and I don't have any idea. However, when
> > someone would propose something in this field, I would never
> > oppose them.
> If we had a text editor designed for the visually impaired that was very
> frustrating for sighted users to operate, would you "never oppose" a
> proposal to make that text editor the default?
> > languages, because there are several editors and other softwares which
> > can handle CJK/bidi/... languages. Why should we avoid giving priority
> > to such softwares?
> Because they might alienate and frustrate more users than they help.
Well, you also may be misunderstanding that multilingual softwares are
not useful for European-language speakers. I will never agree to give
high priority for Japanese-only editors, even if there are many
> > I didn't hear any convincing opinion against it. Anyway, I decided
> > to improve and internationalize terminal emulators. It takes years
> > and now it is partly successful. rxvt-beta and eterm have LC_CTYPE
> > sensibility support which is written by me. I am also joining the
> > development of mlterm and try to improve xterm with Juliusz's luit.
> And that's exactly where this type of work *should* be going on.
It depends on cases. In case of terminal emulators, there are not
so many implementations, and it is enough to improve a few of them.
On the other hand, there are so many editors.
And more, even for terminal emulators, I hope multilingual terminal
emulators will have higher priority, because not all terminal emulators
are multilingual. Thus, I need to work in *both* fields, upstream
> Because you are undermining your own thesis. Your position is that
> CJK/bidi/Indic/combining support is mandatory if Debian is stop its
> tradition of racist sin, and yet your own proposal doesn't even go very
> far to accomplishing that goal. The low score you attach to it amounts
> to little more than using the alternatives mechanism as a forum for
> editorializing about how we ought be good little boys and girls and not
> disenfranchise the CJK/bidi/Indic/combining support community.
You mean, I should give more scores? It may be true, because I
didn't examined my scores.
However, I wonder that all other items (undo/redo, and so on) are
well examined or not. I think the scores for these items should
be reviewed *after* we determine the items to be adopted, because
what is important is *not* the absolute values of the scores, *but*
the relative values among terms.
> The point of this thread, if I recall correctly, is to improve the
> chances that a sysadmin -- regardless of his experience level with
> Unix-style systems -- will have a editor with sufficient functionality
> to carry out administrative tasks in a non-intimitdating way. Frankly,
> until most of the files in /etc can be written in Devanagari or
> Japanese, I do not think a CJK/bidi/Indic/combining editor is very
> important for this goal. I agree that is is suboptimal that Debian
> sysadmins who don't speak English have a river to cross when it comes to
> /etc. I don't think CJK/bidi/Indic/combining (10) is going to do
> anything to help these people.
I understand your point. However, I don't think the priority score
*must* be limited for sysadmin purpose. There are a lot of scenes
where a software wants to invoke some text editor.
If you say that alternative mechanism is not a place for i18n,
where do you think is suitable? I think alternative mechanism
*is* suitable. When we have a method which can be used, I think
we should not re-invent similar mechanism.
>> * 8bit clean (+20)
> Do we have any editors in Debian that *aren't* 8-bit clean? Is this
> going to serve to differentiate anything?
I hope you have already read I wrote "I don't know" in the original
message where I introduced "8bit clean". If there are no such editors,
European people don't have i18n problem in this field. Then, please
don't disturb non-European people trying to solve this problem.
Tomohiro KUBOTA <email@example.com>
"Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com