emacs-devel
[Top][All Lists]
Advanced

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

Re: Issues with quail.el


From: Amit Ramon
Subject: Re: Issues with quail.el
Date: Sun, 27 May 2018 16:09:24 +0300

K. Handa <address@hidden> [2018-05-23 23:27 +0900]:

In article <address@hidden>, Amit Ramon <address@hidden> writes:

There are still some slight issued, for example the quail's definition
of the standard keyboard layout is based on VT100 layout, which is
different in some minor aspects from a standard PC keyboard (e.g. the
location of the tilde key), but this is not related to the problem
this patch fixes.

When I first wrote that part (looong ago), we were using Unix (not
GNU/Linux) on workstations (not PC).  At that time, the choice of VT100
as the starndard layout was, I thought, not that bad.

Yes, I guessed that is the reason. I really don't know which keyboard
layout is the most prevalent now days (I would guess that a PC
keyboard, but I can't back it up with data), so I don't have a strong
opinion regarding which keyboard layout should be the
default. However, we should at least have a definition of a 'standard
PC' keyboard layout in quail's list of keyboards, as well as, IMHO, a
'standard English Dvorak' (we discussed this in a previous email), so
I suggest that I'll prepare a patch and post it here as soon as I find
time for it.

Also, there is a new standard for Hebrew keyboard layout, and I intend
to prepare a patch for it and post it here.

[...]

Thank you for testing it.  I'll commit that patch soon.

Glad I could help with that, thanks.

There are still some issued that are, perhaps, related to a broader
question, I'll try to describe them briefly here, but I think they
should not stop us from applying your fixes.

1. Key sequences

Lets assume I'm using a Dvorak keyboard layout and a Hebrew input
method. This input method include some key sequences for typing some
special Hebrew signs. For example, for inputting HEBREW PUNCTUATION
MAQAF (־), one has to type q-p. When the keyboard layout is standard,
there is no problem. When it is Dvorak, C-h I still says you have to
type q-p, and it works if you press the keys that are q-p in the
standard layout, but since I use Dvoark it is (for me) '-l. Here comes
the question of what the input method really wants -- to keep the
actual location of the keys you need to type a sequence constant, or
that the constant should be the keys themselves (i.e., their meaning).

At first, there's something wrong in the docstring of Hebrew.  It says:
------------------------------------------------------------
'q' is used to switch levels instead of Alt-Gr.
Maqaaf (־) is mapped to '/פ'.
------------------------------------------------------------
Why does it say "mapped to '/פ'"?  Shouldn't it be "mapped to 'qp'"?
[I included address@hidden in CC: because it seems that this
part is added by him].

I cannot know the reasoning for that, but it does make some sense. If
the keyboard layout is standard, then MAQAF is produced by "qp". But
if the keyboard layout is, say, Dvoark, then the corresponding key
sequence would be "'l". The message you are referring to comes from
hebrew.el so it is "hard coded". If it would say "qp", it will be
incorrect for users of Dvorak and, possibly, other keyboard layouts.

So as long as this message is hard coded using the key system of the
input method is, perhaps, a reasonable compromise -- at least it
refers to keys that are in a fixed location, no matter what is the
keyboard layout.

Anyway, to make that part shown correctly in *Help* buffer for Dvorak
users, we need a new mechanism to convert "qp" to "-l".  One idea is to
introduce a new notation, something like "\[q]" and modify
quail-help to convert it to the key on the current layout.

I agree that converting it on-the-fly would be the best solution.

Here, I have a question.  I think 'q' of 'qp' is selected because a user
won't have to insert "q" while typing Hebrew.  But, is it ok to use "/"
for that kind of prefix key?

When we are in Hebrew input method, the "q" key produces "/", like you
said, so the question is about the usage of "/". This key is indeed
rarely used in Hebrew, so probably this is the reason for its
selection as the prefix key. Perhaps another reason is the location of
it on the keyboard, which, at least to me, is convenient.

The following section in *Help* buffer can be fixed rather easily...
============================================================
KEY SEQUENCE
------------
You can also input more characters by the following key sequences:
key char  [type a key sequence to insert the corresponding character]
--- ---- --- ---- --- ---- --- ---- --- ---- --- ---- --- ----
q"  ״       q0  ׁ    q4  ִ    q8  ָ            q\  ֻ     qh         ײ    qw  ׳
[...]
============================================================
because the table is generated by a program.  Perhaps, we should fix
quail-insert-decode-map.

That would be great.

2. Shifted keys

This is somewhat similar to the above. If (Hebrew + Dvorak layout) I
ask quail-show-key to tell what to type for inputting Z, it tells me
"To input 'Z', just type it".

But (again, Hebrew input method is active) this is not really true
since my keyboard layout is Dvorak -- to enter Z in Hebrew input
method I need to press Shift-;, since the key that has ; in Dvorak is
the z key in the standard layout.

This part should also be fixed.

I am for it.

These are, maybe, questions of semantics and context -- when one say
that I have to type q-p (to get HEBREW MAQAF), is it in the context of
my real keyboard (then it is not true for Dvoark), or is it in the
context of a standard keyboard (and then it is confusing people who're
using, say, a Dvorak keyboard).

As I wrote above, 'qp' should be converted to '-l' in *Help* buffer.

Yes, it could be that I repeated myself.


P.s. Handa san, I have some [...] suggestions for simplifying some
parts of quail.el [...]

Could you post to emacs-devel with a new proper subject?

Yes, I would do that. Anyway, these are not functional issues, they
are more of code refactoring, and perhaps we wouldn't want to modify
working code just for 'ascetics'. But I'll post it anyway and let you
decide.

Best,

--- Amit



reply via email to

[Prev in Thread] Current Thread [Next in Thread]