all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Amit Ramon <amit.ramon@riseup.net>
To: "K. Handa" <handa@gnu.org>
Cc: yair.f.lists@gmail.com, emacs-devel@gnu.org
Subject: Re: Issues with quail.el
Date: Sun, 27 May 2018 16:09:24 +0300	[thread overview]
Message-ID: <20180527130924.ot3k7wngig2uqjjp@isis.luna> (raw)
In-Reply-To: <87a7sqphug.fsf@gnu.org>

K. Handa <handa@gnu.org> [2018-05-23 23:27 +0900]:

>In article <20180519120124.ee4bompnunw2gxuv@isis.luna>, Amit Ramon <amit.ramon@riseup.net> 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 yair.f.lists@gmail.com 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	other threads:[~2018-05-27 13:09 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-05 11:53 Issues with quail.el Amit Ramon
2018-05-07 19:33 ` Eli Zaretskii
2018-05-08  8:41   ` Amit Ramon
2018-05-08 17:28     ` Eli Zaretskii
2018-05-08 19:53       ` Amit Ramon
2018-05-09  3:19 ` Michael Welsh Duggan
2018-05-10 14:12   ` Amit Ramon
2018-05-11  3:18     ` Van L
2018-05-11 16:41       ` Amit Ramon
2018-05-12  4:13     ` Michael Welsh Duggan
2018-05-12 17:12       ` Amit Ramon
2018-05-12 12:24     ` K. Handa
2018-05-17 12:31       ` K. Handa
2018-05-17 15:41         ` Amit Ramon
2018-05-17 15:44         ` Filipp Gunbin
2018-05-17 18:57           ` Amit Ramon
2018-05-18 14:36           ` K. Handa
2018-05-19 12:01         ` Amit Ramon
2018-05-23 14:27           ` K. Handa
2018-05-27 13:09             ` Amit Ramon [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180527130924.ot3k7wngig2uqjjp@isis.luna \
    --to=amit.ramon@riseup.net \
    --cc=emacs-devel@gnu.org \
    --cc=handa@gnu.org \
    --cc=yair.f.lists@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.