Re: Issue with rx: (rx (and anything anything)) seems incorrect
Nick Alexander wrote: In GNU Emacs 22.0.95.1 (powerpc-apple-darwin8.9.0, Carbon Version 1.6.0) of 2007-03-15 on g5.tokyo.stp.isas.jaxa.jp Windowing system distributor `Apple Inc.', version 10.4.9 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'' Hi all, The following is expected: (rx (and ?a ?b)) = \\(?:ab\\) The following is not: (rx (and anything anything)) = \\(?:.\\| .\\| \\) I have no idea why the newlines are inserted, nor why there are choice bars (|). Why not just \\(?:..\\) as before? I think that . does not match newline. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: key binding of `M-' shows up in menu as (M-)
Eli Zaretskii wrote: Date: Fri, 15 Jun 2007 21:43:08 +0200 From: Lennart Borgman (gmail) [EMAIL PROTECTED] Cc: Emacs-Pretest-Bug emacs-pretest-bug@gnu.org Drew Adams wrote: I think this is specific to w32. Yes needs to be escaped there. I hope you mean that Emacs or Emacs W32 should do the escaping. These binding indications are added automatically. I am not sure I understand you, but is the character you put before a character in the menu string on w32 to mark that character as an accelerator in menu. (It will be shown underlined then.) An example: Help will show Help in the menu with H underlined. So fixing this is a w32 specific problem. I think I fixed this in CVS (trunk and branch); please try. Btw, there's a much easier way to demonstrate the bug: just create a buffer called, say, foobar, then click Buffers from the menu bar. Unfortunately I do not think that is the right change. This totally spoils the possibility to use accelerators for the menus on w32. I do not think the minor problem it solves justifies that. I think the change should be reverted and added back later when it is clear how menu accelerators should be supported in Emacs. Maybe this is the time to add a new field to _widget_value for this? The reasonable value is in my opinion the position for the accelerator within *name. Then of course something with a name like :accpos could be added for use with (menu-item ...) when definining menus. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: key binding of `M-' shows up in menu as (M-)
Drew Adams wrote: emacs -Q Bind a command `foo' in a minibuffer completion map to `M-'. Add `foo' to the Minibuf menu: (define-key map [menu-bar minibuf foo] '(menu-item Foo It foo)) In the Minibuf menu, the item appears with the wrong binding: Foo It (M-) The `' was removed - it should show (M-). Perhaps the `' needs to be automatically escaped? In GNU Emacs 22.1.50.1 (i386-mingw-nt5.1.2600) of 2007-05-22 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' I think this is specific to w32. Yes needs to be escaped there. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: key binding of `M-' shows up in menu as (M-)
Drew Adams wrote: I think this is specific to w32. Yes needs to be escaped there. I hope you mean that Emacs or Emacs W32 should do the escaping. These binding indications are added automatically. I am not sure I understand you, but is the character you put before a character in the menu string on w32 to mark that character as an accelerator in menu. (It will be shown underlined then.) An example: Help will show Help in the menu with H underlined. So fixing this is a w32 specific problem. We discussed a little bit before adding the possibility to use accelerators in the menus. Perhaps this should be fixed when that is done to avoid splitting the code to much? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: key binding of `M-' shows up in menu as (M-)
Drew Adams wrote: I think this is specific to w32. Yes needs to be escaped there. I hope you mean that Emacs or Emacs W32 should do the escaping. These binding indications are added automatically. I am not sure I understand you, but is the character you put before a character in the menu string on w32 to mark that character as an accelerator in menu. (It will be shown underlined then.) An example: Help will show Help in the menu with H underlined. So fixing this is a w32 specific problem. We discussed a little bit before adding the possibility to use accelerators in the menus. Perhaps this should be fixed when that is done to avoid splitting the code to much? The key-binding indication, e.g. (`C-x C-f') or (`M-'), is added automatically by Emacs. This is not text that I added as a user (e.g. using :keys). So the problem needs to be fixed at the program level (Emacs W32 or Emacs), not at the user level. That's all I am saying. Yes, that is what I tried to say too ;-) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Dired sorting case sensitive on w32
Dired sorts the file case sensitive on w32. I do not think that is what users on w32 expects since file names are case insensitive on w32 (except for the display of the names). In GNU Emacs 22.0.990.1 (i386-mingw-nt5.1.2600) of 2007-05-31 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Elisp manual doc on `intangible' is incomplete
Drew Adams wrote: Elisp manual node Special Properties says this about `intangible': If a group of consecutive characters have equal and non-`nil' `intangible' properties, then you cannot place point between them. If you try to move point forward into the group, point actually moves to the end of the group. If you try to move point backward into the group, point actually moves to the start of the group. When the variable `inhibit-point-motion-hooks' is non-`nil', the `intangible' property is ignored. It does not say anything about what the meaning or behavior is if consecutive characters have unequal but non-nil `intangible' values. Why the qualification of having equal values? What is a user to understand about this? Is it not a corallary that the values does not have to be equal? Even consecutive characters with non-nil, but unequal values will form a group behaving the same way. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [h-e-w] EmacsW32: ange-ftp to Tru64 hangs on write.
Thanks Nelson, I am not sure whether this is a bug or not, but I am forwarding this to the pretest bug list so others who knows more about this can decide what to do. To emacs-pretest-bug readers: Is this a bug, or? Is there some setting that can generally be used to avoid this problem? Nelson E. Ingersoll wrote: FWIW - I figured out what's going on, though not entirely why. And I do have a work-around. The problem is that the FTP client is sending the file as BINARY'. Binary data, AFAIK, is sent in 512 byte chunks. A text file rarely ends on a 512 byte boundary. When the text file is sent as BINARY the far end Tru-64 system hangs waiting for the chunk to finish. It doesn't finish. Ultimately the Tru64 FTP daemon gets tired of waiting and times out... unless the user aborts the transmission before using the CTRL-G key in Emacs. All behaviors are explained. And I didn't have to fall back on Intelligent Design either! 9-) I'm not sure exactly why; but the Coding system for the file being read from Tru64 is set to UNIX. When writing back the FTP client, guessing here, tells the Tru64 FTP daemon that the UNIX coded file is BINARY. However, if before transmitting the file I change the Coding system to DOS using the set-buffer-file-coding-system function, the transmission get set correctly to ASCII and the transmission works. I'm looking into how to automatically have Emacs set the Coding system to DOS by default. Was something changed in a recent release of either Emacs or EmacsW32? The problem exists, as outlined in the initial report, almost all the way back to the original version of Ange-FTP. It exists regardless of which FTP client (EmacsW32 or Windows) is used. It exists regardless of patched or unpatched EmacsW32. The only version I couldn't replicate the problem in is the GNU 21.3 Emacs for NT. I must have had the older Ange-FTP somewhere in my load-path and then deleted it. Don't remember doing this; but facts can be ugly things when they get in your face. Regardless, problem resolved. Emacs is truly a many splint'ored program! (Sorry Barbara!) Lovely and dangerous at the same time. - Nelson Nelson E. Ingersoll wrote: I'm having a problem with the Tramp/Ange-FTP which comets with Emacs32 20070501 (patched and unpatched). I have set the variable tramp-default-method to ftp so that I am forcing the use of ange-ftp. Tramp plays even less well with Tru64. When I connect to a Tru64 4.0d system, running it's FTP server Digital UNIX Version 5.60 everything appears to work fine. However, when I save my work the save hangs for a long time. The file is written successfully almost immediately; however, Emacs hangs and the modification flag in the status bar at the bottom does not change from *'s to dashes. The hang will clear successfully after, literally, a minute or two. A CTRL-G will also clear the hang, though the status bar and buffer write-status remain set as changed, not saved. I can use the exact same setup and perform the exact same action to log onto, modify, and save a file to Linux or Sun systems without any obvious trouble. Therefore, it appears to be something to do with Tru64's FTP server. An old version of ange-ftp (1.14?) does NOT have this problem. However, it does have trouble working with Tramp and can't perform a simple filename completion because of changes to the code. Has anyone else experienced a similar problem using EmacsW32 ange-ftp with Tru64's FTP? If so, did you fix it? - Nelson EmacsW32: GNU Emacs 22.0.99.1 (i386-mingw-nt5.1.2600) of 2007-05-01 on LENNART-69DE564 (patched) unpatched. Tramp:2.0.55 ftp: Both gnuwin32 ftp.exe and C:\windows\system32\ftp.exe ftpd: FTP server (Digital UNIX Version 5.60) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: M-x dired //server/sharename crashes emacs
Rainer Stengele wrote: David Kastrup schrieb: Rainer Stengele [EMAIL PROTECTED] writes: Hi. M-x dired //server/sharename crashes my emacs w32 repeatable. Emacs asks to attach the gdb debugger but that doesn't really help. The crash happens independently of having the share on a linux server or a windows server/pc GNU Emacs 22.0.99.1 (i386-mingw-nt5.1.2600) of 2007-05-01 on LENNART-69DE564 (patched) Can anybody reproduce this behavior and maybe fix it or help workaround it? Have you tried the _unpatched_ version? yes, just tried the unpatched version GNU Emacs 22.1.50.1 (i386-mingw-nt5.1.2600) of 2007-05-01 on LENNART-69DE564 same result. emacs crashes immediately after dired //felix/C This should go to emacs-pretest-bug@gnu.org so I forwarded it there. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Some libraries does (require 'cl)
Richard Stallman wrote: It seems to me that idlwave.el loads cl only at compile time. Why do you think otherwise? Yes, there is a second (require 'cl) on line 4157. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Some libraries does (require 'cl)
Lennart Borgman (gmail) wrote: Some libraries (iswitchb.el for example) does (require 'cl) without (eval-when-compile ...). Is not that incorrect? In GNU Emacs 22.1.50.1 (i386-mingw-nt5.1.2600) of 2007-05-06 More files doing this: lucid.el viper.el gnus-registry.el spam-stat.el mh-acros.el (in the macro mh-require-cl too) eudc.el tramp.el Maybe cc-lang.el? idlwave.el ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: no device event controller found
Gary Lawrence Murphy wrote: Please write in English if possible, because the Emacs maintainers usually do not have translators to read other languages for them. Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list. Please describe exactly what actions triggered the bug and the precise symptoms of the bug: This is new with the emacs that I built from the CVS sources a few days ago, I think it may be related to the gnus agent doing background polling of the IMAP host, but I periodically get the following message in the console window: ** (emacs-22-1-50:2180): WARNING **: failure: no device event controller found. In GNU Emacs 22.1.50.1 (i686-pc-linux-gnu, GTK+ Version 2.10.3) of 2007-04-30 on maya.teledyn.com I know nothing about the problem, but your version number looks suspect if you built this just a few days ago. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
iswitchb-mode matches too match
It looks to me like iswitchb-mode matches too much. To show this do emacs -Q Then find some files beginning with m and n. Now do M-x iswitchb-mode C-x b m For me that matches both buffers beginning with m and n. In GNU Emacs 22.1.50.1 (i386-mingw-nt5.1.2600) of 2007-05-06 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Some libraries does (require 'cl)
Richard Stallman wrote: Some libraries (iswitchb.el for example) does (require 'cl) without (eval-when-compile ...). Is not that incorrect? It is incorrect, in general. However, in the case of iswitchb, it is a no-op: ;; CL needed for cadr and last (if (not (and (fboundp 'cadr) (fboundp 'last))) (require 'cl)) The current Emacs has `cadr' and `last' as primitives, so cl will never be loaded. There are some more in a comment I made to this in another message. However there is one thing I do not understand and that other people have asked: If one want to use functions from cl.el (not only macros), how does one do then? Is (eval-when-compile (require 'cl)) sufficient then? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
Juanma Barranquero wrote: On 5/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: Sorry, I was using -n too, forgot that. With -n you do not see the error anywhere. That's what I would expect. You're saying to emacsclient to no expect any answer, after all. You can always do: emacsclient -n -e (condition-case nil (my-bad-fun) (error (raise-frame) (backtrace))) or something like that if you want to see errors in the server. Would it not be easier if you get a normal backtrace if debug-on-error is t? Something like this can be used in server.el, server-process-filter: (if eval (let* (errorp (v (if debug-on-error (eval (car (read-from-string arg))) (condition-case errobj (eval (car (read-from-string arg))) (error (setq errorp t) errobj) (when v (with-temp-buffer (let ((standard-output (current-buffer))) (when errorp (princ error: )) (pp v) (ignore-errors (process-send-region proc (point-min) (point-max))) I have just added the (if debug-on-error ...) here. Maybe there should be another, server specific variable too so that one can have debug-on-error t without getting a backtrace for this case. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
Juanma Barranquero wrote: On 5/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: Would it not be easier if you get a normal backtrace if debug-on-error is t? Perhaps. OTOH, it is an error in an emacsclient-sent string to evaluate an Error *in* Emacs? Eh, you lost me on this one ;-) -- I do not understand the context. Can you please explain? Something like this can be used in server.el, server-process-filter: Can you please send it as a patch? Otherwise it's kind of difficult to see what's changing. It is not much, just two or three new lines actually. (The line numbers below are not correct.) *** c:/DOCUME~1/LENNAR~1/LOCALS~1/Temp/ediff972RQU 2007-05-16 13:55:37.203125000 +0200 --- c:/emacs/p/070515/emacs/lisp/server.el 2007-05-16 13:32:13.328125000 +0200 *** *** 469,477 (setq arg (decode-coding-string arg coding-system))) (if eval (let* (errorp ! (v (condition-case errobj (eval (car (read-from-string arg))) ! (error (setq errorp t) errobj (when v (with-temp-buffer (let ((standard-output (current-buffer))) --- 482,493 (setq arg (decode-coding-string arg coding-system))) (if eval (let* (errorp ! (v ! (if debug-on-error ! (eval (car (read-from-string arg))) !(condition-case errobj (eval (car (read-from-string arg))) ! (error (setq errorp t) errobj) (when v (with-temp-buffer (let ((standard-output (current-buffer))) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
Juanma Barranquero wrote: On 5/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: Eh, you lost me on this one ;-) -- I do not understand the context. Can you please explain? Why would emacsclient --eval BIG-MISTAKE cause a traceback on Emacs, even if debug-on-error is t? It already shows an error on the output of emacsclient. Two reasons: - It is not necessarily emacsclient -e BIG-COMMAND-LINE-MISTAKE, it could equally well be somewhere in the elisp libraries. - If you use -n you will see nothing as it is now. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
Juanma Barranquero wrote: On 5/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: - It is not necessarily emacsclient -e BIG-COMMAND-LINE-MISTAKE, it could equally well be somewhere in the elisp libraries. Fair enough, though if you set debug-on-error to debug the problem, it will happen also if you evaluate the code from inside Emacs (as opposed to from emacsclient). Some errors are very hard to track down. I think it can help very much to be able to directly debug what happens when the call is from emacsclient. - If you use -n you will see nothing as it is now. That's no reason, I think. If you're worried about errors, don't use -n. It might not be the right thing to do in all cases. BTW, does emacsclient exit with an error when there is an error evaluating the code that is sent from emacsclient? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
Juanma Barranquero wrote: Perhaps you're right, but I'd like to see some examples of things that are much easier to debug from --eval than directly. I have no examples at hand, but the context where the functions are running is slightly different when they are called from emacsclient. Is not that enough? It might not be the right thing to do in all cases. No. But if it is normal operation for your emacsclient invocation to fail sometimes, it'd be sensible to *not* use -n and read emacsclient's stderr output and exit code; and if it is not normal, the moment you detect a problem you can remove the -n and try again. Sure, but see above. This is not to say that I oppose the feature; I just don't feel it compelling right now (but I can be easily convinced :) I am glad to read that ;-) BTW, does emacsclient exit with an error when there is an error evaluating the code that is sent from emacsclient? Not currently, no. It returns an error for any trouble communicating with Emacs, not because of what happens to the info exchanged between them. Then could it not easily happen that the source of the problem is not detected? Is not that an argument for beeing able to get a traceback the way I suggested? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
Juanma Barranquero wrote: On 5/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: the context where the functions are running is slightly different when they are called from emacsclient. Is not that enough? I'm not sure. On one hand, if there's no trouble, there's no need to complicate things. On the other, yeah, the context is slightly The complication seems very minor as I see it. I am glad to read that ;-) Eh, so long as you're also ready to be easily convinced... Maybe the hardest thing is to convince me I am not easy to convince ... ;-) That depends of what you're doing with emacsclient -n --eval. I'd expect the user (or client program) to detect that nothing is happening :) I looked at the problem just because Klaus Z was doing something in the background from emacsclient. Perhaps. All this is in the purely hypothetical realm right now. Yes, probably. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
Juanma Barranquero wrote: On 5/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: The complication seems very minor as I see it. Sure. That's why real examples will easily win the day. Yes, the important thing is of course that there is a way to make it easy to debug then. If such cases shows up my little patch can be used. Maybe the hardest thing is to convince me I am not easy to convince ... ;-) Hummm... I've thought past threads were a convincing example ;-) I hope for the best, we will see. Life is a long learning experience. :-) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Debug on error and Emacs client
It seems like errors are not handled as I expect them too when using Emacs client. If I do something like emacsclient -e (my-bad-fun) where my-bad-fun is not defined or contains an error I see no backtrace even if debug-on-error is t. In fact I see nothing. In GNU Emacs 22.1.50.1 (i386-mingw-nt5.1.2600) of 2007-05-06 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
Juanma Barranquero wrote: On 5/15/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: If I do something like emacsclient -e (my-bad-fun) where my-bad-fun is not defined or contains an error I see no backtrace even if debug-on-error is t. In fact I see nothing. C:\ emacsclient -e (my-bad-fun) error: (void-function my-bad-fun) Sorry, I was using -n too, forgot that. With -n you do not see the error anywhere. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: show-paren-mode and browse customizations
Richard Stallman wrote: If show-paren-mode is turned on I see a strange visual distortion in *Customize Browser*, see attached image. I looked at it, but I don't see the problem. The highlighted parens characters are broader than the non-highlighted. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
show-paren-mode and browse customizations
If show-paren-mode is turned on I see a strange visual distortion in *Customize Browser*, see attached image. In GNU Emacs 22.1.50.1 (i386-mingw-nt5.1.2600) of 2007-05-06 inline: show-paren-mode-and-customize.png___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
compilation-finish-functions is not run as a hook
The variable compilation-finish-functions is said to be a hook. However using add-hook to make a local value results later in an error: (add-hook 'compilation-finish-functions 'my-fun nil t) This gives the hook variables the value '(my-fun t). compilation-handle-exit tries to run t as a function then. Should not run-hook-with-args be used there? BTW the doc string for run-hook-with-args does not mention the special handling of t. In GNU Emacs 22.1.50.1 (i386-mingw-nt5.1.2600) of 2007-05-06 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Maximization doesn't work properly on Windows Xp, Emacs 22.0.92.1
Eli Zaretskii wrote: Date: Sun, 06 May 2007 21:19:53 +0200 From: Lennart Borgman (gmail) [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org The reason for the problem is that the Emacs window (frame) is not really maximized on MS Windows. That's true, but I'm not sure it's relevant. Even if Emacs doesn't really maximize the frame, it does try to keep away of the parts of the screen taken by the task bar and the other standard decorations. That it doesn't always succeed means we have a subtle bug. To find and fix that bug, we need a reliable way of reproducing it. If Eivind or you can provide such a reliable recipe, we will be on our way towards fixing the bug. I thought of that in the beginning, but I believe Windows is beeing fooled by the way Emacs tries to make a semi-maximized window. It may be hard to cure it. I think it is better to wait for an OK to really maximize the window from Kim and others that are experts on the display engine. The semi-maximized windows have other subtle problems too. And indeed there are thousands of users who have had the possibilities to use the patch for really maximized windows, but I have no idea how many of those that are using maximized windows. It is hard to believe that no one has done it and there are no bug reports. Eh, or was it one person who had seen the same problem as I have seen? Not sure. (Of course it does not mean more than an indication that there are no big problems.) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Maximization doesn't work properly on Windows Xp, Emacs 22.0.92.1
Eli Zaretskii wrote: Date: Sun, 06 May 2007 22:40:52 +0200 From: Lennart Borgman (gmail) [EMAIL PROTECTED] CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org I believe Windows is beeing fooled by the way Emacs tries to make a semi-maximized window. How can Emacs fool Windows? All we do is create a window; if that window's size is too large, or it's positioned over the task bar, it's our bug. Ah, you are maybe right. It was quite a long time ago since I started using the patch so I do not remember exactly any more. I just remember that I was rather perplexed by the behaviour I saw. However Emacs somehow tells Windows that the window is maximized and that might create some problems since it actually is not maximized. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Maximization doesn't work properly on Windows Xp, Emacs 22.0.92.1
Jason Rumney wrote: Eivind Midtgård wrote: In GNU Emacs 22.0.92.1 (i386-mingw-nt5.1.2600) of 2007-01-01 on DTOP Please try the latest pretest before reporting bugs in old unreleased versions. I just tried the latest pretest (unpatched) and indeed AFAICS Emacs now behave as it should with a maximized window, at least on Windows XP. That is very nice! When was that change made? Or is there no change? (And what about Kim's note?) Last time I tested this I was using NT and then Emacs did not handle maximized windows very good. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Maximization doesn't work properly on Windows Xp, Emacs 22.0.92.1
Jason Rumney wrote: Lennart Borgman (gmail) wrote: I just tried the latest pretest (unpatched) and indeed AFAICS Emacs now behave as it should with a maximized window, at least on Windows XP. That is very nice! When was that change made? Apparently there is no such change, as Eivind can still reproduce the bug. So we need to find what is required to reproduce it, beyond simply moving the taskbar to the left of the screen, as neither I nor Lennart can reproduce it by that simple recipe. Hm. Yes, I wonder what is going on. I am more surprised by that it works for me now than that it does not work for Eivind. Eivind, what version of Windows are you using? I remember one other symptom of the semi-maximized Emacs window at the moment: I could move the maximized window (I can't do that now). Can you move the maximized window, Eivind? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Regexp not stateless?
I have just seen a state problem with regexps. I am not able to isolate the problem completely at the moment, but here is a sketch of it: I have this regexp: (defconst mumamo-script-tag-start-regex (rx script (1+ space) type (0+ space) = (0+ space) ?\ ;;(or text application) ;;/ ;;(or javascript ecmascript) text/javascript ?\ (0+ (not (any ))) (optional (0+ space) ![CDATA[ ) )) This matches at the start of this text with `looking-at': script type=text/javascript ![CDATA[ However sometimes it matches just to the end of the first line and sometimes to the end of the second line (as it should). I am using this little function to test: (defun x() (interactive) (when (looking-at mumamo-script-tag-start-regex) (goto-char (match-end 0 (global-set-key [f7] 'x) That is unfortunately not all that is needed to reproduce the problem however. It looks like the regexp engine somehow saves a state. Once it matches the first variant it continue to do that and the same for the second variant. It does not matter where in the file I try to do the match. (As long as the text above is available at the test point of course.) As I said it is easily reproduceable by me, but unfortunately there is a lot of other code involved to switch between the two states above. In GNU Emacs 22.1.50.1 (i386-mingw-nt5.1.2600) of 2007-04-27 on ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: define-globalized-minor-mode has no custom link
Richard Stallman wrote: A globalized minor mode can be customized. There is currently no link to custom from the doc string that is generated. What do you mean by that? Please show concretely what you mean. Ah, it is me beeing a bit confused. I looked at the documentation for the function and there is no information about customization. This is the same as for other global minor modes. There is currently a link from the global minor mode variable doc to the function, but not from the function doc to the variable. I think it would be easier for users if there where such a link too. How else should they understand that they can make the global minor mode be turned on automatically? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Indentation bug in html-mode
Stefan Monnier wrote: The attached file is valid XHTML 1.1 but indents badly because of the inte ?php ... ? part. I paste it here for simplicity too: Hmm... does the patch below fix it for you? If you put a ? inside your PHP code, it seems it would still be valid XML, but indentation will probably get confused. It fixes the last two lines (/body and /html), but not the /div line. Stefan --- orig/lisp/textmodes/sgml-mode.el +++ mod/lisp/textmodes/sgml-mode.el @@ -1183,6 +1183,15 @@ ((sgml-looking-back-at ]]) ; cdata (setq tag-type 'cdata tag-start (re-search-backward !\\[[A-Z]+\\[ nil t))) + ((sgml-looking-back-at ?) ; XML processing-instruction +(setq tag-type 'pi + ;; IIUC: SGML processing instructions take the form ?foo ... + ;; i.e. a normal tag, handled below. In XML this is changed + ;; to ?foo ... ? where ... can contain and and even ? + ;; but not ?. This means that when parsing backward, there's + ;; no easy way to make sure that we find the real beginning of + ;; the PI. + tag-start (search-backward ? nil t))) (t (setq tag-start (with-syntax-table sgml-tag-syntax-table ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: html-mode demanding html a bit too tight
Stefan Monnier wrote: Maybe if magic-mode-alist were combined into auto-mode-alist it'd be easier to control conflicts or precedence among content vs filename tests. (Not that you want to get too fancy about such things ...) Agreed. I think the most important thing is getting something done to this. Currently if you for example open some PHP mode files they will be opened in some html-mode even though the user has set it to php-mode in the file list. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
define-globalized-minor-mode has no custom link
A globalized minor mode can be customized. There is currently no link to custom from the doc string that is generated. I think there should be one, just as there is one for a minor mode defined with define-minor-mode. In GNU Emacs 22.0.99.1 (i386-mingw-nt5.1.2600) of 2007-04-24 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Why does a globalized mode check all buffers?
I had some trouble with Emacs hanging and a globalized minor mode so I checked `define-globalized-minor-mode'. It looks a bit strange to me. Why should a globalized mode check every buffer after a change in major mode in one buffer, for example? Or am I misreading the macro? In GNU Emacs 22.0.98.1 (i386-mingw-nt5.1.2600) of 2007-04-22 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Why does a globalized mode check all buffers?
Lennart Borgman (gmail) wrote: I had some trouble with Emacs hanging and a globalized minor mode so I checked `define-globalized-minor-mode'. It looks a bit strange to me. Why should a globalized mode check every buffer after a change in major mode in one buffer, for example? Or am I misreading the macro? Ah, yes, I was. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with overlays (on w32 only?)
Glenn Morris wrote: Lennart Borgman (gmail) wrote: In the attached images I have one overlay one character long that has a red underline. [...] In the second picture I have added another overlay, with a slightly blue background. This overlay is 10 characters long and includes a new line. The first overlay with the red underline is still just one character long, but the red underline now displays in the whole range of the second overlay. (The two oeverlays starts at the same character.) Yes, but what shade of blue? emacs -q --no-site-file Press [RET] on i in This buffer is for... At end of buffer, evaluate this: (setq o1 (make-overlay 1 2)) (overlay-put o1 'face '(:underline t :foreground red)) (setq o2 (make-overlay 1 10)) (overlay-put o2 'face '(:background green)) Works as it should for me. This is on GNU/Linux. Thanks, but I should have sent some code in addition to my explanation. The above works for me to, but can you please test the code below. That code gives the error. The important thing is the newline characters. (defvar o1 nil) (defvar o2 nil) (defun test-me() (interactive) (let ((buf (get-buffer-create *OVERLAY Error*))) (switch-to-buffer-other-window buf) (with-current-buffer buf (erase-buffer) (insert 123\n\n 890) (if o1 (move-overlay o1 3 5) (setq o1 (make-overlay 3 5))) (overlay-put o1 'face '(:underline red)) (if o2 (move-overlay o2 3 9) (setq o2 (make-overlay 4 9))) (overlay-put o2 'face '(:background #77)) (other-window -1) ))) (test-me) ;;(delete-overlay o2) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: html-mode demanding html a bit too tight
Stefan Monnier wrote: In a recent build of the cvs, visiting the file minimal.html below selects sgml-mode, where I hoped to get html-mode. According to the Again, the best fix seems to be to make sure the .html extension is heeded. I agree. If you look at EmacsWiki for example you can see that a good number of users gets confused by the mode selection caused by that magic-mode-alist overrides auto-mode-alist. I think that should be reversed before release. Didn't we discuss that before? The only real drawback I can see is that magic-mode-alist does not deserve it's name that much if we do that change. 8-) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with overlays (on w32 only?)
Jason Rumney wrote: Thanks, but I should have sent some code in addition to my explanation. The above works for me to, but can you please test the code below. That code gives the error. The important thing is the newline characters. The behaviour is the same on w32 as it is on X. What made you say it was on w32 only? I asked, I did not say is was. I have only access to w32 most of the time so I could not test. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with overlays (on w32 only?)
Chong Yidong wrote: Lennart Borgman (gmail) [EMAIL PROTECTED] writes: In the attached images I have one overlay one character long that has a red underline. In the code you provide, the overlay is two characters long, not one. If you make the overlay span 3 to 4, everything works fine. Ah, yes, but that was just to show that it is not necessary that it is one character long. (When I reported it first that was all I knew. I thought it was best to do it as quickly as possible.) Sorry for beeing unclear. (defun test-me() (interactive) (let ((buf (get-buffer-create *OVERLAY Error*))) (switch-to-buffer-other-window buf) (with-current-buffer buf (erase-buffer) (insert 123\n\n 890) (if o1 (move-overlay o1 3 5) (setq o1 (make-overlay 3 5))) (overlay-put o1 'face '(:underline red)) (if o2 (move-overlay o2 3 9) (setq o2 (make-overlay 4 9))) (overlay-put o2 'face '(:background #77)) (other-window -1) ))) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Strange undo problem
I just saw a very strange undo problem. I have no simple way to reproduce it, but I can frame it a bit. Lock at the backtrace below: Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil) rng-error-modified(#overlay in no buffer t 777 777 85) primitive-undo(2 (nil (777 . 862) (t 17963 . 2531))) undo-more(2) undo() call-interactively(undo) Doesn't it look strange that rng-error-modified (from the nxml-mode package) is the first thing on the backtrace, before primitive-undo? The problem is very reproduceable for me, it happens every time I call undo in a certain situation. I can give more detail instructions on how to reproduce this problem if someone is interested. It is not complicated to do that, but quite many things are involved. Maybe a bit of the problem is the look of the backtrace? rng-error-modified is part of the rng validation package that comes with nxml-mode. The validation is running with idle timers. It uses a defmacro similar to save-buffer-state in font-lock.el when it modifies the faces in the buffer. It does that during validation and validation is triggered by changes in the buffer. I am sure that a lot of validation takes place right after the undo. I can not see how it can interfere with undo however. Or at least I can not see how it can do that if the Emacs timers all run within the lisp w32 thread of Emacs on w32. (If however w32 timers are used the situation is very, very different. I think I asked about if such timers were used long ago, but I can't remember I got any clear answer to that.) A problem is that I do not know what to do with this. The undo information in the buffer seems corrupt after the above traceback. In GNU Emacs 22.0.98.1 (i386-mingw-nt5.1.2600) of 2007-04-22 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/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: Debugger Minor modes in effect: nxhtml-global-validation-header-mode: t appmenu-mode: t emacsw32-mode: t mlinks-mode: t indent-region-mode: t swbuff-y-mode: t which-function-mode: t show-paren-mode: t recentf-mode: t cua-mode: t encoded-kbd-mode: t tooltip-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 transient-mark-mode: t abbrev-mode: t Recent input: f5 return f10 menu-bar options debug-on-error M-x m u m a m o - m o d e return j j j j j j j j j j j j j j A lwindow M-x n x m l - c o m p l e t e return escape u C-a C-c timeout C-x 5 2 f12 h f12 right right left left f10 menu-bar help-menu report-emacs-bug Recent messages: Loading sgml-mode...done Loading c:/emacs/u/070422/emacsw32/nxml/nxhtml/php-mode.el (source)...done `' that is not markup must be entered as `lt;' Loading c:/emacs/u/070422/emacsw32/nxml/nxhtml/javascript.el (source)...done undo! Loading debug...done Entering debugger... Mark set [2 times] Type C-x 1 to remove help window. Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: pending-undo-list is not buffer local
martin rudalics wrote: If those calls are done in different buffers it looks like trouble to me. Should not pending-undo-list be buffer local? Not by default. If you want to write a function which say, tries to undo changes simultaneously in two or more buffers in some lock-step fashion, you can always make it local yourself (and probably `undo-in-region' as well). I think for the reason above that it should be buffer local and I also think that it should be permanent buffer local then. I think this wouldn't make much sense since `buffer-undo-list' isn't permanently buffer-local either. Maybe this is a stupid test, but it looks like buffer-undo-list at least does not get killed by kill-all-local-variables, and that is what 'permanent-local is for: (let ((undo-list-copy (undo-copy-list buffer-undo-list))) (kill-all-local-variables) (equal undo-list-copy buffer-undo-list)) Too me it looks bad that pending-undo-list is not permanent buffer local. And of course all other variables that should reflect the undo state in the buffer. But it depends a bit on how they are used. I can not think of any reason why they should not be permanent buffer local. Can anyone else? Making the buffer local means that there is less chance mixing the values from different buffers up (though it will still be possible using with-current-buffer for example). Making them 'permanent-local t means that they do not get killed when changing major mode. And that is good of course. Are there any other way of killing buffer local variables than calling kill-.*local-.*? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange undo problem
Lennart Borgman (gmail) wrote: I just saw a very strange undo problem. I have no simple way to reproduce it, but I can frame it a bit. Lock at the backtrace below: Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil) rng-error-modified(#overlay in no buffer t 777 777 85) primitive-undo(2 (nil (777 . 862) (t 17963 . 2531))) undo-more(2) undo() call-interactively(undo) Doesn't it look strange that rng-error-modified (from the nxml-mode package) is the first thing on the backtrace, before primitive-undo? I think I am beginning to understand. I found these lines in the nxml-mode files: (put 'rng-error 'modification-hooks '(rng-error-modified)) (defun rng-error-modified (overlay after-p beg end optional pre-change-len) And in elisp Info: `modification-hooks' If a character has the property `modification-hooks', then its value should be a list of functions; modifying that character calls all of those functions. Each function receives two arguments: the beginning and end of the part of the buffer being modified. Note that if a particular modification hook function It seems like rng-error-modified does not have the correct format for the new Emacs 22. Is there anyone who knows if this was a change in Emacs 22? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange undo problem
Lennart Borgman (gmail) wrote: Lennart Borgman (gmail) wrote: I just saw a very strange undo problem. I have no simple way to reproduce it, but I can frame it a bit. Lock at the backtrace below: Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil) rng-error-modified(#overlay in no buffer t 777 777 85) primitive-undo(2 (nil (777 . 862) (t 17963 . 2531))) undo-more(2) undo() call-interactively(undo) Doesn't it look strange that rng-error-modified (from the nxml-mode package) is the first thing on the backtrace, before primitive-undo? I think I am beginning to understand. I found these lines in the nxml-mode files: (put 'rng-error 'modification-hooks '(rng-error-modified)) (defun rng-error-modified (overlay after-p beg end optional pre-change-len) And in elisp Info: `modification-hooks' If a character has the property `modification-hooks', then its value should be a list of functions; modifying that character calls all of those functions. Each function receives two arguments: the beginning and end of the part of the buffer being modified. Note that if a particular modification hook function It seems like rng-error-modified does not have the correct format for the new Emacs 22. Is there anyone who knows if this was a change in Emacs 22? Eh, but wait a minute ... - The traceback indicates that the elisp Info is wrong here, or? Actually the parameter spec to rng-error-modified seems ok, but it gets an #overlay in no buffer that it does not check. So there are two bugs here, one in nxml-mode and one in the elisp Info manual. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange undo problem
Lennart Borgman (gmail) wrote: So there are two bugs here, one in nxml-mode and one in the elisp Info manual. And BTW the bug in nxml-mode was that the variable rng-error-count did not have the property 'permanent-local t. And that was what my code needed there. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange undo problem
Johan Bockgård wrote: Lennart Borgman (gmail) [EMAIL PROTECTED] writes: And in elisp Info: That is, (info (elisp)Special Properties) `modification-hooks' If a character has the property `modification-hooks', then its value should be a list of functions; modifying that character calls all of those functions. Each function receives two arguments: the beginning and end of the part of the buffer being modified. Note that if a particular modification hook function Wrong section. Try (info (elisp)Overlay Properties) `modification-hooks' This property's value is a list of functions to be called if any character within the overlay is changed or if text is inserted strictly within the overlay. Ah, thanks. Looks much better ;-) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Indentation bug in html-mode
The attached file is valid XHTML 1.1 but indents badly because of the
inte ?php ... ? part. I paste it here for simplicity too:
?xml version=1.0 encoding=iso-8859-1?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN
http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd;
html xmlns=http://www.w3.org/1999/xhtml; xml:lang=en
head
titleIndentation bug at lt;/title
/head
body
div id=main
?php
for ($i = 0; $i 4711; ++$i) {
}
?
/div
/body
/html
In GNU Emacs 22.0.98.1 (i386-mingw-nt5.1.2600)
of 2007-04-22
Title: Indentation bug at
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Display problems with overlays (on w32 only?)
In the attached images I have one overlay one character long that has a red underline. In the first picture there is only this overlay at that point and the display is correct. In the second picture I have added another overlay, with a slightly blue background. This overlay is 10 characters long and includes a new line. The first overlay with the red underline is still just one character long, but the red underline now displays in the whole range of the second overlay. (The two oeverlays starts at the same character.) Is this perhaps a simple typo somewhere in the display code? Here is the output from C-u C-x = character: C-j (10, #o12, #xa, U+000A) charset: ascii (ASCII (ISO646 IRV)) code point: #x0A syntax:which means: whitespace buffer code: #x0A file code: #x0A (encoded by coding system undecided-unix) display: by this font (glyph code) -outline-Courier New-normal-r-normal-normal-13-97-96-96-c-*-iso8859-1 (#x0A) There are 2 overlays here: From 786 to 787 category rng-error help-echo? not followed by name priority 786 From 786 to 796 face mumamo-background-chunk-submode mumamo-major-modefundamental-mode mumamo-narrownil priority 100 There are text properties here: fontifiedt nxml-inside processing-instruction And the output when clicking on rng-error: Category rng-error: face rng-error-face modification-hooks (rng-error-modified) [back] Dito mumamo-background-chunk-submode: Face: mumamo-background-chunk-submode (sample) (customize this face) Documentation: Background colors for chunks in major mode. You should only specify :background here, otherwise it will interfere with syntax highlighting. FIX-ME: background colors for dark cases. Defined in `mumamo.el'. Family: unspecified Width: unspecified Height: unspecified Weight: unspecified Slant: unspecified Foreground: unspecified Background: azure Underline: unspecified Overline: unspecified Strike-through: unspecified Box: unspecified Inverse: unspecified Stipple: unspecified Font or fontset: unspecified Inherit: unspecified [back] In GNU Emacs 22.0.98.1 (i386-mingw-nt5.1.2600) of 2007-04-22 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange undo problem
Richard Stallman wrote: So there are two bugs here, one in nxml-mode and one in the elisp Info manual. What do you think is a bug in the Emacs Lisp Reference Manual? Where is it? There is no bug in the manual. Johan Bockgård pointed out I was reading the wrong section in the manual. But it would help with links between description of `modification-hooks' for text and overlays, since they are a bit different. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Link in define-key doc broken
The link to Extended Menu Items in the doc string for define-key is broken. In GNU Emacs 22.0.98.1 (i386-mingw-nt5.1.2600) of 2007-04-17 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Bottom part of Extended Menu Items badly formatted
The bottom part of (info (elisp) Extended Menu Items) is badly formatted which makes it quite hard to understand. The very last paragraph should belong to :filter. In GNU Emacs 22.0.98.1 (i386-mingw-nt5.1.2600) of 2007-04-19 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
pending-undo-list is not buffer local
The variable pending-undo-list is used by for example undo-start and undo-more. The doc strings says that you should first call undo-start and then you can call one or several times undo-more later. If those calls are done in different buffers it looks like trouble to me. Should not pending-undo-list be buffer local? I think for the reason above that it should be buffer local and I also think that it should be permanent buffer local then. I asked before if it should not be permanent buffer local. That was said not to be necessary since it is not buffer local. I think that is wrong, but please see the thread here: http://lists.gnu.org/archive/html/emacs-devel/2007-03/msg01712.html In GNU Emacs 22.0.98.1 (i386-mingw-nt5.1.2600) of 2007-04-17 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
Stefan Monnier wrote: I agree that this situation should be improved, but as long as the position is chosen arbitrarily anyway, I don't see it as a big problem if this arbitrary choice happens to be occasionally in the middle of the display string rather than at one of its ends. My weak memory whispers something about that this has been improved quite a while ago, but I am not sure. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
Eli Zaretskii wrote: Date: Mon, 16 Apr 2007 22:58:47 +0200 From: Lennart Borgman (gmail) [EMAIL PROTECTED] CC: Juanma Barranquero [EMAIL PROTECTED], emacs-pretest-bug@gnu.org But let me turn the table around, Lennart, and ask you: what arguments will actually convince _you_ to change your mind on this? Following Karl Popper, if your answer is ``nothing will change my mind'', then this is a religious type of argument that we should just stop, because it has no hope of any agreement whatsoever. That is a good question. Which you didn't answer, sigh... In what sense did I not answer it? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
Eli Zaretskii wrote: Date: Tue, 17 Apr 2007 22:08:06 +0200 From: Lennart Borgman (gmail) [EMAIL PROTECTED] CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org But let me turn the table around, Lennart, and ask you: what arguments will actually convince _you_ to change your mind on this? Following Karl Popper, if your answer is ``nothing will change my mind'', then this is a religious type of argument that we should just stop, because it has no hope of any agreement whatsoever. That is a good question. Which you didn't answer, sigh... In what sense did I not answer it? In the sense that I still do not know what would convince you to change your mind. For example, if I would to argue with someone which of two apples to buy, telling me that one is 10 times cheaper than the other might make me change my mind. I am not the easiest one to convince, but it is in no way impossible. I tried to point out the answer. What is needed is not very different from when you meet other people. You must try to meet me where I am. And I failed for similar reasons to make it possible to convince you. You were arguing from a managerial standpoint. I tried to mix this standpoint with estimates of some details in the problem. If you wanted to convince me I then I think you should have to follow me a bit on that road. It would be nice if you commented on this because I honestly fail to understand why you did not do that. I can of course think of a lot of reasons, lack of time for example. Or that you did not find my arguments valuable. Whichever it was I think it would have been easier to get a bit longer on the road to convincing me if you explained your reasons for the turn you took. I tried in the prev-previous mail to do explain something similar from my point of view, but I think I missed something there since you thought I did not answer you. I have a feeling that the difficulties to meet is for some reason mainly a lack of trust. That may be personal for me, I do not know. It is easy for me to say that I trust your experience and appreciate your concerns, but that I think differently. But it is not easy to get the message through to you. Maybe because of the media and the way we communicate. Maybe because we actually have different styles of thinking as I understand it. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
Eli Zaretskii wrote: Date: Tue, 17 Apr 2007 23:29:12 +0200 From: Lennart Borgman (gmail) [EMAIL PROTECTED] CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org I am not the easiest one to convince, but it is in no way impossible. You again are not answering the question. I think we should end this discussion, as it became futile. Please read Karl Popper if you wish to understand what kind of answer I asked for, and why I think there's no point in continuing this discussion with you. It is hard for me to understand how you think Popper's thinking could be used here so if you want me to understand I believe you must point out what claim of knowledge you have from a falsifiability standpoint and maybe how you think I relate to that. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
Eli Zaretskii wrote: Date: Mon, 16 Apr 2007 03:14:13 +0200 From: Lennart Borgman (gmail) [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org Then what arguments are actually convincing to you? Did you ever managed release of some software product, Lennart? Because if you didn't, then there's really no way we could convince you, since you lack a significant experience of having to decide what needs to be fixed before the release and what's after it. Of course experience is good. Did I ever say something else? Or why did you say the above? I know that both Kim and Chong hesitate to do the changes now. My argument is not that I do not trust them. I try to look at the actual changes and estimate the chances that it can go wrong. This estimation on the one hand, and the estimated seriousness of the bug on the other, is the fundamental issue. We are getting closer to a serious discussion, thanks. If you cannot see how the former is much larger than the latter, then we have no real basis for a reasonable discussion. And now you are leaving it again. That's because everyone else but you look at this issue at a fundamentally different level. You look at the details, but no amount of details will ever lead you to the bigger picture--that we need to release soon, and that Emacs is ready for that. And now you have left it totally. Instead of asking me you say that I am thinking in a certain way. If you discuss that way you will always win a discussion. If you please separate my opinion from my arguments it will be much nicer. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
Juanma Barranquero wrote: On 4/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: We are getting closer to a serious discussion, thanks. Because you're the arbiter of when a discussion is serious enough? Yes, I do have an opinion about that. Disrespect is not one of the things I respect. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
Juanma Barranquero wrote: On 4/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: Yes, I do have an opinion about that. Disrespect is not one of the things I respect. Disrespect is often in the eye of the beholder. I certainly have no trouble detecting disrespect in some of your messages, but I'm sure you'll disagree. It has not been my intent. I do get a bit upset by some type of answers and you are right, it is then in the eye of the beholder. I can understand if Eli feel a bit hurt. He took long time to write a long answer and I just pointed to some a little bit weaker points in the answer. So, Eli, there I missed your point and I apologize for that. I try to have respect for that more economic reasoning that you are using, but I often fail there. (On the other hand I often try to tell people that I learned one thing from that kind of reasoning and that is that you sometimes have to take a decision without having all the knowledge of the details that you wish you had.) And I often prefer to keep my own opinion even under strong pressure. It is unusual, but it is not out of disrespect. Though those things are close in a way it is still possible to distinguish them. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
David Kastrup wrote: I will not be surprised at all if we will see after the release a flood of problem reports currently held back by a large release pain threshold. Uhm. At least I have tried to avoid reporting some bugs now just because it seems useless. We all want a release I guess. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
Juanma Barranquero wrote: I was not offended, but saying to your opponent I suggested reading my arguments is not keep[ing your] own opinion, for example. I point it out merely to show that it is easy to cross the line without being aware. Oh, yes it is easy. And I know you have told me about this one before, but in some situations it is easy to forget. The only way avoiding this is probably beeing very carefully when one is commenting on the opponents view. Perhaps it works in this kind of communication to clearly state that my view of your arguments is At least that is often a way forward in face-to-face communication. Though one have to say it with an querying voice. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
Eli Zaretskii wrote: Then what arguments are actually convincing to you? At this point in time, just days short of the intented release? Either the bug crashes Emacs, or it does cause trouble for some really major package, or it is very common and/or confusing for many users. And such bugs are almost unthinkable at this stage, given the long pretest -- unless, that is, they were caused by unsafe changes we did very recently, on one of the occasions we failed to exercise will power and resist the temptation of fixing ``one more bug''. But let me turn the table around, Lennart, and ask you: what arguments will actually convince _you_ to change your mind on this? Following Karl Popper, if your answer is ``nothing will change my mind'', then this is a religious type of argument that we should just stop, because it has no hope of any agreement whatsoever. That is a good question. I am of course also worried about stability. We can unfortunately not only use logical thinking, the problem is too complex for that. So we are arguing about how to look upon the different arguments. I agree that a managerial/economical view is good to use as a tool for deciding. And there must be a decision at the end. Just fixing the bug is not enough for this kind of bug. My guess is that so far we do not differ very much, or? A note: What makes me a bit upset is more that I get the feeling that you think the bug is unimportant though I have said that I do have a real use case where it will show up. Note that I do not say that you actually think so, it is perhaps more my feelings. Anyway those feelings are noticeable in my replies. This is part of the difficulties with arguing now. Probably I disturb you in a similar manner. I think that from both sides this is unintentional, but it is worth noting when we try to solve this. I have tried to explain in similar situations before that I always try to look at the problem at different levels. When you ask for what arguments will convince me this is key. If you want to convince me the best you can do is try to argument on all the different levels of the problem. Maybe you think that you have done so by referring to the experts on this code for their opinion? The difficulty I have with this is that the actual arguments on the details gets hidden. I can not argue at all then since I am trying to estimate the stability by looking at the details. That said I must point out that I can not say anything for sure about the stability. I give my arguments, hope for feedback from the experts. The may very well kill my arguments, no problems, but I do have some arguments that I think may be worth listening too. I feel very much better if the arguments are killed than if they are never looked upon. (This is kind of human I think.) Killed by some sound logic of course. I have tried to list my argumenting below (except the one above). If you want to you can comment on it. I do not know if it matters now, but to frame the situation I think we can state something like this: - We all want a release. I think we may feel a little bit weary. - There is/was a bug in cursor positionining that affects multiline 'before-string, 'after-string or 'display properties in characters or overlays. - This bug is perhaps not seen very often. - I have however a use case were it will be seen. - A bug in cursor positioning is confusing and can lead a user to suspect that something is terribly wrong (and indeed that is often a plausible thinking when the cursor is in the wrong position). I have got a milder reaction of this kind - the user thought something was wrong in my code, not in Emacs. - The display code is complex, very complex. - There is/was a bug now, which may indicate that it is fragile too (in the sense that one should be very careful and thoughtful when changing it). - We see some consequences of this bug, but there may be more, even instability. - We have not seen any instability for 2 years however with the bug. - As far as I remember we did not see any instability either with the old bug (for how many years? 1-2?) that unfortunately was cured in such a way that it created this new bug. - The fix (that Chong installed a version of) is in a sense a middle way between the two bugs above. This does not prove it does not cause instability, but it may be seen as an indication (which I prefer to see it as). - The fix is rather local and as far as I can see it only affects multi-line 'before-string, 'after-string and 'display. That makes my worries for stability less. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
Eli Zaretskii wrote: Date: Mon, 16 Apr 2007 10:38:14 +0200 From: Lennart Borgman (gmail) [EMAIL PROTECTED] CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org Eli Zaretskii wrote: Date: Mon, 16 Apr 2007 03:14:13 +0200 From: Lennart Borgman (gmail) [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org Then what arguments are actually convincing to you? Did you ever managed release of some software product, Lennart? Because if you didn't, then there's really no way we could convince you, since you lack a significant experience of having to decide what needs to be fixed before the release and what's after it. Of course experience is good. Did I ever say something else? Or why did you say the above? I said that in the hope that you will respect our experience and the grey hair that came with it. Ah, I always learned that grey hair was caused by children. If you please separate my opinion from my arguments it will be much nicer. It is fundamentally human to interpret the arguments to understand the opinions of your opponent, and then try to deal with those opinions. I don't know how to discuss an issue without trying to understand what you think. Yes, but since we differ please be careful. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Kim F. Storm wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
Just another note if someone else is trying this. Having coming back
to this several times today I am starting to believe that the way to
fix this is to change cursor_row_p. This was the original way that Kim
tried to solve it. Maybe Kim's solution with an added test of if the
string has the 'display property will solve the problem for now.
I am unable to test this now, since I do not understand how to check
for the 'display property in cursor_row_p. If someone can tell that I
will test.
That is _not_ easy.
You have to record that during redisplay (by display_line in the glyph
row) if you need that information later.
Here is a version that I believe works. It just does local changes to
cursor_row_p. I seems to me that is sufficient. I have not seen any
problems with the display of 'display property parts, only with cursor
positioning.
If this way works (my test works) then as I said before this seems
rather safe as far as the return value from cursor_row_p is concerned.
However I think the actual code I added in cursor_row_p must be checked
carefully and perhaps rewritten. I have tried to use the ideas from
set_cursor_from_row, but I may easily have misunderstood things. I am
not good at C and the code in xdisp.c is complicated.
Here is the patch:
Index: xdisp.c
===
RCS file: /sources/emacs/emacs/src/xdisp.c,v
retrieving revision 1.1146
diff -c -r1.1146 xdisp.c
*** xdisp.c 10 Apr 2007 15:57:25 - 1.1146
--- xdisp.c 15 Apr 2007 14:31:07 -
***
*** 15858,15865
string if the string starts in this row.
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row-end.string_pos) = 0)
! cursor_row_p = (row-continued_p
! || PT = MATRIX_ROW_START_CHARPOS (row));
else if (MATRIX_ROW_ENDS_IN_MIDDLE_OF_CHAR_P (row))
{
/* If the row ends in middle of a real character,
--- 15858,15880
string if the string starts in this row.
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row-end.string_pos) = 0)
! {
! /* Check for 'display property: */
! int end = row-end.pos.charpos;
! struct glyph *text_glyphs = row-glyphs[TEXT_AREA];
! struct glyph *end_glyph = text_glyphs + row-used[TEXT_AREA];
! struct glyph *glyph = end_glyph;
! int q2 = -1;
! while (-1 == q2 glyph text_glyphs) {
! int gend2 = -1;
! if (STRINGP (glyph-object))
! gend2 = string_buffer_position(w, glyph-object, end);
! if (gend2 0)
! q2 = Fget_char_property (make_number (gend2), Qdisplay,
Qnil);
! --glyph;
! }
! cursor_row_p = (row-continued_p || (q2 != -1) );
! }
else if (MATRIX_ROW_ENDS_IN_MIDDLE_OF_CHAR_P (row))
{
/* If the row ends in middle of a real character,
___
emacs-pretest-bug mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Chong Yidong wrote: Lennart Borgman (gmail) [EMAIL PROTECTED] writes: Here is a version that I believe works. It just does local changes to cursor_row_p. I seems to me that is sufficient. I have not seen any problems with the display of 'display property parts, only with cursor positioning. Thanks for the patch. Thanks for fixing it up. Sorry for not doing it myself, but I was in a hurry. My main concern with such an approach is that this will be slow for long multi-line strings filling most of the window. In such a case, we will basically scan over all glyphs every redisplay cycle. On the other hand, maybe this situation need not bother us right now. You mean multi-line 'display strings? Then there is something I misunderstand. I mean 1) Scanning starts from the end and stops as soon as STRINGP is true. 2) It is the glyph row that is scanned. Is that not just a line? There are various problems with this patch: 1. Due to an off-by-one error, you start scanning from beyond the end of the glyph row, which can cause a segfault. Now you see why I normally do not touch C code ;-) 2. You have a mixup between Lisp_Object and int in the return value of Fget_char_property. Ah, yes, I thought it was a pointer. 3. The call to get_char property is unnecessary, since string_buffer_position checks only the display property. Thanks, I forgot that. I still believe it's adviseable to hold off redisplay changes till Emacs 22.2, but if RMS insists, I guess we might as well check it in instead of continuing this thread. I would be glad if we included this. I have already got complaints about this bug from some testers of my code. I think it would be good if this code were tested with all libraries using 'display prop as soon as possible. My worst doubt about this code is that I am not sure whether the necessary information actually always is available when cursor_row_p is called, but it looks to me like it must be that. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
Eli Zaretskii wrote: From: Richard Stallman [EMAIL PROTECTED] Date: Sun, 15 Apr 2007 09:59:10 -0400 Cc: emacs-pretest-bug@gnu.org, [EMAIL PROTECTED] It seems that you and I define serious in a different way. My criterion says that a bug where an important feature does something that is indisputably wrong and that causes real trouble is a serious bug. While such bugs create a well-understood motivation for fixing them, we should always weigh that against the possibility of introducing new and exciting bugs into an already very stable code base, and delaying an already long overdue release. When such a risk is real (as in this case, since we are talking about a change in the guts of a general purpose display code), we should, as a counter-balance, estimate the risk of someone tripping on the original bug. If that latter risk is low (as it is in this case, as evidenced by the 2-year period passed since the commit of the buggy code), we should seriously consider leaving the bug alone until after the release. I think this analysis could be a big deal deeper and less general. I think that would help to create a more meaningful discussion if we want that. Frankly, I'm astonished that I need to explain such truisms that are well known to anyone who has ever managed a software release, present company included. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
Nick Roberts wrote: In other words: I have seen this bug. I'm not questioning that you have seen it, just the wisdom of ignoring the advice of those who are experts in that part of the code and say that it is dangerous to fix shortly before the release. I am not ignoring Kim's advice, neither am I ignoring Richard's advice here. And I have listened to Chong. If you read my messages carefully you will see why I do not think this is dangerous to fix the way I have suggested. This is what I wrote to Kim some hours ago (who if I understand correctly is suspecting that a slightly different way to fix it is better in the long run): The advantage of this way (my fix) is that it is rather safe. In essence it just switches the value or-ed with row-continued_p between that your a little bit unfortunate patch gave (ie t) and the previous value (ie nil). Both these values have been tested for quite a while so it does not look as there can much stability problems. Given that you appear to be the only one to have been inconvenienced by this bug (and how often do you need an overlay at the start of the buffer?) while probably thousands want to see a release, and thousands more want to see Unicode added to Emacs, I just find the whole thing absurd. Some things are worth dying for, but I don't this is one of them. Oh, good, I am delaying the Unicode release! I did not think of that. Sorry, I could not really resist. I can understand your frustration, this makes me frustrated too, but I have tried my best not to delay the release. I believe the fix I sent today and that Chong turned into something more well written does what is needed. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
Juanma Barranquero wrote: On 4/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: If you read my messages carefully you will see why I do not think this is dangerous to fix the way I have suggested. That you don't think it is dangerous doesn't make it harmless or safe. I really did not say so of course. I suggested reading my arguments. Is not that a better level of discussion? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
Juanma Barranquero wrote: On 4/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: I really did not say so of course. I suggested reading my arguments. I did. I've read this thread in full. I know nothing about the redisplay code (I've taken a few looks at it and that's all), but AFAIK you're not very knowledgeable about it either. OTOH, it seems that people who really knows it inside and out is unconvinced that changing it now is safe. Excuse me if I trust their opinion. Ok, that is fine, but see below. Is not that a better level of discussion? I'd suggest as a better level of discussion if you presupposed that people who disagrees with your arguments *perhaps* does so for reasons other than not having read them... Ok, sorry. Then what arguments are actually convincing to you? For sure I found it troublesome to change that code now. There is however no other way to fix the bug. I know that both Kim and Chong hesitate to do the changes now. My argument is not that I do not trust them. I try to look at the actual changes and estimate the chances that it can go wrong. Then I try to get their feedback on this because I know that they know the code better from both a present and a historical point of view. Chong has given concrete feedback to the list to the fix I sent. Kim has not done so yet and I do not know if he will give feedback on that level. You are of course free to take any standpoint you want, but I think it would be nice and useful if you tried to keep it on the level I suggest above. If you just want to say that you do not want that change to be made now that is also ok. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Chong Yidong wrote: Richard Stallman [EMAIL PROTECTED] writes: You could add code inside a conditional which tests for that case. Then you know it won't affect any other cases. I don't have a clue to how to write the conditional which tests for that case. Have you tried to figure out how? To figure out what this conditional is, one must first get to the bottom of the failure. If you explain the failure mode to me, I will try to figure out a safe fix. I already explained twice what the problem is, and why it's better to postphone the fix. I took the sketchial patch Chong sent, inserted a lot of dump messages and played with it to try to understand what is happening. The patch looks bigger than it actually is. I mean much of it just adds another parameter to string_buffer_pos and that is rather harmless from a stability point of view. I think I see several small bugs, most related to the 'display property, but not all: A) It looks like set_cursor_from_row gets called over and over again in some circumstances. I might have done something stupid that triggers this, I am not sure at the moment, but if I move to the end of the file with right error this happens. If stops when I press down arrow. B) Moving with right arrow across the 'display part on the screen moves point across the part of the buffer that has the 'display property. In contrast moving with left arrow make point stop at the first of the characters that has the overlay with the 'display property (which is the correct behavior I believe). This seems to be a bug in another part than the ones Chong tried to cover with his patch sketch. C) Even when moving with left arrow the cursor stops at the wrong position. It stops after the 'display part. (This behavior is correct for 'before-string and 'after-string, but not for 'display strings.) D) When the cursor is at the second 'display area of Kim's example set_cursor_from_row gets called over and over again. It does not matter how that row was entered AFAICS. Can others reproduce the bug in B? If so I believe this is the most serious one. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Lennart Borgman (gmail) wrote: B) Moving with right arrow across the 'display part on the screen moves point across the part of the buffer that has the 'display property. In contrast moving with left arrow make point stop at the first of the characters that has the overlay with the 'display property (which is the correct behavior I believe). This seems to be a bug in another part than the ones Chong tried to cover with his patch sketch. Can others reproduce the bug in B? If so I believe this is the most serious one. I reverted the changes to keyboard.c in Chongs patch sketch. That cured this problem. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Lennart Borgman (gmail) wrote: A) It looks like set_cursor_from_row gets called over and over again in some circumstances. I might have done something stupid that triggers this, I am not sure at the moment, but if I move to the end of the file with right error this happens. If stops when I press down arrow. Whatever size the buffer have when point is at the end of buffer and I press left arrow then set_cursor_from_row has PT=14 and when I press down arrow PT=1. In other circusomstances PT seems to be what I expect (ie ==(point)). Could not this be a problem for the cursor position routines? ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Just another note if someone else is trying this. Having coming back to this several times today I am starting to believe that the way to fix this is to change cursor_row_p. This was the original way that Kim tried to solve it. Maybe Kim's solution with an added test of if the string has the 'display property will solve the problem for now. I am unable to test this now, since I do not understand how to check for the 'display property in cursor_row_p. If someone can tell that I will test. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Kim F. Storm wrote: Lennart Borgman (gmail) [EMAIL PROTECTED] writes: Just another note if someone else is trying this. Having coming back to this several times today I am starting to believe that the way to fix this is to change cursor_row_p. This was the original way that Kim tried to solve it. Maybe Kim's solution with an added test of if the string has the 'display property will solve the problem for now. I am unable to test this now, since I do not understand how to check for the 'display property in cursor_row_p. If someone can tell that I will test. That is _not_ easy. You have to record that during redisplay (by display_line in the glyph row) if you need that information later. But does not the code in set_cursor_from_row test for 'display in strings? Or is that another situation? But I see now set_cursor_from_row just calls pos = XINT (Fnext_single_char_property_change (make_number (pos), Qdisplay, Qnil, limit)); Can't that approach be used? glyph_row has a pointer to the position in the buffer through the field display_pos start, where display_pos has a text_pos field. And text_pos has a charpos field, which I assume is the position in the buffer. I am thinking about this solution since it seems rather safe to me. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: keymap changes in run-with-timer
Stefan Monnier wrote: selecting a keymap (e.g. when changing minor-mode, creating 'keymap overlays, setting overriding-local-map, use-local-map) in a run-with-timer or run-with-idle-timer event doesn't take immediate effect. Consider the following example: (run-with-timer 3 nil '(lambda () (let ((map (make-sparse-keymap))) (define-key map x y) (use-local-map map)) (message timer fired))) After the message timer fired, pressing the x key still inserts an x. Only beginning with the second time it will insert a y. Indeed it does: the list of active keymaps is computed right before calling `read', i.e. right when going idle at the end of the previous command. It would probably be good to delay it, but this is not very high priority. I've added it to the TODO list. If you think it is possible to do it now it would be good. I need this for mumamo too. (Mumamo is here: http://www.emacswiki.org/cgi-bin/wiki/MuMaMo) I have a workaround there for this. I call top-level after such changes (in this case after changing major mode in a timer). ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Lennart Borgman (gmail) wrote: Another little question: On w32 I failed to apply this patch with the patch program from gnuwin32 (version 2.5.9). I wonder if this is a problem with that patch program or something else. How do I continue when patch fails? Most of the patch where applied. The patch fails with the following reject (xdisp.c.rej): Sorry if I wasted someonce time. There were no problems applying the patch, I just applied it to the wrong tree. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Eli Zaretskii wrote: Date: Wed, 11 Apr 2007 22:48:34 +0200 From: Lennart Borgman (gmail) [EMAIL PROTECTED] CC: Chong Yidong [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] FWIW, I wouldn't touch this so close to the release: if no one noticed this since July 2005, it's hardly a grave bug. How do you know? This just looks so strange so it could well be a grave bug. How do I know what? that it's not grave? But I just explained that! To me it looks more like using a 'before-string of the kind I am using is uncommon. But maybe that is what you mean, that is not grave because it is uncommon. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Kim F. Storm wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
Looking at the logic it seems like it perhaps should be like below
instead? This at least works in my case. The current test just seems
useless. Or perhaps I am just very bad at reading C code?
The useless code you refer to was installed to fix a bug, and it
did fix _that_ bug.
The code before my change looked like this:
if (PT == MATRIX_ROW_END_CHARPOS (row))
{
if (CHARPOS (row-end.string_pos) = 0)
cursor_row_p = (row-continued_p
|| PT = MATRIX_ROW_START_CHARPOS (row));
I thought it was useless because it the first test with PT seems to
imply that the second test with PT must be true. I did not look into the
structures and how they are used, only the names of the macros and the
definition of them.
Do you say that the second test actually could fail? I believed it was
perhaps a mis-paste or something.
Now you have found a different bug in the same code, and you propose
a different way to fix _your_ bug.
Indeed your code does look like it could fix the problem - but it
definitely changes the semantics of the test, so there may very well
be other corner casee which are broken by _your_ code.
Can you track down the bug report(s) which lead up to the fix I
installed, so you can confirm that your change also fixes the old bug(s).
I must be close to the date in the ChangeLog.
If you think that the test actually does something I can try.
Besides, the ++row seems dangrous to me. Would row+1 do the same?
Sorry, yes, that is better and my first test now implies it works.
This is the bug I want to have fixed (since it is very visible), but
there are other bugs there too. The first one is for the record, perhaps
you care about the second:
1) In some situations the cursor can still stop at the end of the first
row in the 'before-string. But I have only seen it once and I am not
sure how to reproduce it. (It does not happen when the overlay is at 1-1
or at least I have not seen it then.) Does this imply that some other
test in cursor_row_p may be wrong?
2) If you shrink the window so that the 'before-string fills from top to
bottom the first char after it disappears from the screen. Not extremely
serious in itself, but perhaps easy to fix (and it might also point to
other troubles, of course). To reproduce this eval the code below (same
as before):
(defvar temp-ovl nil)
(defun temp-toggle-ovl()
(interactive)
(if temp-ovl
(progn
(delete-overlay temp-ovl)
(setq temp-ovl nil))
(setq temp-ovl (make-overlay 1 1))
(let ((s A string\nwith several rows\nthat should be at top\n))
(put-text-property 0 (length s)
'face (list (cons 'background-color
yellow))
s)
(overlay-put temp-ovl 'before-string s
The create a new buffer with two rows:
First char may disappear.
But second line is ok.
Do
M-x temp-toggle-ovl
go to char 1 and then shrink the window vertically. When the number of
lines gets down to the height of the 'before-string the char F
disappears. Or the cursor may move to the first line of the 'before-string.
___
emacs-pretest-bug mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Kim F. Storm wrote: At this stage of the release cycle, a grave bug is one that makes Emacs crash, or causes really bad redisplay behaviour. As you said yourself, this is a corner case, so it is not a grave error. Ok, but with a corner case I meant a logical corner case. Those +-1 you often have to rethink after coding. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Chong Yidong wrote: I think the current code is mistaken. The ChangeLog entry and the comments both say that we want to set cursor_row_p to a non-zero value in the case where the display string starts in this row. But that's not what it's doing; Lennart is correct in pointing out that it's setting cursor_row_p unconditionally, since PT == MATRIX_ROW_END_CHARPOS (row) implies PT = MATRIX_ROW_START_CHARPOS (row). Looking at it again I wonder why my test change did not do that too ... ;-) To actually do what the comments and ChangeLog say we want to do, we would have to scan backward in the glyph row for the beginning of the string, which would be significantly more complicated than the current code. For the Emacs 22 release, maybe we should simply revert this change to cursor_row_p = row-continued_p; It does not cause the original 2005 bug report to reappear, and it doesn't seem to affect anything else as far as I can tell. WDYT? Reverting as you propose seems to at least cure the problem I saw. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Chong Yidong wrote:
[EMAIL PROTECTED] (Kim F. Storm) writes:
IIRC, the original problem I tried to solve is shown by this test-case:
(progn
(switch-to-buffer (get-buffer-create *test*))
(erase-buffer)
(insert .\n\n.\n\n)
(goto-char (point-min))
(let ((ov (make-overlay 4 7)))
(overlay-put ov 'display Ax\nyB))
(goto-char (point-max)))
With my change, moving the cursor places it on the 'A'.
Without my change, moving the cursor places it on the 'y'.
So my change may be incorrect - but it _does_ solve a real problem.
OK, now I see the problem.
I believe the underlying fault is not in cursor_row_p, but in
set_cursor_from_row, on xdisp.c:11948:
pos = string_buffer_position (w, string, string_before_pos);
/* If STRING is from overlay, LAST_POS == 0. We skip such glyphs
because we always put cursor after overlay strings. */
while (pos == 0 glyph stop)
{
string = glyph-object;
The assumption made in the comment is not correct:
string_buffer_position returns non-zero values for overlay strings
with the `display' property. In xdisp.c:4446:
prop = Fget_char_property (pos, Qdisplay, Qnil);
if (!NILP (prop) display_prop_string_p (prop, string))
found = 1;
This suggests that the way to fix this is to change
string_buffer_position to do what that says. However, it is dangerous
to change string_buffer_position right now, because it's called from
several places in xdisp.c. Changing its behavior runs a serious risk
of introducing subtle bugs.
I tested another way that perhaps is in line with Kim's original intent.
Since I do not know this code I had to guess put I put it here so you
can comment:
static int
cursor_row_p (w, row)
struct window *w;
struct glyph_row *row;
{
int cursor_row_p = 1;
if (PT == MATRIX_ROW_END_CHARPOS (row))
{
/* If the row ends with a newline from a string, we don't want
the cursor there, but we still want it at the start of the
string if the string starts in this row.
If the row is continued it doesn't end in a newline. */
fprintf (stderr, cont=%d, start.string_pos=%d, %d, end=%d, %d\n,
row-continued_p,
CHARPOS (row-start.string_pos),
row-start.pos.charpos,
CHARPOS (row-end.string_pos),
row-end.pos.charpos);
if (CHARPOS (row-end.string_pos) = 0)
cursor_row_p = (row-continued_p
||
(
/* If an overlay string starts on this glyph
line, then put the cursor here, but only
if not on the first buffer line and there
are no characters there. */
((CHARPOS (row-start.string_pos)) == -1)
((CHARPOS (row-end.string_pos)) -1)
(row-start.pos.charpos 1)
));
else if (MATRIX_ROW_ENDS_IN_MIDDLE_OF_CHAR_P (row))
{
/* If the row ends in middle of a real character,
and the line is continued, we want the cursor here.
That's because MATRIX_ROW_END_CHARPOS would equal
PT if PT is before the character. */
if (!row-ends_in_ellipsis_p)
cursor_row_p = row-continued_p;
else
/* If the row ends in an ellipsis, then
MATRIX_ROW_END_CHARPOS will equal point after the invisible text.
We want that position to be displayed after the ellipsis. */
cursor_row_p = 0;
}
/* If the row ends at ZV, display the cursor at the end of that
row instead of at the start of the row below. */
else if (row-ends_at_zv_p)
cursor_row_p = 1;
else
cursor_row_p = 0;
}
return cursor_row_p;
}
This works for me and for Kim's test case as far as I can see. However
as can be seen from the fprintf output with my test case it starts
looping when I go to the first character and then press left arrow.
Thus, I think this issue should be left alone for the Emacs 22.1. It
is easy to work around the affected corner case, by using text
properties or a display property rather an overlay with a
before-string. After 22.1, I can take a look at fixing this along the
lines discussed above.
Could you please tell me how then? I want to display text at the top of
a buffer, but I do not want to change the users text in the buffer.
___
emacs-pretest-bug mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Lennart Borgman (gmail) wrote: This works for me and for Kim's test case as far as I can see. However as can be seen from the fprintf output with my test case it starts looping when I go to the first character and then press left arrow. This was wrong. The looping occurs without my changes. The only thing one has to do is to go to the first character in a buffer and then press left arrow. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Chong Yidong wrote: Lennart Borgman (gmail) [EMAIL PROTECTED] writes: /* If the row ends with a newline from a string, we don't want the cursor there, but we still want it at the start of the string if the string starts in this row. If the row is continued it doesn't end in a newline. */ if (CHARPOS (row-end.string_pos) = 0) cursor_row_p = (row-continued_p || ( /* If an overlay string starts on this glyph line, then put the cursor here, but only if not on the first buffer line and there are no characters there. */ ((CHARPOS (row-start.string_pos)) == -1) ((CHARPOS (row-end.string_pos)) -1) (row-start.pos.charpos 1) )); This does not solve the underlying problem, because the unexpected cursor position can occur even if the affected overlay is not on the first line. I trust you that it does not solve the underlying problem, but it works in my case and in the test case Kim supplied. That said I of course believe there can be problems with this solution, but I hope for your comments on that. as can be seen from the fprintf output with my test case it starts looping when I go to the first character and then press left arrow. As you can see, tweaking redisplay can have rather non-trivial effects. Yes, I really believe it can, but I was wrong in this case. The problem is there without my changes. A new small bug. Could you please tell me how then? I want to display text at the top of a buffer, but I do not want to change the users text in the buffer. Why not just use a header line? Because I need several lines and I think it is rather necessary that they move together with the buffer contents to save screen estate. I want to put this at the top of the buffer to make it easier for users to understand what is happening. This is part of nXhtml where I try to adopt James Clark's nxml-mode for editing of XHTML files and also files that are not full XHTML, like php, jsp etc. The framework from nxml-mode parses the XML code in the buffer and gives the user the possibility to use completion of tags, attributes and values in accordance with the DTD. Now in the case of php this headers may not be there in the buffer (since they may instead be created dynamically) so I give the framework a starting state instead. To show the user the starting state I want to (optionally) show these lines in the buffer. Even with this feedback it may be difficult to understand what is happening, but hopefully with it users will learn. So at the top of the buffer I am displaying something like this with the help of an overlay and 'before-string: ?xml version=1.0 encoding=iso-8859-1? !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; html xmlns=http://www.w3.org/1999/xhtml; head titleDummy/title /head body ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Chong Yidong wrote: Lennart Borgman (gmail) [EMAIL PROTECTED] writes: Lennart Borgman (gmail) wrote: This works for me and for Kim's test case as far as I can see. However as can be seen from the fprintf output with my test case it starts looping when I go to the first character and then press left arrow. This was wrong. The looping occurs without my changes. The only thing one has to do is to go to the first character in a buffer and then press left arrow. With current CVS, I do not observe any infloop for the test case you sent. If you think you have observed one, please send a precise recipe. Could you please recompile with the fprint part of the code I sent before? Then start with emacs -Q. For me a continues output from the frpintf statements starts immediately, something like the below. It stops if I enter some text and continues if I go to the beginning of the buffer and then press left arrow again. cont=0, start.string_pos=-1, 1, end=-1, 67 cont=0, start.string_pos=-1, 1, end=-1, 67 cont=0, start.string_pos=-1, 1, end=-1, 1 cont=0, start.string_pos=-1, 1, end=-1, 67 cont=0, start.string_pos=-1, 1, end=-1, 1 cont=0, start.string_pos=-1, 1, end=-1, 67 cont=0, start.string_pos=-1, 1, end=-1, 67 cont=0, start.string_pos=-1, 1, end=-1, 67 cont=0, start.string_pos=-1, 1, end=-1, 67 cont=0, start.string_pos=-1, 1, end=-1, 67 cont=0, start.string_pos=-1, 1, end=-1, 20 cont=0, start.string_pos=-1, 1, end=-1, 1 cont=0, start.string_pos=-1, 1, end=-1, 20 cont=0, start.string_pos=-1, 1, end=-1, 20 cont=0, start.string_pos=-1, 1, end=-1, 20 cont=0, start.string_pos=-1, 1, end=-1, 20 ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Chong Yidong wrote: Lennart Borgman (gmail) [EMAIL PROTECTED] writes: With current CVS, I do not observe any infloop for the test case you sent. If you think you have observed one, please send a precise recipe. Could you please recompile with the fprint part of the code I sent before? Then start with emacs -Q. For me a continues output from the frpintf statements starts immediately, something like the below. It does not loop infinitely, at least for me. The messages stop as soon as Emacs finishes starting up, as expected. It stops if I enter some text and continues if I go to the beginning of the buffer and then press left arrow again. I can't reproduce this. You probably left some of your code in xdisp.c. Yes, you are right. it actually stops if you wait a little longer than I did. But it takes 80-100 turns before it does that. And it starts again if you press left or right arrow. And it stops if you press up or down arrow. Something strange perhaps, but nothing to worry about. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Chong Yidong wrote:
[EMAIL PROTECTED] (Kim F. Storm) writes:
IIRC, the original problem I tried to solve is shown by this test-case:
(progn
(switch-to-buffer (get-buffer-create *test*))
(erase-buffer)
(insert .\n\n.\n\n)
(goto-char (point-min))
(let ((ov (make-overlay 4 7)))
(overlay-put ov 'display Ax\nyB))
(goto-char (point-max)))
With my change, moving the cursor places it on the 'A'.
Without my change, moving the cursor places it on the 'y'.
So my change may be incorrect - but it _does_ solve a real problem.
OK, now I see the problem.
I believe the underlying fault is not in cursor_row_p, but in
set_cursor_from_row, on xdisp.c:11948:
pos = string_buffer_position (w, string, string_before_pos);
/* If STRING is from overlay, LAST_POS == 0. We skip such glyphs
because we always put cursor after overlay strings. */
while (pos == 0 glyph stop)
{
string = glyph-object;
The assumption made in the comment is not correct:
string_buffer_position returns non-zero values for overlay strings
with the `display' property. In xdisp.c:4446:
prop = Fget_char_property (pos, Qdisplay, Qnil);
if (!NILP (prop) display_prop_string_p (prop, string))
found = 1;
This suggests that the way to fix this is to change
string_buffer_position to do what that says.
I tested with !display_prop_string_p at the two places in
string_buffer_position where it occurs. That does the correct thing in
my case, but not in Kim's example AFAICS.
In Kim's example the cursor stops after the 'display part when moving
char by char from left or right. It stays on that position for an extra
left or right arrow.
Checking if the string is from 'display at the correct position in
set_cursor_from_row could perhaps cure the problem. There is a test now
for Qdisplay, but it looks like this test might be disabled by the while
loop right above it which skips all overlays.
However, it is dangerous
to change string_buffer_position right now, because it's called from
several places in xdisp.c. Changing its behavior runs a serious risk
of introducing subtle bugs.
Maybe. They are either in set_cursor_from_row or note_mouse_highlight.
___
emacs-pretest-bug mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Lennart Borgman (gmail) wrote: I want to put an overlay at the top of a buffer and display several lines of text there. I use an overlay of length 1 at point 1 with a 'before-string property to do this. Doing this I see some strange display problems when moving point to the beginning of buffer. When (point) is 1 I want the cursor to be displayed after the 'before-string. And as a pessimist I fear that it might be displayed before the 'before-string. However none of these alternatives happen. Instead the cursor is displayed at the end of the first line of the 'before-string. To reproduce the problem eval this code and go to the beginning of the buffer: (defvar temp-ovl nil) (defun temp-toggle-ovl() (interactive) (if temp-ovl (progn (delete-overlay temp-ovl) (setq temp-ovl nil)) (setq temp-ovl (make-overlay 1 1)) (let ((s A string\nwith several rows\nthat should be at top\n) (put-text-property 0 (length s) 'face (list (cons 'background-color yellow)) s) (overlay-put temp-ovl 'before-string s I have attached an image display the cursor at point 1. In GNU Emacs 22.0.97.1 (i386-mingw-nt5.1.2600) of 2007-04-09 Could I get some feedback on this please? I know now that the problem exists also on GNU/Linux. It looks to me like it could be easy to fix, but I do not know the code involved for displaying the cursor, 'before-string etc. I would really like this bug to be fixed before the release. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Ugly W32 display bug - fontified letters chopped on right
Richard Matthew Stallman wrote: The Windows system was using ClearType. Changing that setting fixed the problem. Thanks Eli. Should Emacs users always turn off use of ClearType? If so, can Emacs do it automatically? If not, is this documented in PROBLEMS or somewhere suitable? No, unfortunately there are cases where it should be turned on instead. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Eli Zaretskii wrote:
From: Chong Yidong [EMAIL PROTECTED]
Date: Wed, 11 Apr 2007 13:46:37 -0400
Cc: emacs-pretest-bug@gnu.org
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
I want to put an overlay at the top of a buffer and display several
lines of text there. I use an overlay of length 1 at point 1 with a
before-string property to do this... the cursor is displayed at the
end of the first line of the 'before-string.
[Modified test function]:
(defun foo ()
(interactive)
(let ((o (make-overlay 1 1))
(s (propertize A string\nwith several rows\nat top\n
'face 'highlight)))
(overlay-put o 'before-string s)))
This buglet appears to be due to the following change:
2005-07-13 Kim F. Storm [EMAIL PROTECTED]
* xdisp.c (cursor_row_p): Row is ok if cursor is at newline
from string, but string starts on this line (so we always
position cursor at start of string).
The relevant code is at xdisp.c:15861:
if (PT == MATRIX_ROW_END_CHARPOS (row))
{
/* If the row ends with a newline from a string, we don't want
the cursor there, but we still want it at the start of the
string if the string starts in this row.
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row-end.string_pos) = 0)
cursor_row_p = (row-continued_p
|| PT = MATRIX_ROW_START_CHARPOS (row));
Changing this last line to `cursor_row_p = row-continued_p;', as it
was before, eliminates the bug. I haven't thought about how to fix
this, though.
FWIW, I wouldn't touch this so close to the release: if no one noticed
this since July 2005, it's hardly a grave bug.
How do you know? This just looks so strange so it could well be a grave bug.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Ugly W32 display bug - fontified letters chopped on right
Juanma Barranquero wrote: On 4/11/07, Richard Matthew Stallman [EMAIL PROTECTED] wrote: Should Emacs users always turn off use of ClearType? No. ClearType improves readability, and the problems depend on the font used and perhaps other factors. In my setup, for example, ClearType is quite usable. If so, can Emacs do it automatically? ClearType cannot be deactivated for specific apps, but it can be for specific fonts, so we could fix it in w32_load_system_font. That'd be overkill IMO. If not, is this documented in PROBLEMS or somewhere suitable? The problem and workaround are documented in PROBLEMS. Maybe it would help users and save developers some time if the problems specific to common fonts where mentioned too? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Chong Yidong wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
if (PT == MATRIX_ROW_END_CHARPOS (row))
{
/* If the row ends with a newline from a string, we don't want
the cursor there, but we still want it at the start of the
string if the string starts in this row.
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row-end.string_pos) = 0)
cursor_row_p = (row-continued_p
|| PT = MATRIX_ROW_START_CHARPOS (row));
Changing this last line to `cursor_row_p = row-continued_p;', as it
was before, eliminates the bug. I haven't thought about how to fix
this, though.
FWIW, I wouldn't touch this so close to the release: if no one noticed
this since July 2005, it's hardly a grave bug.
How do you know? This just looks so strange so it could well be a
grave bug.
Its only effect is that if a before-string spans multiple lines then
the cursor ends up being displayed on the end of the first line. It
does not have any further implications, such as crashing Emacs or
corrupting data.
If that is the case then it is perhaps also easy and not dangerous to
fix it?
As for whether or not to change the code, I guess it's up to KFS.
Yes, I looked at the code but decided it takes me too long time at the
moment. Kim, is this easy for you?
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Kim F. Storm wrote: Lennart Borgman (gmail) [EMAIL PROTECTED] writes: Yes, I looked at the code but decided it takes me too long time at the moment. Kim, is this easy for you? Changes to redisplay are NEVER easy ... I made a seemingly trivial change to fix one bug ... and two years later someone finds a problem with it. IMO, this is not the time to try to fix that. Maybe not, but is not this more about positioning the cursor? The characters are displayed correctly. Moving to char = 2 works correctly. But moving to char = 1 fails. Looks like it could be a corner case to me, ie something that perhaps could be fixed without general impact. BTW I wonder if I did not complain about this two years ago too? But at that time I worked against a different solution since I wanted to get something that worked then. This time I think I need this change to get things working. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Lennart Borgman (gmail) wrote: Kim F. Storm wrote: Lennart Borgman (gmail) [EMAIL PROTECTED] writes: Yes, I looked at the code but decided it takes me too long time at the moment. Kim, is this easy for you? Changes to redisplay are NEVER easy ... I made a seemingly trivial change to fix one bug ... and two years later someone finds a problem with it. IMO, this is not the time to try to fix that. Maybe not, but is not this more about positioning the cursor? The characters are displayed correctly. Moving to char = 2 works correctly. But moving to char = 1 fails. Looks like it could be a corner case to me, ie something that perhaps could be fixed without general impact. BTW I wonder if I did not complain about this two years ago too? But at that time I worked against a different solution since I wanted to get something that worked then. This time I think I need this change to get things working. I looked a bit at the code. (First time I used tags, quite nice.) Is it in set_point_both in intervals.c that the magic happens? It looks from that code like internally an intangible property is used in cases like this. I therefore compared using 'before-string with using (put-text-property 1 (point) 'intangible t) The cursor moves quite differently in those cases. Is there an intangible property missing internally on line endings in 'before-string? (A wild guess of course, but the best I can do at the moment.) BTW I also noticed that using 'before-string like I did here also influences undo intervals. Quite strange. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Lennart Borgman (gmail) wrote: I looked a bit at the code. (First time I used tags, quite nice.) Is it in set_point_both in intervals.c that the magic happens? It looks from that code like internally an intangible property is used in cases like this. And that was totally wrong of course. That is not the display code. Looking at the code Chong mentioned instead. BTW I also noticed that using 'before-string like I did here also influences undo intervals. Quite strange. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Chong Yidong wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
if (PT == MATRIX_ROW_END_CHARPOS (row))
{
/* If the row ends with a newline from a string, we don't want
the cursor there, but we still want it at the start of the
string if the string starts in this row.
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row-end.string_pos) = 0)
cursor_row_p = (row-continued_p
|| PT = MATRIX_ROW_START_CHARPOS (row));
Changing this last line to `cursor_row_p = row-continued_p;', as it
was before, eliminates the bug. I haven't thought about how to fix
this, though.
FWIW, I wouldn't touch this so close to the release: if no one noticed
this since July 2005, it's hardly a grave bug.
How do you know? This just looks so strange so it could well be a
grave bug.
Its only effect is that if a before-string spans multiple lines then
the cursor ends up being displayed on the end of the first line. It
does not have any further implications, such as crashing Emacs or
corrupting data.
As for whether or not to change the code, I guess it's up to KFS.
Looking at the logic it seems like it perhaps should be like below
instead? This at least works in my case. The current test just seems
useless. Or perhaps I am just very bad at reading C code?
Index: xdisp.c
===
RCS file: /cvsroot/emacs/emacs/src/xdisp.c,v
retrieving revision 1.1146
diff -c -r1.1146 xdisp.c
*** xdisp.c 10 Apr 2007 15:57:25 - 1.1146
--- xdisp.c 12 Apr 2007 00:40:36 -
***
*** 15859,15865
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row-end.string_pos) = 0)
cursor_row_p = (row-continued_p
! || PT = MATRIX_ROW_START_CHARPOS (row));
else if (MATRIX_ROW_ENDS_IN_MIDDLE_OF_CHAR_P (row))
{
/* If the row ends in middle of a real character,
--- 15859,15865
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row-end.string_pos) = 0)
cursor_row_p = (row-continued_p
! || PT MATRIX_ROW_START_CHARPOS (++row));
else if (MATRIX_ROW_ENDS_IN_MIDDLE_OF_CHAR_P (row))
{
/* If the row ends in middle of a real character,
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Ugly W32 display bug - fontified letters chopped on right
Eli Zaretskii wrote: Date: Wed, 11 Apr 2007 22:53:18 +0200 From: Lennart Borgman (gmail) [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], Kim F. Storm [EMAIL PROTECTED] Maybe it would help users and save developers some time if the problems specific to common fonts where mentioned too? What problems are those? I mean those specific cases that has been discussed here lately. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Display problems with 'before-string in overlay
I want to put an overlay at the top of a buffer and display several lines of text there. I use an overlay of length 1 at point 1 with a 'before-string property to do this. Doing this I see some strange display problems when moving point to the beginning of buffer. When (point) is 1 I want the cursor to be displayed after the 'before-string. And as a pessimist I fear that it might be displayed before the 'before-string. However none of these alternatives happen. Instead the cursor is displayed at the end of the first line of the 'before-string. To reproduce the problem eval this code and go to the beginning of the buffer: (defvar temp-ovl nil) (defun temp-toggle-ovl() (interactive) (if temp-ovl (progn (delete-overlay temp-ovl) (setq temp-ovl nil)) (setq temp-ovl (make-overlay 1 1)) (let ((s A string\nwith several rows\nthat should be at top\n) (put-text-property 0 (length s) 'face (list (cons 'background-color yellow)) s) (overlay-put temp-ovl 'before-string s I have attached an image display the cursor at point 1. In GNU Emacs 22.0.97.1 (i386-mingw-nt5.1.2600) of 2007-04-09 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: miss spell in `accept-process-output' doc string
Glenn Morris wrote: Stefan Monnier wrote: The iff idiom is sufficiently common that we don't want to shy away from it just at this one place. So either we rule it out everywhere, or we use it liberally. Sufficiently common in Emacs (~ 600 instances); I've never seen it anywhere else as far as I remember. All it does is save some typing at the expense of confusing people from time to time. Personally, I think it should not be used. I believe it is understandable to people used to math and logics, but the very bad thing about it is that in the context of more normal English text (like a doc string) it may very well be taken for a misspelling of if. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Error when creating new frame
jpff wrote: I attempted to create a new frame from the File menu. The frame is created but I always get this error: Debugger entered--Lisp error: (wrong-number-of-arguments #[nil =8c0=8c1!=83 =8c1=8c2!=88=8c0=8c3!=85=8c3=8c2!=87 [functionp tool-bar-mode -1 blink-cursor-mode] 2] 1) #[nil =8c0=8c1!=83\n=8c1=8c2!=88=8c0=8c3!=85=8c3=8c2!=87 [functionp tool-bar-mode -1 blink-cursor-mode] 2](#frame [EMAIL PROTECTED] 0x9312880) run-hook-with-args(#[nil =8c0=8c1!=83\n=8c1=8c2!=88=8c0=8c3!=85=8c3=8c2!=87 [functionp tool-bar-mode -1 blink-cursor-mode] 2] #frame [EMAIL PROTECTED] 0x9312880) make-frame() make-frame-command() call-interactively(make-frame-command) As far as I can tell the problem is my initialisation (setq after-make-frame-functions (function (lambda (f) (tool-bar-mode -1 But the documentation for after-make-frame-functions suggests this is correct and I call (tool-bar-mode -1) always in .emacs I do not know the cause of the problem you see, but here are some comments: - I think you should write (tool-bar-mode 1) now to turn on tool-bar-mode. - I can not reproduce the traceback when I just set after-make-frame-functions after start up. (I did not try to put it .emacs) - What is the value of your after-make-frame-functions? From the traceback it looks a bit strange. I really cannot see the problem and it did work in emac 21 In GNU Emacs 22.0.97.4 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2007-04-07 on cardew ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
