Re: [PATCH] Unicode Lisp reader escapes.
Ar an seachtú lá déag de mí Meitheamh, scríobh Eli Zaretskii: > > > Is it to trigger an "Invalid character" message, or is something else > > > going on here? > > > > It doesn't actually trigger a message, it displays a character to be > > interpreted as ``the character couldn't be interpreted.'' > > But in my testing, I do see an "Invalid character" message. Yes. That’s because I yanked the wrong charset from charset.h when porting the code from XEmacs, and the attempt to create two-dimensional character in JISX0201 fails, as it should, since JISX0201 is a one-dimensional character set. The code as intended, doesn’t trigger the message. As it was written, to my discredit, it did. > Could you please show an example of using this new function to produce > this special ``character that couldn't be interpreted''? > > My feeling is that the syntax should be close in its behaviour to what the > > coding systems do, and when the coding systems see a code point that is > > valid but that they can't interpret, they trash the user's data. > > This function is not about coding systems, it's about character sets. This function is about transformation from an external format to the editor’s internal format. Which is a big part of what coding systems do. So some parallels in our approach is reasonable. > Coding systems already replace unsupported characters with `?' (other > applications behave like that as well), so perhaps we should use some > more conventional character here. > Does anyone have an opinion? Perhaps, indeed. -- Aidan Kehoe, http://www.parhasard.net/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
dired listing is case-sensitive on MS Windows
emacs -Q on MS Windows Dired a directory with both uppercase and lowercase file names. The uppercase names all appear before any lowercase names. MS Windows is case-insensitive for file and directory names, so Dired should respect that, by default: an alphabetic listing should pay no attention to letter case. In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600) of 2006-03-20 on W2ONE X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Id:/g/include' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Dired by name Minor modes in effect: encoded-kbd-mode: t tooltip-mode: t auto-compression-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t line-number-mode: t Recent input: C-x d c o n t r i Recent messages: (C:\Emacs-22-2006-03-20\bin\emacs.exe -q --no-site-file --debug-init C:\drews-lisp-20) Loading encoded-kb...done For information about the GNU Project and its goals, type C-h C-p. Loading dired... Loading regexp-opt...done Loading dired...done Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: dired listing is case-sensitive on MS Windows
> From: "Drew Adams" <[EMAIL PROTECTED]> > Date: Sun, 18 Jun 2006 12:38:36 -0700 > > Dired a directory with both uppercase and lowercase file names. The > uppercase names all appear before any lowercase names. MS Windows is > case-insensitive for file and directory names, so Dired should respect > that, by default: an alphabetic listing should pay no attention to > letter case. You have the `ls-lisp-ignore-case' option to get what you want (and `ls-lisp-dirs-first' if you are used to see the directories first, as in the Windows Explorer). As for changing the default, I disagree: I'm used to look for upper-case file names near the beginning of the directory listing, like they are on Unix. I don't want to change my habits depending on what OS I'm working. (And what to do on a Unix filesystem mounted via NFS or Samba?) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [PATCH] Unicode Lisp reader escapes.
> From: Aidan Kehoe <[EMAIL PROTECTED]> > Date: Sun, 18 Jun 2006 18:11:06 +0200 > Cc: emacs-pretest-bug@gnu.org, emacs-devel@gnu.org > > > Coding systems already replace unsupported characters with `?' (other > > applications behave like that as well), so perhaps we should use some > > more conventional character here. > > Does anyone have an opinion? > > Perhaps, indeed. Handa-san, could you please comment on this issue? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Delayed redisplay problem
Jorgen Schaefer <[EMAIL PROTECTED]> writes: > I'm sorry for the miserable bug report. I'll try to better myself > :-) Don't worry. Your report got us going in the right direction!! > It does fix all the reproducible problems I found, too. Thanks a > lot! Thanks for testing. -- 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
appt-display-format has bad Customize default and no value menu
I don't use appt.el anymore, but I ran across this while testing something else. emacs -Q M-x load-library appt M-x customize-variable appt-display-format The standard value is `ignore', and this is a mismatch (`ignore' is not a valid value). No value menu is available to pick a value. In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600) of 2006-03-20 on W2ONE X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Id:/g/include' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Custom Minor modes in effect: encoded-kbd-mode: t tooltip-mode: t auto-compression-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t line-number-mode: t Recent input: i s p l a y - f o r m a t d i s p l a y - d i a r M-x c u s t o m i z e - v a r i a b d i a p p t - d i s p l a y - f o Recent messages: Creating customization items ...done Resetting customization items...done Creating customization setup...done Making completion list... Creating customization items... Loading pp...done Creating customization items ...done Resetting customization items...done Creating customization setup...done Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
customize-variable RET tries to customize nil
emacs -Q M-x customize-variable RET Get customize buffer with this: Nil: Hide Value nil State: NO CUSTOMIZATION DATA; not intended to be customized. A simple error message would be better - there is no sense sending someone to Customize unless s?he can customize something. In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600) of 2006-03-20 on W2ONE X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Id:/g/include' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Custom Minor modes in effect: encoded-kbd-mode: t tooltip-mode: t auto-compression-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t line-number-mode: t Recent input: e v e n q M-x c u x s t o m i z e - v a r t e m p - b u f f e r - r e s i z q q M-x M-p w o r i e q M-x M-p pM-x c u s t o m i z e - v a r Recent messages: Making completion list... Creating customization items... Creating customization items ...done Resetting customization items...done Creating customization setup...done Creating customization items... Creating customization items ...done Resetting customization items...done Creating customization setup...done Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: dired listing is case-sensitive on MS Windows
> Dired a directory with both uppercase and lowercase file names. The > uppercase names all appear before any lowercase names. MS Windows is > case-insensitive for file and directory names, so Dired should respect > that, by default: an alphabetic listing should pay no attention to > letter case. You have the `ls-lisp-ignore-case' option to get what you want (and `ls-lisp-dirs-first' if you are used to see the directories first, as in the Windows Explorer). As for changing the default, I disagree: I'm used to look for upper-case file names near the beginning of the directory listing, like they are on Unix. I don't want to change my habits depending on what OS I'm working. (And what to do on a Unix filesystem mounted via NFS or Samba?) Well, we disagree about the default behavior. I don't care about this for my own use. I think that the default behavior for MS Windows users should be case-insensitive. People who have other habits (;-)) or special needs such as you describe can use `ls-lisp-ignore-case' to adjust. The default behavior on Windows should be geared to the average (even the novice) Windows user. That user will expect 1) directories first and 2) case insensitivity for names. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Customize value menu doesn't recognize mouse-2
emacs -Q M-x customize-variable ad-default-compilation-action Click mouse-2 on button Value Menu. The menu opens. Try to click mouse-2 on a menu item - the action is unrecognized. Mouse-2 can be used to click any links and buttons. However, if you use it to open the Value Menu, then you cannot also use it to choose an item in the menu. Mouse-2 should be usable for all actions, including choosing a menu item. More precisely, if a mouse button opens a menu, then it should also choose from it. If you don't want mouse-2 to choose from the menu, then it should not be able to open the menu either. I would prefer that mouse-2 be able to do both, but if it can do neither, then that is acceptable. In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600) of 2006-03-20 on W2ONE X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Id:/g/include' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Custom Minor modes in effect: encoded-kbd-mode: t tooltip-mode: t auto-compression-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t line-number-mode: t Recent input: s s SPC s ? h e SPC c a n SPC c u s t o m i z e SPC s o m e t h i n g . M-q C-c C-c y e s M-x c u s t o m i z e - a p r o o - o p . q C-x 0 C-v Recent messages: Creating customization items ...96% Loading whitespace...done Creating customization items ...98% [9 times] Loading winner...done Creating customization items ...99% [6 times] Loading xt-mouse...done Creating customization items ...done Resetting customization items...done Creating customization setup...done To install your edits, invoke [State] and choose the Set operation ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: dired listing is case-sensitive on MS Windows
> From: "Drew Adams" <[EMAIL PROTECTED]> > Date: Sun, 18 Jun 2006 13:11:05 -0700 > > I think that the default behavior for MS Windows users should be > case-insensitive. People who have other habits (;-)) or special needs such > as you describe can use `ls-lisp-ignore-case' to adjust. When this came up here, most Windows users on this list disagreed with you. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
default-frame-alist apparently overriding font from minibuffer-frame-alist
> Please describe exactly what actions triggered the bug and the precise symptoms of the bug: Dear Emacs maintainers and/or Mr. Zenitani, Here is the entire contents of my .emacs file: (setq minibuffer-frame-alist '((font . "-apple-arial-medium-r-normal--18-*-*-*-*-*-mac- roman")) ) (setq default-frame-alist '((minibuffer) ;;; BUG: 22.0.50.1 Carbon Emacs Package 20060617 following line ;;; overrides value in minibuffer-frame-alist (font . "-apple-courier-medium-r-normal--13-*-*-*-*-*-mac-roman") ) ) If I start up emacs reading this .emacs file, it creates a separate main frame and minibuffer frame, as expected, but the font in *both* windows is courier. I believe that is a bug, as the Emacs internal documentation on the variable "minibuffer-frame-alist" explicitly states that: Parameters specified here supersede the values given in `default-frame-alist', for a minibuffer frame. Note that I need not take any action in the emacs after it starts up to observe the issue, as there is a remaining log message in the minibuffer, so the font it's using is directly observable. If on the other hand, I comment out the line with containing "courier" in the .emacs file and restart emacs, the minibuffer comes up with the arial font, as expected, and the main frame comes up with some system default font. I can fix that first window with initial- frame-alist without disturbing the minibuffer, but then subsequent frames I create have the ugly system font. I am using the latest test build of the Carbon Emacs package, based on Gnu Emacs 22.0.50 CVS dated 20060607, available on the web at http://homepage.mac.com/zenitani/emacs-e.html I also observed the bug in exactly the same way on the version of Emacs available via the "Fink" system on Mac OS X as of a few weeks ago. My apologies if this is a repeat posting of the bug, but I could not find any way to search open pretest bug reports. Sincerely yours, Glen Whitney - Following automatically generated by report-emacs-bug - If emacs crashed, and you have the emacs process in the gdb debugger, please include the output from the following gdb commands: `bt full' and `xbacktrace'. If you would like to further debug the crash, please read the file /MoreApps/Emacs.app/Contents/Resources/etc/DEBUG for instructions. In GNU Emacs 22.0.50.1 (powerpc-apple-darwin8.6.0) of 2006-06-16 on mini.local X server distributor `Apple Computers', version 10.4.6 configured using `configure '--prefix=/Applications/Emacs.app/ Contents/Resources' '--with-carbon' '--without-x' '--libexecdir=/ Volumes/Emacs/Emacs.app/Contents/MacOS/libexec' 'CFLAGS=-arch i386 - arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk -DUSE_ATSUI - DUSE_MAC_TSM'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: nil locale-coding-system: iso-8859-1 default-enable-multibyte-characters: t Major mode: Info Minor modes in effect: encoded-kbd-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: C-h p C-x 0 C-h C-h C-s b u g C-h C-h C-s C-h C-h C-x b * h e SPC H C-s b u g C-s C-h i C-s e m a C-s C-s C-s C-a m C-s b u g C-s m C-g M-x r e p o r t - e m a c s - b u g Recent messages: Loading encoded-kb...done Loading finder...done RET = select, = select, d = to finder directory, q = quit, ? = help Loading help-mode...done Mark saved where search started Loading info...done Composing main Info directory...done Mark saved where search started [3 times] Quit Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Weird interaction between `move-beginning-of-line', fields, and invisible overlays
Hello! When using a prompt in a buffer with a field property, `move-beginning-of-line' will move to the end of the prompt, not the beginning of the line - unless the line before the field is made invisible by an overlay. To reproduce (tested in emacs -D -Q): (with-current-buffer (get-buffer-create "*Test*") (let ((inhibit-read-only t)) (erase-buffer)) (insert "At this prompt, `move-beginning-of-line' stays behind the prompt.\n" "This is the expected behavior.\n" (propertize "Bar> " 'field 'fnord 'read-only t 'rear-nonsticky t)) (insert "\n\nHere, it moves to the beginning the prompt.\n") (let ((beg (point))) (insert "Fnord!\n") (let ((o (make-overlay beg (point (overlay-put o 'invisible t))) (insert (propertize "Bar> " 'field 'fnord 'read-only t 'rear-nonsticky t)) (switch-to-buffer "*Test*") (goto-char (point-max))) Regards, -- Jorgen -- ((email . "[EMAIL PROTECTED]") (www . "http://www.forcix.cx/";) (gpg . "1024D/028AF63C") (irc . "nick forcer on IRCnet")) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: dired listing is case-sensitive on MS Windows
> I think that the default behavior for MS Windows users should be > case-insensitive. People who have other habits (;-)) or > special needs such as you describe can use `ls-lisp-ignore-case' > to adjust. When this came up here, most Windows users on this list disagreed with you. That doesn't make them right. Default values should be those expected by users, including novices - those values most appropriate to users who will not think to customize Emacs. People "on this list" (pretest-bug?) can customize to get the values they prefer - myself included. We are not representative of the average Emacs user on Windows, let alone new Windows users. If, as on Windows, no distinction is made between file names FOOBAR and foobar, then why should the former be way near the top of the dired listing and the latter be way near the bottom? Why should fooBar2 come before foobar1? If you are unsure of the letter case (irrelevant to Windows, anyway), then you must _search_ to find a file, instead of just picking it out alphabetically. "I'm used to look for upper-case file names near the beginning of the directory listing, like they are on Unix." People who work with Dired listings that way on Windows must have some special consideration in mind. That is not the way people are used to working with file listings in Windows (e.g. Windows Explorer). Windows users are used to looking for file names in alphabetic order, without distinction of letter case. Why look for a file in multiple places, depending on the case of its name? FOOBAR, Foobar, and foobar are the same thing (a priori) to Windows. That said, this is not a new bug - the same behavior is in Emacs 20, alas. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: appt-display-format has bad Customize default and no value menu
"Drew Adams" wrote: > M-x customize-variable appt-display-format > > The standard value is `ignore', and this is a mismatch (`ignore' is > not a valid value). This is by design. ignore is a special value, meaning fall back on the previous (now obsolete) way of doing it, which used different variables. The available customize values represent the new way of doing it. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: appt-display-format has bad Customize default and no value menu
> M-x customize-variable appt-display-format > > The standard value is `ignore', and this is a mismatch (`ignore' is > not a valid value). This is by design. ignore is a special value, meaning fall back on the previous (now obsolete) way of doing it, which used different variables. The available customize values represent the new way of doing it. Sorry, I don't understand. How is a user supposed to use this or understand it? Should users not try to customize this option? If they shouldn't, then we should not enable customization for this variable at all. If they should, then how do they do so? If something about this has been deprecated, shouldn't the user be informed of that in Customize? If the default value causes Customize to somehow fall back to something that is obsolete, isn't that a bug? Why should the default behavior call upon something that is obsolete? Sorry, I really don't understand what you are saying. Looking at the doc string, presumably there should be a Value Menu that lets you choose (only) valid values. There is no such menu. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: customize-variable RET tries to customize nil
I don't claim that this *should* be the case, but we *might* want to make the default (i.e. empty input) customize all variables. That would consistent with what customize-face does. In any case, users should not see a Customize buffer for nil. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: appt-display-format has bad Customize default and no value menu
Sorry, I did not read carefully enough the first time. I see custom barfs if I have a default value which is not in the allowed value list. I guess I will have to add 'ignore to the allowed value list. I wanted to avoid this because I specifically wanted people to have to choose any of the other settings when they customized this variable. Maybe I'm going about this wrong... ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: dired listing is case-sensitive on MS Windows
> From: "Drew Adams" <[EMAIL PROTECTED]> > Date: Sun, 18 Jun 2006 14:34:49 -0700 > > > I think that the default behavior for MS Windows users should be > > case-insensitive. People who have other habits (;-)) or > > special needs such as you describe can use `ls-lisp-ignore-case' > > to adjust. > > When this came up here, most Windows users on this list disagreed with > you. > > That doesn't make them right. Maybe not, but people here and on emacs-devel do influence Emacs development. Anyway, we had this discussion almost exactly a year ago (in July 2005, to be exact). There really isn't anything to be said that wasn't already said then. Let's not waste any more time by reiterating the same arguments. > That said, this is not a new bug - the same behavior is in Emacs 20, alas. Also mentioned in past discussions: ls-lisp behaved like that since day one (which was in Emacs 19). Back then, we didn't have the customizable options we have today that can be used to get the Explorer-like behavior. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: appt-display-format has bad Customize default and no value menu
Sorry, I did not read carefully enough the first time. I see custom barfs if I have a default value which is not in the allowed value list. I guess I will have to add 'ignore to the allowed value list. I wanted to avoid this because I specifically wanted people to have to choose any of the other settings when they customized this variable. Maybe I'm going about this wrong... I don't understand the problem you tried to describe, so I can't offer any help with it. But whatever you do, there should be a Value Menu of possible values. Thx. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Random crashes
> On Fri, 16 Jun 2006 18:34:08 -0500, Pablo Barros <[EMAIL PROTECTED]> said: > Crashes randomly on MacOS X. Seems to be related to usage time; > works fine right after installation, then gets unstable after around > a week. I'm afraid the above information is not too useful for debugging. I think the "Reporting Bugs" section in Emacs info is good to read. > In GNU Emacs 22.0.50.1 (powerpc-apple-darwin8.5.0) of 2006-03-22 on > G5.local X server distributor `Apple Computers', version 10.4.6 > configured using `configure '--prefix=/Applications/Emacs.app/ > Contents/Resources' '--with-carbon' '--without-x' '--libexecdir=/ > Volumes/Emacs/Emacs.app/Contents/MacOS/libexec' 'CFLAGS=-arch i386 - > arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk -DUSE_ATSUI'' Are you using a "distribution" of precompiled Carbon Emacs? Then, please try the latest CVS if possible in order to rule out the possibility of: * The bug is already fixed (2006-03-22 is rather old.) * Some local changes in the "distribution" affect the unstableness. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [EMAIL PROTECTED]: Overlay string not displayed on text with `display' property]
> On Fri, 16 Jun 2006 13:52:47 +0200, [EMAIL PROTECTED] (Kim F. Storm) said: > Please continue testing!!! Yes, thanks. Here are two cases: * Case 1: The before-string is shown twice. ; emacs -Q -D (setq overlay (make-overlay 1 3)) (overlay-put overlay 'before-string (propertize "BE" 'face 'bold)) (overlay-put overlay 'after-string (propertize "AF" 'display (propertize "XY" 'face 'underline))) (put-text-property 1 3 'display (compose-string "DISP")) * Case 2: Cursor at a wrong position. ; emacs -q -D ;; not `-Q' in order to show a message in *scratch* (setq overlay (make-overlay 1 3)) (overlay-put overlay 'before-string (propertize "BEFORE_STRING" 'face 'bold)) (overlay-put overlay 'after-string (propertize "AF" 'display (propertize "XY" 'face 'underline))) (put-text-property 1 3 'invisible t) ;; make sure that the first line is wrapped M-< YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
