* Re: Can't isearch 'ö' [not found] ` <87fyxtxwku.fsf-monnier+emacs@gnu.org> @ 2005-04-14 23:42 ` Kenichi Handa 2005-04-15 12:36 ` Stefan Monnier 0 siblings, 1 reply; 14+ messages in thread From: Kenichi Handa @ 2005-04-14 23:42 UTC (permalink / raw) Cc: Peter_Dyballa, emacs-devel, emacs-pretest-bug In article <87fyxtxwku.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes: > Hmm... indeed the translation-table-for-input is not used for X11 keys. > Now that I look at it a bit more, I think the patch below would make sense. > What do other people think? That doesn't work in some case. The value of translation-table-for-input can be different in each buffer (depending of buffer-file-coding-system of a buffer). The translation should be done where we are sure about the target buffer; for instance, in isearch-printing-char. --- Ken'ichi HANDA handa@m17n.org ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Can't isearch 'ö' 2005-04-14 23:42 ` Can't isearch 'ö' Kenichi Handa @ 2005-04-15 12:36 ` Stefan Monnier 2005-04-18 2:52 ` Kenichi Handa 0 siblings, 1 reply; 14+ messages in thread From: Stefan Monnier @ 2005-04-15 12:36 UTC (permalink / raw) Cc: Peter_Dyballa, emacs-devel, emacs-pretest-bug >> Hmm... indeed the translation-table-for-input is not used for X11 keys. >> Now that I look at it a bit more, I think the patch below would make sense. >> What do other people think? > That doesn't work in some case. The value of > translation-table-for-input can be different in each buffer > (depending of buffer-file-coding-system of a buffer). Of course, that's why we can't do directly it in the xkeysym->char conversion. But it seems like doing it in read-char should work. Can you show me an existing piece of code where it wouldn't work right? Hypothetical examples aren't too interesting since we can also concoct such examples where the current "translate in self-insert-command" can be made to fail. Stefan ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Can't isearch 'ö' 2005-04-15 12:36 ` Stefan Monnier @ 2005-04-18 2:52 ` Kenichi Handa 2005-04-18 3:27 ` Stefan Monnier 2005-04-18 21:05 ` Richard Stallman 0 siblings, 2 replies; 14+ messages in thread From: Kenichi Handa @ 2005-04-18 2:52 UTC (permalink / raw) Cc: Peter_Dyballa, emacs-pretest-bug, emacs-devel In article <87br8g2pe0.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes: >>> Hmm... indeed the translation-table-for-input is not used for X11 keys. >>> Now that I look at it a bit more, I think the patch below would make sense. >>> What do other people think? >> That doesn't work in some case. The value of >> translation-table-for-input can be different in each buffer >> (depending of buffer-file-coding-system of a buffer). > Of course, that's why we can't do directly it in the > xkeysym-> char conversion. But it seems like doing it in read-char > should work. I don't know the diffence between them because even read-char doesn't know how a caller will treat the returned character. > Can you show me an existing piece of code where it wouldn't > work right? No, I can't. But shouldn't we avoid such an incompatible change at this stage? > Hypothetical examples aren't too interesting since we can also > concoct such examples where the current "translate in > self-insert-command" can be made to fail. I didn't know that self-insert-cmmand also uses translation-table-for-input. I have thought that the variable is for an input method as in this docstring: Char table for translating self-inserting characters. This is applied to the result of input methods, not their input. See also `keyboard-translate-table'. Anyway, could you show me such an example? --- Ken'ichi HANDA handa@m17n.org ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Can't isearch 'ö' 2005-04-18 2:52 ` Kenichi Handa @ 2005-04-18 3:27 ` Stefan Monnier 2005-04-18 5:16 ` Kenichi Handa 2005-04-18 21:05 ` Richard Stallman 1 sibling, 1 reply; 14+ messages in thread From: Stefan Monnier @ 2005-04-18 3:27 UTC (permalink / raw) Cc: Peter_Dyballa, emacs-pretest-bug, emacs-devel > No, I can't. But shouldn't we avoid such an incompatible > change at this stage? Can be. But since it's about a year now since we called a freeze and I see no sign of getting to the pretest stage, I figure I don't understand enough what "feature freeze" means: I just propose changes and I'll let someone else decide whether they should be installed. I think it's The Right Way to solve the problem, so that's what I use in my local code, but if someone wants to write a "quick&safe" fix instead and use that instead I see no problem with it. I'm still interested to know whether I'm right or not in thinking that my fix is The Right Way. >> Hypothetical examples aren't too interesting since we can also >> concoct such examples where the current "translate in >> self-insert-command" can be made to fail. > I didn't know that self-insert-command also uses > translation-table-for-input. I have thought that the > variable is for an input method as in this docstring: > Char table for translating self-inserting characters. > This is applied to the result of input methods, not their input. See also > `keyboard-translate-table'. > Anyway, could you show me such an example? Let's see: (insert (with-current-buffer foo (buffer-substring (point) (progn (call-interactively 'self-insert-command) (point))))) Yes, it's silly, Stefan ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Can't isearch 'ö' 2005-04-18 3:27 ` Stefan Monnier @ 2005-04-18 5:16 ` Kenichi Handa 2005-04-18 12:59 ` Stefan Monnier 0 siblings, 1 reply; 14+ messages in thread From: Kenichi Handa @ 2005-04-18 5:16 UTC (permalink / raw) Cc: Peter_Dyballa, emacs-devel, emacs-pretest-bug In article <877jj07owm.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes: >> No, I can't. But shouldn't we avoid such an incompatible >> change at this stage? > Can be. But since it's about a year now since we called a freeze and I see > no sign of getting to the pretest stage, I figure I don't understand enough > what "feature freeze" means: I just propose changes and I'll let someone > else decide whether they should be installed. > I think it's The Right Way to solve the problem, so that's what I use in my > local code, but if someone wants to write a "quick&safe" fix instead and use > that instead I see no problem with it. I'm still interested to know whether > I'm right or not in thinking that my fix is The Right Way. The very right way is to shift to emacs-unicode. As long as we have multiple character codes for characters that user don't want to distinguish, any fix is just a dirty work around. And, for the current case, I think the quick&safe work around is something like attached. Your patch may fix not only the current case but also the other cases, but may break some case. My patch fix only the current case and won't break the other case. >>> Hypothetical examples aren't too interesting since we can also >>> concoct such examples where the current "translate in >>> self-insert-command" can be made to fail. >> I didn't know that self-insert-command also uses >> translation-table-for-input. I have thought that the >> variable is for an input method as in this docstring: >> Char table for translating self-inserting characters. >> This is applied to the result of input methods, not their input. See also >> `keyboard-translate-table'. >> Anyway, could you show me such an example? > Let's see: > (insert (with-current-buffer foo > (buffer-substring (point) > (progn > (call-interactively 'self-insert-command) > (point))))) > Yes, it's silly, As it's too silly, we can't guess what is the right behaviour. Perhaps, the reason for using "foo" buffer is that the author wanted to translate a character in that buffer, then, the above does what expected. --- Ken'ichi HANDA handa@m17n.org *** isearch.el 21 Mar 2005 11:32:26 +0900 1.261 --- isearch.el 18 Apr 2005 13:34:38 +0900 *************** *** 1805,1810 **** --- 1805,1812 ---- (defun isearch-process-search-char (char) ;; Append the char to the search string, update the message and re-search. + (if (char-table-p translation-table-for-input) + (setq char (or (aref translation-table-for-input char) char))) (isearch-process-search-string (char-to-string char) (if (>= char ?\200) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Can't isearch 'ö' 2005-04-18 5:16 ` Kenichi Handa @ 2005-04-18 12:59 ` Stefan Monnier 2005-04-25 6:32 ` Kenichi Handa 0 siblings, 1 reply; 14+ messages in thread From: Stefan Monnier @ 2005-04-18 12:59 UTC (permalink / raw) Cc: Peter_Dyballa, emacs-devel, emacs-pretest-bug > The very right way is to shift to emacs-unicode. As long as > we have multiple character codes for characters that user > don't want to distinguish, any fix is just a dirty work > around. I'm not sure about "workaround" but it'll only ever be a heuristic. > Your patch may fix not only the current case but also the > other cases, but may break some case. My patch fix only the > current case and won't break the other case. Within the constraints of the non-unicode Emacs, it seems to be The Right Way in that it's a heuristic that fixes all the places where we've already had to introduce a fix, and I can't think of a place where it's going to break something. I.e. it's a much better heuristic than the one we currently have. Also it allows us to remove the heuristic code (in quail and self-insert-command, and soon in isearch) we've added at various other places, so it cleans up the code a bit. Since that code is not necessary in Emacs-unicode, it ends up bringing the two closer which I think is a good thing as well. I.e. it just feels Right. Stefan ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Can't isearch 'ö' 2005-04-18 12:59 ` Stefan Monnier @ 2005-04-25 6:32 ` Kenichi Handa 2005-04-26 10:06 ` Richard Stallman 0 siblings, 1 reply; 14+ messages in thread From: Kenichi Handa @ 2005-04-25 6:32 UTC (permalink / raw) Cc: Peter_Dyballa, emacs-pretest-bug, emacs-devel In article <87k6n05jo7.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes: >> The very right way is to shift to emacs-unicode. As long as >> we have multiple character codes for characters that user >> don't want to distinguish, any fix is just a dirty work >> around. > I'm not sure about "workaround" but it'll only ever be a heuristic. The current heuristic about translation-table-for-input is that: We translate a character to what matches buffer-file-coding-system of a buffer to which a user is going to insert that character. But you are going to extend that heuristic to: We translate a character event to what matches buffer-file-coding-system of the current buffer (regardless of how the character is going to be used). I basically agree that such an extension is good considering the current limitation of non-unicode Emacs. But, as we are in the stage of feature freeze, I think we should not do that unless there's no other way to fix a problem. And, for the current case, we do have another solution; fixing ispell.el. > Within the constraints of the non-unicode Emacs, it seems to be The Right > Way in that it's a heuristic that fixes all the places where we've already > had to introduce a fix, and I can't think of a place where it's going to > break something. With your change, what (read-char) returns will be different depending on buffer-file-coding-system. I don't know a single actual example, but one may bind a non-ASCII character to some command, or one may have his own input method that does something about typed non-ASCII character. Your change may break such cases. > I.e. it's a much better heuristic than the one we > currently have. Also it allows us to remove the heuristic code (in quail > and self-insert-command, and soon in isearch) we've added at various other > places, so it cleans up the code a bit. Since that code is not necessary in > Emacs-unicode, it ends up bringing the two closer which I think is a good > thing as well. I.e. it just feels Right. I don't oppose to that. Richard Stallman <rms@gnu.org> writes: > I didn't know that self-insert-cmmand also uses > translation-table-for-input. I have thought that the > variable is for an input method as in this docstring: > Perhaps the first step is to come up with a clearer statement of what > its job should be. From that, we should be able to decide easily > where it should or should not be used. At least the current statement is clear that it should not be used for translating in read-char. Char table for translating self-inserting characters. This is applied to the result of input methods, not their input. See also ^^^^^^^^^^^^^^^ `keyboard-translate-table'. Anyway, as far as I know, we are now discussing "what its job should be". We (me and Stefan) has already shown opinions and solutions to the problem. Richard, could you please decide what to do? --- Ken'ichi HANDA handa@m17n.org ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Can't isearch 'ö' 2005-04-25 6:32 ` Kenichi Handa @ 2005-04-26 10:06 ` Richard Stallman 2005-04-28 11:31 ` Kenichi Handa 0 siblings, 1 reply; 14+ messages in thread From: Richard Stallman @ 2005-04-26 10:06 UTC (permalink / raw) Cc: Peter_Dyballa, emacs-devel, emacs-pretest-bug We (me and Stefan) has already shown opinions and solutions to the problem. Richard, could you please decide what to do? I have not been reading these messages, because they were numerous and long. Now that there are two proposals, would you please show me the two proposals, each described clearly from scratch in one message? ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Can't isearch 'ö' 2005-04-26 10:06 ` Richard Stallman @ 2005-04-28 11:31 ` Kenichi Handa 2005-04-29 10:15 ` Richard Stallman 0 siblings, 1 reply; 14+ messages in thread From: Kenichi Handa @ 2005-04-28 11:31 UTC (permalink / raw) Cc: Peter_Dyballa, emacs-devel, monnier, emacs-pretest-bug In article <E1DQMxC-0001xK-Le@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes: > We (me and Stefan) has already shown opinions and solutions > to the problem. Richard, could you please decide what to > do? > I have not been reading these messages, because they were numerous and > long. Now that there are two proposals, would you please show me the > two proposals, each described clearly from scratch in one message? The original problem was that when a user have `ö' of iso-8859-15 in a buffer of iso-8859-15 coding system, he can't isearch that character by typing `ö' on his keyboard because that key is recognized as `ö' of iso-8859-1. Stefan's proposal is to translate a character by translation-table-for-input in read_char (). This is a generic solution, but it makes read_char () return different character depending on the buffer-file-coding-system of the current buffer, which may or may not cause anther problem. My proposal is to translate a character by translate-table-for-input in isearch-process-search-char. This is a limitted solution only for the current problem. --- Ken'ichi HANDA handa@m17n.org ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Can't isearch 'ö' 2005-04-28 11:31 ` Kenichi Handa @ 2005-04-29 10:15 ` Richard Stallman 2005-04-30 2:25 ` Luc Teirlinck 0 siblings, 1 reply; 14+ messages in thread From: Richard Stallman @ 2005-04-29 10:15 UTC (permalink / raw) Cc: Peter_Dyballa, monnier, emacs-pretest-bug, emacs-devel Stefan's proposal is to translate a character by translation-table-for-input in read_char (). This is a generic solution, but it makes read_char () return different character depending on the buffer-file-coding-system of the current buffer, which may or may not cause anther problem. My proposal is to translate a character by translate-table-for-input in isearch-process-search-char. This is a limitted solution only for the current problem. Suppose we use the latter solution. We probably would want to use it in other places as well, but which ones? Can you suggest a rule for programmers to decide whether to translate the result from read-char thru translate-table-for-input, and when not to? Could you look thru the calls to read-char in Emacs, and see which ones clearly should do this translation, which ones clearly should not, and which ones would work right either with or without the translation? ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Can't isearch 'ö' 2005-04-29 10:15 ` Richard Stallman @ 2005-04-30 2:25 ` Luc Teirlinck 2005-05-01 20:33 ` Stefan Monnier 2005-05-02 0:29 ` Kenichi Handa 0 siblings, 2 replies; 14+ messages in thread From: Luc Teirlinck @ 2005-04-30 2:25 UTC (permalink / raw) Cc: Peter_Dyballa, emacs-devel, emacs-pretest-bug, handa There is something that has not been pointed out in the summary Handa gave, but which I believe may be relevant. If I understood correctly, the problem in question will automatically completely disappear with Unicode and hence with Emacs 23. (Unless I misunderstood.) Sincerely, Luc. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Can't isearch 'ö' 2005-04-30 2:25 ` Luc Teirlinck @ 2005-05-01 20:33 ` Stefan Monnier 2005-05-02 0:29 ` Kenichi Handa 1 sibling, 0 replies; 14+ messages in thread From: Stefan Monnier @ 2005-05-01 20:33 UTC (permalink / raw) Cc: Peter_Dyballa, handa, rms, emacs-pretest-bug, emacs-devel > There is something that has not been pointed out in the summary Handa > gave, but which I believe may be relevant. If I understood correctly, > the problem in question will automatically completely disappear with > Unicode and hence with Emacs 23. (Unless I misunderstood.) Indeed, Stefan ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Can't isearch 'ö' 2005-04-30 2:25 ` Luc Teirlinck 2005-05-01 20:33 ` Stefan Monnier @ 2005-05-02 0:29 ` Kenichi Handa 1 sibling, 0 replies; 14+ messages in thread From: Kenichi Handa @ 2005-05-02 0:29 UTC (permalink / raw) Cc: Peter_Dyballa, emacs-devel, emacs-pretest-bug In article <200504300225.j3U2P9M18132@raven.dms.auburn.edu>, Luc Teirlinck <teirllm@dms.auburn.edu> writes: > There is something that has not been pointed out in the summary Handa > gave, but which I believe may be relevant. If I understood correctly, > the problem in question will automatically completely disappear with > Unicode and hence with Emacs 23. Yes. --- Ken'ichi HANDA handa@m17n.org ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Re: Can't isearch 'ö' 2005-04-18 2:52 ` Kenichi Handa 2005-04-18 3:27 ` Stefan Monnier @ 2005-04-18 21:05 ` Richard Stallman 1 sibling, 0 replies; 14+ messages in thread From: Richard Stallman @ 2005-04-18 21:05 UTC (permalink / raw) Cc: Peter_Dyballa, emacs-devel, emacs-pretest-bug I didn't know that self-insert-cmmand also uses translation-table-for-input. I have thought that the variable is for an input method as in this docstring: Perhaps the first step is to come up with a clearer statement of what its job should be. From that, we should be able to decide easily where it should or should not be used. ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2005-05-02 0:29 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <ea747b3b2d97aa98d6f831fd50b24adf@Web.DE> [not found] ` <m18y3qitbv.fsf-monnier+emacs@gnu.org> [not found] ` <296c27822efac3bf0271bf82f19ca485@Web.DE> [not found] ` <m1r7hih67o.fsf-monnier+emacs@gnu.org> [not found] ` <606b3ca39653eb6a62837e841402d5c8@Web.DE> [not found] ` <87fyxtxwku.fsf-monnier+emacs@gnu.org> 2005-04-14 23:42 ` Can't isearch 'ö' Kenichi Handa 2005-04-15 12:36 ` Stefan Monnier 2005-04-18 2:52 ` Kenichi Handa 2005-04-18 3:27 ` Stefan Monnier 2005-04-18 5:16 ` Kenichi Handa 2005-04-18 12:59 ` Stefan Monnier 2005-04-25 6:32 ` Kenichi Handa 2005-04-26 10:06 ` Richard Stallman 2005-04-28 11:31 ` Kenichi Handa 2005-04-29 10:15 ` Richard Stallman 2005-04-30 2:25 ` Luc Teirlinck 2005-05-01 20:33 ` Stefan Monnier 2005-05-02 0:29 ` Kenichi Handa 2005-04-18 21:05 ` Richard Stallman
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.