Re: lookup.jl google and koi8-r

[Vladimir Zolotykh <gsmith eurocom od ua>]

On Sun, 25 Jun 2006 08:33:08 +0100
Ewan Mellor <sawfish ewanmellor org uk> wrote:

> On Sat, Jun 24, 2006 at 12:27:00PM +0300, Vladimir Zolotykh wrote:
> 
[snip]
> > in sawfish-client and type the same koi8-r word as before I get
> > 
> >   user> (prompt-for-string "FOO:")
> >   "\301\302\327\307\304\305\326"
> >   user> 
> > 
> > What arrangements must be made to pass it properly to Google, causing
> > Google to interpret it as koi8-r word, not as don't-now-what ?
> 
> Which koi8 word did you type here?  I don't know, but I'd guess that if those
> aren't koi8 bytes then they are the UTF-8 equivalents instead.  I'm sure that
> with a little help from someone who uses non-latin encodings we could get the
> transcoding sorted out.
It was first seven lower-case letters of the Russian alphabet, e.g.

  абвгдеж

Their KOI8-r octal codes are

  301
  302
  327
  307
  304
  305
  326

Their UTF-8 codes (hex) are

  430
  431
  432
  433
  434
  435
  436

I'd say that Mozilla (the browser I'm using, version mozilla-firefox
1.0.4-2sarge7) expects somehow UTF-8 letters but gets KOI8-r instead,
which he thinks are UTF-8 coded, hence the confusion. In my opinion,
either PROMPT-FOR-STRING should convert what it reads to UTF-8, or
explicit conversion from KOI8-r to UTF-8 should be done before passing
the string to Mozilla. However, I'm not that familiar with LIBREP to
fix that myself.

I've got another question about using lookup.jl (and Sawfish or
Librep?). I'm using two keyboard layouts, or groups in XKB
terminology: US/ASCII and Russian. Locale as you already know is
ru_RU.KOI8-R. Groups (or keyboard layouts) are changed on per window
basis, e.g. each window has its own group, either US/ASCII or Russian.
I'm concerned with the popup window produced by
PROMPT-FOR-STRING. Does it have a name (or a class)? Is it focused
when present on the screen? Let me give a few more detail. My
~/.xxkbrc contains

  XXkb.app_list.wm_class_class.alt_group1: emacs Emacs

which roughly means 'don't change group for the Emacs window'. And my
~/.sawfishrc has

  (defun event-for-emacs ()
    (when (string-match "^Emacs" (window-class (input-focus)))
      (synthesize-event (current-event) (input-focus))))

  (bind-keys global-keymap "F13" event-for-emacs)

there is a couple of other detail which I'll omit for shortness
sake. All this enables Emacs's command TOGGLE-INPUT-METHOD being
invoked by Shift+CAPS (another setting in the XKB), while pressing the
same key Shift+CAPS in say Xterm window just changes it's group. 

Returning back to the PROMPT-FOR-STRING, seems that the window it
produces somehow inherits the related properties of the visible window
above which it's positioned.  To put it simple, if PROMPT-FOR-STRING
window positioned above Emacs's window, I'm unable to enter Russian
letters at all (Emacs always in Group1 according to ~/.xxkbrc
settings), with PROMPT-FOR-STRING's window positioned above say Xterm
window all is fine.

One final observation, BackSpace (keycode 22) being used for
PROMPT-FOR-STRING, correcting typed string interactively doesn't
back space at all.
     
  user> (prompt-for-string "FOO:")
  "\301\302\010"
  user> 

In this example, after the PROMPT-FOR-STRING window appeared, I
changed Group to Russian and pressed three keys

  Cyrillic small letter A
  Cyrillic small letter BE
  BackSpace

It's applicable also for other non-printable letters like Return and
only while typing in Russian Group.

-- 
Vladimir Zolotykh