Re: Redraw problem with overlapping frames
David Kastrup <[EMAIL PROTECTED]> writes: >> When I have overlapping frames and issue a command in the lower frame >> that will cause the minibuffer to be extended in size (here: >> emacs-version), then after the resize, there is redraw cruft in the >> lower frame (which disappears once the minibuffer is shrunk again). >> One can't consistently trigger this, and the probability of getting >> this behavior is much lower when compared to versions from the >> beginning of the year. I would not recommend trying to fix this in >> EMACS_22_BASE as the effect lasts only temporarily (until the >> minibuffer gets shrunk again). For Emacs 23, however, one might want >> to see how it is triggered. >> >> I have only ever seen this effect with overlapping Emacs frames from >> the same session: overlapping frames from other applications possibly >> don't trigger it (no guarantees, though). I include a screenshot. > > Uh, no guarantees... It turns out that when I place something like a > shell window partially obscuring an Emacs frame with, say, a shell > buffer running some compilation, then I get lots of display cruft in > the Emacs frame. The cruft occurs in > a) the top line partially obscured by the obscuring window > b) below the bottom line partially obscured > > It would appear that scrolling does copy the material in the partially > obscured cases, but fails to clear the partial lines before > resp. after moving the displayed material at top resp. bottom. I haven't been able to reproduce this at all. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: no set button in Custom buffer
Katsumi Yamaoka <[EMAIL PROTECTED]> writes: > When I run `customize-option', I don't see the Set button in > the Custom buffer. Maybe this is caused by the recent changes > in cus-edit.el. It's been moved to the toolbar. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: clipboard integration hangs pasting text from emacs
Nick Roberts <[EMAIL PROTECTED]> writes: > Jason Rumney writes: > > Peter Wisnovsky wrote: > > > In GNU Emacs 22.0.990.1 (i386-mingw-nt5.1.2600) > > > > > > Loading semantic-edit...done > > > Loading semanticdb-file...done > > > > Emacs 21.1 has been released, so please use that rather than a pretest > > version. > > I think you mean "Emacs 22.1 has been released". I've made the same mistake. > Perhaps we should give the next release a name. I suggest "Bob". ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: memory leak in xpm_load
"Juanma Barranquero" <[EMAIL PROTECTED]> writes: > On 6/6/07, YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> wrote: > >> In xpm_load (if HAVE_XPM and ALLOC_XPM_COLORS), xpm_init_color_cache >> is called twice without an intervening xpm_free_color_cache call, and >> that causes a memory leak ~4KB per XPM image creation. > > Try removing the second one; I think it's a leftover from a patch by Chong. Actually, I think I added the first call by mistake. I removed it. Thanks for spotting the problem. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Changelog mode entry in auto-mode-alist
Dan Nicolaescu <[EMAIL PROTECTED]> writes: > > Is this really desirable? With this change, ChangeLog.sh (for > > instance) opens in change-log-mode rather than shell script mode. > > Maybe we should either revert this change (and use file variables to > > specify the mode for ChangeLog.unicode and similarly-named files), or > > move the change-log-mode entry further down in auto-mode-alist. > > File variables are not very good for non-emacs hackers. We can do it > in emacs, but there are other projects that use the > ChangeLog.BRANCH_NAME convention, we should make using the right mode > easier for those projects. > > I'd vote for moving the change-log-mode further down in > auto-mode-alist. I've split the ChangeLog.[0-9] and ChangeLog.[a-z0-9] entries, and moved the latter further down the list. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Changelog mode entry in auto-mode-alist
The following patch, which was only checked into the trunk, changed
the change-log-mode entry in auto-mode-alist:
2007-05-19 Dan Nicolaescu <[EMAIL PROTECTED]>
* files.el (auto-mode-alist): Change the regexp so that
ChangeLog.unicode and ChangeLog.multi-tty use change-log-mode.
--- files.el2007/05/17 01:12:55 1.899
+++ files.el2007/05/19 23:44:43 1.900
@@ -1924,7 +1924,7 @@
("\\.[sS]\\'" . asm-mode)
("\\.asm\\'" . asm-mode)
("[cC]hange\\.?[lL]og?\\'" . change-log-mode)
- ("[cC]hange[lL]og[-.][0-9]+\\'" . change-log-mode)
+ ("[cC]hange[lL]og[-.][-0-9a-z]+\\'" . change-log-mode)
("\\$CHANGE_LOG\\$\\.TXT" . change-log-mode)
("\\.scm\\.[0-9]*\\'" . scheme-mode)
("\\.[ck]?sh\\'\\|\\.shar\\'\\|/\\.z?profile\\'" . sh-mode)
Is this really desirable? With this change, ChangeLog.sh (for
instance) opens in change-log-mode rather than shell script mode.
Maybe we should either revert this change (and use file variables to
specify the mode for ChangeLog.unicode and similarly-named files), or
move the change-log-mode entry further down in auto-mode-alist.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash: XSetWMIconName, x_set_name_internal, prepare_menu_bars
Richard Stallman <[EMAIL PROTECTED]> writes: > > If my change broke something, then please undo it; but in that case, > > please put in whatever GCPROs are needed for x_encode_text. > > The GCPRO you added in x_encode_text was not deleted. > > I know that, but we are miscommunicating. There needs to be a GCPRO > in x_set_name_internal around the calls to x_encode_text, at least to > protect the variable encoded_name. Or else the code needs to be > rearranged so encoded_name is not used after the calls to > x_encode_text. Ah, now I understand what you are saying. But even if your change had been left in place, wouldn't these GCPRO would have been needed anyway (for the case where HAVE_GTK is false)? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash: XSetWMIconName, x_set_name_internal, prepare_menu_bars
Richard Stallman <[EMAIL PROTECTED]> writes: > So I propose undoing the latest change for x_set_name_internal for > now. > > If my change broke something, then please undo it; but in that case, > please put in whatever GCPROs are needed for x_encode_text. The GCPRO you added in x_encode_text was not deleted. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash: XSetWMIconName, x_set_name_internal, prepare_menu_bars
YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> writes: >> I looked at the GTK+ sources. Apparently, if we don't set >> WM_ICON_NAME ourselves, gtk_window_set_icon_name sets WM_ICON_NAME >> for us. So I think we are perfectly safe. > > But now we can't set the icon title separately from the frame title > using the `icon-name' frame parameter on GTK+ builds. > > So I propose undoing the latest change for x_set_name_internal for > now. I have checked in a patch to revert x_set_name_internal to the version before the latest RMS change. The GCPRO added to x_encode_text has been kept. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash: XSetWMIconName, x_set_name_internal, prepare_menu_bars
Chong Yidong <[EMAIL PROTECTED]> writes: > YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> writes: > >>> After looking at it, I realized there was no need to call >>> x_encode_text in the GTK case. So I separated the two cases >>> completely, which should improve things. >> >> I'm not so familiar with GTK+, but is the call to XSetWMIconName >> unnecessary in the GTK+ case? Previously, it was called in both cases >> and that was the reason for x_encode_text in the GTK+ case. > > I believe this was an oversight. However, on my Gnome desktop, it > makes no observable difference. According to the Xlib specs, > XSetWMIconName sets the WM_ICON_NAME window property, which is a > "string that the client wants to be displayed in association with the > window when it is iconified (for example, in an icon label)". > However, I see the same iconfied window names for GTK and non-GTK > builds, both before and after RMS's change. I looked at the GTK+ sources. Apparently, if we don't set WM_ICON_NAME ourselves, gtk_window_set_icon_name sets WM_ICON_NAME for us. So I think we are perfectly safe. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash: XSetWMIconName, x_set_name_internal, prepare_menu_bars
YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> writes: >> On Fri, 01 Jun 2007 10:51:12 -0400, Richard Stallman <[EMAIL PROTECTED]> >> said: > >> After looking at it, I realized there was no need to call >> x_encode_text in the GTK case. So I separated the two cases >> completely, which should improve things. > > I'm not so familiar with GTK+, but is the call to XSetWMIconName > unnecessary in the GTK+ case? Previously, it was called in both cases > and that was the reason for x_encode_text in the GTK+ case. I believe this was an oversight. However, on my Gnome desktop, it makes no observable difference. According to the Xlib specs, XSetWMIconName sets the WM_ICON_NAME window property, which is a "string that the client wants to be displayed in association with the window when it is iconified (for example, in an icon label)". However, I see the same iconfied window names for GTK and non-GTK builds, both before and after RMS's change. If we want to be safe, we can undo RMS's refactoring on the branch, going back to YAMAMOTO Mitsuharu's patch plus an additional GCPRO for x_encode_text. In either case, we should be getting on with the release! ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash: XSetWMIconName, x_set_name_internal, prepare_menu_bars
Richard Stallman <[EMAIL PROTECTED]> writes: > Thanks for guessing this. > > After your change, there was another similar bug: > x_encode_text can call Lisp code, which would have needed a GCPRO. > > After looking at it, I realized there was no need to call > x_encode_text in the GTK case. So I separated the two cases > completely, which should improve things. > > Would people please test setting the name, in both GTK and non-GTK > builds? Setting the frame title works fine on both GTK and non-GTK builds. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Unexpected recentering
MIYOSHI Masanori <[EMAIL PROTECTED]> writes: > In GNU Emacs 22.0.990 on Windows, when the cursor is moved up to > the taller line, it sometimes jumps back to the center of the > window. This is due to a small change in paren.el that I made in April to work around the recentering-on-continued-lines problem. Recently, I checked in a better fix to the recentering problem, but at the time I did not remove the now unnecessary paren.el workaround in the branch, just the trunk. According to this bug, the workaround is problematic anyway, so I have removed it from the branch too. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: cannot activate font-lock-mode
Richard Stallman <[EMAIL PROTECTED]> writes: > > Font-lock-keywords can not be set any more in the local variables > > section of a file. Use font-lock-defaults instead. > > I find the change in behavior sufficiently mysterious that I'm > not even sure this characterization is correct. > > We want to give users a simple and clear recommendation. > What should it be? Do we want to give a recommendation at all? I suggest simply keeping silent. Setting font-lock-keywords in file-local variables is a hack---it's not documented in the Emacs manual, and it's not something we want to encourage users to do, due to security concerns. Advanced users can search the web to find the workarounds discussed in this thread, or they can simply use hi-lock mode (which *is* documented in the Emacs manual). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash: XSetWMIconName, x_set_name_internal, prepare_menu_bars
YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> writes: >> On Fri, 01 Jun 2007 10:05:41 +0900, YAMAMOTO Mitsuharu <[EMAIL >> PROTECTED]> said: > >> I think this is due to string data relocation caused by ENCODE_UTF_8 >> in x_set_name_internal (GTK+ only). > > GCPRO was missing in the previous patch. Below is a revised one. Yes. I dunno how you managed to deduce that this is the reason for the reported bug, but the patch looks like it DTRT. I've checked it into the branch and trunk for you. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Elisp manual doc of `fontified' property
Richard Stallman <[EMAIL PROTECTED]> writes: > I think it should instead say something like: > > `fontified' >This property says whether the text is ready for display. If nil, >Emacs's redisplay routine will call the `fontification-function' (which >see) to prepare this part of the buffer before it is displayed. >This is used internally by jit-lock. > > The manual also needs updating w.r.t fontification-function since it says > that this var is used for font-lock, whereas it's used for jit-lock. > > Can you please fix it in Emacs 22? I corrected this text along the lines suggested by Stefan. However: > The manual also needs updating w.r.t fontification-function > since it says that this var is used for font-lock, whereas it's > used for jit-lock. In fact, fontification-functions is called from handle_fontified_prop in xdisp.c, so I don't think the current text is incorrect (I just read through it again briefly). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash: XSetWMIconName, x_set_name_internal, prepare_menu_bars
Reiner Steib <[EMAIL PROTECTED]> writes: > report-emacs-bug wrote: > >> Please describe exactly what actions triggered the bug >> and the precise symptoms of the bug: > > My Emacs session which has been already running for several days > (notebook with suspend to disk) crashed. I don't recall which command > triggered the bug. > > (gdb) bt > #0 0xb74fc4ca in memcpy () from /lib/libc.so.6 > #1 0xb77a049e in XChangeProperty () from /usr/lib/libX11.so.6 > #2 0xb77c0711 in XSetTextProperty () from /usr/lib/libX11.so.6 > #3 0xb77c0793 in XSetWMIconName () from /usr/lib/libX11.so.6 > #4 0x080d550a in x_set_name_internal (f=0xa4dd960, name=222515027) > at ~/.../cvs-HEAD/emacs/src/xfns.c:1653 > #5 0x0807efec in prepare_menu_bars () > at ~/.../cvs-HEAD/emacs/src/xdisp.c:9015 > > ... I'll dig around and see what I can find, but OTOH this looks like a crash in the X libraries, probably not related to Emacs. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: cannot activate font-lock-mode
martin rudalics <[EMAIL PROTECTED]> writes:
>> (set (make-local-variable 'font-lock-keywords)
>> ! (font-lock-eval-keywords (or keywords font-lock-keywords)))
>
> Wouldn't this mean that old keywords survive a major-mode change?
> What about the companions in `font-lock-defaults'? In general I
> think all those should survive iff they have been hacked before.
It's saner to treat font-lock-keywords as an internal variable, so
that anything that wants to change font lock highlighting should use
font-lock-defaults or font-lock-add/remove-keywords. This is already
implicitly the case: according to the font-lock-keywords docstring,
Normally the [value of font-lock-keywords] would come from
`font-lock-defaults' ... You can also alter it by calling
`font-lock-add-keywords' or `font-lock-remove-keywords'...
The proximate cause for the problem seen by Francesco Potorti is that
font-lock-set-defaults recomputes the value of font-lock-keywords.
One easy way to avoid this is, as mentioned by Francesco Potorti, to
change font-lock-defaults; another way (since font-lock-add-keywords
runs font-lock-set-defaults) is:
Local variables:
eval: (font-lock-add-keywords nil '("^asdf"))
end:
Since setting font-lock-keywords in file local variables is something
of a hack in the first place, I don't think this should delay the
Emacs 22.1 release.
As for making font-lock-keywords and font-lock-defaults survive a
major-mode change if they have been hacked on before, I think that is
a bad idea, because it introduces an unnecessary complication. Any
"external" Lisp code that hacks font-lock-keywords/defaults and wants
it to persist through major-mode changes can easily arrange to
re-apply its changes.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: cannot activate font-lock-mode
Richard Stallman <[EMAIL PROTECTED]> writes: > Should this fix be installed in Emacs 22.1? > Or is it safer for us to leave that bug unfixed? I suggest not patching Emacs 22.1 at this time. First, this only affects setting font-lock-keywords in local variables, which is an advanced user activity that we generally discourage for security reasons; that is why font-lock-keywords is marked risky. Second, allowing file local variables to change font-lock-keywords seems to violate an implicit assumption made in font-lock that font-lock-keywords is managed by font-lock, and set by either major/minor modes or by higher-level variables such as font-lock-defaults. That assumption is why font-lock-set-defaults inadvertently wipes out the font-lock-keywords set by file-local variables. This may be a simple oversight made when revamping font-lock-keywords earlier in the development cycle, but this just emphasizes the fact that this behavior is delicate. So I think changing it is risky at this stage. Third, for those advanced users that want this feature, there are many ways to work around this problem: calling font-lock-add-keyword using an eval in the file variables section, using hi-lock-mode, etc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
martin rudalics <[EMAIL PROTECTED]> writes: >> I think it's cleaner to put the condition-case outside. Does this >> work for you? > > Good. Eventually, someone could try to avoid theses scans when it's > easy to determine that they fail. I've checked it into the branch. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
martin rudalics <[EMAIL PROTECTED]> writes: >> I couldn't reproduce it on Mac OS X. It only shows an error like >> >> forward-list: Scan error: "Containing expression ends prematurely" > > OK. To prevent this I'd apply something like the attached patch (low > priority). I think it's cleaner to put the condition-case outside. Does this work for you? *** emacs/lisp/textmodes/sgml-mode.el.~1.121.~ 2007-05-14 10:56:30.0 -0400 --- emacs/lisp/textmodes/sgml-mode.el 2007-05-28 08:47:21.0 -0400 *** *** 897,912 ;; Show preceding or following hidden tag, depending of cursor direction. (let ((inhibit-point-motion-hooks t)) (save-excursion ! (message "Invisible tag: %s" ! ;; Strip properties, otherwise, the text is invisible. ! (buffer-substring-no-properties ! (point) ! (if (or (and (> x y) !(not (eq (following-char) ?<))) ! (and (< x y) !(eq (preceding-char) ?>))) ! (backward-list) ! (forward-list))) (defun sgml-validate (command) --- 897,915 ;; Show preceding or following hidden tag, depending of cursor direction. (let ((inhibit-point-motion-hooks t)) (save-excursion ! (condition-case nil ! (message "Invisible tag: %s" ! ;; Strip properties, otherwise, the text is invisible. ! (buffer-substring-no-properties ! (point) ! (if (or (and (> x y) !(not (eq (following-char) ?<))) ! (and (< x y) !(eq (preceding-char) ?>))) ! (backward-list) ! (forward-list ! (error nil) ! (defun sgml-validate (command) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> writes: > I meant the only direct call to `current_column' from > redisplay_internal: > > /* If %c is in the mode line, update it if needed. */ > if (!NILP (w->column_number_displayed) > /* This alternative quickly identifies a common case >where no change is needed. */ > && !(PT == XFASTINT (w->last_point) > && XFASTINT (w->last_modified) >= MODIFF > && XFASTINT (w->last_overlay_modified) >= OVERLAY_MODIFF) > && (XFASTINT (w->column_number_displayed) > != (int) current_column ())) /* iftc */ > w->update_mode_line = Qt; > > and as I said, binding Qinhibit_point_motion_hooks just around this > part as the following patch also works for me on Mac OS X. > > Could someone check if this works on Windows for the original problem? It fixes the bug as seen on GNU/Linux (i.e., with `debug-on-error' on, I no longer see a `forward-list' error with original bug recipe; I never observed the "other operations are blocked" part of the bug report on this platform.) Let's get this into the branch. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
martin rudalics <[EMAIL PROTECTED]> writes: >> This patch works on Mac OS X for the original problem (without my >> previous patch). Adding specbind and unbind_to around the >> `current_column' in redisplay_internal also works. > > I'm still uncertain whether this would catch all occurrences. > > The most simple patch I can come up with is specbinding it within > `display_mode_line' since that's causing the present problems. Please > test it (no other patches needed). This patch does not work for me. I think we should go with the approach suggested by YAMAMOTO Mitsuharu, which does work. It may not be the most general approach---as you pointed out, exotic user-set mode lines might cause failures---but such situations are sufficiently rare that I think it is good enough for 22.1. Could you (or Mitsuharu) implement that and check it in? I am travelling at the moment, and cannot work on this. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
Chong Yidong <[EMAIL PROTECTED]> writes:
>> Maybe you need to use specbind for the `current_column' call in
>> redisplay_internal instead.
>>
>> *** src/xdisp.c.~1.1149.2.2.~Fri May 25 11:00:00 2007
>> --- src/xdisp.c Sun May 27 22:48:48 2007
>> *** redisplay_internal (preserve_echo_area)
>> *** 10888,10893
>> --- 10888,10894
>> Fcons (make_number (redisplaying_p), selected_frame));
>> ++redisplaying_p;
>> specbind (Qinhibit_free_realized_faces, Qnil);
>> + specbind (Qinhibit_point_motion_hooks, Qt);
>>
>> {
>> Lisp_Object tail, frame;
>>
>> This patch works on Mac OS X for the original problem (without my
>> previous patch). Adding specbind and unbind_to around the
>> `current_column' in redisplay_internal also works.
>
> For safety, I would prefer to add specbind and unbind_to around the
> `current_column' in redisplay_internal, instead of binding
> Qinhibit_point_motion_hooks for the entirety of redisplay_internal.
>
> If that works, I suggest checking this into just the branch, and
> investigating further after the release.
BTW, as far as I can tell, this is a satisfactory permanent solution,
not just a temporary hack; so we might as well check it into the trunk
too. However, we may want to overhaul the way column-number-works,
after the release, to avoid problems of this sort.
Thanks.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> writes:
> Maybe you need to use specbind for the `current_column' call in
> redisplay_internal instead.
>
> *** src/xdisp.c.~1.1149.2.2.~ Fri May 25 11:00:00 2007
> --- src/xdisp.c Sun May 27 22:48:48 2007
> *** redisplay_internal (preserve_echo_area)
> *** 10888,10893
> --- 10888,10894
>Fcons (make_number (redisplaying_p), selected_frame));
> ++redisplaying_p;
> specbind (Qinhibit_free_realized_faces, Qnil);
> + specbind (Qinhibit_point_motion_hooks, Qt);
>
> {
> Lisp_Object tail, frame;
>
> This patch works on Mac OS X for the original problem (without my
> previous patch). Adding specbind and unbind_to around the
> `current_column' in redisplay_internal also works.
For safety, I would prefer to add specbind and unbind_to around the
`current_column' in redisplay_internal, instead of binding
Qinhibit_point_motion_hooks for the entirety of redisplay_internal.
If that works, I suggest checking this into just the branch, and
investigating further after the release.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
martin rudalics <[EMAIL PROTECTED]> writes: >>>In GNU Emacs 22.0.990 on Windows, the following operation causes >>>contiguous redisplay of the menu and beeps. And Emacs doesn't >>>accept any operations for a while. >>> >>> emacs -q >>> M-x html-mode ;; in the scratch buffer >>> M-x column-number-mode >>> >>> C-u 8 C-b ;; move back the cursor on `>' of "" >>> C-c C-i ;; runs the command sgml-tags-invisible >> >> >> I can't reproduce this on GNU Emacs 22.0.990.2 (i686-pc-linux-gnu). > > With `debug-on-error' t you do get an error from `forward-list'? Yes, but I don't see the "not accepting any operations" or "continuous redisplay" behaviors. Maybe that part of the bug is specific to Windows. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
MIYOSHI Masanori <[EMAIL PROTECTED]> writes: > In GNU Emacs 22.0.990 on Windows, the following operation causes > contiguous redisplay of the menu and beeps. And Emacs doesn't > accept any operations for a while. > > emacs -q > M-x html-mode ;; in the scratch buffer > M-x column-number-mode > > C-u 8 C-b ;; move back the cursor on `>' of "" > C-c C-i ;; runs the command sgml-tags-invisible I can't reproduce this on GNU Emacs 22.0.990.2 (i686-pc-linux-gnu). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: More on crash this morning
jpff <[EMAIL PROTECTED]> writes: > I reverted to the previous version of xterm and it runs. > With the newer xterm it crashed when using X bit ran in -nw mode in an > xterm. Suggests that the last change for "Yet Another Uncaught X > Error Crash" is the cause but this is beyond my expertise I reverted the change for now. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Recent change to Faccept_process_output
Richard Stallman <[EMAIL PROTECTED]> writes: > Is it on the branch? If so, that would be extremely annoying. This > kind of change obviously shouldn't be made without discussion. > > The reason I have mostly stopped discussing changes with people is > that I expect them to respond mechanically with "Don't make this > change because I want a release NOW". Since I don't agree with that > basis for the conclusion, these responses are not useful. The basis for the conclusion is the danger of breaking things that used to work, which is what happened here. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Recent change to Faccept_process_output
Eli Zaretskii <[EMAIL PROTECTED]> writes: >> From: Romain Francoise <[EMAIL PROTECTED]> >> Date: Sun, 06 May 2007 01:06:31 +0200 >> Cc: emacs-pretest-bug@gnu.org >> >> Chong Yidong <[EMAIL PROTECTED]> writes: >> >> > Is it on the branch? If so, that would be extremely annoying. This >> > kind of change obviously shouldn't be made without discussion. >> >> Yes it's on the branch, for the discussion see this thread: >> >> http://lists.gnu.org/archive/html/bug-gnu-emacs/2007-05/msg0.html >> >> Eli makes a good point: >> >> http://lists.gnu.org/archive/html/bug-gnu-emacs/2007-05/msg3.html > > And Richard now says in a follow-up that he will take out that change. Which all goes to show the silliness of continuing to tinker with the branch instead of releasing it! ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Recent change to Faccept_process_output
Nick Roberts <[EMAIL PROTECTED]> writes: > 2007-05-03 Per Cederqvist > > * process.c (Faccept_process_output): Revert 2006-03-22 change so > that the third argument once again is in microseconds (not > milliseconds). This makes it compatible with Emacs 21 and > earlier. Problem found by Henrik Rindl??w. > > I've seen no discussion about this change. It seems to just revert an > earlier one. Did you read the thread in the archives about why it was made? > > Maybe it solves a problem for Henrik Rindl??w, but it probably causes problems > for many others. Another solution would be to revert back again and explain > in NEWS that this feature is no longer compatible with Emacs 21. Is it on the branch? If so, that would be extremely annoying. This kind of change obviously shouldn't be made without discussion. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
Richard Stallman <[EMAIL PROTECTED]> writes: > > However, 1.40 (2006-08-20) by you is extensive and the changelog says > > "Update to Dave Love's latest version". Was this directly from him? > > We could simply revert to the pre-2006-08-20 version and reapply > subsequent tiny changes. Will satisfy everybody (including RMS)? > > I don't know yet. I need to get more info from Dave Love, and discuss > the matter with a lawyer, to find out whether his previous code is > really ok to use. In that case, why not remove Python support in Emacs 22.1? We can put it back for 22.2, if and when the legal issues get sorted out. Note that Emacs 21 did not have Python support, so this will not be a step backward in that sense. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
Stefan Monnier <[EMAIL PROTECTED]> writes: >> However, 1.40 (2006-08-20) by you is extensive and the changelog says >> "Update to Dave Love's latest version". Was this directly from him? > > Ahh... I guess my memory failed. We should revert this change, then. Could you do this? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
"Juanma Barranquero" <[EMAIL PROTECTED]> writes: > On 4/27/07, Stefan Monnier <[EMAIL PROTECTED]> wrote: > >> While I can imagine myself doing it, I don't remember taking anything from >> the version of your website. Did anybody else do that? > > Excluding lines by you, and removing trivial changes to comments and > version numbers, the current python.el in HEAD contains the following > changes: > ... > All of them are in the tiny category (ten lines or less, excluding > whitespace changes), and none seem to be lifted from anywhere (though > it is up to the individual authors to confirm, of course). > > However, 1.40 (2006-08-20) by you is extensive and the changelog says > "Update to Dave Love's latest version". Was this directly from him? We could simply revert to the pre-2006-08-20 version and reapply subsequent tiny changes. Will satisfy everybody (including RMS)? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
>> Anyway, back to the topic at hand: there's a potential legal problem >> with python.el. Is all the code you wrote for python.el affected, or >> just the 2006-08-20 changes? Before that, there are no changes from >> python.el from you until we get to 2004-12-02. > > Only more recent stuff, I reckon, but I'm not sure exactly what > off-hand. Anything I didn't send (including to gnu-Emacs-sources) or > install myself is best treated as suspect. > >> If it's just the 2006-08-20 stuff: Stefan, is there anyway this can >> easily be removed and still leave a working python.el? Dave, would >> that be acceptable to you? > > I guess that's OK. Could you be a little more specific about what the legal problem is? - Did your previous employment contract forbid you from assigning copyright for your Emacs changes, or was it some other restriction? - Are you in fact free to offer the version python.el available on your webpage, or does your employment contract prevent you from distributing and licensing that version under the GPL? (This doesn't affect Emacs directly, but would help clarify things). - How far back do the above restrictions/problems go? Does it affect the 2004-05-06 merge of the Emacs CVS python.el to your python.el, which was initiated by you on the emacs-pretest-bug mailing list? How about earlier or later versions? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
> There are potential problems due to my previous employer with things I > wrote until I left in April 2006. I'm contractually obliged to inform > the FSF about that, whether or not I consider it spurious or actually > care about GNU. Do these "potential problems" apply also to, e.g., this patch that you sent to emacs-pretest-bug in 2004? http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-05/msg00055.html From:Dave Love Subject: python.el update Date:Thu, 06 May 2004 17:46:33 +0100 These changes to python.el are relative to a previous revision (before one or more rounds of compilation changes) and won't now apply cleanly, but I'm not currently in a position to merge and test them. They rely on a new file of Python code living in `etc' (also attached). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
Luc Teirlinck <[EMAIL PROTECTED]> writes: > I suggest the following small changes to the Changelog (mainly for the > benefit of people who might want to find out when the optional arg for > locate was introduced), as well as the adding of an additional comment > to locate.el Checked in, thanks. ___ 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?)
"Lennart Borgman (gmail)" <[EMAIL PROTECTED]> writes: > 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.) It also shows that the bug can be trivially worked around. I don't think we should make any changes to the redisplay code, at least not for this class of bug. ___ 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?)
"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. > (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
Re: python.el
Glenn Morris <[EMAIL PROTECTED]> writes: > Anyway, back to the topic at hand: there's a potential legal problem > with python.el. Is all the code you wrote for python.el affected, or > just the 2006-08-20 changes? Before that, there are no changes from > python.el from you until we get to 2004-12-02. > > If it's just the 2006-08-20 stuff: Stefan, is there anyway this can > easily be removed and still leave a working python.el? Dave, would > that be acceptable to you? > > Otherwise, our only recourse AFAICS is to remove python.el before the > (imminent) release of Emacs 22. I suggest simply removing python.el. We can add it back for Emacs 22.2 if/when the unspecified legal issues get ironed out. What do people think? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info-scroll-up/down on mode-line
Nick Roberts <[EMAIL PROTECTED]> writes: > Info-scroll-up/down are bound on the mode-line (over the node name) to > mouse-1 and mouse-3. However, in a split window configuaration with Info at > the top and the bottom window selected, clicking there scrolls the _bottom_ > window, and Emacs gets confused if this is already at the top or bottom. Thanks, I checked in a fix for this. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
Richard Stallman <[EMAIL PROTECTED]> writes: > Please install your patch. I installed the patch. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: visiting certain .c file adds to kill ring
Kevin Ryde <[EMAIL PROTECTED]> writes: > With my recent cvs build or the debian snapshot, and starting from > "emacs -Q", visiting the file foo.c below with > > C-x C-f foo.c > > leaves the first line in the kill ring, > > C-y > => inserts "/* hello */ > > where I hoped it would leave the kill ring alone. (In particular it's > not good to have the kill changed when you're doing a cut and paste > from another file into that one.) > > I suspect c-remove-any-local-eval-or-mode-variables in cc-mode.el > shouldn't be using kill-line, but cc-mode is hellishly complicated ... I can't reproduce this. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
Luc Teirlinck <[EMAIL PROTECTED]> writes: > What I did test was that reverting the changes in revisions 1.38 and > 1.40 (the one from today) and then applying the patch below, not only > solves the three bugs reported today, but also solves the three > problems described in the above paragraph. The first two, I checked. > The third one I could not actually check, because I do not use eshell, > but it _should_ be fixed, as my patch eliminates dependence from these > history lists. I verified that this works. The patch looks good, so I checked it in. Thanks! ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
Luc Teirlinck <[EMAIL PROTECTED]> writes: > Undo no longer works in a locate buffer. This is a serious bug and a > regression in Emacs 22 if it does not get fixed. You are supposed to > be able to do essentially everything you can do in a dired buffer > (including undo) in a locate buffer. That is the very purpose of > locate-mode. After studying the patch that introduced this, it seems to me that the one line (buffer-disable-undo) in locate.el:472 was sneaked in without further justification. Luc, could you test if removing this line solves your problem? Also, could you see if the original problem addressed by this patch, i.e. Reverting Locate mode buffers (via locate-update) currently ignores filters from locate-with-filter. It also doesn't work with uniquely renamed buffers, or when locate has been called non-interactively (e.g., from eshell/locate) and locate-history-list and locate-grep-history-list aren't modified. remains solved after removing that line? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: cannot activate font-lock-mode
Stefan Monnier <[EMAIL PROTECTED]> writes: >>> Now, when desktop.el loads it, it asks if I want to apply the >>> font-lock-keywords customisation, because it is risky (is it?). > >> Font-lock can modify arbitrary text properties, such as display >> strings, and not just faces. > > And it can also directly run any code, which is even more immediately scary. > We should probably write a font-lock-keywords-safe-p. Something like the > one below, maybe. > > +(put 'font-lock-keywords 'safe-local-variable 'font-lock-keywords-safe-p) I suggest not changing this until we have time to discuss this, i.e. after the release. It would not be good to introduce a security risk into Emacs at the 11th hour. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
Luc Teirlinck <[EMAIL PROTECTED]> writes: > Francesco Potorti` <[EMAIL PROTECTED]> wrote: > >A bug was apparently introduced in locate.el, but I did not check when >and why. > > That was not the only bug introduced by the following change: > > 2006-09-09 Matt Hodges <[EMAIL PROTECTED]> > > * locate.el (locate-current-search): New variable. > (locate): Set buffer local value. Use current buffer if it is > in Locate mode. > (locate-mode): Disable undo here. > (locate-do-setup): Use locate-current-filter from buffer to be killed. > (locate-update): Use locate-current-search and locate-current-filter. > > Undo no longer works in a locate buffer. This is a serious bug and a > regression in Emacs 22 if it does not get fixed. You are supposed to > be able to do essentially everything you can do in a dired buffer > (including undo) in a locate buffer. That is the very purpose of > locate-mode. > > From the above changelog entry, this bug seems to have been introduced > _on purpose_. What was the purpose of the above changes? They seem to > have been made by somebody who does not understand how other people > use locate mode and only cares about the way he personally uses it. > Who knows what else these changes broke. FWIW, the only discussion of this I could find is here: http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-09/msg00068.html From: Matt Hodges Subject: Reverting locate buffers. Date: Tue, 05 Sep 2006 14:08:37 +0100 Reverting Locate mode buffers (via locate-update) currently ignores filters from locate-with-filter. It also doesn't work with uniquely renamed buffers, or when locate has been called non-interactively (e.g., from eshell/locate) and locate-history-list and locate-grep-history-list aren't modified. The attached patch has suggested changes to address these issues. If suitable, a ChangeLog entry is: 2006-09-05 Matt Hodges <[EMAIL PROTECTED]> * locate.el (locate-current-search): New variable. (locate): Set buffer local value. Use current buffer if it is in Locate mode. (locate-mode): Disable undo here. (locate-do-setup): Use locate-current-filter from buffer to be killed. (locate-update): Use locate-current-search and locate-current-filter. Thanks, Matt ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: cannot activate font-lock-mode
Francesco Potorti` <[EMAIL PROTECTED]> writes: >> > I answer y, but I get the message: Toggling font-lock-mode off; >> > better pass an explicit argument. >> >>This is done in `hack-one-local-variable' where >> >> (funcall mode) >> >>simply executes `font-lock-mode' which toggles font-lock mode off since >>it does not get an argument. > > Why does it do that? Shouldn't it simply set font-lock-keywords to the > value I specified? This is what happened in Emacs 21, as far as I can > tell. Not because of font-lock-keywords, but because of this line: # mode: font-lock Note that font-lock-mode is now turned on by default. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: cannot activate font-lock-mode
Francesco Potorti` <[EMAIL PROTECTED]> writes: > Now, when desktop.el loads it, it asks if I want to apply the > font-lock-keywords customisation, because it is risky (is it?). Font-lock can modify arbitrary text properties, such as display strings, and not just faces. So one can imagine a trojan horse that works through font-lock (probably not practical, but not obviously impossible either). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: patch for locate.el when called with prefix arg
Francesco Potorti` <[EMAIL PROTECTED]> writes: > Calling C-u M-x locate RET gives no results, whatever the command line. > > A bug was apparently introduced in locate.el, but I did not check when > and why. I found the problem in 22.0.96, but, by looking at the source, > it is still there in 22.0.98. > > Here is a patch and Changelog entry: Thanks. I've checked the patch in. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Compile failure due to Xaw3d include file issues
Glenn Morris <[EMAIL PROTECTED]> writes: > It seems bad form to abort in the middle of the build though. A small > addition to configure.in makes it clearer IMO: I agree. I checked this in. Thanks. (I also added an Xaw3d-without-Xaw item to TODO.) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Compile failure due to Xaw3d include file issues
Glenn Morris <[EMAIL PROTECTED]> writes: > Ulrich Mueller wrote: > >>libXaw Xaw3d >> 0 0 fails in lwlib.c due to missing X11/Xaw/Paned.h >> 0 1 OK, links against libXaw3d.so.8 > > I think it's also going to fail in this case if you configure > --without-toolkit-scroll-bars --with-x-toolkit=lucid because then > HAVE_XAW3D never gets set. > > And if you configure with no options, it's not going to realize that > it could in fact use the Xaw3d include files to build the lucid > toolkit. > > Emacs 21 had the same problem, and since no-one ever reported it here > (?), it doesn't seem that big an issue. So rather than making > significant changes to the build process so close to the release, it > might be best just to document the problem and leave it alone for now. Yes, I agree. I can put the patch in PROBLEMS. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Compile failure due to Xaw3d include file issues
Ulrich Mueller <[EMAIL PROTECTED]> writes: > Hi, > not entirely sure if this is really an Emacs bug (or if X.Org is to > blame): > > Emacs 22.0.97 compilation fails on a system where: > - Xaw3d is installed, > - libXaw is not installed. Thanks for the bug report. Could you test the following patch? If you could take the time, please see if it works as expected with all 4 combinations of Xaw3d and libXaw installed/not installed. *** emacs/src/xfns.c.~1.681.~ 2007-03-24 11:49:48.0 -0400 --- emacs/src/xfns.c2007-04-18 01:18:52.0 -0400 *** *** 72,79 --- 72,84 #include #ifndef USE_MOTIF + #ifdef HAVE_XAW3D + #include + #include + #else /* !HAVE_XAW3D */ #include #include + #endif /* HAVE_XAW3D */ #endif /* USE_MOTIF */ #ifdef USG *** emacs/src/xmenu.c.~1.317.~ 2007-01-20 23:18:14.0 -0500 --- emacs/src/xmenu.c 2007-04-18 01:15:43.0 -0400 *** *** 82,88 --- 82,92 #include #include #ifdef USE_LUCID + #ifdef HAVE_XAW3D + #include + #else /* !HAVE_XAW3D */ #include + #endif /* HAVE_XAW3D */ #endif /* USE_LUCID */ #include "../lwlib/lwlib.h" #else /* not USE_X_TOOLKIT */ *** emacs/lwlib/lwlib.c.~1.55.~ 2007-02-27 23:25:05.0 -0500 --- emacs/lwlib/lwlib.c 2007-04-18 01:21:44.0 -0400 *** *** 48,54 --- 48,58 #endif /* not USE_MOTIF && USE_LUCID */ #endif #if defined (USE_XAW) + #ifdef HAVE_XAW3D + #include + #else /* !HAVE_XAW3D */ #include + #endif /* HAVE_XAW3D */ #include "lwlib-Xaw.h" #endif *** emacs/lwlib/lwlib-Xaw.c.~1.25.~ 2007-02-26 22:07:08.0 -0500 --- emacs/lwlib/lwlib-Xaw.c 2007-04-18 01:22:33.0 -0400 *** *** 35,46 --- 35,55 #include #include + #ifdef HAVE_XAW3D + #include + #include + #include + #include + #include + #include + #else /* !HAVE_XAW3D */ #include #include #include #include #include #include + #endif /* HAVE_XAW3D */ #include ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: expand-file-name leaves "/../" in expansions at times
Jason Rumney <[EMAIL PROTECTED]> writes: > Chong Yidong wrote: >> Convert filename name to absolute, and canonicalize it. >> >> All your examples are consistent with this behavior. The important >> thing is that DEFAULT-DIRECTORY is only consulted if the filename is >> relative. >> > But shouldn't the "and canonicalize it" step involve replacing the ../ > with the actual directories they represent? Hmm, that's true. It seems that Emacs treats both / and /../ as semi-independent canonical directories, which is a little counter-intuitive. (expand-file-name "/../a") "/../a" (expand-file-name "/../../a") "/a" On the other hand, I just checked, and this behavior seems to have been around since at least Emacs 20. Glancing through the source code, this behavior seems to be deliberate---something to do with the "superroot directory". Maybe someone on this list can elucidate? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: expand-file-name leaves "/../" in expansions at times
Diane Murray <[EMAIL PROTECTED]> writes: > I have no idea if this is a bug or not, but sometimes > `expand-file-name' returns a path with "/../" at the beginning of it. > Below are a few simple examples. C-h f expand-file-name RET expand-file-name is a built-in function in `C source code'. (expand-file-name name &optional default-directory) Convert filename name to absolute, and canonicalize it. Second arg default-directory is directory to start with if name is relative (does not start with slash); if default-directory is nil or missing, the current buffer's value of `default-directory' is used. All your examples are consistent with this behavior. The important thing is that DEFAULT-DIRECTORY is only consulted if the filename is relative. Also, note that (/../ == /). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display margin errors on a tty
Richard Stallman <[EMAIL PROTECTED]> writes: > It forces a glyph matrix reallocation after each call to > enlarge_window. The slowdown will be undetectable since redisplay is > so fast on text terminals anyway. > > I think this is a good solution, if it works. It is simple, and it is > safe. And the slowdown is insignificant compared with everything else > that is going on when you change window sizes. > > However, KFS wrote > > No, the problem seems to come up as long as there is a window with a > marginal area in use. > > Does that mean your fix doesn't actually solve the problem? It papers over it. An optimization in dispnew.c gets screwed up when display margins are present for terminal display. I just checked in a patch that basically disables the optimization when we are in that situation. So it's not *really* solving the problem. But it's a lot safer, and AFAICT it completely prevents the problem from appearing. So we can probably live with it for now. ___ 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
[EMAIL PROTECTED] (Kim F. Storm) writes: > Richard Stallman <[EMAIL PROTECTED]> writes: > >> Does drawing cursor in the wrong position on multi-line before-strings >> cause "real trouble"? >> >> Yes. Whenever the cursor is in the wrong position, that is real trouble. >> >> Is the display of multi-line before-strings an >> "important feature"? >> >> before-strings is an important feature. It is true that multi-line >> before-strings are not often used. But we should make such a feature >> work correctly in all cases, not just most cases. > > Chong, > > I suggest you install the patch (the one you feel most comfortable > about), make a new pretest, and let's get on with the release. I did 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
Richard Stallman <[EMAIL PROTECTED]> writes: > 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. Does drawing cursor in the wrong position on multi-line before-strings cause "real trouble"? Is the display of multi-line before-strings an "important feature"? ___ 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)" <[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.
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.
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.
2. You have a mixup between Lisp_Object and int in the return value
of Fget_char_property.
3. The call to get_char property is unnecessary, since
string_buffer_position checks only the display property.
I fixed up the patch; see below.
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.
*** emacs/src/xdisp.c.~1.1146.~ 2007-04-14 11:35:10.0 -0400
--- emacs/src/xdisp.c 2007-04-15 12:37:47.0 -0400
***
*** 15850,15865
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. */
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,
--- 15850,15886
struct glyph_row *row;
{
int cursor_row_p = 1;
+ int row_end_charpos = MATRIX_ROW_END_CHARPOS (row);
! if (PT == row_end_charpos)
{
! /* If the row ends with a newline from a string (other than a
!display string), we don't want the cursor there.
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row->end.string_pos) >= 0)
! {
! if (row->continued_p)
! cursor_row_p = 1;
! else
! {
! /* Check for `display' property. */
! struct glyph *beg = row->glyphs[TEXT_AREA];
! struct glyph *end = beg + row->used[TEXT_AREA] - 1;
! struct glyph *glyph;
! Lisp_Object prop = Qnil;
!
! for (glyph = end;
! !STRINGP (glyph->object) && glyph > beg;
! --glyph)
! ;
!
! cursor_row_p =
! (STRINGP (glyph->object)
!&& (string_buffer_position (w, glyph->object,
!row_end_charpos)
!> 0));
! }
! }
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 margin errors on a tty
[EMAIL PROTECTED] (Kim F. Storm) writes: > Chong Yidong <[EMAIL PROTECTED]> writes: > >> Eli Zaretskii <[EMAIL PROTECTED]> writes: >> >>>> It forces a glyph matrix reallocation after each call to >>>> enlarge_window. The slowdown will be undetectable since redisplay is >>>> so fast on text terminals anyway. >>> >>> Are you sure redisplay is ``so fast''? what about remote connections >>> via a slow link? >> >> I don't have a way to test this, but I believe the cost should be >> negligible even for that case. In the very worst case scenario it, >> will only lead to one extra screen redraw every time you do C-x ^. > > Could you test if the current window has non-empty left margin, > and only set the garbaged flag in that case? No, the problem seems to come up as long as there is a window with a marginal area in use. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
[EMAIL PROTECTED] (Kim F. Storm) writes:
> (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.
I think the following approach may work.
It reverts your cursor_row_p change, and deals with overlays
containing display properties by modifying adjust_point_for_property
so that one is never at the start of such an overlay (the behavior for
display text properties is left unchanged). It doesn't deal with the
other issue I raised (i.e., the apparently false assumption in the way
set_cursor_from_row uses string_buffer_position). However, dealing
with the opens up another can of worms, and the current patch seems
sufficient to provide good behavior for all cases I've tried.
Of course, redisplay can lead to some pretty subtle bugs. It's still
debatable whether we want to make such a change at this stage.
*** emacs/src/xdisp.c.~1.1146.~ 2007-04-14 16:57:50.0 -0400
--- emacs/src/xdisp.c 2007-04-14 19:03:17.0 -0400
***
*** 15854,15865
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));
else if (MATRIX_ROW_ENDS_IN_MIDDLE_OF_CHAR_P (row))
{
/* If the row ends in middle of a real character,
--- 15854,15863
if (PT == MATRIX_ROW_END_CHARPOS (row))
{
/* If the row ends with a newline from a string, we don't want
!the cursor there.
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;
else if (MATRIX_ROW_ENDS_IN_MIDDLE_OF_CHAR_P (row))
{
/* If the row ends in middle of a real character,
*** emacs/src/keyboard.c.~1.899.~ 2007-04-14 16:26:52.0 -0400
--- emacs/src/keyboard.c2007-04-14 19:22:33.0 -0400
***
*** 2006,2027
}
check_composition = 0;
if (check_display
! && PT > BEGV && PT < ZV
&& !NILP (val = get_char_property_and_overlay
(make_number (PT), Qdisplay, Qnil, &overlay))
! && display_prop_intangible_p (val)
! && (!OVERLAYP (overlay)
! ? get_property_and_range (PT, Qdisplay, &val, &beg, &end, Qnil)
! : (beg = OVERLAY_POSITION (OVERLAY_START (overlay)),
!end = OVERLAY_POSITION (OVERLAY_END (overlay
! && (beg < PT /* && end > PT <- It's always the case. */
! || (beg <= PT && STRINGP (val) && SCHARS (val) == 0)))
! {
! xassert (end > PT);
! SET_PT (PT < last_pt
! ? (STRINGP (val) && SCHARS (val) == 0 ? beg - 1 : beg)
! : end);
! check_composition = check_invisible = 1;
}
check_display = 0;
if (check_invisible && PT > BEGV && PT < ZV)
--- 2006,2041
}
check_composition = 0;
if (check_display
! && PT >= BEGV && PT < ZV
&& !NILP (val = get_char_property_and_overlay
(make_number (PT), Qdisplay, Qnil, &overlay))
! && display_prop_intangible_p (val))
! {
! if (OVERLAYP (overlay))
! {
! beg = OVERLAY_POSITION (OVERLAY_START (overlay));
! end = OVERLAY_POSITION (OVERLAY_END (overlay));
! if (beg <= PT)
! {
! SET_PT (PT < last_pt
! ? (beg > BEGV) ? beg - 1 : end
! : end);
! check_composition = check_invisible = 1;
! }
! }
! else if (PT > BEGV)
! {
! get_property_and_range (PT, Qdisplay, &val, &beg, &end, Qnil);
! xassert (end > PT);
! if ((beg < PT)
! || (beg == PT && STRINGP (val) && SCHARS (val) == 0))
! {
! SET_PT (PT < last_pt
! ? (STRINGP (val) && SCHARS (val) == 0 ? beg - 1 : beg)
! : end);
! check_composition = check_invisible = 1;
! }
! }
}
check_display = 0;
if (check_invisible && PT > BEGV && PT < ZV)
___
emacs-pretest-bug mailing lis
Re: display margin errors on a tty
Eli Zaretskii <[EMAIL PROTECTED]> writes: >> It forces a glyph matrix reallocation after each call to >> enlarge_window. The slowdown will be undetectable since redisplay is >> so fast on text terminals anyway. > > Are you sure redisplay is ``so fast''? what about remote connections > via a slow link? I don't have a way to test this, but I believe the cost should be negligible even for that case. In the very worst case scenario it, will only lead to one extra screen redraw every time you do C-x ^. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display margin errors on a tty
Chong Yidong <[EMAIL PROTECTED]> writes: > I managed to reproduce the bug. > > emacs -nw > M-: (set-window-margins (selected-window) 1) RET > C-x 2 > C-x ^ > > Pressing left and right button and inserting text now makes it clear > that redisplay is broken. > > The call to enlarge-window and set-window-margins appears to be > essential to producing this bug. I can't seem to track down this bug. There seems to be some subtle bug in the optimizations for reusing glyph matrices on text terminals, which only shows up when display margins are present. For the release, I propose the following hack. It forces a glyph matrix reallocation after each call to enlarge_window. The slowdown will be undetectable since redisplay is so fast on text terminals anyway. I'll try to track this down completely after the release. Any objections? (I'll also insert the appropriate comments explaining the situation, of course.) *** emacs/src/window.c.~1.575.~ 2007-03-31 10:10:14.0 -0400 --- emacs/src/window.c 2007-04-14 11:43:03.0 -0400 *** *** 4415,4422 XSETFASTINT (p->last_modified, 0); XSETFASTINT (p->last_overlay_modified, 0); /* Adjust glyph matrices. */ ! adjust_glyphs (XFRAME (WINDOW_FRAME (XWINDOW (window; } --- 4415,4425 XSETFASTINT (p->last_modified, 0); XSETFASTINT (p->last_overlay_modified, 0); + if (!FRAME_WINDOW_P (WINDOW_XFRAME (XWINDOW (window + SET_FRAME_GARBAGED (WINDOW_XFRAME (XWINDOW (window))); + /* Adjust glyph matrices. */ ! adjust_glyphs (WINDOW_XFRAME (XWINDOW (window))); } ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Richard Stallman <[EMAIL PROTECTED]> writes:
> At this stage of the release cycle, a grave bug is one that makes Emacs
> crash, or causes really bad redisplay behaviour.
>
> I think redisplay bugs are serious bugs.
In this case, I know what the fix is (see attached patch). The
trouble is that it's a rather big change, and likely to cause
problems, whereas the problem it corrects is not commonly encountered
(cursor positioning in multi-line overlay before/after-strings).
So I'd like to delay this till after Emacs 22.1. WDYT?
*** emacs/src/keyboard.c.~1.899.~ 2007-04-04 13:05:31.0 -0400
--- emacs/src/keyboard.c2007-04-13 14:04:15.0 -0400
***
*** 2010,2021
&& !NILP (val = get_char_property_and_overlay
(make_number (PT), Qdisplay, Qnil, &overlay))
&& display_prop_intangible_p (val)
! && (!OVERLAYP (overlay)
! ? get_property_and_range (PT, Qdisplay, &val, &beg, &end, Qnil)
! : (beg = OVERLAY_POSITION (OVERLAY_START (overlay)),
!end = OVERLAY_POSITION (OVERLAY_END (overlay
! && (beg < PT /* && end > PT <- It's always the case. */
! || (beg <= PT && STRINGP (val) && SCHARS (val) == 0)))
{
xassert (end > PT);
SET_PT (PT < last_pt
--- 2010,2022
&& !NILP (val = get_char_property_and_overlay
(make_number (PT), Qdisplay, Qnil, &overlay))
&& display_prop_intangible_p (val)
! && (OVERLAYP (overlay)
! ? (beg = OVERLAY_POSITION (OVERLAY_START (overlay)),
!end = OVERLAY_POSITION (OVERLAY_END (overlay)),
!beg <= PT)
! : (get_property_and_range (PT, Qdisplay, &val, &beg, &end, Qnil),
!(beg < PT
! || (beg <= PT && STRINGP (val) && SCHARS (val) == 0)
{
xassert (end > PT);
SET_PT (PT < last_pt
*** emacs/src/dispextern.h.~1.225.~ 2007-01-21 13:34:43.0 -0500
--- emacs/src/dispextern.h 2007-04-13 13:42:58.0 -0400
***
*** 2636,2642
struct glyph_row *row_containing_pos P_ ((struct window *, int,
struct glyph_row *,
struct glyph_row *, int));
! int string_buffer_position P_ ((struct window *, Lisp_Object, int));
int line_bottom_y P_ ((struct it *));
int display_prop_intangible_p P_ ((Lisp_Object));
void resize_echo_area_exactly P_ ((void));
--- 2636,2642
struct glyph_row *row_containing_pos P_ ((struct window *, int,
struct glyph_row *,
struct glyph_row *, int));
! int string_buffer_position P_ ((struct window *, Lisp_Object, int,
Lisp_Object *));
int line_bottom_y P_ ((struct it *));
int display_prop_intangible_p P_ ((Lisp_Object));
void resize_echo_area_exactly P_ ((void));
*** emacs/src/xdisp.c.~1.1146.~ 2007-04-12 16:23:44.0 -0400
--- emacs/src/xdisp.c 2007-04-13 14:09:22.0 -0400
***
*** 4425,4434
called asynchronously from note_mouse_highlight. */
int
! string_buffer_position (w, string, around_charpos)
struct window *w;
Lisp_Object string;
int around_charpos;
{
Lisp_Object limit, prop, pos;
const int MAX_DISTANCE = 1000;
--- 4425,4435
called asynchronously from note_mouse_highlight. */
int
! string_buffer_position (w, string, around_charpos, overlay)
struct window *w;
Lisp_Object string;
int around_charpos;
+ Lisp_Object *overlay;
{
Lisp_Object limit, prop, pos;
const int MAX_DISTANCE = 1000;
***
*** 4438,
limit = make_number (min (XINT (pos) + MAX_DISTANCE, ZV));
while (!found && !EQ (pos, limit))
{
! prop = Fget_char_property (pos, Qdisplay, Qnil);
if (!NILP (prop) && display_prop_string_p (prop, string))
found = 1;
else
--- 4439,4445
limit = make_number (min (XINT (pos) + MAX_DISTANCE, ZV));
while (!found && !EQ (pos, limit))
{
! prop = get_char_property_and_overlay (pos, Qdisplay, Qnil, overlay);
if (!NILP (prop) && display_prop_string_p (prop, string))
found = 1;
else
***
*** 4451,4457
limit = make_number (max (XINT (pos) - MAX_DISTANCE, BEGV));
while (!found && !EQ (pos, limit))
{
! prop = Fget_char_property (pos, Qdisplay, Qnil);
if (!NILP (prop) && display_prop_string_p (prop, string))
found = 1;
else
--- 4452,4458
limit = make_number (max (XINT (pos) - MAX_DISTANCE, BEGV));
while (!found && !EQ (pos, limit))
{
! prop = get_char_property_and_overlay (pos, Qdisplay, Qnil, overlay);
if (!NILP (prop) && display_prop_string_p (prop, string))
Re: display margin errors on a tty
I managed to reproduce the bug. emacs -nw M-: (set-window-margins (selected-window) 1) RET C-x 2 C-x ^ Pressing left and right button and inserting text now makes it clear that redisplay is broken. The call to enlarge-window and set-window-margins appears to be essential to producing this bug. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display margin errors on a tty
Nick Roberts <[EMAIL PROTECTED]> writes: > > I don't see this. > > > > But I cannot use the mouse when emacs -nw is running in an xterm > > (xterm seems to own the mouse) - is it necessary to use the mouse to > > see the problem? > > Yes, that's strange. It seems to have something to do with xterm-mouse-mode > being enabled. I can't see any connection between the two, though. I can't seem to reproduce this, even with xterm-mouse-mode enabled. Can you give a more precise recipe? ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: misbehaviour of outline-backward-same-level
Leo <[EMAIL PROTECTED]> writes: > `outline-backward-same-level' will move from a heading line to a > non-heading line when on the first level-1 heading. I checked in a (hopefully pretty safe) fix. ___ 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)" <[EMAIL PROTECTED]> writes: >> 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. In the past, we've had point-is-completely-stuck bugs originating from the former code, and crash bugs from the latter. ___ 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)" <[EMAIL PROTECTED]> writes: > 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. Like I said, the unexpected cursor position can occur even if the affected overlay is not on the first line, so there's no point introducing a kludge to handle the case where it is on the first line. It is better to wait for Emacs 22.2 to fix it for real. ___ 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)" <[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. ___ 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)" <[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. ___ 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)" <[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. > 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. > 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? ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
[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.
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.
___
emacs-pretest-bug mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
[EMAIL PROTECTED] (Kim F. Storm) writes: > 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. The original bug report was at http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-06/msg00342.html However, your fix appears to have been unrelated to that original bug report: http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-07/msg00246.html From: Kim F. Storm Subject: Re: Overlays disappearing during line-by-line scrolling Date: Wed, 13 Jul 2005 12:35:42 +0200 I have installed some changes to fix this and other problems related to line-move around such multi-line overlay strings. The changes touches on some tricky low-level "move_it_..." functions so I may have broken other things... * I also fixed problems with positioning the cursor on (first char of) * such multi-line strings. Finally, I fixed problems related to vertical-motion not moving when point is on an image. The ChangeLog entry says: 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). 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). 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? ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: dnd bug with setting case-fold-search nil
graphist <[EMAIL PROTECTED]> writes: > I'm using NTemacs22 and have found one small bug. > If you add the following statement in .emacs file: > (setq-default case-fold-search nil) > you can't drag and drop some files to emacs (eg: with ":" in its full path). I haven't been able to reproduce this, but this is probably windows-specific. Please give a more precise recipe. "Some files" is too vague. ___ 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)" <[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.
___
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)" <[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.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Regression in WoMan
Sven Joachim <[EMAIL PROTECTED]> writes: > It seems that WoMan can no longer handle the case where a manpage > loads another one with a .so request. At least I got the error > > WoMan can only format man pages written with the usual `-man' macros > > when trying to view the manpage for dpkg-buildpackage, which consists > of a single line: > > .so man1/dpkg-source.1 > > Emacs 21.4 handles this well, and I'm sure that it worked in CVS at > least until a few months ago, too. This was a consequence of the recently-added checked for macro sets that woman can't handle. The case of a single .so line was overlooked. I've checked in a fix, thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash in redisplay_internal -> note_mode_line_or_margin_highlight
[EMAIL PROTECTED] (Kim F. Storm) writes: > Chong Yidong <[EMAIL PROTECTED]> writes: > >> Kim, could you study this patch and tell me what you think? > > Looks alright to me. I've checked it in. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: infloop in python code
> Ah yes, now I can replicate it. The trouble was that your test
> program had long lines that were automatically snipped by Gnus.
>
> Here is a simpler test case:
>
> #!/usr/bin/env python
> def foo(bar):
> foo = foo("""foo""").bar("
> cmd = """foo"""
> bar
>
> emacs -q foo.py
> M-: (python-imenu-create-index) RET
This seems to be traceable to the naughty while loop in
python-end-of-block.
(catch 'done
(while (zerop (python-next-statement))
(when (or (and open (<= (current-indentation) ci))
(< (current-indentation) ci))
(python-skip-comments/blanks t)
(beginning-of-line 2)
(throw 'done t
I think something like the following fixes it (someone more
knowledgeable about this code should probably take a look).
*** emacs/lisp/progmodes/python.el.~1.57.~ 2007-04-04 13:05:27.0
-0400
--- emacs/lisp/progmodes/python.el 2007-04-09 22:42:45.0 -0400
***
*** 981,991
(_ (if (python-comment-line-p)
(python-skip-comments/blanks t)))
(ci (current-indentation))
! (open (python-open-block-statement-p)))
(if (and (zerop ci) (not open))
(not (goto-char point))
(catch 'done
! (while (zerop (python-next-statement))
(when (or (and open (<= (current-indentation) ci))
(< (current-indentation) ci))
(python-skip-comments/blanks t)
--- 981,995
(_ (if (python-comment-line-p)
(python-skip-comments/blanks t)))
(ci (current-indentation))
! (open (python-open-block-statement-p))
! opoint)
(if (and (zerop ci) (not open))
(not (goto-char point))
(catch 'done
! (setq opoint (point))
! (while (and (zerop (python-next-statement))
! (not (= opoint (point
! (setq opoint (point))
(when (or (and open (<= (current-indentation) ci))
(< (current-indentation) ci))
(python-skip-comments/blanks t)
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: infloop in python code
Benjamin Rutt <[EMAIL PROTECTED]> writes:
> Benjamin Rutt osu.edu> writes:
>
>> Is there anything I can do to make this report more useful? It
>> doesn't happen with emacs -q unfortunately.
>
> hoorah, I can now dupe it with command line
>
> emacs -q --eval '(add-hook (quote python-mode-hook) (lambda ()
> (imenu-add-menubar-index)))' --eval '(setq imenu-auto-rescan t)'
> bugreport.py
>
> so imenu is implicated. can anyone else dupe it now?
Ah yes, now I can replicate it. The trouble was that your test
program had long lines that were automatically snipped by Gnus.
Here is a simpler test case:
#!/usr/bin/env python
def foo(bar):
foo = foo("""foo""").bar("
cmd = """foo"""
bar
emacs -q foo.py
M-: (python-imenu-create-index) RET
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: infloop in python code
Benjamin Rutt <[EMAIL PROTECTED]> writes: > Benjamin Rutt osu.edu> writes: > >> Is there anything I can do to make this report more useful? It >> doesn't happen with emacs -q unfortunately. > > hoorah, I can now dupe it with command line > > emacs -q --eval '(add-hook (quote python-mode-hook) (lambda () > (imenu-add-menubar-index)))' --eval '(setq imenu-auto-rescan t)' > bugreport.py > > so imenu is implicated. can anyone else dupe it now? I still can't reproduce this. Is this with Emacs' built-in python.el or with the external python-mode.el? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: infloop in python code
Benjamin Rutt <[EMAIL PROTECTED]> writes:
> Emacs infloops when I press the " key at the end of this line (to the right of
> the last '(':
>
> matching_dbs = commands.getoutput("""cat
> //xx/x/x.xxx | grep "^%s" | grep -v xxx""" %
> region).strip().split(
I can't reproduce this at all. Could you try to send a smaller
testcase and give a precise recipe starting from emacs -Q?
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash in gc_sweep (SIGH!)
Eli Zaretskii <[EMAIL PROTECTED]> writes: >> Following my last bug report on W32 display error, I noticed that >> the image didn't get through. So I tried various stuff to decode >> the base64 stuff in various ways like this: >> >> - copy it to a new file buffer named x.gif, mark it, do >> base64-decode-region, and C-c C-c to view the image (no luck!) > > This works for me, if I invoke image-toggle-display by hand (you may > need to load image-mode before that). It is bound to C-c C-c only in > buffers that visit image files. Works for me too. Could there be something wrong with your gif libraries? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash in redisplay_internal -> note_mode_line_or_margin_highlight
David Reitter <[EMAIL PROTECTED]> writes:
> This crash occurred with a (slightly modified) CVS version
> (2007-04-04), Carbon build.
>
> I was trying out tabbar.el (providing tabbar-mode) using PNG files
> for `tabbar-home-button-enabled-image' and the other tabbar buttons.
> I think I clicked on the "mode" (leftmost) button before this
> happened, but I'm not sure.
I can't reproduce this patch, but I can see how it could conceivably
happen.
Kim, could you study this patch and tell me what you think?
*** emacs/src/xdisp.c.~1.1145.~ 2007-04-09 11:36:15.0 -0400
--- emacs/src/xdisp.c 2007-04-09 12:23:04.0 -0400
***
*** 22437,22443
Lisp_Object mouse_face;
int original_x_pixel = x;
! struct glyph * glyph = NULL;
struct glyph_row *row;
if (area == ON_MODE_LINE || area == ON_HEADER_LINE)
--- 22437,22443
Lisp_Object mouse_face;
int original_x_pixel = x;
! struct glyph * glyph = NULL, * row_start_glyph = NULL;
struct glyph_row *row;
if (area == ON_MODE_LINE || area == ON_HEADER_LINE)
***
*** 22455,22461
/* Find glyph */
if (row->mode_line_p && row->enabled_p)
{
! glyph = row->glyphs[TEXT_AREA];
end = glyph + row->used[TEXT_AREA];
for (x0 = original_x_pixel;
--- 22455,22461
/* Find glyph */
if (row->mode_line_p && row->enabled_p)
{
! glyph = row_start_glyph = row->glyphs[TEXT_AREA];
end = glyph + row->used[TEXT_AREA];
for (x0 = original_x_pixel;
***
*** 22579,22590
is converted to a flatten by emacs lisp interpreter.
The internal string is an element of the structures.
The displayed string is the flatten string. */
! for (tmp_glyph = glyph - 1, gpos = 0;
! tmp_glyph->charpos >= XINT (b);
! tmp_glyph--, gpos++)
{
! if (!EQ (tmp_glyph->object, glyph->object))
! break;
}
/* Calculate the lenght(glyph sequence length: GSEQ_LENGTH) of
--- 22579,22594
is converted to a flatten by emacs lisp interpreter.
The internal string is an element of the structures.
The displayed string is the flatten string. */
! gpos = 0;
! if (glyph != row_start_glyph)
{
! for (tmp_glyph = glyph - 1;
! tmp_glyph->charpos >= XINT (b);
! tmp_glyph--, gpos++)
! {
! if (!EQ (tmp_glyph->object, glyph->object))
! break;
! }
}
/* Calculate the lenght(glyph sequence length: GSEQ_LENGTH) of
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash in gc_sweep (SIGH!)
It's unlikely that such a bug would have gone undetected over the last few pretests. Could you me help check the last few checkins to the src directory for any obvious bugs? 2007-04-07 Chong Yidong <[EMAIL PROTECTED]> * editfns.c (Ftranspose_regions): Validate interval before setting text properties. 2007-04-01 Chong Yidong <[EMAIL PROTECTED]> * keymap.c (Fcommand_remapping): New optional argument. (where_is_internal): Use new keymaps argument. (Fkey_binding): Caller changed. 2007-03-29 Kim F. Storm <[EMAIL PROTECTED]> * process.c (wait_reading_process_output) [HAVE_PTYS]: When EIO happens, clear channel from descriptor masks before raising SIGCHLD signal to avoid busy loop between read and sigchld_handler. (sigchld_handler): Remove sleep (2007-03-11 & 2007-03-26 changes). 2007-03-28 YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> * gmalloc.c [HAVE_GTK_AND_PTHREAD]: Define USE_PTHREAD. [USE_PTHREAD]: Include pthread.h. (malloc_init_once_control, _malloc_mutex) [USE_PTHREAD]: New variables. (malloc_initialize_1): New function created from __malloc_initialize. (__malloc_initialize): Use it. (LOCK, UNLOCK): New macros to make malloc etc. thread safe. (_malloc_internal, _free_internal, _realloc_internal): Use them. * lread.c (readchar): Extend BLOCK_INPUT block to ferror/clearerr. ___ 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 <[EMAIL PROTECTED]> writes: > 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](# 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] # 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 I can't reproduce this. Please give a recipe starting from emacs -Q. For example, emacs -Q M-: (setq after-make-frame-functions (lambda (f) (tool-bar-mode -1))) RET M-x make-frame RET => No error is seen. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: smtp bug with most recent cvs gnu emacs
"emacs user" <[EMAIL PROTECTED]> writes: > using GNU/linux (redhat enterprise 4), most recent cvs Emacs 22.0.97.3 , > trying to mail using smtp results in the error message > (invalid-function with-case-table). traceback attached. thanks, EU You need to recompile your lisp directory and dump Emacs again. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: erc-open-ssl-stream: Wrong type argument: stringp, nil
intrigeri <[EMAIL PROTECTED]> writes: > after upgrading from my one-month-old Romain Françoise's > emacs-snapshot (1:20070302-1) + Debian sid's ERC (5.1.4-4) to the > brand new Romain's package (1:20051124-1) with ERC 5.2 included, I can > not connect to IRC anymore ; running erc-ssl fails, saying : > > erc-open-ssl-stream: Wrong type argument: stringp, nil It seemed that open-tls-stream did not properly handle the case where nil is passed as the BUFFER argument. I fixed this. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Hanoi causes SEGV
Chong Yidong <[EMAIL PROTECTED]> writes: > Chong Yidong <[EMAIL PROTECTED]> writes: > >> "Jeffrey C Honig" <[EMAIL PROTECTED]> writes: >> >>> This happens with CVS emacs from two hours ago on both FC6 and FC4. >>> Both compiled with (./configure --with-gtk; make bootstrap). >> >> This appears to be the result of Kim Storm's recent change to >> set_text_properties_1. > > Whoops, I meant *my* recent change to Ftranspose_region. I'll sort it > out :-P OK, I fixed this. Thanks for the bug report. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Hanoi causes SEGV
Chong Yidong <[EMAIL PROTECTED]> writes: > "Jeffrey C Honig" <[EMAIL PROTECTED]> writes: > >> This happens with CVS emacs from two hours ago on both FC6 and FC4. >> Both compiled with (./configure --with-gtk; make bootstrap). > > This appears to be the result of Kim Storm's recent change to > set_text_properties_1. Whoops, I meant *my* recent change to Ftranspose_region. I'll sort it out :-P ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Hanoi causes SEGV
"Jeffrey C Honig" <[EMAIL PROTECTED]> writes: > This happens with CVS emacs from two hours ago on both FC6 and FC4. > Both compiled with (./configure --with-gtk; make bootstrap). This appears to be the result of Kim Storm's recent change to set_text_properties_1. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: "case" has incorrect colour in cc-mode
"Matzi Kratzi" <[EMAIL PROTECTED]> writes: > If I open process.c (1.510) in the distribution, "case" on line 2565 > (or is it the next case on line 2574) has the wrong colour. It would > be nice if this could be fixed before the release. I think this is fixed with the latest CVS. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: CC Mode, labels not fontified
Alan Mackenzie <[EMAIL PROTECTED]> writes: > Hi, everybody! > > I've just committed a fix (cc-engine.el, cc-fonts.el) to savannah. I > hope that it fixes the problem. Certainly, labels now get fontified as > labels, and keywords (e.g. case:, private:, default:, and also QT's > macros, slots:, signals:) get fontified as keywords. > > I wasn't able to reproduce the exact problem reported, in particular I > couldn't find any dependency on jit-lock (but my Emacs hadn't been > updated for some while). I hope nevertherless to have fixed the bug. > > Please let me know whether there are still problems. Excellent, thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs hangs (presumably) while parsing faulty python code
"Cameron Christensen" <[EMAIL PROTECTED]> writes: > 1. C-xC-f voodoo.py > 2. Cut and paste > (I originally quoted code from http://blog.pettomato.com/index.php?paged=5) > 3. Try to move around text... quickly hangs. > In GNU Emacs 23.0.0.1 (i386-mingw-nt5.1.2600) > of 2007-01-01 on DTOP > X server distributor `Microsoft Corp.', version 5.1.2600 I can't reproduce this on Emacs 22 on GNU/Linux, so I guess it's a unicode-branch bug. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: C-a acts different in 22.0.90 then past versions
Chong Yidong <[EMAIL PROTECTED]> writes: > martin rudalics <[EMAIL PROTECTED]> writes: > >>> emacs-22.0.90 -Q >>> c-xc-f /etc/termcap >>> >>> c-xc-q To make it writable >>> c-kc-kc-y kill the first line and put it back.It will >>> not do it without this line kill >>> >>> c-s thedo this until you leave the first screen displayed. This will >>>recenter the buffer on the "the" found. Then c-s for one more >>>"the" below but on the same display screen. For the GNU/Linux on >>>the redhat 4.0 release it was about 16 additional c-s commands to >>>get it. I think near the bottom will work also. >>> >>> c-athis will recent the screen on the line where the "the" was at. >> >> I can repeat this. AFAICT it's due to a change between June 12th, 2006 and >> July 2nd, 2006. > > Aha, I could reproduce this reliably with a June 20th version of CVS > as well. However, I cannot reproduce it using the latest version in > CVS, following the exact same steps. I guess this bug has already > been solved. The problem shows up in 22.0.90, but is solved in 22.0.96. So I guess it is solved. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: C-a acts different in 22.0.90 then past versions
martin rudalics <[EMAIL PROTECTED]> writes: >> emacs-22.0.90 -Q >> c-xc-f /etc/termcap >> >> c-xc-q To make it writable >> c-kc-kc-y kill the first line and put it back.It will >> not do it without this line kill >> >> c-s thedo this until you leave the first screen displayed. This will >>recenter the buffer on the "the" found. Then c-s for one more >>"the" below but on the same display screen. For the GNU/Linux on >>the redhat 4.0 release it was about 16 additional c-s commands to >>get it. I think near the bottom will work also. >> >> c-athis will recent the screen on the line where the "the" was at. > > I can repeat this. AFAICT it's due to a change between June 12th, 2006 and > July 2nd, 2006. Aha, I could reproduce this reliably with a June 20th version of CVS as well. However, I cannot reproduce it using the latest version in CVS, following the exact same steps. I guess this bug has already been solved. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: narrowing *shell* buffer causes odd error
Richard Stallman <[EMAIL PROTECTED]> writes: > The OP accidentally narrowed his shell buffer, and tried to send input > to the comint prompt. The error popped up because the comint prompt > was now outside the accessible part of the buffer. Widening the > buffer solves the problem. > > there is no reason this should fail, and I think it will be easy > to fix. Would someone please fix it? OK, I just added a call to (widen) in comint-send-input. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: C-a acts different in 22.0.90 then past versions
martin rudalics <[EMAIL PROTECTED]> writes: >> emacs-22.0.90 -Q >> c-xc-f /etc/termcap >> >> c-xc-q To make it writable >> c-kc-kc-y kill the first line and put it back.It will >> not do it without this line kill >> >> c-s thedo this until you leave the first screen displayed. This will >>recenter the buffer on the "the" found. Then c-s for one more >>"the" below but on the same display screen. For the GNU/Linux on >>the redhat 4.0 release it was about 16 additional c-s commands to >>get it. I think near the bottom will work also. >> >> c-athis will recent the screen on the line where the "the" was at. > > I can repeat this. AFAICT it's due to a change between June 12th, 2006 and > July 2nd, 2006. I still cannot reproduce this. Can you give a recipe using some file in the Emacs distribution? (I don't have a termcap file.) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
