From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Amit Ramon Newsgroups: gmane.emacs.devel Subject: Re: Issues with quail.el Date: Sun, 27 May 2018 16:09:24 +0300 Message-ID: <20180527130924.ot3k7wngig2uqjjp@isis.luna> References: <20180519120124.ee4bompnunw2gxuv@isis.luna> <87a7sqphug.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1527426489 20520 195.159.176.226 (27 May 2018 13:08:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 27 May 2018 13:08:09 +0000 (UTC) Cc: yair.f.lists@gmail.com, emacs-devel@gnu.org To: "K. Handa" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun May 27 15:08:05 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fMvP2-0005GF-1b for ged-emacs-devel@m.gmane.org; Sun, 27 May 2018 15:08:04 +0200 Original-Received: from localhost ([::1]:52080 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fMvR7-0007oL-ID for ged-emacs-devel@m.gmane.org; Sun, 27 May 2018 09:10:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49496) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fMvQV-0007o5-4C for emacs-devel@gnu.org; Sun, 27 May 2018 09:09:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fMvQQ-0003O6-FI for emacs-devel@gnu.org; Sun, 27 May 2018 09:09:35 -0400 Original-Received: from mx1.riseup.net ([198.252.153.129]:37976) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fMvQQ-0003MB-1k; Sun, 27 May 2018 09:09:30 -0400 Original-Received: from piha.riseup.net (piha-pn.riseup.net [10.0.1.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id 5759B1A0654; Sun, 27 May 2018 06:09:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1527426568; bh=eS/x27OMQl6uK2TKxTSibiOpXlQXpJOtoJN4n9AADGA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=i5E7nY94+ydfKh32CQlOkA/WVPJx/OZKGz2d1RdaYgWrdOOkodhvMnx/hKQxtuAjv 6MjslBxtFoPdk9iOUKzERpvmqHfmBLYth0H24nk33uTaZzByR5w3m6zP431M14b3FF fABqL5icdQ2X9MoO4uSbcC7xterey2BZxFUIe8Lg= X-Riseup-User-ID: E2A7531F74B4A0466E973FE5F47FB2D6572D2186F1DDD18734048A54DADC4BA5 Original-Received: from [127.0.0.1] (localhost [127.0.0.1]) by piha.riseup.net with ESMTPSA id 824DB291D3; Sun, 27 May 2018 06:09:27 -0700 (PDT) Mail-Followup-To: "K. Handa" , yair.f.lists@gmail.com, emacs-devel@gnu.org Content-Disposition: inline In-Reply-To: <87a7sqphug.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 198.252.153.129 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:225766 Archived-At: K. Handa [2018-05-23 23:27 +0900]: >In article <20180519120124.ee4bompnunw2gxuv@isis.luna>, Amit Ramon 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 (=D6=BE), one has to type q-p. When the keyboard layout is stand= ard, >> 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 (=D6=BE) is mapped to '/=D7=A4'. >------------------------------------------------------------ >Why does it say "mapped to '/=D7=A4'"? 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... >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >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" =D7=B4 q0 =D7=81 q4 =D6=B4 q8 =D6=B8 q\ =D6=BB qh = =D7=B2 qw =D7=B3 >[...] >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >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