Re: customize Cua Rectangle Noselect Face error
Peter Dyballa [EMAIL PROTECTED] writes: Hello! When cutomizing this item, the background value changes indeed the foreground, i.e. the colour of the script sample, not its background. I have installed a fix. Please try again (after you have removed any customizations to cua related faces from your .emacs, and restarted emacs). -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Warnings
xrdb.c:92:1: warning: malloc redefined In file included from config.h:941, from xrdb.c:24: s/darwin.h:334:1: warning: this is the location of the previous definition xrdb.c:93:1: warning: realloc redefined s/darwin.h:335:1: warning: this is the location of the previous definition xrdb.c:94:1: warning: free redefined s/darwin.h:336:1: warning: this is the location of the previous definition regex.c: In function `re_search_2': regex.c:4294: warning: comparison is always true due to limited range of data type regex.c: In function `re_match_2_internal': regex.c:5248: warning: comparison is always true due to limited range of data type In article-display-x-face: gnus-art.el:2186:23:Warning: `process-kill-without-query' is an obsolete function (as of Emacs 22.1); use `process-query-on-exit-flag' or `set-process-query-on-exit-flag'. In mm-insert-file-contents: mm-util.el:898:10:Warning: `find-file-hooks' is an obsolete variable (as of Emacs 22.1); use `find-file-hook' instead. In GNU Emacs 22.0.50.1 (powerpc-apple-darwin7.8.0, X toolkit, Xaw3d scroll bars) of 2005-04-14 on Latsche.local Distributor `The XFree86 Project, Inc', version 11.0.4030 configured using `configure '--without-carbon' '--with-x' '--without-pop' '--with-xpm' '--with-jpeg' '--with-tiff' '--with-png' '--with-gif' '--with-x-toolkit=lucid' 'CFLAGS=-I/sw/include' 'CPPFLAGS=-I/sw/include' 'LDFLAGS=-L/sw/lib'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: de_DE.UTF-8 value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: de_DE.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Emacs-Lisp Minor modes in effect: desktop-save-mode: t auto-compression-mode: t display-time-mode: t mouse-sel-mode: t show-paren-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-decoding-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t next-error-follow-minor-mode: Fol -- Mit friedvollen Grüßen Pete Windows, c'est un peu comme le beaujolais nouveau: a chaque nouvelle cuvée on sait que ce sera dégueulasse, mais on en prend quand même, par masochisme. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: customize Cua Rectangle Noselect Face error
Am 14.04.2005 um 13:03 schrieb Kim F. Storm: Peter Dyballa [EMAIL PROTECTED] writes: Hello! When cutomizing this item, the background value changes indeed the foreground, i.e. the colour of the script sample, not its background. I have installed a fix. Could be that I am undestanding the customization of faces in a faulty way! I still see [X] Background: cyan (sample) and the word sample is cyan, i.e. the foreground, not the background, while only the header to this item is correct: Cua Rectangle Noselect Face face: (sample) Hide Face where sample's background is cyan. The other faces of the Cua Group show the same behaviour, appealing to one's imagination, so I have to confess that I made a mistake. Sorry for that! -- Greetings Pete We are usually convinced more easily by reasons we have found ourselves than by those which have occurred to others. (Blaise Pascal) ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: more key bindings for xterm
But it seems that X.org is now what most people seem to be converging to. So supporting these bindings should be helpful for a lot of users. I agree, but I think we should document the situation so people won't be puzzled when some things sometimes don't work. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Point of wrong window used in read-from-minibuffer?
If you try my example again: % emacs -Q [ type in some random text] C-x 2 [ move point elsewhere ] M-: (save-window-excursion (select-window (next-window))) RET you'll see that at the end the second window's point is being set to the value of the first window's point. I see what behavior you mean, but that is not the way to understand it. It doesn't concern the second window's point, or the first window's point, because neither of them is in use at the time in question. Before exit from the save-window-excursion, the first window's point is not in use, because it's the selected window. The current buffer's own value of point is the one that takes effect. After exit from the save-window-excursion, the second window is selected, so its point value is not in use. The current buffer's own value of point continues to be the one that takes effect. It happens that the current buffer's own value of point is unchanged through this process, because save-window-excursion is not supposed to restore that. It is supposed to leave that value alone, and it does. (Or rather, it did so before you made a change.) I agree that the current behavior is counterintuitive in this case. Perhaps a different behavior would be better. However, in order to consider a different behavior, we have to have a clear picture of it. What behavior does your patch result in? We need to be able to document it clearly and in general. Also, there's the possibility that this change will break some code. Some uses of save-window-excursion expect to do (goto-char ...) inside the save-window-excursion and have point still be at that place outside the save-window-excursion. That's the kind of case that this patch could break. Maybe there are no cases that in fact would break. Maybe the places that do that don't switch windows in a way that could cause trouble. But it leads me to ask: does putting (save-excursion ...) around the call to save-window-excursion fix the problem? ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Re: Can't isearch 'ö'
Am 14.04.2005 um 16:31 schrieb Stefan Monnier: Any objection/adjustment? In X11 in an ISO 8859-1 buffer it works to i-search (and find) for ... but: in an ISO 8859-2 buffer it fails to find (degree). The original is: character: (04260, 2224, 0x8b0, U+00B0) charset: latin-iso8859-1 (Right-Hand Part of Latin Alphabet 1 (ISO/IEC 8859-1): ISO-IR-100.) code point: 48 syntax: _ which means: symbol category: l:Latin buffer code: 0x81 0xB0 file code: 0xB0 (encoded by coding system iso-latin-2-unix) display: by this font (glyph code) -BH-LucidaTypewriter-Medium-R-Normal-Sans-10-100-75-75-M-60-ISO8859-1 (0xB0) One that I entered (after C-u M-: (read-event) RET): character: (04460, 2352, 0x930, U+00B0) charset: latin-iso8859-2 (Right-Hand Part of Latin Alphabet 2 (ISO/IEC 8859-2): ISO-IR-101.) code point: 48 syntax: _ which means: symbol category: l:Latin buffer code: 0x82 0xB0 file code: 0xB0 (encoded by coding system iso-latin-2-unix) display: by this font (glyph code) -BH-LucidaTypewriter-Medium-R-Normal-Sans-10-100-75-75-M-60-ISO8859-2 (0xB0) The read event is: 2224 (04260, 0x8b0). Similiar happening for , , , , ... Similiar for a buffer in ISO 8859-3, ISO 8859-4, ISO 8859-8, ISO 8859-9, ISO 8859-10, ISO 8859-11, ISO 8859-13, ISO 8859-14, ISO 8859-15, ISO 8859-16 ( and/or tested). In GNU Emacs 22.0.50.1 (powerpc-apple-darwin7.8.0, X toolkit, Xaw3d scroll bars) of 2005-04-14 on Latsche.local Distributor `The XFree86 Project, Inc', version 11.0.4030 configured using `configure '--without-carbon' '--with-x' '--without-pop' '--with-xpm' '--with-jpeg' '--with-tiff' '--with-png' '--with-gif' '--with-x-toolkit=lucid' 'CFLAGS=-I/sw/include' 'CPPFLAGS=-I/sw/include' 'LDFLAGS=-L/sw/lib'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: de_DE.UTF-8 value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: de_DE.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Text Minor modes in effect: desktop-save-mode: t auto-compression-mode: t display-time-mode: t mouse-sel-mode: t show-paren-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-decoding-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t next-error-follow-minor-mode: Fol view-mode: t -- Mit friedvollen Gren Pete Das Militr ist eine Pflanze, die mensch sorgfltig pflegen muss, damit sie keine Frchte trgt. (Jaques Tati) ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Re: Can't isearch 'ö'
Any objection/adjustment? In X11 in an ISO 8859-1 buffer it works to i-search (and find) for ä,ö,ü,Ñ,í ... but: in an ISO 8859-2 buffer it fails to find ° (degree). [... more cut ...] Sorry, you went too fast for me. Could you restate the problem with more details of what you did? To start with, please mention if you're using my patch and/or any other patch. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: more key bindings for xterm
Dan Nicolaescu [EMAIL PROTECTED] writes: Stefan Monnier [EMAIL PROTECTED] writes: In what xterm did you test these? I remember vaguely that I tried in the past to add more bindings to xterm.el, but abandoned the idea after I discovered that different flavors of Unix had xterm's that used incompatible bindings. Luckily, tho the bindings are sometimes different, they rarely conflict. I'm not sure. I think, at the time, I did find conflicts. We can deal with them when we find them. As I said, those bindings are weak and overridden by anything, so they can't be much worse than no binding at all. Actually, it seems that when I was testing this patch I had an incomplete terminfo entry in ~/.terminfo that seems to be picked up by default on GNU/Linux (without setting the TERMINFO environment variable). This affects all the mappings involving the F1-12 keys. (the strings are correct, but the keys don't work as expected). It seems that any MODIFIER-F_KEY emits a string that is defined in one terminfo entry kf13-kf63. So given that key definitions in xterm.el don't have priority Emacs does not see them and it reports an undefined key. For example for C-f5 it says f29 undefined. I am not sure what is the best way to deal with these key bindings. Would it be acceptable to add something like: (substitute-key-definition [f29] [C-f5] function-key-map) to xterm.el? There probably is a better way to create the MODIFIER-F_KEY bindings, but I am not aware of it. Can somebody help please? Thanks --dan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: more key bindings for xterm
Would it be acceptable to add something like: (substitute-key-definition [f29] [C-f5] function-key-map) to xterm.el? Would it work? I thought the translation from esc-sequence to f29 is already done by function-key-map (with elements added by reading the terminfo data) and you function-key-map is not iterated, so once we get f29 we don't look at function-key-map again. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: more key bindings for xterm
Stefan Monnier [EMAIL PROTECTED] writes: Would it be acceptable to add something like: (substitute-key-definition [f29] [C-f5] function-key-map) to xterm.el? Would it work? It does, I tested it. I thought the translation from esc-sequence to f29 is already done by function-key-map (with elements added by reading the terminfo data) and you function-key-map is not iterated, so once we get f29 we don't look at function-key-map again. I don't know... ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Can't isearch 'ö'
In article [EMAIL PROTECTED], Stefan Monnier [EMAIL PROTECTED] 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 [EMAIL PROTECTED] ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: two imenu entries for same function in C-mode
On GNU Emacs 22.0.50.1 (i386-mingw-windows98.3000) of 2005-04-11 imenu creates _two_ entries for, say static void describe_abbrev (sym, stream) Lisp_Object sym, stream; I can't reproduce this. Would you please give a complete test case, saying exactly what to type so as to observe the bug? ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: C-h k is overly verbose/wrong for some menu bindings
This has now been fixed to say menu-bar edit select-paste (any string) Wouldn't it be clearer to say menu-bar edit select-paste any string This shows that the any string part is part of the sequence. Not necessarily. It could also lead people to think it refers to a menu item named `any string'. I chose parens to avoid that possible misunderstanding. Perhaps an added space after (any string) would make it clearer. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
