[9fans] non-english keyboard?

[9fans] non-english keyboard?

[David Tolpin]

Hi,

Is there support for keyboard mapping in Plan9? Either in the kernel
or in rio?

I regularly need access to Armenian and Russian, occasionally to Hebrew
and Arabic. 

David

Re: [9fans] non-english keyboard?

[andrey mirtchovski]

> Hi,
> 
> Is there support for keyboard mapping in Plan9? Either in the kernel
> or in rio?
> 
> I regularly need access to Armenian and Russian, occasionally to Hebrew
> and Arabic. 
> 
> David

why not read the archives and find out for yourself?

Re: [9fans] non-english keyboard?

[David Tolpin]

> > Is there support for keyboard mapping in Plan9? Either in the kernel
> > or in rio?
> > 
>
> why not read the archives and find out for yourself?
>

The only thing I have found in the archives, Andrey, is
a driver for russian keyboard compiled into the kernel;
it is out of sync with the current kernel code and
makefiles, and is generally a wrong thing.

I did read about the driver (from ask.km.ru) and have
decided to ask hoping there is a better solution around.

I would appreciate less rude to attitude, Andrey. When
I ask something, it is because I have a good reason too.

David

Re: [9fans] non-english keyboard?

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 107 bytes --]

9fs sources

Use then the alternate driver (usbhid) from /n/sources/nemo
drop a line if you need help.

[-- Attachment #2: Type: message/rfc822, Size: 2556 bytes --]

From: David Tolpin <dvd@davidashen.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] non-english keyboard?
Date: Tue, 9 Mar 2004 21:07:32 +0400 (AMT)
Message-ID: <200403091707.i29H7WO1093277@adat.davidashen.net>

> > Is there support for keyboard mapping in Plan9? Either in the kernel
> > or in rio?
> > 
>
> why not read the archives and find out for yourself?
>

The only thing I have found in the archives, Andrey, is
a driver for russian keyboard compiled into the kernel;
it is out of sync with the current kernel code and
makefiles, and is generally a wrong thing.

I did read about the driver (from ask.km.ru) and have
decided to ask hoping there is a better solution around.

I would appreciate less rude to attitude, Andrey. When
I ask something, it is because I have a good reason too.

David

Re: [9fans] non-english keyboard?

[andrey mirtchovski]

On Tue, 9 Mar 2004, David Tolpin wrote:

> I would appreciate less rude to attitude, Andrey. When
> I ask something, it is because I have a good reason too.

I admit to finding your 'ask questions first' attitude a tad irritating,
but that is, quite likely, completely my fault -- I would like to see the
people interested in Plan 9 more immersed in its culture (which, in my
opinion, favours searching for the answers instead of having them served
on a platter) instead of dragging with them the one which I have tried to
leave behind in a Lunix world. As an OS it has its ups and downs, but as a
culture for learning and experimenting I frankly think there's no better.

We'll find first gear at some point, I'm sure :)

andrey

Re: [9fans] non-english keyboard?

[Dave Lukes]

> > I would appreciate less rude to attitude, Andrey. When
> > I ask something, it is because I have a good reason too.

Now, to be pedantic, Andrey was not "rude":
"terse", maybe "impolite", but not actually "rude".

> I admit to finding your 'ask questions first' attitude a tad irritating,

Ditto.  If we spend all our time answering questions,
we'll _never_ get the USB/hotplug/wifi/PDP11 ... support finished:-).

> but that is, quite likely, completely my fault

No ...

For example, when I was training/mentoring people,
I forced them to find as much information as possible independently.

Apart from (obviously) trying to foster a hunger for knowledge
and make them more independent,
there is also an important psychological issue:
information which is given to you is less permanently embedded in your
memory than information which takes an effort to find.
(No, I can't back this up experimentally or theoretically,
 but I'd bet money on it).

Of course, this also eventually lessens your own workload,
so you can concentrate on other things!

Cheers,
	Dave.

[9fans] information <-> knowledge

[rog]

> information which is given to you is less permanently embedded in your
> memory than information which takes an effort to find.
> (No, I can't back this up experimentally or theoretically,
>  but I'd bet money on it).

the same thing applies to learning tunes - tunes that one learns to
play from written music seem to embed themselves less deeply than
tunes learnt by ear.  (i learn lots of tunes...)

i think the difference might be in the degree of conscious attention
that one has directed at the problem.

that said, in the 9 world, there are still some things that i have to
look up every time, despite having researched the answer originally.

Re: [9fans] non-english keyboard?

[David Tolpin]

> > I admit to finding your 'ask questions first' attitude a tad irritating,
>
> Ditto.  If we spend all our time answering questions,
> we'll _never_ get the USB/hotplug/wifi/PDP11 ... support finished:-).

You'd better answered my questions once, instead of training and
mentoring me. You'd save a whole lot of time. Really. 

> Of course, this also eventually lessens your own workload,
> so you can concentrate on other things!

So, am I looking in the wrong direction trying to figure out
how to use usbhid driver (which is helpful, thank you for the
hint) to have different keyboard mappings 
in different rio windows? 

Is there bidi support? I have failed to find anything on it.

What would be the right level for bidi?

David

Re: [9fans] non-english keyboard?

[Dave Lukes]

> You'd better answered my questions once, instead of training and
> mentoring me. You'd save a whole lot of time. Really. 

No, because if we train you in how to find the information,
then we get asked less questions in the future!

	Dave.

Re: [9fans] non-english keyboard?

[David Tolpin]

> > You'd better answered my questions once, instead of training and
> > mentoring me. You'd save a whole lot of time. Really. 
>
> No, because if we train you in how to find the information,
> then we get asked less questions in the future!

So, what would be the right level to implement bidi support?

Re: [9fans] non-english keyboard?

[Latchesar Ionkov]

On Tue, Mar 09, 2004 at 10:42:51PM +0400, David Tolpin said:
> > > I admit to finding your 'ask questions first' attitude a tad irritating,
> >
> > Ditto.  If we spend all our time answering questions,
> > we'll _never_ get the USB/hotplug/wifi/PDP11 ... support finished:-).
> 
> You'd better answered my questions once, instead of training and
> mentoring me. You'd save a whole lot of time. Really. 
> 
> > Of course, this also eventually lessens your own workload,
> > so you can concentrate on other things!
> 
> So, am I looking in the wrong direction trying to figure out
> how to use usbhid driver (which is helpful, thank you for the
> hint) to have different keyboard mappings 
> in different rio windows?

IMO the easiest way is to replace the original /dev/keyboard with one that
translates the default keymap with the one you need. I am sure somebody
already wrote it, but if you cannot find it you can write it yourself. Check
pipefile(1) and /sys/src/cmd/aux/accupoint.c as an example how can you
use it to replace /dev/mouse.

> Is there bidi support? I have failed to find anything on it.

There is no bidi support.

> What would be the right level for bidi?

I think libframe is a good place to add it. It will work both for acme and
rio.

	Lucho

Re: [9fans] non-english keyboard?

[9nut]

> Is there bidi support? I have failed to find anything on it.

No.

I got as far as reading the UNICODE spec about it and downloading
fribidi.  It would be great if you got something going.  I can put in
a couple of hours a week, testing or fixing.  I have a few
Farsi/Arabic fonts converted also, but Andrey has the
most complete set.

Re: [9fans] bidi

[David Tolpin]

> > I think libframe is a good place to add it. It will work both for acme and
> > rio.
>
> do we really want non-displaying characters in acme/rio?  how does one
> deal with selection (have i selected this zero-width character i've
> just clicked on or not?)

This has no relation to bidi. Unicode bidi does not imply use
of any extra characters; just the opposite, the display media
should automatically re-order the text. Explicit bidi marks
are used only for codepoints with weak directionality, and
this feature can be easily dropped if strong bidirectionality
is supported.

> and if i've got l-r and r-l text on the same line, and i drag a
> selection...  how can it work?  either i've got a discontinuous
> selection in the underlying file, or a discontinuous selection on
> screen.

You get discontinuous selection in the underlying file. If it
does not work with the current model, then it is a limitation
of the current model.

> glyphs as display markup don't make a great deal of sense to me (but
> i'm sure others will tell me they're the only way forward).

What is it about?

[9fans] bidi

[rog]

> I think libframe is a good place to add it. It will work both for acme and
> rio.

do we really want non-displaying characters in acme/rio?  how does one
deal with selection (have i selected this zero-width character i've
just clicked on or not?)

and if i've got l-r and r-l text on the same line, and i drag a
selection...  how can it work?  either i've got a discontinuous
selection in the underlying file, or a discontinuous selection on
screen.

glyphs as display markup don't make a great deal of sense to me (but
i'm sure others will tell me they're the only way forward).

bidi *display*, certainly.

but in rio/acme... bad idea, i think.

Re: [9fans] bidi

[rog]

> You get discontinuous selection in the underlying file. If it
> does not work with the current model, then it is a limitation
> of the current model.

it is indeed a limitation of the current model.  for instance sam and
acme's command language assumes that dot, the current selection, can
be represented by two numbers, and changing that would change many
fundamental assumptions in the code.

acme(4) exposes its selections externally too; how would that
work?

i wouldn't say it'd be impossible, but it might be easier to code the
whole thing from scratch. would it be worth it (against, say,
having a heuristic to determine directionality for the whole
of a window)?

> What is it about?

it?

Re: [9fans] bidi

[Latchesar Ionkov]

What is the point of having full Unicode support in Plan9, if people
that use r-l languages cannot use it? How are they supposed to write in
these languages if rio/acme doesn't render the text correctly? 

If bidi support doesn't add too much complexity, I don't see why we, the
majority that uses l-r languages, should object to something that doesn't
affect us much.

Thanks,
	Lucho

On Tue, Mar 09, 2004 at 08:02:23PM +0000, rog@vitanuova.com said:
> > I think libframe is a good place to add it. It will work both for acme and
> > rio.
> 
> do we really want non-displaying characters in acme/rio?  how does one
> deal with selection (have i selected this zero-width character i've
> just clicked on or not?)
> 
> and if i've got l-r and r-l text on the same line, and i drag a
> selection...  how can it work?  either i've got a discontinuous
> selection in the underlying file, or a discontinuous selection on
> screen.
> 
> glyphs as display markup don't make a great deal of sense to me (but
> i'm sure others will tell me they're the only way forward).
> 
> bidi *display*, certainly.
> 
> but in rio/acme... bad idea, i think.

Re: [9fans] bidi

[Latchesar Ionkov]

I think the better way is to have discontinuous selection on the screen. It
is more straightforward, and doesn't look that bad.

You can check both in Mozilla and IE how the selection works with mixed
direction text:

	http://ppewww.ph.gla.ac.uk/~flavell/charset/dir-sample.html

Thanks,
	Lucho

On Tue, Mar 09, 2004 at 08:18:59PM +0000, rog@vitanuova.com said:
> > You get discontinuous selection in the underlying file. If it
> > does not work with the current model, then it is a limitation
> > of the current model.
> 
> it is indeed a limitation of the current model.  for instance sam and
> acme's command language assumes that dot, the current selection, can
> be represented by two numbers, and changing that would change many
> fundamental assumptions in the code.
> 
> acme(4) exposes its selections externally too; how would that
> work?
> 
> i wouldn't say it'd be impossible, but it might be easier to code the
> whole thing from scratch. would it be worth it (against, say,
> having a heuristic to determine directionality for the whole
> of a window)?
> 
> > What is it about?
> 
> it?

Re: [9fans] bidi

[David Tolpin]

> > You get discontinuous selection in the underlying file. If it
> > does not work with the current model, then it is a limitation
> > of the current model.
>
> it is indeed a limitation of the current model.  for instance sam and
> acme's command language assumes that dot, the current selection, can
> be represented by two numbers, and changing that would change many
> fundamental assumptions in the code.
>
> acme(4) exposes its selections externally too; how would that
> work?

1. That means that the code should be changed.

2. Untill it is changed, there are choices, and the choices are
well explored:
- limit selection to spans with one direction.
- limit selection to spans with starting and ending points with
  the same direction

> i wouldn't say it'd be impossible, but it might be easier to code the
> whole thing from scratch. would it be worth it 

Untill bidi is implemented, it is not very usable for roughly a half
of the Earth's population.

> (against, say,
> having a heuristic to determine directionality for the whole
> of a window)?

1) It is not a heuristic, it is a setting. One does have now
this setting, it has one value - ltr. It should be possible to
add the other one, rtl.

2) It is not an issue of bidi. The basic bidi can be implemented
without it.

> > What is it about?
>
> it?
>

Use of glyphs  for markup. Bidi is independent of use of direction
marks. Bidi can be implemented without direction-override marks. And
still be very usable. 'embed' as the only mode is almost the answer.

It lets people write and read in their languages.

?tfel ot thgir morf hsilgnE daer ot deirt uoy evaH

David

Re: [9fans] non-english keyboard?

[boyd, rounin]

> I regularly need access to Armenian and Russian, occasionally to Hebrew
> and Arabic. 

port this:

    http://www.insultant.net/repo/plan9/kbd.tar

Re: [9fans] non-english keyboard?

[boyd, rounin]

> Now, to be pedantic, Andrey was not "rude":
> "terse", maybe "impolite", but not actually "rude".

andrey has been more than reasoanable.

> > I admit to finding your 'ask questions first' attitude a tad irritating,
>
> Ditto.  If we spend all our time answering questions,

ditto.  it's easier to post to 9fans than to think.

Re: [9fans] non-english keyboard?

[boyd, rounin]

> You'd better answered my questions once, ...

you'd be better off thinking and doing your own research, BEFORE posting.

Re: [9fans] non-english keyboard?

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 181 bytes --]

give a man a fish and he eats for a day.

teach a man to fish and his industry will be destroyed by cheaper import
fish and he'll be back on the street and even more depressed.

[-- Attachment #2: Type: message/rfc822, Size: 2477 bytes --]

From: Dave Lukes <davel@anvil.com>
To: 9fans <9fans@cse.psu.edu>
Subject: Re: [9fans] non-english keyboard?
Date: Tue, 09 Mar 2004 18:45:57 +0000
Message-ID: <1078857957.6146.480.camel@zevon>

> You'd better answered my questions once, instead of training and
> mentoring me. You'd save a whole lot of time. Really. 

No, because if we train you in how to find the information,
then we get asked less questions in the future!

	Dave.

Re: [9fans] bidi

[Scott Schwartz]

| it is indeed a limitation of the current model.  for instance sam and
| acme's command language assumes that dot, the current selection, can
| be represented by two numbers, and changing that would change many
| fundamental assumptions in the code.
 
bidi text aside, I think that could be worth doing.  Sam already has a
notion of iterating over discontiguous regions, so this is essentially
a proposal to make them first class, by making dot a list of regions.
For example, if you write an x expression, wouldn't it be nice for all
the matches to show up as hilighted text?  Then you could interactively
give the next command to act on that set of regions.

It might involve lots of internal changes, of course, but just stepping
back for a minute and thinking about the interface, it seems interesting
enough.

Re: [9fans] non-english keyboard?

[Fco.J.Ballesteros]

> IMO the easiest way is to replace the original /dev/keyboard with one that
> translates the default keymap with the one you need. I am sure somebody
> already wrote it, but if you cannot find it you can write it yourself. Check
> pipefile(1) and /sys/src/cmd/aux/accupoint.c as an example how can you
> use it to replace /dev/mouse.

Am I missing something?  This is what usbhid does under -c flag.

Re: [9fans] non-english keyboard?

[Dave Cummings]

Give a man a fish and you will feed him for a day. Teach a man to fish 
and you will feed him for a lifetime.

Re: [9fans] non-english keyboard?

[Aharon Robbins]

In article <1078856477.6146.470.camel@zevon> you write:
>For example, when I was training/mentoring people,
>I forced them to find as much information as possible independently.

This is fine and good, (a) in person, (b) in a work or school environment,
where the relationship is clearly not peer-to-peer, and both sides
agree and understand that.

Those conditions don't apply to the mailing list/newsgroup, where the
"RTFM, you idiot" attitude, without even a pointer as to which FM to R,
is just likely to drive people away.

It's particularly inappropriate when, as is the case here, the original
questioner has shown a willingness to do his own research when pointed
in the right direction.

Arnold

Re: [9fans] bidi

[Fco.J.Ballesteros]

> What is the point of having full Unicode support in Plan9, if people
> that use r-l languages cannot use it? How are they supposed to write in
> these languages if rio/acme doesn't render the text correctly? 

I wouldn't like support for r-l if I don't get also support for t-d (top-down).
ネ
モ

Re: [9fans] non-english keyboard?

[a]

Give a man a fish and he'll eat for a day.
Teach a man to fish and he'll sit in a boat and drink beer all day.

or, my personal favorite:

Build a man a fire and he'll be warm for a night.
Set a man on fire and he'll be warm for the rest of his life.

uh, anyway.
ア

Re: [9fans] non-english keyboard?

[Dave Lukes]

> This is fine and good, (a) in person, (b) in a work or school environment,
> where the relationship is clearly not peer-to-peer, and both sides
> agree and understand that.
> 
> Those conditions don't apply to the mailing list/newsgroup, where the
> "RTFM, you idiot" attitude, without even a pointer as to which FM to R,
> is just likely to drive people away.

Being gratuitously insulting _never_ applies.
Yes, some people on this list (myself included)
can be terse to the point where it is considered rude,
but usually not deliberately.

> It's particularly inappropriate when, as is the case here, the original
> questioner has shown a willingness to do his own research when pointed
> in the right direction.

He _was_ pointed in the right direction ...
I don't even have a plan9 system but  it took me all of 2 minutes
to google the archive for Nemo's stuff on keyboards?

Cheers,
	Dave.

Re: [9fans] bidi

[David Tolpin]

> > What is the point of having full Unicode support in Plan9, if people
> > that use r-l languages cannot use it? How are they supposed to write in
> > these languages if rio/acme doesn't render the text correctly? 
>
> I wouldn't like support for r-l if I don't get also support for t-d (top-down).

Are you aware of languages for which there is support in UCS2 and
which cannot be written either l-r or r-l instead of tb-rl or tb-lr?

For presentation and publishing, vertical writing modes are required
for Japanese, at least. For text display, this is not needed. 

David

Re: [9fans] non-english keyboard?

[Michael Baldwin]

Give a man a fire, and he keeps warm for a day.  Set him on fire and 
he's warm for the rest of his life.

Re: [9fans] bidi

[Derek Fawcus]

On Wed, Mar 10, 2004 at 12:39:26AM +0400, David Tolpin wrote:
> ?tfel ot thgir morf hsilgnE daer ot deirt uoy evaH

reading it isn't a problem,  now writing r->l would be a bit nore difficult.

Hmm - bit I do find refelected slighty harder.

DF

Re: [9fans] bidi

[rog]

> > (against, say,
> > having a heuristic to determine directionality for the whole
> > of a window)?
> 
> 1) It is not a heuristic, it is a setting. One does have now
> this setting, it has one value - ltr. It should be possible to
> add the other one, rtl.

i guess i was imagining that rather than have bidi implemented as per
the spec, with different directions in each paragraph, each line, etc,
one could just do a version that looked at the characters being
displayed, and decided on directionality for the entire window (but
automatically, so it would try and do the "right" thing)

much simpler...  but might be insufficient for normal usage; i dunno.

Re: [9fans] bidi

[rog]

> It might involve lots of internal changes, of course, but just stepping
> back for a minute and thinking about the interface, it seems interesting
> enough.

true.
it'd be expensive for big files though (imagine "x/[a-z]+/")

Re: [9fans] bidi

[Latchesar Ionkov]

If I remember correctly some languages use both l-r (for numbers for
example) and r-l (for the rest).

Thanks,
	Lucho

On Wed, Mar 10, 2004 at 09:07:59PM +0000, rog@vitanuova.com said:
> > > (against, say,
> > > having a heuristic to determine directionality for the whole
> > > of a window)?
> > 
> > 1) It is not a heuristic, it is a setting. One does have now
> > this setting, it has one value - ltr. It should be possible to
> > add the other one, rtl.
> 
> i guess i was imagining that rather than have bidi implemented as per
> the spec, with different directions in each paragraph, each line, etc,
> one could just do a version that looked at the characters being
> displayed, and decided on directionality for the entire window (but
> automatically, so it would try and do the "right" thing)
> 
> much simpler...  but might be insufficient for normal usage; i dunno.

Re: [9fans] bidi

[9nut]

> If I remember correctly some languages use both l-r (for numbers for
> example) and r-l (for the rest).

Correct. This is not the only reason for full bidi support. Citing titles of
books or peoples names, or any type of quoting in line would run into
the same issue.

Re: [9fans] bidi

[Kenji Okamoto]

> I wouldn't like support for r-l if I don't get also support for t-d (top-down).
> ネ
> モ

Well done!  ネモ

Kenji