Re: adding consistent extra symbols to input methods (cyrillic-*, croatian-*, slov*, czech-* etc.) input methods

[Kenichi Handa <handa@m17n.org>]

In article <864p76lp60.fsf_-_@lifelogs.com>, Ted Zlatanov <tzz@lifelogs.com> writes:

> Right, I'm trying to do the above for input methods that are in
> input-method-alist but not necessarily loaded.  So this works:

> (dolist (method 
> 	 (remove nil
> 		 (mapcar 
> 		  (lambda(m) 
> 		    (let ((name (car-safe m)))
> 		      (when (and (string-match "cyrillic" name)
> 				 (quail-package name))
> 			name)))
> 		  input-method-alist)))
>   (message "Defining rules for method %s" method)
>   (quail-defrule ",," ?„ method))

> The question is, should I load those input methods explicitly, or just
> assume that it's enough to handle what's in leim/quail/cyrillic.el?

You can't assume that all "cyrillic*" input methods are in
leim/quail/cyrillic.el.  So the safest (and more efficient)
way is something like this:

(mapc (lambda(m) 
	(let ((name (car m)))
	  (when (string-match "cyrillic" name)
	    (message "Defining rules for method %s" method)
	    (activate-input-method name)
	    (quail-defrule ",," ?„)
	    (inactivate-input-method))))
      input-method-alist)

But, I'm now thiking about introducing this variable to
avoid eval-after-load in leim-ext.el:

;;;###autoload
(defvar quail-additional-rule-alist nil
  "Alist of Quail package names vs. the rules to add after loading the package.
Each element has the form (PACKAGE-NAME RULE ...), where
PACKAGE-NAME is a Quail package name (string representing an input method),
and RULE is a translation rule of the form (KEY TRANSLATION APPEND).
See the documentaion of the function `quail-defrule' for the meanings
or KEY, TRANSLATION, and APPEND.")

With this, you can do: 

(mapc (lambda(m) 
	(let ((name (car m)))
	  (when (string-match "cyrillic" name)
	    (message "Defining rules for method %s" method)
	    (push (list name '(",," ?„)) quail-additional-rule-alist))))
      input-method-alist)

> Specifically, cyrillic-jis-russian wouldn't be handled this way, and it
> can benefit from the extended mappings I am creating (proper double
> quotes „ “, single quotes ‚‘ and the № § « » symbols).  If I should
> special-case it in leim-ext.el that's fine, I'm just trying to approach
> it programmatically.  

I think cyrillic-jis-russian is now obsolete because all
Cyrillic character in JIS are now unified into Unicode.

---
Kenichi Handa
handa@ni.aist.go.jp