home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Source Code 1993 July / THE_SOURCE_CODE_CD_ROM.iso / gnu / lucid / help-lucid-emacs / text0427.txt < prev    next >
Encoding:
Text File  |  1993-07-14  |  7.7 KB  |  172 lines
  1. Per Abrahamsen wrote:
  2. > 
  3. > How do I map 248 (?°) into 'oslash?
  4.  
  5. There's not currently a good way to do that, but you're right, it should
  6. be possible.  Enclosed is a patch to lisp/x11/x-iso8859-1.el which defines
  7. a variable which does this mapping.
  8.  
  9. > I would have written 
  10. >     
  11. >     (define-key global-map [°] 'self-insert-command)
  12. > 
  13. > which I hope you agree is obvious, but feared what the mail and news
  14. > software might do to the `°'.
  15.  
  16. Yes, that is more obvious; I'm not sure of a good way to make that work,
  17. however.  The problem is that the `symbols' which one can use as an
  18. argument to define-key are essentially equivalent to X keysyms.  You can
  19. use the symbols `A' and `a' because those are the official X keysym names
  20. of characters 65 and 97 in the Latin1 character set.  But the traditional
  21. ASCII printing characters are the only keysyms which have one-character
  22. names.  So `°', being a symbol whose name is the one-character string
  23. "\370", is not a valid X keysym name.
  24.  
  25. I don't pretend to know the rationale for this decision of the X
  26. designers, but one good reason is that \370 is character-set dependent;
  27. the names of the keysyms are expressed in Latin1, but `oslash' could
  28. concievably have a different character code in some other character set,
  29. which would be confusing.
  30.  
  31. One of the things I've been trying to do with lemacs is avoid any
  32. character-set dependence.  I don't claim that I've accomplished this, but
  33. that's what I've been striving for...  All of the patches I've seen for
  34. v18 have simply traded one character set (ASCII) for another (ISO8859/1).
  35. I want to avoid that.
  36.  
  37. > I get a Danish keyboard layout on a US Style keyboard using the Latin 1
  38. > character set.  That is, pressing "'" will insert oslash because the "'"
  39. > key is located at the place where oslash would be found on a Danish 
  40. > keyboard.  
  41. > 
  42. > This works on all flavours of Emacs 18 and 19 as long as the
  43. > translation is 7-bit to 7-bit or 7-bit to 8-bit. Now someone wanted to
  44. > do 8-bit to 7-bit (ISO 8859-1 to ISO 646 SE) and this does not work in
  45. > Emacs 19 under X (emacs 18 and non-X11 emacses are too stupid to give 
  46. > any problems).  
  47. > 
  48. > The translation tables are also used for text, so I would rather not
  49. > store keyboard event directly in the tables.  Especially since I want 
  50. > them to work on all GNU Emacs flavours.
  51.  
  52. (I assume that by "Emacs 19" you mean "Lucid Emacs" and not "FSF v19" or
  53. "Lucid Emacs as well as FSF v19", but one should be careful about this 
  54. ambiguity these days...)
  55.  
  56. I'm not sure what the right solution here is.  At one level, you're mapping
  57. keysyms to keysyms: doing what xmodmap does.  But at the next level down,
  58. you're using character codes, since they were the same thing in v18.
  59.  
  60. My first thought was that, if you were writing this from scratch for the 
  61. lemacs keyboard model, the right thing would be to include keysym names
  62. instead of their character codes, since the name->charcode mapping happens
  63. internally.  (You might need to include the charcodes in this table as well
  64. in order to support the v18 input model, but remember, the v18 input model
  65. is "considered obsolete" :-)  It's just not expressive enough, and this
  66. equivalence of keysyms and character codes was a big part of the problem.)
  67.  
  68. But then, why not just use the new mapping table that I've added below, in
  69. the variable iso8859/1-code-to-x-keysym-table?  Well, it's name suggests
  70. that it is X-specific.  But is it, really?
  71.  
  72. This brings up an interesting question, which is whether by including the
  73. symbol/keysym `oslash' into one's code, one has introduced an X-specific
  74. name.  I'm not sure.  Does anyone know whether there is a standard set of
  75. names for the ISO-8859/1 characters, and whether X is using those names?
  76. (Are things specified well enough that it's clear that the name should be
  77. "oslash" and not "o-slash" or "o slash"?  And what about things like 
  78. "Adiaeresis" -- might that legally be called "Aumlaut"?  And what about
  79. "ETH" and "THORN"?  Is it specified that those should be all caps?)
  80.  
  81. Because I wasn't sure, I had been assuming that those names were X
  82. specific; that's why lisp/prim/iso8859-1.el deals with all aspects of that
  83. character set except the keysym names, which have been shuffled off to the
  84. file lisp/x11/x-iso8859-1.el.  If it turns out that the names which X uses
  85. are officially sanctioned as window-system-independent, then most of what's
  86. in x-iso8859-1.el can be moved to iso8859-1.el, and the new variable the
  87. patch belows adds (iso8859/1-code-to-x-keysym-table) can be more officially
  88. sanctioned with a non-X-specific name.
  89.  
  90. Conversely, if it turns out that there is a standard for these names but
  91. the X keysyms don't follow it, then perhaps it would be worthwhile to add
  92. a translation down in event-Xt.c so that define-key always works with the
  93. ISO names and never with the nonstandard X names.  And presumably some
  94. hypothetical future non-X port of lemacs will also do this translation to
  95. the officially sanctioned names if necessary.
  96.  
  97. If there's no standard, I don't see how to avoid introducing some level of
  98. window system dependence into user code...  Emacs could adopt the X keysym
  99. names as the "Emacs" keysym names, and these future hypothetical other
  100. window systems could translate to that, but this makes those other window
  101. systems be second-class citizens again, which is another thing I wanted to
  102. avoid.
  103.  
  104. (As an aside, using the term "8-bit input" to refer to these issues isn't
  105. quite correct.  It reflects the historical fact that old input devices
  106. could only deliver 8 bits worth of "keysym", which isn't true under a
  107. window system.  If you're thinking of hitting a key and having it deliver
  108. some particular integer (which happens to take 8 bits to represent) then
  109. you're not taking into account an important aspect of this whole mess.)
  110.  
  111.     -- Jamie
  112.  
  113. diff -c -r1.3 x-iso8859-1.el
  114. *** 1.3    1992/08/20 01:37:30
  115. --- x-iso8859-1.el    1993/05/31 20:19:20
  116. ***************
  117. *** 1,5 ****
  118.   ;; Mapping between X keysym names and ISO 8859-1 (aka Latin1) character codes.
  119. ! ;; Copyright (C) 1992 Free Software Foundation, Inc.
  120.   
  121.   ;; This file is part of GNU Emacs.
  122.   
  123. --- 1,5 ----
  124.   ;; Mapping between X keysym names and ISO 8859-1 (aka Latin1) character codes.
  125. ! ;; Copyright (C) 1992, 1993 Free Software Foundation, Inc.
  126.   
  127.   ;; This file is part of GNU Emacs.
  128.   
  129. ***************
  130. *** 37,42 ****
  131. --- 37,48 ----
  132.   
  133.   (require 'iso8859-1)
  134.   
  135. + (defconst iso8859/1-code-to-x-keysym-table nil
  136. +   "Maps iso8859/1 to an X keysym name which corresponds to it.
  137. + There may be more than one X name for this keycode; this returns the first one.
  138. + Note that this is X specific; one should avoid using this table whenever 
  139. + possible, in the interest of portability.")
  140. + 
  141.   ;; (This esoteric little construct is how you do MACROLET in elisp.  It
  142.   ;; generates the most efficient code for the .elc file by unwinding the
  143.   ;; loop at compile-time.)
  144. ***************
  145. *** 62,67 ****
  146. --- 68,91 ----
  147.              (list 'global-set-key (list 'quote (car sym-and-code))
  148.                ''self-insert-command))
  149.           syms-and-iso8859/1-codes)
  150. +     ;;
  151. +     ;; Then emit the value of iso8859/1-code-to-x-keysym-table.
  152. +     ;;
  153. +     (let ((v (make-vector 256 nil)))
  154. +       ;; the printing ASCII chars have 1-char names.
  155. +       (let ((i 33))
  156. +         (while (< i 127)
  157. +           (aset v i (intern (make-string 1 i)))
  158. +           (setq i (1+ i))))
  159. +       ;; these are from the keyboard character set.
  160. +       (mapcar '(lambda (x) (aset v (car x) (car (cdr x))))
  161. +           '((8 backspace) (9 tab) (10 linefeed) (13 return)
  162. +             (27 escape) (32 space) (127 delete)))
  163. +       (mapcar '(lambda (sym-and-code)
  164. +              (or (aref v (car (cdr sym-and-code)))
  165. +              (aset v (car (cdr sym-and-code)) (car sym-and-code))))
  166. +           syms-and-iso8859/1-codes)
  167. +       (list (list 'setq 'iso8859/1-code-to-x-keysym-table v)))
  168.       ))))
  169.   
  170.    ;; The names and capitalization here are as per the MIT X11R4 and X11R5
  171.  
  172.