Misfontification of enum typedef name
This is from CVS Emacs, checked out a little before the 22.x branch. Put
this in a C++ buffer:
typedef enum {
foo, bar
} Enum; // Enum fontified as a variable name
main() {
Enum e; // Enum nicely fontified as a type name
}
Is the new cc fontification engine able to distinguish the context of the
first Enum and fontify it as a type name?
(I realise that in the context of
struct Fubar {
} fubar;
then fubar is a variable name, and is therefore currently fontified
correctly.)
Simon.
This email message is intended for the named recipient only. It may be
privileged and/or confidential. If you are not the named recipient of this
email please notify us immediately and do not copy it or use it for any
purpose, nor disclose its contents to any other person. Misys Banking
Systems is a trading name of Misys International Banking Systems Limited which
is registered in England and Wales under company registration number 00971479
and with its registered office address at Burleigh House, Chapel Oak, Salford
Priors, Evesham WR11 8SP.THIS E-MAIL DOES NOT CONSTITUTE THE COMMENCEMENT
OF LEGAL RELATIONS BETWEEN YOU AND MISYS INTERNATIONAL BANKING SYSTEMS LIMITED.
PLEASE REFER TO THE EXECUTED CONTRACT BETWEEN YOU AND THE RELEVANT MEMBER OF
THE MISYS GROUP FOR THE IDENTITY OF THE CONTRACTING PARTY WITH WHICH YOU ARE
DEALING.
___
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
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. Great, it fixes the OP and also seems to have fixed another misfontification I've seen of case statements (suddenly fontified as labels) in long switch statements. Thanks, Simon. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person. Misys Banking Systems is a trading name of Misys International Banking Systems Limited which is registered in England and Wales under company registration number 00971479 and with its registered office address at Burleigh House, Chapel Oak, Salford Priors, Evesham WR11 8SP.THIS E-MAIL DOES NOT CONSTITUTE THE COMMENCEMENT OF LEGAL RELATIONS BETWEEN YOU AND MISYS INTERNATIONAL BANKING SYSTEMS LIMITED. PLEASE REFER TO THE EXECUTED CONTRACT BETWEEN YOU AND THE RELEVANT MEMBER OF THE MISYS GROUP FOR THE IDENTITY OF THE CONTRACTING PARTY WITH WHICH YOU ARE DEALING. ___ 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
[From the original poster.] The `retry:' label is not highlighted. It is fontified correctly by `M-o M-o' though. I'm not sure I believe this. I can't reproduce it. Hi Alan, FWIW, I can using CVS emacs: .../src/emacs -Q +2956 .../src/eval.c # label not fontified until M-o M-o Simon. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person. Misys Banking Systems is a trading name of Misys International Banking Systems Limited which is registered in England and Wales under company registration number 00971479 and with its registered office address at Burleigh House, Chapel Oak, Salford Priors, Evesham WR11 8SP.THIS E-MAIL DOES NOT CONSTITUTE THE COMMENCEMENT OF LEGAL RELATIONS BETWEEN YOU AND MISYS INTERNATIONAL BANKING SYSTEMS LIMITED. PLEASE REFER TO THE EXECUTED CONTRACT BETWEEN YOU AND THE RELEVANT MEMBER OF THE MISYS GROUP FOR THE IDENTITY OF THE CONTRACTING PARTY WITH WHICH YOU ARE DEALING. ___ 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
To give context, the change was to stop this overwriting-mis-fontification: case foo: ^^^ not fontified (generally used to be fontified as a label/constant) fontified as a label/constant (used to be fontified as a keyword) With the change, case remains fontified as a keyword. Superficially, it would seem my change would prevent goto labels from being fontified. That might be true, given my lack of understanding of the new cc-mode fontification engine. However, it looks like it might be some interaction with jit-lock mode, since if font-lock-support-mode is nil, then fontification is OK. (This is presumably why M-o M-o also fontifies correctly.) So I'm tempted to say it's not (simply) due to my change. Stefan, Alan, any pointers? Simon. -Original Message- From: Chong Yidong [mailto:[EMAIL PROTECTED] On Behalf Of Chong Yidong Sent: 30 March 2007 04:23 To: Simon Marshall; Feng Li Cc: emacs-pretest-bug@gnu.org Subject: Re: CC Mode, labels not fontified [EMAIL PROTECTED] (Johan Bockgård) writes: $ emacs -Q +2956 .../emacs/src/eval.c The `retry:' label is not highlighted. It is fontified correctly by `M-o M-o' though. Simon, this appears to be the result of your change. Could you try to fix your patch? 2006-11-10 Simon Marshall [EMAIL PROTECTED] * progmodes/cc-fonts.el (c-font-lock-declarations): Don't overwrite fontification for case and default keywords. *** emacs/lisp/progmodes/cc-fonts.el 2006/07/10 13:17:09 1.16 --- emacs/lisp/progmodes/cc-fonts.el 2006/11/10 16:58:27 1.17 This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person. Misys Banking Systems is a trading name of Misys International Banking Systems Limited which is registered in England and Wales under company registration number 00971479 and with its registered office address at Burleigh House, Chapel Oak, Salford Priors, Evesham WR11 8SP.THIS E-MAIL DOES NOT CONSTITUTE THE COMMENCEMENT OF LEGAL RELATIONS BETWEEN YOU AND MISYS INTERNATIONAL BANKING SYSTEMS LIMITED. PLEASE REFER TO THE EXECUTED CONTRACT BETWEEN YOU AND THE RELEVANT MEMBER OF THE MISYS GROUP FOR THE IDENTITY OF THE CONTRACTING PARTY WITH WHICH YOU ARE DEALING. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Font-lock does not fontify C++ const pointer declaration
I think this bug report got lost somewhere or maybe the fix was incomplete. Emacs 19-21 fontifies the following C++ snippet: int *p; // ok const int *p; // ok int *const p; // not ok in CVS emacs const int *const p; // not ok in CVS emacs so that p is in font-lock-variable-name-face. In Emacs CVS, it does not fontify p when p is declared as a const pointer. (I think it also misfontified in C, when I first reported it, but now C is OK.) Simon. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person. Misys Banking Systems is a trading name of Misys International Banking Systems Limited which is registered in England and Wales under company registration number 00971479 and with its registered office address at Burleigh House, Chapel Oak, Salford Priors, Evesham WR11 8SP.THIS E-MAIL DOES NOT CONSTITUTE THE COMMENCEMENT OF LEGAL RELATIONS BETWEEN YOU AND MISYS INTERNATIONAL BANKING SYSTEMS LIMITED. PLEASE REFER TO THE EXECUTED CONTRACT BETWEEN YOU AND THE RELEVANT MEMBER OF THE MISYS GROUP FOR THE IDENTITY OF THE CONTRACTING PARTY WITH WHICH YOU ARE DEALING. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Font Lock on-the-fly misfontification in C++
This bites on a frustratingly regular basis. Put the following in a
fubar.cpp:
class Fubar :
public Foo, // Foo fontified as a type, at first
public Bar// Bar fontified as a type, at first
{
Foo bar(Snafu snafu, // Types, function, variable fontified, at first
Foo foo,
Bar bar);
Foo bar(Snafu *snafu, // Types, function, variable fontified, at first
Foo foo,
Bar bar);
};
Then emacs -Q fubar.cpp. I see Foo, Bar and Snafu fontified as types even
where declaring functions and variables. The corresponding functions and
variables are fontified correctly. This is great!
Then do the following.
1. Append a space to the first (or second) commented line. Bug:
fontification of Foo (and/or Bar) is removed.
2. Append a space to the third commented line. Bug: fontification of Foo
and bar is removed from that line.
3. Append a space to the fourth commented line. Bug: fontification of Foo,
bar, Snafu and snafu is removed from that line.
Somewhat spookily, if you then repeat (2), then the fourth commented line
(3) gets fontified correctly after the deferral delay.
I think this is some sort of problem with Jit Lock mode multiline
fontification, at least for (2) and (3), since Lazy Lock mode works ok. (Of
course, Lazy Lock mode is now depreciated and lazy-lock-mode is not
autoloaded.)
Stefan Monnier kindly posted a possible partial fix (see
http://lists.gnu.org/archive/html/emacs-devel/2006-07/msg01193.html) but
that thread went into a discussion about the font-lock-multiline text
property. I don't know how valid the approach is now (and obviously the
patch was not checked in).
Simon.
This email message is intended for the named recipient only. It may be
privileged and/or confidential. If you are not the named recipient of this
email please notify us immediately and do not copy it or use it for any
purpose, nor disclose its contents to any other person. Misys Banking
Systems is a trading name of Misys International Banking Systems Limited which
is registered in England and Wales under company registration number 00971479
and with its registered office address at Burleigh House, Chapel Oak, Salford
Priors, Evesham WR11 8SP.THIS E-MAIL DOES NOT CONSTITUTE THE COMMENCEMENT
OF LEGAL RELATIONS BETWEEN YOU AND MISYS INTERNATIONAL BANKING SYSTEMS LIMITED.
PLEASE REFER TO THE EXECUTED CONTRACT BETWEEN YOU AND THE RELEVANT MEMBER OF
THE MISYS GROUP FOR THE IDENTITY OF THE CONTRACTING PARTY WITH WHICH YOU ARE
DEALING.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Partial-completion-mode recently broken
In GNU Emacs 22.0.93.1 (sparc-sun-solaris2.8, Motif Version 2.1.0) of 2007-02-05 on perth X server distributor `Hummingbird Ltd.', version 11.0.100015 configured using `configure '--prefix=/rvcarma/marshals/software/slash/usr/local' '--with-x-toolkit=motif' 'CFLAGS=-g'' I did my weekly CVS update (I had to do a full make bootstrap) and found a problem with partial-completion-mode. Try: src/emacs -Q C-x C-f ~/fub TAB Where ~/fubar is some existing directory. Emacs completes it OK. Quit and try: M-x partial-completion-mode RET ; I see it loads advice, naughty? C-x C-f ~/fub TAB I see the following in the minibuffer: Find file: fubar/ Emacs seems to have lost the prefix and operations subsequently fail. I don't see any recent change to complete.el, but I don't have the time right now to dig into it. Simon. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person. Misys Banking Systems is a trading name of Misys International Banking Systems Limited which is registered in England and Wales under company registration number 00971479 and with its registered office address at Burleigh House, Chapel Oak, Salford Priors, Evesham WR11 8SP.THIS E-MAIL DOES NOT CONSTITUTE THE COMMENCEMENT OF LEGAL RELATIONS BETWEEN YOU AND MISYS INTERNATIONAL BANKING SYSTEMS LIMITED. PLEASE REFER TO THE EXECUTED CONTRACT BETWEEN YOU AND THE RELEVANT MEMBER OF THE MISYS GROUP FOR THE IDENTITY OF THE CONTRACTING PARTY WITH WHICH YOU ARE DEALING. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Font-lock decides function call is function declaration in C+ +
Hi, this bug remains[*] and a quick look at the C++ file I am editing shows that most of my methods have ended up with this sort of misfontification somewhere. Note that misfontification does not occur during initial fontification, only after editing (though not in a way I can replicate). I guess sometimes it thinks function calls are part of a declaration, though it doesn't necessarily happen when the preceding statement is a declaration. In one occurrence in my C++ file, the misfontification has occurred immediately after a for loop. Again, I'm asking for help. I never got a response last time. What do I need to look at to see what is going on? [*] following my revision 1.18 date: 2006-11-15 16:31:03 fix in cc-fonts.el of another unrelated issue in CVS Emacs, Emacs CVS fontifies the below with font-lock-variable-name-face, rather than font-lock-function-name-face, which may/may not give a pointer to where the problem lies. _ From: Marshall, Simon Sent: 07 September 2006 17:41 To: '[EMAIL PROTECTED]' Cc: 'emacs-pretest-bug@gnu.org' Subject: Font-lock decides function call is function declaration in C++ Intermittently, but for ages, Emacs CVS suddenly decides that C++ lines of code of the form: foo(bar); Or: foo() = bar; Are function declarations, and puts font-lock-function-name-face on (in these examples) foo. It seems to happen when I am editing the line in question, or maybe just on a line near it. (I think the last time it appeared when I did M-^ on the line following, but I could be wrong. There is nothing wrong with the code preceding the misfontification.) Editing the line or lines above it do not make the fontification permanently go away. For example, if I comment out all preceding lines, the fontification is removed. However, when I remove the comments, it comes back. The only way I've found to get rid of it is to turn font-lock-mode off and on. It's driving me mad because I can't work out what, in terms of the code preceding it, is causing it to fontify in this way. In one case, the function call was the first statement in the method, and I noticed that the text also had the c-in-sws property (as well as the face property). Debugging through cc-engine.el doesn't look fun and I don't know if the presence of this property is a red herring. I can't reproduce it, so I'm really asking for help. Any ideas? What can I do to work out what is going wrong? Simon. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person. Misys Banking Systems is a trading name of Misys International Banking Systems Limited which is registered in England and Wales under company registration number 00971479 and with its registered office address at Burleigh House, Chapel Oak, Salford Priors, Evesham WR11 8SP.THIS E-MAIL DOES NOT CONSTITUTE THE COMMENCEMENT OF LEGAL RELATIONS BETWEEN YOU AND MISYS INTERNATIONAL BANKING SYSTEMS LIMITED. PLEASE REFER TO THE EXECUTED CONTRACT BETWEEN YOU AND THE RELEVANT MEMBER OF THE MISYS GROUP FOR THE IDENTITY OF THE CONTRACTING PARTY WITH WHICH YOU ARE DEALING. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
FW: cc-mode bug
I'm forwarding this report from Feng Li. (I'm not the guy responsible and
I'm not in the Emacs team - I just fixed a couple of the issues that annoyed
me and were relatively easy!)
AFAICS, the bug is that the pretest no longer fontifies the below
declaration of B::foo(), presumably because it does not know that __stdcall
is a platform-specific keyword. (I'm not volunteering to fix this...)
Is it OK to report bugs to these lists, or should I go through
sourceforge.net?
Simon.
_
From: Feng Li [mailto:[EMAIL PROTECTED]
Sent: 09 January 2007 09:31
To: Marshall, Simon
Subject: cc-mode bug
Hi Simon,
I've noticed a couple of bugs of cc-mode 5.31.4 in the current CVS Emacs. I
know I'm supposed to send bug reports to the cc-mode project page at
sourceforge, but due to the recent earthquake near Taiwan, it's currently
very difficult to access sourceforge.net http://sourceforge.net from
China. Since you looks like the guy responsible for cc-mode in the Emacs
team, I guess maybe I could ask you about my problems.
Here are the 2 cases that the latest cc-mode failed to fontify correctly.
IIRC, earlier versions of cc-mode used to handle these code without problem.
class DLLEXPORT A
{
};
class B
{
void __stdcall foo();
};
However, this code is fontified correctly.
class __declspec(dllexport) A
{
};
So it seems the new cc-mode only recognize certain tokens before a type name
while earlier versions can skip uncrecognized tokens.
Thansks for your time.
--
Feng Li
This email message is intended for the named recipient only. It may be
privileged and/or confidential. If you are not the named recipient of this
email please notify us immediately and do not copy it or use it for any
purpose, nor disclose its contents to any other person. Misys Banking
Systems is a trading name of Misys International Banking Systems Limited which
is registered in England and Wales under company registration number 00971479
and with its registered office address at Burleigh House, Chapel Oak, Salford
Priors, Evesham WR11 8SP.THIS E-MAIL DOES NOT CONSTITUTE THE COMMENCEMENT
OF LEGAL RELATIONS BETWEEN YOU AND MISYS INTERNATIONAL BANKING SYSTEMS LIMITED.
PLEASE REFER TO THE EXECUTED CONTRACT BETWEEN YOU AND THE RELEVANT MEMBER OF
THE MISYS GROUP FOR THE IDENTITY OF THE CONTRACTING PARTY WITH WHICH YOU ARE
DEALING.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Possible mouse-face redisplay glitch
This is with CVS Emacs as of Jan 8. In GNU Emacs 22.0.92.1 (sparc-sun-solaris2.8, Motif Version 2.1.0) of 2007-01-08 on perth X server distributor `Hummingbird Ltd.', version 11.0.100015 configured using `configure '--prefix=/rvcarma/marshals/software/slash/usr/local' '--with-x-toolkit=motif' 'CFLAGS=-g'' First generate a calendar in the lower window with: M-x calendar RET Put mouse over Jan 3 entry such that its mouse-face text property is active and: For me, the position under the mouse (ie, the non-entry above Dec 6 entry) still appears highlighted in mouse-face. A C-l clears the highlighting. This bug might be in the X server (Exceed from Hummingbird), rather than in Emacs, but I'm reporting it here as I've no way of checking with a different server. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person. Misys Banking Systems is a trading name of Misys International Banking Systems Limited which is registered in England and Wales under company registration number 00971479 and with its registered office address at Burleigh House, Chapel Oak, Salford Priors, Evesham WR11 8SP.THIS E-MAIL DOES NOT CONSTITUTE THE COMMENCEMENT OF LEGAL RELATIONS BETWEEN YOU AND MISYS INTERNATIONAL BANKING SYSTEMS LIMITED. PLEASE REFER TO THE EXECUTED CONTRACT BETWEEN YOU AND THE RELEVANT MEMBER OF THE MISYS GROUP FOR THE IDENTITY OF THE CONTRACTING PARTY WITH WHICH YOU ARE DEALING. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Crash on delete-frame
This is with CVS emacs as of 2006-12-11.
In GNU Emacs 22.0.91.8 (sparc-sun-solaris2.8, Motif Version 2.1.0)
of 2006-12-11 on perth
X server distributor `Hummingbird Ltd.', version 11.0.100015
configured using `configure
'--prefix=/rvcarma/marshals/software/slash/usr/local'
'--with-x-toolkit=motif' 'CFLAGS=-g''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: en_GB.ISO8859-1
value of $LC_CTYPE: en_GB.ISO8859-1
value of $LC_MESSAGES: C
value of $LC_MONETARY: en_GB.ISO8859-1
value of $LC_NUMERIC: en_GB.ISO8859-1
value of $LC_TIME: en_GB.ISO8859-1
value of $LANG: en_GB.ISO8859-1
locale-coding-system: iso-8859-1
default-enable-multibyte-characters: t
I'd been editing a fair while, had ~10 frames open, double-clicked on the
WM's close button for one frame and *boom*. The frame in question
contained two windows, one C++ buffer and one Calendar buffer.
I've no idea if it will be of any use whatsoever, but here's a backtrace.
Let me know if there's anything I should look at. I see that the coredump
appears to have occurred when setting the focus, so perhaps it's nothing to
do with emacs?
(gdb) where
#0 0xfed201cc in _libc_kill () from /usr/lib/libc.so.1
#1 0x0017c778 in fatal_error_signal (sig=11) at emacs.c:415
#2 signal handler called
#3 0xff0879c8 in XtSetKeyboardFocus () from /usr/lib/libXt.so.4
#4 0xff08c56c in XtCallCallbackList () from /usr/lib/libXt.so.4
#5 0xff0926c4 in Recursive () from /usr/lib/libXt.so.4
#6 0xff092718 in Recursive () from /usr/lib/libXt.so.4
#7 0xff0926c4 in Recursive () from /usr/lib/libXt.so.4
#8 0xff0926c4 in Recursive () from /usr/lib/libXt.so.4
#9 0xff092b3c in XtPhase2Destroy () from /usr/lib/libXt.so.4
#10 0xff0928b4 in _XtDoPhase2Destroy () from /usr/lib/libXt.so.4
#11 0xff092648 in XtDestroyWidget () from /usr/lib/libXt.so.4
#12 0x00145d28 in x_free_frame_resources (f=0x217ea00) at xterm.c:9196
#13 0x00146198 in x_destroy_window (f=0x217ea00) at xterm.c:9291
#14 0x0005d318 in Fdelete_frame (frame=35121668, force=4757553) at
frame.c:1307
#15 0x00258630 in Ffuncall (nargs=3, args=0xffbed3c0) at eval.c:3000
#16 0x002b1b80 in Fbyte_code (bytestr=3739131, vector=3739148, maxdepth=40)
at bytecode.c:679
#17 0x00259270 in funcall_lambda (fun=3739092, nargs=1, arg_vector=Cannot
access memory at address 0x4c
) at eval.c:3184
#18 0x00258968 in Ffuncall (nargs=2, args=0xffbed788) at eval.c:3043
#19 0x00250d3c in Fcall_interactively (function=5026585,
record_flag=4757505, keys=35215252) at callint.c:860
#20 0x0019a2fc in Fcommand_execute (cmd=5026585, record_flag=4757505,
keys=35215252, special=4757553) at keyboard.c:9876
#21 0x00188064 in read_char (commandflag=1, nmaps=3, maps=0xffbedc68,
prev_event=4757505, used_mouse_menu=0xffbeddd8, end_time=0x0) at
keyboard.c:3060
#22 0x00197310 in read_key_sequence (keybuf=0xffbedfe4, bufsize=30,
prompt=4757505, dont_downcase_last=0, can_return_switch_frame=1,
fix_current_buffer=1) at keyboard.c:8978
#23 0x001824a4 in command_loop_1 () at keyboard.c:1603
#24 0x00254810 in internal_condition_case (bfun=0x181ef4 command_loop_1,
handlers=4821641, hfun=0x181308 cmd_error) at eval.c:1481
#25 0x001819e0 in command_loop_2 () at keyboard.c:1326
#26 0x00253f68 in internal_catch (tag=4815873, func=0x1819b4
command_loop_2, arg=4757505) at eval.c:1222
#27 0x00181954 in command_loop () at keyboard.c:1305
#28 0x00180e30 in recursive_edit_1 () at keyboard.c:1003
#29 0x001810a4 in Frecursive_edit () at keyboard.c:1064
#30 0x0017eac4 in main (argc=1, argv=0xffbee654) at emacs.c:1779
(gdb) up 12
#12 0x00145d28 in x_free_frame_resources (f=0x217ea00) at xterm.c:9196
(gdb) list
9191#endif
9192
9193#ifdef USE_X_TOOLKIT
9194 if (f-output_data.x-widget)
9195{
9196 XtDestroyWidget (f-output_data.x-widget);
9197 f-output_data.x-widget = NULL;
9198}
9199 /* Tooltips don't have widgets, only a simple X window, even
if
9200 we are using a toolkit. */
(gdb) p *f-output_data.x-widget
$1 = {core = {self = 0x1d2d200, widget_class = 0xff0c6a14, parent = 0x0,
xrm_name = 168, being_destroyed = 1 '\001', destroy_callbacks = 0x209afc0,
constraints = 0x0, x = 153, y = 358, width = 680, height = 546, border_width
= 0, managed = 0 '\0', sensitive = 1 '\001', ancestor_sensitive = 1 '\001',
event_table = 0x212e8e0, tm = {translations = 0x0, proc_table = 0x0,
current_state = 0x0, lastEventTime = 0}, accelerators = 0x0, border_pixel =
0, border_pixmap = 2, popup_list = 0x0, num_popups = 0, name = 0x724400
cemacs, screen = 0x4ef100, colormap = 32, window = 67402473, depth = 24,
background_pixel = 12566463, background_pixmap = 2, visible = 1 '\001',
mapped_when_managed = 0 '\0'}}
(gdb) p *f-output_data.x
$2 = {menubar_height = 30, toolbar_height = 0, border_tile = 67402482,
normal_gc = 0x1c69380, reverse_gc = 0x2153b00, cursor_gc = 0x1f04a00,
window_desc = 67402475, icon_desc = 0, parent_desc = 46138726, widget =
0x1d2d200, column_widget =
Fix for C++ class label preventing fontification
The below patch fixes a previous change I made (to fix switch label fontification) that causes missing fontification of a member name declared directly following a label in a C++ class declaration. 2006-12-12 Simon Marshall [EMAIL PROTECTED] * progmodes/cc-fonts.el (c-font-lock-declarations): Fix previous change. === RCS file: /sources/emacs/emacs/lisp/progmodes/cc-fonts.el,v retrieving revision 1.18 diff -c -r1.18 cc-fonts.el *** cc-fonts.el 15 Nov 2006 16:31:03 - 1.18 --- cc-fonts.el 12 Dec 2006 10:55:10 - *** *** 1179,1185 ;; The below code attempts to fontify the case constants in ;; c-label-face-name, but it cannot catch every case [sic]. ;; And do we want to fontify case constants anyway? ! nil ;;; (when (c-forward-label t match-pos nil) ;;; ;; Can't use `c-fontify-types-and-refs' here since we ;;; ;; should use the label face. --- 1179,1185 ;; The below code attempts to fontify the case constants in ;; c-label-face-name, but it cannot catch every case [sic]. ;; And do we want to fontify case constants anyway? ! (c-forward-label t match-pos nil) ;;; (when (c-forward-label t match-pos nil) ;;; ;; Can't use `c-fontify-types-and-refs' here since we ;;; ;; should use the label face. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Man, mouse-sel-mode and mouse-1
In GNU Emacs 22.0.91.6 (sparc-sun-solaris2.8, Motif Version 2.1.0) of 2006-12-04 on perth X server distributor `Hummingbird Ltd.', version 11.0.100015 configured using `configure '--prefix=/rvcarma/marshals/software/slash/usr/local' '--with-x-toolkit=motif' 'CFLAGS=-g'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: en_GB.ISO8859-1 value of $LC_CTYPE: en_GB.ISO8859-1 value of $LC_MESSAGES: C value of $LC_MONETARY: en_GB.ISO8859-1 value of $LC_NUMERIC: en_GB.ISO8859-1 value of $LC_TIME: en_GB.ISO8859-1 value of $LANG: en_GB.ISO8859-1 locale-coding-system: iso-8859-1 default-enable-multibyte-characters: t This is from CVS as of 04-Dec-2006. With emacs -Q: M-x man RET printf RET You get a man page. Go down to the SEE ALSO section and mouse-1 on printf(3C). Eventually you get the appropriate man page. OK. Now do: M-x mouse-sel-mode RET And repeat mouse-1 on an item in the SEE ALSO section of the printf(3C) man page buffer. I get an error No item under point. Switch the current (lower) window to show the original printf man page buffer. Now mouse-1 on any item in the SEE ALSO section just displays the printf(3C) man page buffer in the other (upper) window. (Interestingly, if I start with emacs -Q -f mouse-sel-mode, then mouse-1 on printf(3C) first raises a buffer-read-only error, then sometimes works and sometimes does not. I haven't been able to work out what the criteria is. Hopefully this is just a manifestation of the same bug.) Simon. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Builds ok; runs ok; install nit
From: Marshall, Simon [EMAIL PROTECTED] Date: Mon, 4 Dec 2006 10:00:51 - My system has makeinfo version 4.2 This is too old; please upgrade. Sure it is old, but ppl don't necessarily have an easy root to upgrade (pun intended). That's why I mentioned something might be done to avoid it, eg, don't run makeinfo if it reports it is 4.2 or earlier. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Builds ok; runs ok; install nit
CVS as of Dec 4 builds and runs ok on:
In GNU Emacs 22.0.91.6 (sparc-sun-solaris2.8, X toolkit)
of 2006-12-04 on perth
X server distributor `Hummingbird Ltd.', version 11.0.100015
configured using `configure 'CFLAGS=-g''
And
In GNU Emacs 22.0.91.6 (sparc-sun-solaris2.8, Motif Version 2.1.0)
of 2006-12-04 on perth
X server distributor `Hummingbird Ltd.', version 11.0.100015
configured using `configure
'--prefix=/rvcarma/marshals/software/slash/usr/local'
'--with-x-toolkit=motif' 'CFLAGS=-g''
But there is an install nit. My system has makeinfo version 4.2, which
results in the following during make install:
(cd man; make info)
cd /rvcarma/marshals/software/emacs/man; makeinfo --force emacs.texi
./display.texi:170: Unknown command `tie'.
./display.texi:170: Misplaced {.
./display.texi:170: Misplaced }.
./ack.texi:520: Unknown command `/orgensen'.
*** Error code 2
make: Fatal error: Command failed for target `../info/emacs'
Current working directory /rvcarma/marshals/software/emacs/man
*** Error code 1 (ignored)
(cd lispref; make info)
Not fatal, but maybe something can be done to avoid it?
Simon.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Font-lock assumes C++ variables instantiated via ctor are fun ctions
Hi, I noticed during my weekly cvs update that cyd applied my recent patch
for Font-lock fontifies C/C++ case keyword as a constant, thanks.
The below earlier patch for another bug hasn't been applied, was it missed?
Thanks, Simon.
-Original Message-
From: Marshall, Simon
Sent: 02 November 2006 10:48
To: 'emacs-pretest-bug@gnu.org'; '[EMAIL PROTECTED]'
Cc: 'Feng Li'
Subject: RE: Font-lock assumes C++ variables instantiated via ctor are
functions
Here is a patch that fixes the below problem for cvs emacs.
Feng Li sent me a patch that indicated to me where I could fix the problem
using the same solution used in previous versions of emacs.
2006-11-02 Simon Marshall [EMAIL PROTECTED]
* progmodes/cc-fonts.el (c-font-lock-declarators): Use
c-at-toplevel-p
to recognise T t() as a function declaration, rather than a variable
instantiation, iff at the top-level or inside a class declaration.
From an idea from Feng Li [EMAIL PROTECTED].
===
RCS file: /sources/emacs/emacs/lisp/progmodes/cc-fonts.el,v
retrieving revision 1.16
diff -r1.16 cc-fonts.el
900c900,904
id-face (if (eq (char-after next-pos) ?\()
---
id-face (if (and (eq (char-after next-pos) ?\()
(let (c-last-identifier-range)
(save-excursion
(goto-char next-pos)
(c-at-toplevel-p
Simon.
-Original Message-
From: Marshall, Simon
Sent: 06 September 2006 10:28
To: '[EMAIL PROTECTED]'
Cc: 'emacs-pretest-bug@gnu.org'
Subject: Font-lock assumes C++ variables instantiated via ctor are
functions
Consider this C++ code:
class Fubar { // Fubar as type - OK
Fubar();// Fubar as function - OK
Fubar a;// a as variable - OK
Fubar b(); // b as function - OK
Fubar c(A); // c as function - OK
};
Fubar f; // f as variable - OK
Fubar g();// y as function - OK
Fubar h(f); // z as function - probably OK really
int fubar()
{
Fubar x;// x as variable - OK
Fubar y(); // y as function - OK
Fubar z(X); // z as function - not OK
}
In Emacs 21, assuming you had added Fubar to
c++-font-lock-extra-types, y and z would be fontified as
variables, on the basis that declaring functions locally (as for y) is
not common whereas z is almost certainly a variable and is very
common. In other words, it usually does the right thing. (Emacs 21
fontified y/z differently, IIRC by virtue of them being within a block
but not being part of a class declaration.)
In the current Emacs 22 from CVS, you don't have to add to
c++-font-lock-extra-types, which is great. However, y and z
are fontified as functions. In other words, it usually does the wrong
thing.
Obviously, it's very difficult to get this right without writing a C++
parser. It really isn't clear what is the best thing to do for h,
since it really could be either a function or a variable declaration
(you would have to pick apart the parameters and consult the gods).
But z is almost certainly going to be a variable declaration and this
style of variable instantiation is obviously very common.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Font-lock fontifies C/C++ case keyword as a constant
Here is a patch that fixes the below problem for cvs emacs. The patch prevents the re-fontification of the case keyword as a constant. I also toyed with some code that fontifies the case constants as constants, as Emacs 19-21 tries to do, but it doesn't (can't) work in all cases. Also, I think that's probably over the top, so I have left the additional code in but commented it out. 2006-11-08 Simon Marshall [EMAIL PROTECTED] * progmodes/cc-fonts.el (c-font-lock-declarations): Don't overwrite fontification for case and default keywords. Simon. -Original Message- From: Marshall, Simon Sent: 08 September 2006 11:53 To: '[EMAIL PROTECTED]' Cc: 'emacs-pretest-bug@gnu.org' Subject: Font-lock fontifies C/C++ case keyword as a constant In Emacs 19-21 fontifies the following C/C++ snippet: case fubar: so that the keyword case is fontified as a keyword and fubar is fontified as a constant. Seems reasonable. In Emacs CVS, the keyword case is fontified as a constant, and fubar is not fontified at all. (With the C++ snippet case foo::bar: you get the bemusing situation where everything is fontified as a constant---apart from the constant. Fontifying the type/namespace qualifier as a constant is the subject of another bug report.) The first bug is that the case keyword should not be fontified as a constant. For the second bug, IWBNI the constant was fontified as a constant too, as it used to be, though that can be awkward where the constant is a constant expression. Still, Emacs used to manage to correctly fontify: case foo | bar: so that the keyword case is fontified as a keyword and foo and bar are fontified as constants. But if you don't want to fontify constants like this for some reason, you should make the default keyword be fontified as a keyword too. Simon. cc-fonts.diff2 Description: Binary data ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: mouse-autoselect-window with menu pane
If the timer function cancels the timer, the timer should not be triggered again. So if three repetitions for times T+2, T+4 and T+6 have been delayed until time T+7, and the first call (which should have been at T+2) cancels the timer, the timer should not reschedule itself for T+4, and the function should not be called again. I just clarified that in the Lisp Manual. Does the observed behavior match that or not? I think your words say yes, but I can't really be sure. Yes it does match it ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: mouse-autoselect-window with menu pane
A very quick simple test shows the behaviour seems consistent if the function run by the timer cancels the timer, when the function is run later due to buffering up of timers, in the scenario you describe. I can't understand those words at all. I think Martin was asking what would happen if the function run by a repeating timer cancelled the same timer, in the case where the repeating timer is delayed more than REPEAT*2 seconds due to a popup or something. I was trying to explain that it does not result in the timer being triggered more (or less) than the case where the timer that runs the function is not delayed; the timer cancellation behaviour is consistent between the two cases. My take on the current timer behaviour is that if you ask it to repeat every R seconds, then the timer will typically run N times in the period N*R, if N is large enough. However, Emacs cannot guarantee that the delay between timer n and timer n+1 is always at least R seconds (though it can guarantee that timer n will not run before n*R seconds). An alternative behaviour (which I think Martin was alluding to) is to not guarantee that the timer will run N times in the period N*R, but instead guarantee that the delay between timer n and timer n+1 is always at least R seconds. I'm not arguing that the current behaviour is wrong, but I could argue that the name REPEAT for the delay arg implies the latter behaviour is implemented. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: mouse-autoselect-window with menu pane
Increment of the counter is suspended during the file dialog/menu operation. And after the operation, the timer fires multiple times continuously until the counter catches up the value that it would be if no file dialog/menu were activated. Weird. Suppose `mouse-autoselect-window-select' cancels the timer after it fired the nth time, for some n 2. There's no reason why the timer was not cancelled when it fired the (n - 1)th time. What's even more troubling: There's no reason why the timer shouldn't fire a (n + 1)th time. My description above is about the count-up example in Simon's message. You can observe a similar behavior using the example and M-! sleep 5 RET Funnily enough, weird was the exact word I used in an email too. But then I thought buffering up the timers to run later might be the most logical thing to do, in the circumstances. Maybe it makes more sense than not running the timers at all. After all, as I'm sure the documentation aught to say, the timer will be repeated *as soon as possible* after REPEAT seconds. The behaviour is consistent at that level. A very quick simple test shows the behaviour seems consistent if the function run by the timer cancels the timer, when the function is run later due to buffering up of timers, in the scenario you describe. I found that buffering up of timers also occurs under X, at least for popups of the sort you get from File Open Directory... Under X, timers are buffered up when the mouse is within the popup (though they are run as you go in/out of the Filter, Directory, Files and Selection areas). I'm not sure why that needs to be so for this particular case though. You learn something every day. At least, I do about Emacs. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: mouse-autoselect-window with menu pane
What did you think of treating the scroll-bars in the same way? (That is, suspend autoselection if scrolling.) I could write ((or (menu-or-popup-active-p) (not (coordinates-in-window-p (cons mouse-x-position mouse-y-position) window))) ;; A menu / popup dialog is active or the mouse is on the scroll-bar. ;; Suspend autoselection. (setq mouse-autoselect-window-suspend t)) in `mouse-autoselect-window-select'. Or did you think of something more elaborate? That looks good. (You can avoid the cons with (cdr mouse-position) instead.) I was thinking that it would also simplify mouse-autoselect-window-cancel, to avoid the tests specific to scrolling, but now I see maybe that's not the case. Ta, Simon. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: [EMAIL PROTECTED]: Flickering of mode line buttons]
Would you please investigate this, then ack? I have installed a fix. Seems good to me - I'll keep an eye on it to see if it causes other problems. Thanks, Simon. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: mouse-autoselect-window with menu pane
Please try whether the attached patch works. If `mouse-autoselect-window-suspend' causes any problems I'll take it out. Thanks, seems to work under X. Do you need (fboundp 'menu-or-popup-active-p)? I'm not sure if waiting on average (1.5 * delay) is better than (0.5 * delay), but it's fine by me as it is. What did you think of treating the scroll-bars in the same way? (That is, suspend autoselection if scrolling.) Simon. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: mouse-autoselect-window with menu pane
If the purpose is to know if some menu is *currently* active, then the function will DTRT because Lisp evaluation never happens during menu selection on Mac. Does that apply to popups too? For example, what do you see with: (setq foo 0) (defun foo () (message %d (setq foo (1+ foo (setq bar (run-with-timer 1 1 'foo)) ;(cancel-timer bar) and File Open Directory... For me, the counter continues to increment while the open directory gui popup is active (though I have to move the mouse around to see the counter redisplayed). The same is true if I just open a menu (I don't have to move the mouse to see it). From what I understand from you, on Mac, the counter will pause until you exit the popup (or close the menu). It will then continue from where it paused. Simon. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: mouse-autoselect-window with menu pane
You should be able to see that the selected window changed since the modeline changed to `modeline-inactive' face. [...] Anyway, the problem occurs in practice, hence it should be addressed. Actually, with my setup, I don't see it. The selection does happen (I debugged it) but redisplay does not occur (or does not show it). You might remember this sort of thing sometimes happened when I tested earlier autoselect delay implementations. FWIW, `popup_activated_flag' is not really supported by w32menu.c and it's been removed from macmenu.c recently. Hence, this would have to be fixed first. Otherwise, someone else would have to take care of this since I couldn't reliably test xmenu.c. I'm not sure what you're asking for here - someone else to implement the equivalent of popup_activated_flag on w32 and mac? I can certainly help test on X. I did a quick hack to demonstrate that it works in principle on X. Simon. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: mouse-autoselect-window with menu pane
I did a quick hack to demonstrate that it works in principle on X. I did a quick hack for w32 and it appears that should work for mac too. Anyway, I have to write a _function_ that returns non-nil whenever a menu is active. And probably I should handle popup menus and dialog boxes as well. Can you think of something else this should handle? The function I wrote just returned Qnil/Qt based on popup_activated(), which is non-zero if the menu-bar or a popup-menu is active. That includes dialog boxes. In some ways it's a pity we can't (I assume we can't) shoehorn scroll-bar activation into it too, since that would remove the necessity for the extra conditions in mouse-autoselect-window-cancel. I can't think of anything else to handle. Simon. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: mouse-autoselect-window with menu pane
The function I wrote just returned Qnil/Qt based on popup_activated(),
which
is non-zero if the menu-bar or a popup-menu is active. That includes
dialog
boxes.
Fine. However, as I said before it doesn't work this way
neither on w32
nor on mac. Anyway, please send me just the code of that function and
tell me how you handle it in mouse-autoselect-window-select.
See below. I only tested it with Motif.
As Richard said we have to avoid that the timer triggers and the window
is selected immediately after the menu has become inactive.
Well, he said it would be good, not we have to. Though I agree with
rms, I can live with not rescheduling the timer at the moment of
deactivation.
After all, the user is going to have to move the mouse back into the lower
window regardless of whether you reschedule the timer or not, in which case
autoselection will switch back to the lower window again if necessary.
Also, we don't reschedule the timer when we're interacting with the
scroll-bar of a non-selected window. If we do this for menu-bar/popup-menu,
shouldn't we do the same for scroll-bar?
So, I don't see it being a must-have for this specific fix, particularly
since I think the implementation will be non-trivial (I assume you would
have to maintain some sort of state). IMHO, if you do it, do it separately
from this fix and try to make it consistent with scoll-bar autoselection
behaviour.
Index: src/xmenu.c
===
RCS file: /sources/emacs/emacs/src/xmenu.c,v
retrieving revision 1.308
diff -c -r1.308 xmenu.c
*** src/xmenu.c 9 Sep 2006 17:51:17 - 1.308
--- src/xmenu.c 15 Sep 2006 14:06:10 -
***
*** 1038,1043
--- 1038,1050
return selection;
}
+ DEFUN (x-popup-activatedp, Fx_popup_activatedp, Sx_popup_activatedp, 0,
0, 0,
+doc: /* Return non-nil if the menu-bar or a popup-menu is active.
*/)
+ ()
+ {
+ return popup_activated() ? Qt : Qnil;
+ }
+
#ifdef HAVE_MENUS
DEFUN (x-popup-dialog, Fx_popup_dialog, Sx_popup_dialog, 2, 3, 0,
***
*** 3764,3769
--- 3771,3777
#endif
defsubr (Sx_popup_menu);
+ defsubr (Sx_popup_activatedp);
#if defined (USE_GTK) || defined (USE_X_TOOLKIT)
defsubr (Smenu_bar_open);
Index: lisp/window.el
===
RCS file: /sources/emacs/emacs/lisp/window.el,v
retrieving revision 1.117
diff -c -r1.117 window.el
*** lisp/window.el 8 Sep 2006 14:15:02 - 1.117
--- lisp/window.el 15 Sep 2006 14:06:10 -
***
*** 835,840
--- 835,843
(window (window-at (cadr mouse-position) (cddr mouse-position)
(car mouse-position
(cond
+((x-popup-activatedp)
+ ;; If the menu-bar or a popup-menu is active, do nothing.
+ nil)
((and window (not (eq window (selected-window)))
(or (not (numberp mouse-autoselect-window))
(and ( mouse-autoselect-window 0)
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: mouse-autoselect-window with menu pane
It's the intended behavior: (1) When you cross the border between lower and upper window the timer starts (regardless of whether you hold down mouse-1 or not). (2) When you select the menu nothing happens because pre-command isn't run and the timer has not fired yet. (3) When you leave the menu pane you are in the upper window. When at this very moment the timer fires the upper window is selected. You shouldn't get it with a delay of less than one second. Using a negative value for `mouse-autoselect-window' should avoid the problem for the case that you inadvertently leave the menu pane for a short period. Hi Martin, I do get this problem with the default 0.5s delay. At least, I do see a problem of occasional switching window during menu use. I found this particular problem when I upped the delay to 3s to try to make it easier to reproduce/understand what I was seeing in normal use. What's special about 1s? I'm not sure what you mean by it being the intended behavior. After all, from the user's perspective, this particular gotcha is equivalent to the problem this autoselect delay feature was meant to address (ie, window selection occurs as you move across a window to the menu-bar to perform an action you intended for the original window), but with a nasty twist - the twist being that you can't see that window selection had occurred until after you perform the menu action. Double ouch. While this might seem fairly innocuous, it bites in the more frequent situation where you momentarily leave the menu pane before returning to select an entry. So, instead of releasing mouse-1 after the autoselect timeout, move back into the Help menu pane and select About Emacs. The action occurs in the upper window, not the lower window which was selected when you opened the Help menu. So, it seems that by being outside the menu pane when the autoselect timeout occurs, autoselection is performed. I think it is sensible to suppress autoselection in this case (ie, reschedule the delay). If I wanted to do this, I'd have to intercept `x_activate_menubar', detect whether the `mouse-autoselect-window-timer' timer is active, and kill it. As a consequenece autoselection would be cancelled as soon as the user accesses the menubar. Rescheduling the timer seems hardly feasible since it would almost certainly break the behavior for users with a smaller delay. Sorry, I didn't express it very well. Not reschedule the delay, but allow the delay to repeat or allow the timer to be rescheduled. What I meant would be for mouse-autoselect-window-select to not perform selection if the menu-bar or a popup-menu was active. Since this function is run from a timer with a repeat time, and we would not cancel the timer in this case, this function will just run again. In principle, would this DTRT? Looking at CVS just now, it seems there is no way of knowing from Lisp if the menu-bar or a popup-menu is active. However, popup_activated_flag appears to represent this situation. If so, assuming it is available on all windowing platforms, it could be exposed to Lisp. Simon. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Font-lock does not fontify const pointer declaration
Emacs 19-21 fontifies the following C/C++ snippet: int *p; // ok const int *p; // ok int *const p; // not ok in CVS emacs const int *const p; // not ok in CVS emacs so that p is in font-lock-variable-name-face. In Emacs CVS, it does not fontify p when p is declared as a const pointer. Simon. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Flickering of mode line buttons
src/emacs -Q C-x 2 ; split windows makes flickering more obvious In the selected window, move the mouse across the *scratch* or Lisp Interaction mode-line buttons. I see the other buttons, particularly the buttons on the left (coding, read-only, modified) flickering as they are repeatedly redrawn. (It's possible that the whole mode-line is being repeatedly redrawn - it's more obvious with the buttons.) I also see redrawing continue intermittently for a few seconds after I stop moving the mouse (though still within a button). In GNU Emacs 22.0.50.1 (sparc-sun-solaris2.8, X toolkit) of 2006-09-11 on perth X server distributor `Hummingbird Ltd.', version 11.0.100015 configured using `configure 'CFLAGS=-g'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: en_GB.ISO8859-1 value of $LC_CTYPE: en_GB.ISO8859-1 value of $LC_MESSAGES: C value of $LC_MONETARY: en_GB.ISO8859-1 value of $LC_NUMERIC: en_GB.ISO8859-1 value of $LC_TIME: en_GB.ISO8859-1 value of $LANG: en_GB.ISO8859-1 locale-coding-system: iso-8859-1 default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
mouse-autoselect-window with menu pane
Hi Martin, thanks again for the implementation, but a small buggette... src/emacs -Q (setq mouse-autoselect-window 3) C-x C-e C-x 2 And select the lower window. Move quickly from the lower window up to the menu bar and select the Help menu. While holding down mouse-1, move quickly to the upper window (ie, but off the Help menu pane). Wait until the autoselect timeout has occurred and release mouse-1. Selection of the upper window occurs (presumably it occurred while mouse-1 was down but there was no redisplay at that time), rather than selection remaining in the lower window. Selection only seems to happen if the mouse is outside the menu pane when the autoselect timeout occurs. While this might seem fairly innocuous, it bites in the more frequent situation where you momentarily leave the menu pane before returning to select an entry. So, instead of releasing mouse-1 after the autoselect timeout, move back into the Help menu pane and select About Emacs. The action occurs in the upper window, not the lower window which was selected when you opened the Help menu. So, it seems that by being outside the menu pane when the autoselect timeout occurs, autoselection is performed. I think it is sensible to suppress autoselection in this case (ie, reschedule the delay). Occurs with Lucid/Motif toolkit, Solaris 2.8, displayed on PC via Exceed server. Also occurs if you open the Help menu with a single mouse-1 click, rather than holding down mouse-1. Simon. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
mouse-autoselect-window custom nit
Thanks for implementing delayed mouse-autoselect-window. Just a doc nit - the custom value menu has Off (nil) as an entry. I don't think the lisp value corresponding to entry should be shown. Simon. *** cus-start.el.~1.96.~Mon Sep 11 10:38:42 2006 --- cus-start.elMon Sep 11 11:31:48 2006 *** *** 363,369 (overline-margin display integer 22.1) (mouse-autoselect-window display (choice ! (const :tag Off (nil) :value nil) (const :tag Immediate :value t) (number :tag Delay by secs :value 0.5)) 22.1) ;; xfaces.c --- 363,369 (overline-margin display integer 22.1) (mouse-autoselect-window display (choice ! (const :tag Off :value nil) (const :tag Immediate :value t) (number :tag Delay by secs :value 0.5)) 22.1) ;; xfaces.c ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Font-lock fontifies C/C++ case keyword as a constant
In Emacs 19-21 fontifies the following C/C++ snippet: case fubar: so that the keyword case is fontified as a keyword and fubar is fontified as a constant. Seems reasonable. In Emacs CVS, the keyword case is fontified as a constant, and fubar is not fontified at all. (With the C++ snippet case foo::bar: you get the bemusing situation where everything is fontified as a constant---apart from the constant. Fontifying the type/namespace qualifier as a constant is the subject of another bug report.) The first bug is that the case keyword should not be fontified as a constant. For the second bug, IWBNI the constant was fontified as a constant too, as it used to be, though that can be awkward where the constant is a constant expression. Still, Emacs used to manage to correctly fontify: case foo | bar: so that the keyword case is fontified as a keyword and foo and bar are fontified as constants. But if you don't want to fontify constants like this for some reason, you should make the default keyword be fontified as a keyword too. Simon. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Font-lock decides function call is function declaration in C++
Title: Font-lock decides function call is function declaration in C++ Intermittently, but for ages, Emacs CVS suddenly decides that C++ lines of code of the form: foo(bar); Or: foo() = bar; Are function declarations, and puts font-lock-function-name-face on (in these examples) foo. It seems to happen when I am editing the line in question, or maybe just on a line near it. (I think the last time it appeared when I did M-^ on the line following, but I could be wrong. There is nothing wrong with the code preceding the misfontification.) Editing the line or lines above it do not make the fontification permanently go away. For example, if I comment out all preceding lines, the fontification is removed. However, when I remove the comments, it comes back. The only way I've found to get rid of it is to turn font-lock-mode off and on. It's driving me mad because I can't work out what, in terms of the code preceding it, is causing it to fontify in this way. In one case, the function call was the first statement in the method, and I noticed that the text also had the c-in-sws property (as well as the face property). Debugging through cc-engine.el doesn't look fun and I don't know if the presence of this property is a red herring. I can't reproduce it, so I'm really asking for help. Any ideas? What can I do to work out what is going wrong? Simon. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Font-lock assumes C++ variables instantiated via ctor are functio ns
I'm fairly sure this never made it to the lists, so here it is again...
I'm not on either mailing list, so plz include me directly if you have
questions.
-Original Message-
From: Marshall, Simon
Sent: 16 August 2006 18:30
To: '[EMAIL PROTECTED]'
Cc: 'Emacs Pretest Bug (emacs-pretest-bug@gnu.org)'
Subject: Font-lock assumes C++ variables instantiated via ctor are functions
Consider this C++ code:
class Fubar { // Fubar as type - OK
Fubar(); // Fubar as function - OK
Fubar a; // a as variable - OK
Fubar b();// b as function - OK
Fubar c(A); // c as function - OK
};
Fubar f;// f as variable - OK
Fubar g(); // y as function - OK
Fubar h(f); // z as function - probably OK really
int fubar()
{
Fubar x; // x as variable - OK
Fubar y();// y as function - OK
Fubar z(X); // z as function - not OK
}
In Emacs 21, assuming you had added Fubar to c++-font-lock-extra-types, y
and z would be fontified as variables, on the basis that declaring functions
locally (as for y) is not common whereas z is almost certainly a variable
and is very common. In other words, it usually does the right thing.
(Emacs 21 fontified y/z differently, IIRC by virtue of them being within a
block but not being part of a class declaration.)
In the current Emacs 22 from CVS, you don't have to add to
c++-font-lock-extra-types, which is great. However, y and z are fontified
as functions. In other words, it usually does the wrong thing.
Obviously, it's very difficult to get this right without writing a C++
parser. It really isn't clear what is the best thing to do for h, since it
really could be either a function or a variable declaration (you would have
to pick apart the parameters and consult the gods). But z is almost
certainly going to be a variable declaration and this style of variable
instantiation is obviously very common.
I'm off on holiday, so let the flame fest begin! Simon.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Multiple runs of menu-bar-update-hook
For cases like this, typing `c' does not get precise information. If you see foo called from bar each time, you can't tell if it is the same call to bar, or a second call to bar. Ok. In this case it seemed consistent with what I was seeing without the debugger; the hook was being run twice for a single mouse-1 at point. With the breakpoint where the hook is run from, the breakpoint was hit twice for a single mouse-1 at point and the backtrace was different in each case. To find that out, use the `finish' command frame by frame, or use stepping. Ok, thanks. (gdb) c Continuing. Hardware watchpoint 6: windows_or_buffers_changed Old value = 0 New value = 1 That might be what we need to know. mouse-drag-region has to call delete-overlay. So it isn't a bug. Just the lack of optimization in this case. I guess that depends on your definition of a bug. The hook isn't run at all when the buffer is shown in a single frame, but is run twice when the buffer is shown in more than one frame. You say optato, I say bugato... Or, at least, inconsistency. Does that mean you don't plan on optimising for this case? Thanks, Simon. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Error during ask-user-about-lock
I've checked in the changes, can you try the thing that failed for you with an up to date Emacs? Hi Jan, yes, it does. Thanks, Simon. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Multiple runs of menu-bar-update-hook
You can see that both calls have come via redisplay(); the difference is their callers. (Of course both runs of the hook are unnecessary, they have been carried out because windows_or_buffers_changed = 1.) Normally, windows_or_buffers_changed gets cleared near the end of redisplay_internal. Did the first call to redisplay_internal do that? If not, why not? If it did that, where did it get set again before the second call to redisplay? Well, debugging gets a bit weird here. I had to debug it from a second X session, rather than in the same X session in which the debugged emacs is displayed. Otherwise, having the watchpoint seemed to interfere with the sequence of events somehow, and the first break in update_menu_bar() never occurred. Anyhow, with the usual breakpoints wherever the hook is run, and mouse-1 at point in the selected-frame where the buffer is shown in the other frame, I get: (gdb) watch windows_or_buffers_changed Hardware watchpoint 6: windows_or_buffers_changed (gdb) c Continuing. Hardware watchpoint 6: windows_or_buffers_changed Old value = 0 New value = 1 0x001b0868 in modify_overlay (buf=0x481c00, start=27, end=27) at buffer.c:3654 (gdb) list 3649 we must do other windows. */ 3650 if (buf != XBUFFER (XWINDOW (selected_window)-buffer)) 3651windows_or_buffers_changed = 1; 3652 /* If multiple windows show this buffer, we must do other windows. */ 3653 else if (buffer_shared 1) 3654windows_or_buffers_changed = 1; 3655 /* If we modify an overlay at the end of the buffer, we cannot 3656 be sure that window end is still valid. */ 3657 else if (end = ZV start = ZV) 3658windows_or_buffers_changed = 1; (gdb) p buffer_shared $1 = 2 (gdb) where #0 0x001b0868 in modify_overlay (buf=0x481c00, start=27, end=27) at buffer.c:3654 #1 0x001b0f9c in Fmove_overlay (overlay=5796370, beg=216, end=216, buffer=4725764) at buffer.c:3744 #2 0x0024ab58 in Ffuncall (nargs=4, args=0xffbedaf8) at eval.c:2992 #3 0x002a2cb8 in Fbyte_code (bytestr=3724931, vector=3724948, maxdepth=32) at bytecode.c:679 #4 0x0024b5b8 in funcall_lambda (fun=3724876, nargs=4, arg_vector=0xffbeddc4) at eval.c:3169 #5 0x0024ad30 in Ffuncall (nargs=5, args=0xffbeddc0) at eval.c:3028 #6 0x002a2cb8 in Fbyte_code (bytestr=3725379, vector=3725396, maxdepth=48) at bytecode.c:679 #7 0x0024b5b8 in funcall_lambda (fun=3725324, nargs=2, arg_vector=0xffbee094) at eval.c:3169 #8 0x0024ad30 in Ffuncall (nargs=3, args=0xffbee090) at eval.c:3028 #9 0x002a2cb8 in Fbyte_code (bytestr=3724235, vector=3724252, maxdepth=40) at bytecode.c:679 #10 0x0024b5b8 in funcall_lambda (fun=3724196, nargs=1, arg_vector=0xffbee384) at eval.c:3169 #11 0x0024ad30 in Ffuncall (nargs=2, args=0xffbee380) at eval.c:3028 #12 0x00243528 in Fcall_interactively (function=7566081, record_flag=4687873, keys=4747268) at callint.c:880 #13 0x00190a7c in Fcommand_execute (cmd=7566081, record_flag=4687873, keys=4687873, special=4687873) at keyboard.c:9797 #14 0x0017b290 in command_loop_1 () at keyboard.c:1790 #15 0x00246eb4 in internal_condition_case (bfun=0x17910c command_loop_1, handlers=4752009, hfun=0x178734 cmd_error) at eval.c:1469 #16 0x00178dd8 in command_loop_2 () at keyboard.c:1326 #17 0x00246644 in internal_catch (tag=4746241, func=0x178dac command_loop_2, arg=4687873) at eval.c:1210 #18 0x00178d50 in command_loop () at keyboard.c:1305 #19 0x00178280 in recursive_edit_1 () at keyboard.c:1003 #20 0x001784e0 in Frecursive_edit () at keyboard.c:1064 #21 0x001760a4 in main (argc=2, argv=0xffbeecb4) at emacs.c:1794 Lisp Backtrace: move-overlay (0x587212) mouse-move-drag-overlay (0x587212) mouse-drag-track (0x67e525) mouse-drag-region (0x67e525) call-interactively (0x737301) (gdb) c Continuing. Breakpoint 5, update_menu_bar (f=0x6d9200, save_match_data=0, hooks_run=0) at xdisp.c:9195 (gdb) where #0 update_menu_bar (f=0x6d9200, save_match_data=0, hooks_run=0) at xdisp.c:9195 #1 0x000806ac in prepare_menu_bars () at xdisp.c:9073 #2 0x00085810 in redisplay_internal (preserve_echo_area=1) at xdisp.c:10902 #3 0x0008745c in redisplay_preserve_echo_area (from_where=6) at xdisp.c:11512 #4 0x001809cc in tracking_off (old_value=4687873) at keyboard.c:3474 #5 0x0024bf70 in unbind_to (count=27, value=4687873) at eval.c:3337 #6 0x00180a80 in Ftrack_mouse (args=3725805) at keyboard.c:3499 #7 0x00248fe8 in Feval (form=3725797) at eval.c:2260 #8 0x00244430 in Fprogn (args=3725789) at eval.c:435 #9 0x0024b554 in funcall_lambda (fun=3725773, nargs=0, arg_vector=0xffbeddc4) at eval.c:3162 #10 0x0024ae14 in Ffuncall (nargs=1, args=0xffbeddc0) at eval.c:3039 #11 0x002a2cb8 in Fbyte_code (bytestr=3725379, vector=3725396, maxdepth=48) at bytecode.c:679 #12 0x0024b5b8 in funcall_lambda (fun=3725324, nargs=2, arg_vector=0xffbee094) at eval.c:3169 #13 0x0024ad30 in Ffuncall (nargs=3, args=0xffbee090) at eval.c:3028 #14 0x002a2cb8 in Fbyte_code (bytestr=3724235,
RE: Multiple runs of menu-bar-update-hook
Was update_menu_bar called twice from a single call to prepare_menu_bars? If so, that means the mechanism I recently added to prevent that is broken. Or was prepare_menu_bars called twice? If so, how was it called, each time? It was called twice. Sorry if this still isn't clear, this is just the stack frames I sent earlier, but from a gcc build. This is the first call: Breakpoint 5, update_menu_bar (f=0x997400, save_match_data=0, hooks_run=0) at xdisp.c:9195 (gdb) where #0 update_menu_bar (f=0x997400, save_match_data=0, hooks_run=0) at xdisp.c:9195 #1 0x000806ac in prepare_menu_bars () at xdisp.c:9073 #2 0x00085810 in redisplay_internal (preserve_echo_area=0) at xdisp.c:10902 #3 0x00083ecc in redisplay () at xdisp.c:10491 #4 0x0017dba4 in read_char (commandflag=0, nmaps=0, maps=0x0, prev_event=4687921, used_mouse_menu=0x0, end_time=0x0) at keyboard.c:2555 #5 0x00270af4 in read_filtered_event (no_switch_frame=0, ascii_required=0, error_nonascii=0, input_method=0, seconds=4687873) at lread.c:495 #6 0x00270eb0 in Fread_event (prompt=4687873, inherit_input_method=4687873, seconds=4687873) at lread.c:600 #7 0x0024ab14 in Ffuncall (nargs=1, args=0xffbecec0) at eval.c:2988 #8 0x002a2cb8 in Fbyte_code (bytestr=3725827, vector=3725852, maxdepth=48) at bytecode.c:679 #9 0x002492a4 in Feval (form=3725813) at eval.c:2319 #10 0x00244430 in Fprogn (args=3725805) at eval.c:435 #11 0x00180a68 in Ftrack_mouse (args=3725805) at keyboard.c:3498 #12 0x00248fe8 in Feval (form=3725797) at eval.c:2260 #13 0x00244430 in Fprogn (args=3725789) at eval.c:435 #14 0x0024b554 in funcall_lambda (fun=3725773, nargs=0, arg_vector=0xffbed54c) at eval.c:3162 #15 0x0024ae14 in Ffuncall (nargs=1, args=0xffbed548) at eval.c:3039 #16 0x002a2cb8 in Fbyte_code (bytestr=3725379, vector=3725396, maxdepth=48) at bytecode.c:679 #17 0x0024b5b8 in funcall_lambda (fun=3725324, nargs=2, arg_vector=0xffbed81c) at eval.c:3169 #18 0x0024ad30 in Ffuncall (nargs=3, args=0xffbed818) at eval.c:3028 #19 0x002a2cb8 in Fbyte_code (bytestr=3724235, vector=3724252, maxdepth=40) at bytecode.c:679 #20 0x0024b5b8 in funcall_lambda (fun=3724196, nargs=1, arg_vector=0xffbedb0c) at eval.c:3169 #21 0x0024ad30 in Ffuncall (nargs=2, args=0xffbedb08) at eval.c:3028 #22 0x00243528 in Fcall_interactively (function=7566081, record_flag=4687873, keys=4747268) at callint.c:880 #23 0x00190a7c in Fcommand_execute (cmd=7566081, record_flag=4687873, keys=4687873, special=4687873) at keyboard.c:9797 #24 0x0017b290 in command_loop_1 () at keyboard.c:1790 #25 0x00246eb4 in internal_condition_case (bfun=0x17910c command_loop_1, handlers=4752009, hfun=0x178734 cmd_error) at eval.c:1469 #26 0x00178dd8 in command_loop_2 () at keyboard.c:1326 #27 0x00246644 in internal_catch (tag=4746241, func=0x178dac command_loop_2, arg=4687873) at eval.c:1210 #28 0x00178d50 in command_loop () at keyboard.c:1305 #29 0x00178280 in recursive_edit_1 () at keyboard.c:1003 #30 0x001784e0 in Frecursive_edit () at keyboard.c:1064 #31 0x001760a4 in main (argc=2, argv=0xffbee43c) at emacs.c:1794 Lisp Backtrace: read-event (0x0) byte-code (0x38da03) track-mouse (0x38d9ed) 0x38d9cd Lisp type 5 mouse-drag-track (0x5c44ed) mouse-drag-region (0x5c44ed) call-interactively (0x737301) (gdb) The second call is: Breakpoint 5, update_menu_bar (f=0x997400, save_match_data=0, hooks_run=0) at xdisp.c:9195 (gdb) where #0 update_menu_bar (f=0x997400, save_match_data=0, hooks_run=0) at xdisp.c:9195 #1 0x000806ac in prepare_menu_bars () at xdisp.c:9073 #2 0x00085810 in redisplay_internal (preserve_echo_area=0) at xdisp.c:10902 #3 0x00083ecc in redisplay () at xdisp.c:10491 #4 0x0017dba4 in read_char (commandflag=1, nmaps=2, maps=0xffbedb60, prev_event=4687873, used_mouse_menu=0xffbedcb4, end_time=0x0) at keyboard.c:2555 #5 0x0018dd50 in read_key_sequence (keybuf=0xffbede60, bufsize=30, prompt=4687873, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:8902 #6 0x00179668 in command_loop_1 () at keyboard.c:1535 #7 0x00246eb4 in internal_condition_case (bfun=0x17910c command_loop_1, handlers=4752009, hfun=0x178734 cmd_error) at eval.c:1469 #8 0x00178dd8 in command_loop_2 () at keyboard.c:1326 #9 0x00246644 in internal_catch (tag=4746241, func=0x178dac command_loop_2, arg=4687873) at eval.c:1210 #10 0x00178d50 in command_loop () at keyboard.c:1305 #11 0x00178280 in recursive_edit_1 () at keyboard.c:1003 #12 0x001784e0 in Frecursive_edit () at keyboard.c:1064 #13 0x001760a4 in main (argc=2, argv=0xffbee43c) at emacs.c:1794 (gdb) Which I assume is the main loop. You can see that both calls have come via redisplay(); the difference is their callers. (Of course both runs of the hook are unnecessary, they have been carried out because windows_or_buffers_changed = 1.) In the first: #4 0x0017dba4 in read_char (commandflag=0, nmaps=0, maps=0x0, prev_event=4687921, used_mouse_menu=0x0, end_time=0x0) at keyboard.c:2555 #5 0x00270af4 in read_filtered_event
RE: Error during ask-user-about-lock
The question is, what SHOULD Emacs do when a drag-and-drop event arrives while it is asking the user a question? I was afraid your question was going to be WHY does Emacs get a drag'n'drop event?, because I don't know the answer (and it doesn't make much sense to me). One possibility is, what it does now. Another possibility is, handle the drag-and-drop event on the side and continue asking. That could be implemented by binding it on special-event-map, as shown below. Do you like the results of this change? Does anyone think it is a mistake? Well, it works, and I still seem to be able to drag items from CDE's File Manager into Emacs. (I have never used drag'n'drop before---I use Dired.) I can't comment on it otherwise... Thanks, Simon. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Multiple runs of menu-bar-update-hook
Is this the kind of debugging you wanted - does it help? It is the right kind, and it gives some useful info. Now the question is, since it ran the hook inside update_menu_bar, why did it run the hook again in set_frame_menubar? Something near the start of that function must be setting deep_p to nonzero. Can you see what it is, and why? It did not run it again in set_frame_menubar()---both runs of the hook are from update_menu_bar() and via the same redisplay route. The snippets from the earlier email are: =[1] update_menu_bar(f = 0x964400, save_match_data = 0, hooks_run = 0), line 9195 in xdisp.c [2] prepare_menu_bars(), line 9073 in xdisp.c [3] redisplay_internal(preserve_echo_area = 0), line 10902 in xdisp.c [4] redisplay(), line 10491 in xdisp.c [5] read_char(commandflag = 0, nmaps = 0, maps = (nil), prev_event = 541825072, used_mouse_menu = (nil), end_time = (nil)), line 2555 in keyboard.c [6] read_filtered_event(no_switch_frame = 0, ascii_required = 0, error_nonascii = 0, input_method = 0, seconds = 541825024), line 496 in lread.c [7] Fread_event(prompt = 541825024, inherit_input_method = 541825024, seconds = 541825024), line 600 in lread.c ... And then: =[1] update_menu_bar(f = 0x964400, save_match_data = 0, hooks_run = 0), line 9195 in xdisp.c [2] prepare_menu_bars(), line 9073 in xdisp.c [3] redisplay_internal(preserve_echo_area = 0), line 10902 in xdisp.c [4] redisplay(), line 10491 in xdisp.c [5] read_char(commandflag = 1, nmaps = 2, maps = 0xffbedd50, prev_event = 541825024, used_mouse_menu = 0xffbeddcc, end_time = (nil)), line 2555 in keyboard.c [6] read_key_sequence(keybuf = 0xffbedf38, bufsize = 30, prompt = 541825024, dont_downcase_last = 0, can_return_switch_frame = 1, fix_current_buffer = 1), line 8893 in keyboard.c [7] command_loop_1(), line 1536 in keyboard.c [8] internal_condition_case(bfun = 0x1bba38 = command_loop_1(), handlers = 541881992, hfun = 0x1bb068 = cmd_error(Lisp_Object data)), line 1469 in eval.c [9] command_loop_2(), line 1326 in keyboard.c [10] internal_catch(tag = 541883392, func = 0x1bb650 = command_loop_2(), arg = 541825024), line 1210 in eval.c [11] command_loop(), line 1305 in keyboard.c [12] recursive_edit_1(), line 1003 in keyboard.c [13] Frecursive_edit(), line 1064 in keyboard.c [14] main(argc = 2, argv = 0xffbee444), line 1794 in emacs.c I would also say that it is not just the second call that is important to understand, the first call is unnecessary too. After all, I only did mouse-1 in the selected frame (where the other frame is showing the same buffer). This is a guess based on what you have said previous: I think the reason update_menu_bar() ran the hooks is because windows_or_buffers_changed = 1, and that is because modify_overlay() sets it, and that is because the buffer is shown in more than one window. (See the latter parts of the earlier email---let me know if you want me to send it again.) Simon. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Multiple runs of menu-bar-update-hook
Earlier I made the point that Qmenu_bar_update_hook is already run when I mouse-1 on the menu bar. I suggested that it seemed reasonable to run it at that time and other specific times only (such as when switching buffers or windows), rather than during redisplay. No-one came out and said it was mad or stupid, so would dealing with the menu bar that way be better than dealing with it during redisplay and fixing the existing code? I don't like it. It makes new assumptions about what conditions menu-bar-update-hook cares about. Ok, your call, though emacs-22.1 would be a good time to change assumptions! Simon. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Error during ask-user-about-lock
Can you find out what Lisp object the event is?
That should make the cause clear.
It's probably a `switch-frame' event.
It took a while to get a gcc build built. I put a breakpoint on:
if (ascii_required !(NUMBERP (seconds) NILP (val)))
{
/* Convert certain symbols to their ASCII equivalents. */
-- if (SYMBOLP (val))
{
Lisp_Object tem, tem1;
tem = Fget (val, Qevent_symbol_element_mask);
if (!NILP (tem))
{
tem1 = Fget (Fcar (tem), Qascii_character);
/* Merge this symbol's modifier bits
with the ASCII equivalent of its basic code. */
if (!NILP (tem1))
XSETFASTINT (val, XINT (tem1) | XINT (Fcar (Fcdr (tem;
}
}
/* If we don't have a character now, deal with it appropriately. */
if (!INTEGERP (val))
{
if (error_nonascii)
{
Vunread_command_events = Fcons (val, Qnil);
error (Non-character input-event);
}
else
goto retry;
}
}
Got myself ready and hit ? when ask-user-about-lock prompted:
Breakpoint 7, read_filtered_event (no_switch_frame=1, ascii_required=1,
error_nonascii=1, input_method=0, seconds=4687873) at lread.c:517
517 if (SYMBOLP (val))
(gdb) p val
$3 = 504
(gdb) pr
63
This appears to be the ? I entered (ascii 63), so I step and then
continue:
532 if (!INTEGERP (val))
544 if (! NILP (delayed_switch_frame))
556 return val;
557 }
Fread_char (prompt=4687873, inherit_input_method=4687873, seconds=4687873)
at lread.c:583
583 }
Ffuncall (nargs=1, args=0xffbed358) at eval.c:2990
2990 goto done;
Continuing.
It hits the break point again:
Breakpoint 7, read_filtered_event (no_switch_frame=1, ascii_required=1,
error_nonascii=1, input_method=0, seconds=4687873) at lread.c:517
517 if (SYMBOLP (val))
(gdb) p val
$4 = 6898253
(gdb) pr
(drag-n-drop (#frame *Help* 0xa8a800 nil (788 . 20) 0)
[_MOTIF_WM_MESSAGES #frame *Help* 0xa8a800 32 [135 6 25 0 0]])
(gdb)
This time I get a drag-n-drop event. Is there anything else you need?
(I couldn't reproduce this bug with a lucid toolkit build.)
Simon.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Error when applying hunk in Diff buffer
Does the patch below provide an acceptable compromise? Ok, thanks. Simon. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Broken mode-line buffer-name button
I used to be able to mouse-1 and mouse-3 on the buffer name in the mode line, but this stopped working recently. Now they run mouse-drag-mode-line and mouse-delete-window, respectively. The other mode line buttons seem ok. In GNU Emacs 22.0.50.13 (sparc-sun-solaris2.8, Motif Version 2.1.0) of 2006-07-31 on perth X server distributor `Hummingbird Ltd.', version 11.0.100015 configured using `configure '--prefix=/rvcarma/marshals/software/slash/usr/local' '--with-x-toolkit=motif' 'CFLAGS=-g'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: en_GB.ISO8859-1 value of $LC_CTYPE: en_GB.ISO8859-1 value of $LC_MESSAGES: C value of $LC_MONETARY: en_GB.ISO8859-1 value of $LC_NUMERIC: en_GB.ISO8859-1 value of $LC_TIME: en_GB.ISO8859-1 value of $LANG: en_GB.ISO8859-1 locale-coding-system: iso-8859-1 default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Multiple runs of menu-bar-update-hook
As for running menu-bar-update-hook multiple times when multiple frames update their menu bars, I see there's no way for the hook functions to tell which frame they are being called for. So there is no possible use in running it once for each frame. This patch should get rid of that. Does it? Yes, it does seem to, there are multiple runs but they only occur in one frame. I have another gem that might provide some insight: src/emacs -Q (setq bar 0) (defun foo () (message foo: %s %d (buffer-name) (setq bar (1+ bar (add-hook 'menu-bar-update-hook 'foo) M-x eval-buffer RET C-x 5 2 Now double mouse-1 on message. The hook gets run multiple times (4 with your patch, 8 with CVS emacs). This is as I've already reported. Now, without doing anything else, quickly do double mouse-1 on message again. After the initial run multiple times as before, I see the hook being run repeatedly, perhaps twice a second. Note that it doesn't always happen like this (which is why I hadn't noticed it before) and you might need to try it again to reproduce it. Before you ask, disabling Options Blinking Cursor seems to prevent it happening with a twist: there is a run of the hook after a pause (half a second?) but it is not repeated. I guess this is a quirk of the way blinking cursor is implemented. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Multiple runs of menu-bar-update-hook
The function update_menu_bar does various things, such as running menu-bar-update-hook. Then it calls set_frame_menubar, with DEEP_P = 0. This is supposed to tell set_frame_menubar not to run menu-bar-update-hook, and not to do various other things that would be redundant. Apologies if this is noise. I can see that update_menu_bar() attempts to detect whether it needs to run the hook. Amongst other things, that test allows the hook to run if windows_or_buffers_changed is non-zero. The complexity of the test suggested to me that update_menu_bar() should not be called as frequently as it is or perhaps from where it is, particularly because... I notice that the hook is run once whenever I down-mouse-1 on the menu bar (at least with lucid or motif toolkit). This may be a stupid question, but isn't it enough to run at this point? Does emacs need to run the hook during buffer editing, window motion or frame switching? (Obviously it needs to be run during buffer or window switching.) In other words, does the hook need to be run from under redisplay() itself? I appreciate there are some special cases when the hook should be run, such as when the menu bar is reconfigured (eg, when the major mode changes). But, assuming that these happen from a small number of interface functions (eg, define-key), the hook could be run from lisp. (The hook could also be run from those functions that handle buffer or window switching.) For example, to show how the update_menu_bar() test gets compromised, we get runs of the hook with mouse-1 in a buffer (when the buffer is shown in more than one frame) because windows_or_buffers_changed is set to 1 at this point in modify_overlay(): /* If this is a buffer not in the selected window, we must do other windows. */ if (buf != XBUFFER (XWINDOW (selected_window)-buffer)) windows_or_buffers_changed = 1; /* If multiple windows show this buffer, we must do other windows. */ else if (buffer_shared 1) ==windows_or_buffers_changed = 1; /* If we modify an overlay at the end of the buffer, we cannot be sure that window end is still valid. */ else if (end = ZV start = ZV) windows_or_buffers_changed = 1; (dbx) where =[1] modify_overlay(buf = 0x4c2c00, start = 32, end = 32), line 3673 in buffer.c [2] Fmove_overlay(overlay = 1079977680, beg = 32, end = 32, buffer = -2142491648), line 3763 in buffer.c [3] Ffuncall(nargs = 4, args = 0xffbed3a8), line 2993 in eval.c [4] Fbyte_code(bytestr = 1614550196, vector = -2143546172, maxdepth = 4), line 679 in bytecode.c [5] funcall_lambda(fun = -2143546244, nargs = 4, arg_vector = 0xffbed694), line 3171 in eval.c [6] Ffuncall(nargs = 5, args = 0xffbed690), line 3028 in eval.c [7] Fbyte_code(bytestr = 1614550636, vector = -2143545732, maxdepth = 6), line 679 in bytecode.c [8] funcall_lambda(fun = -2143545800, nargs = 2, arg_vector = 0xffbed984), line 3171 in eval.c [9] Ffuncall(nargs = 3, args = 0xffbed980), line 3028 in eval.c [10] Fbyte_code(bytestr = 1614549532, vector = -2143546836, maxdepth = 5), line 679 in bytecode.c [11] funcall_lambda(fun = -2143546892, nargs = 1, arg_vector = 0xffbedc94), line 3171 in eval.c [12] Ffuncall(nargs = 2, args = 0xffbedc90), line 3028 in eval.c [13] Fcall_interactively(function = 544701776, record_flag = 541825024, keys = -2142470144), line 880 in callint.c [14] Fcommand_execute(cmd = 544701776, record_flag = 541825024, keys = 541825024, special = 541825024), line 9780 in keyboard.c [15] command_loop_1(), line 1790 in keyboard.c [16] internal_condition_case(bfun = 0x1bb988 = command_loop_1(), handlers = 541881992, hfun = 0x1bafb8 = cmd_error(Lisp_Object data)), line 1469 in eval.c [17] command_loop_2(), line 1326 in keyboard.c [18] internal_catch(tag = 541883392, func = 0x1bb5a0 = command_loop_2(), arg = 541825024), line 1210 in eval.c [19] command_loop(), line 1305 in keyboard.c [20] recursive_edit_1(), line 1003 in keyboard.c [21] Frecursive_edit(), line 1064 in keyboard.c [22] main(argc = 2, argv = 0xffbee43c), line 1794 in emacs.c (dbx) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Multiple runs of menu-bar-update-hook
I notice that the hook is run once whenever I down-mouse-1 on the menu bar (at least with lucid or motif toolkit). This may be a stupid question, but isn't it enough to run at this point? Does emacs need to run the hook during buffer editing, window motion or frame switching? (Obviously it needs to be run during buffer or window switching.) In other words, does the hook need to be run from under redisplay() itself? Buffer text may have a keymap or local-map property which may define specific menu-items (even top-level items) that are specific to that buffer position. So even just moving point must call the update hook. Surely only when point moves in/out of text that has those properties? Ok, I appreciate there are special cases, just like switching the buffer or window. If those can be handled specifically when the buffer or window changes, why can't your example be handled when point moves in/out of text that has those properties? In other words, in general, is the update of the menu bar more appropriate for redisplay (which in reality hardly ever needs to actually update the menu bar) or for the (small?) set of actions that can effect menu bars? Simon. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Multiple runs of menu-bar-update-hook
I noticed this when debugging something else that I found when trying to debug a reason for poor Emacs responsiveness. What comes around comes around - I think I have found a problem that could cause poor responsiveness. This is with CVS as of 2006-07-24 with/without Martin's chars_modiff patch. emacs -Q and evaluate in *scratch*: (setq bar 0) (defun foo () (message foo: %s %d (buffer-name) (setq bar (1+ bar (add-hook 'menu-bar-update-hook 'foo) Now do a double mouse-1 on the word message in *scratch* to select the word. You can see from the messages in the minibuffer that menu-bar-update-hook is run twice. I am assuming that menu-bar-update-hook need not be called to support region-sensitive menu entries, since they can use an :enable property to achieve that. Should menu-bar-update-hook be called in this context? Should it be called twice? Now open multiple frames so there is more than 1 frame showing *scratch*, and repeat the selection of a word in *scratch*. You can see from the messages in the minibuffer that menu-bar-update-hook is run twice for each frame (both *scratch* and non-*scratch* frames). Should it be run multiple times for each frame? Now do a single mouse-1 at EOB. Again, menu-bar-update-hook is run twice for each frame. This happens regardless of the number of frames. Now do a single mouse-1 anywhere in *scratch*. When there is more than 1 frame showing *scratch*, menu-bar-update-hook is run twice for each frame. Now do a down mouse-1 anywhere in *scratch* and slowly drag to extend the region. When there is more than 1 frame and there is more than 1 frame showing *scratch*, menu-bar-update-hook is run once for each frame for each character that the region is extended by. I use msb.el and imenu.el, both of which put their functions on menu-bar-update-hook, and I frequently use 5+ frames. I know they attempt to limit the amount of work they do, but I'm sure calling lisp in this way is going to have an impact. In GNU Emacs 22.0.50.10 (sparc-sun-solaris2.8, Motif Version 2.1.0) of 2006-07-26 on perth X server distributor `Hummingbird Ltd.', version 11.0.100015 configured using `configure '--prefix=/rvcarma/marshals/software/slash/usr/local' '--with-x-toolkit=motif' 'CFLAGS=-g'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: en_GB.ISO8859-1 value of $LC_CTYPE: en_GB.ISO8859-1 value of $LC_MESSAGES: C value of $LC_MONETARY: en_GB.ISO8859-1 value of $LC_NUMERIC: en_GB.ISO8859-1 value of $LC_TIME: en_GB.ISO8859-1 value of $LANG: en_GB.ISO8859-1 locale-coding-system: iso-8859-1 default-enable-multibyte-characters: t ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Error in menu-bar-update-hook: (error Point before start of p rope rties)
The above already looks wrong: i-left covers 145078 chars, so i-position should be at least 145078 + 1 (aka BEG). The difference, 88, is presumably the length of the line you copiedpasted, so i's position hasn't been updated as it should have (the `position' field of interval nodes is updated lazily, so it's sometimes normal for it to be out-of-date, but not in this case). Good spot. I had rapidly done C-k C-k C-y C-y to copy a line. I can't remember exactly which line I was copying, but one of the few candidate lines does happen to be 44 chars long. I did C-y C-y, which means I did paste 88 chars (after deleting 44 chars). Of course, the paste was via two inserts, albeit with a very small time interval between them. Maybe I circumvented the lazy update somehow? What should I look for re the buffer text properties? The buffer is full of them - it's visiting a C++ file. Without a reliable way to reproduce the problem, it's going to be difficult to fix it, because the problem is most likely introduced sometime *before* we crash. I appreciate that. If someone would like to reproduce my environment, my setup includes: (custom-set-variables ... '(imenu-auto-rescan t) '(imenu-auto-rescan-maxout 1048576) '(imenu-max-items 30) '(imenu-scanning-message nil) '(imenu-sort-function (quote imenu--sort-by-name)) ...) (add-hook 'c-mode-common-hook 'imenu-add-menubar-index) I get the error within a day of editing C++ buffers. However, I'll continue to run under a debugger, and hopefully will be able to provide some useful feedback. Simon. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Error when applying hunk in Diff buffer
Or maybe diff-mode should be able to cope with a diff like this: [...] And DTRT? Yes, maybe diff-mode could use some heuristic to decide which of the two file names should be used. Maybe if one of the two is a backup files (with the ~ at the end) or if one of the two is read-only, then the default should be to apply the hunk to the other... But to tell you the truth, I think there's already too much heuristic involved in diff-mode's selection of the file, place, and direction of the hunk application. So it's probably better to get used to telling Emacs what you mean, rather than let Emacs figure out that you meant something else than what you said. I understand what you're saying from a developer's perspective, but I raised this as a user from a user's perspective. I have (AFAIK) always been able to do C-x v = and C-c C-a (or frequently their menu entries) and emacs happily DTRT. Now I find it does not work, barfing about a buffer I didn't open that is visiting a file I didn't create. See what I mean? And there is nothing (even in NEWS---assuming a user would look in it) to tell me to set vc-stay-local to nil or do C-u C-c C-a (which does not have a menu-only entry) to make it work. Simon. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: [EMAIL PROTECTED]: Font Lock on-the-fly misfontificat ion in C++]
The patch below seems to fix number 2 and 3 for me. Someone who understands cc-fonts.el better than me and thus knows where the two public XXX lines are handled could probably do a similar adjustment for them. Thanks, I'll see how the fix for #2 and #3 performs. Simon. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Error when applying hunk in Diff buffer
The change in Emacs-22 is that the diff can be done locally (with `diff') rather than via `cvs'. If you remove the file foo.~.rev~, then it'll force VC to ask `cvs' to do the diff and you'll get a header just like the one we get with -L (this use of -L is specifically to reproduce the header that `cvs' would have output). So you'd basically have to tell VC to knot use the local copy of the file in vc-diff-internal. As Andre suggested, setting vc-stay-local to nil solves the problem. Maybe vc-stay-local should be set when vc-diff-internal sets vc-diff-knows-L? Or maybe vc-stay-local should default to nil so vc.el always works? It seems wrong that vc.el may not work out of the box and that the user is expected to change some variable to make it work. Or maybe if vc-diff-knows-L is 'no then vc-stay-local should be ignored (treated as if nil)? Or maybe those 2 variables should be combined? I appreciate they are used at different times. Or maybe diff-mode should be able to cope with a diff like this: *** ChangeLog.~1.481.~ Mon Jul 17 09:47:44 2006 --- ChangeLog Thu Jul 20 11:59:52 2006 *** *** 1,7 2006-07-14 Eli Zaretskii [EMAIL PROTECTED] * configure.in (PKG_CHECK_MODULES): Redirect the output of - $PKG_CONFIG --exists $2 to config.log. * configure: Regenerated. 2006-07-14 Kim F. Storm [EMAIL PROTECTED] --- 1,6 And DTRT? Though I don't know if that would be easy or even desirable (maybe it would break some expected behaviour)... Lots of questions, hopefully an easy answer. Simon. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Error in menu-bar-update-hook: (error Point before start of p rope rties)
The anomaly here is in the original error. I am not sure
whether that error ought to be possible at all.
How about if you run with a breakpoint at the line in
intervals.c which gets that error? When you get there, look
at the value of POS.
Then examine the existing buffer properties. You can do that
at the C level, or continue into the Lisp debugger and do it there.
This time it happened while I was doing C-k C-k C-y C-y to copy a line.
(Though I guess the edit is irrelevant - the error is during a buffer-wide
imenu update.) The caller is update_syntax_table():
if (NULL_INTERVAL_P (i))
error (Error in syntax_table logic for to-the-end intervals);
else if (charpos i-position) /* Move left. */
{
if (count 0)
error (Error in syntax_table logic for intervals -);
/* Update the interval. */
== i = update_interval (i, charpos);
if (INTERVAL_LAST_POS (i) != gl_state.b_property)
{
invalidate = 0;
gl_state.forward_i = i;
gl_state.e_property = INTERVAL_LAST_POS (i) - gl_state.offset;
}
}
Here's some hopefully useful info from the stack:
(dbx) frame 1
Current function is update_interval
(dbx) print pos
pos = 30065
(dbx) print i
i = 0xb46710
(dbx) print *i
*i = {
total_length = 357181U
position = 144991U
(*i).left = 0x110ba4c
(*i).right= 0x1113f10
up= {
(*i).up.interval = 0x80f1e800
obj = -2131630080
}
up_obj= 1U
gcmarkbit = 0
write_protect = 0
visible = 0
front_sticky = 0
rear_sticky = 0
plist = 541931520
}
(dbx) print *i-left
*i-left = {
total_length = 145078U
position = 76520U
(*i-left).left = 0x10d5684
(*i-left).right = 0x10adb80
up= {
(*i-left).up.interval = 0xb46710
obj = 11822864
}
up_obj= 0
gcmarkbit = 0
write_protect = 0
visible = 0
front_sticky = 0
rear_sticky = 0
plist = 541931520
}
(dbx) print *i-right
*i-right = {
total_length = 212060U
position = 252468U
(*i-right).left = 0x10b00c4
(*i-right).right = 0x105348c
up= {
(*i-right).up.interval = 0xb46710
obj = 11822864
}
up_obj= 0
gcmarkbit = 0
write_protect = 0
visible = 0
front_sticky = 0
rear_sticky = 0
plist = 541931520
}
(dbx) frame 2
Current function is update_syntax_table
(dbx) print i
i = 0x10d5684
(dbx) print *i
*i = {
total_length = 76563U
position = 30107U
(*i).left = 0xfc0bb8
(*i).right= 0x113eed8
up= {
(*i).up.interval = 0x110ba4c
obj = 17873484
}
up_obj= 0
gcmarkbit = 0
write_protect = 0
visible = 0
front_sticky = 0
rear_sticky = 0
plist = 541931520
}
(dbx)
What should I look for re the buffer text properties? The buffer is full of
them - it's visiting a C++ file.
The full backtrace is:
(dbx) where
=[1] update_interval(i = 0xb46710, pos = 30065), line 784 in intervals.c
[2] update_syntax_table(charpos = 30065, count = -1, init = 0, object =
541931520), line 179 in syntax.c
[3] re_match_2_internal(bufp = 0x4c1084, string1 = 0x1d8dcd0 [...] ...,
size2 = 344731, pos = 30064, regs = 0x4b5ce4, stop = 357181), line 5861 in
regex.c
[4] re_search_2(bufp = 0x4c1084, str1 = 0x1d8dcd0 [...] ..., size2 =
344731, startpos = 30064, range = -30064, regs = 0x4b5ce4, stop = 357181),
line 4383 in regex.c
[5] search_buffer(string = 1626133504, pos = 357182, pos_byte = 357182,
lim = 1, lim_byte = 1, n = -1, RE = 1, trt = 541931520, inverse_trt =
541931520, posix = 0), line 1109 in search.c
[6] search_command(string = 1626133504, bound = 541931520, noerror =
541931568, count = 541931520, direction = -1, RE = 1, posix = 0), line 947
in search.c
[7] Fre_search_backward(regexp = 1626133504, bound = 541931520, noerror =
541931568, count = 541931520), line 2192 in search.c
[8] Ffuncall(nargs = 4, args = 0xffbec660), line 2926 in eval.c
[9] Fbyte_code(bytestr = 1621738544, vector = -2137846272, maxdepth = 8),
line 679 in bytecode.c
[10] funcall_lambda(fun = -2136168768, nargs = 1, arg_vector =
0xffbec95c), line 3104 in eval.c
[11] Ffuncall(nargs = 2, args = 0xffbec958), line 2961 in eval.c
[12] Fbyte_code(bytestr = 1621738496, vector = -2137082880, maxdepth = 3),
line 679 in bytecode.c
[13] funcall_lambda(fun = -2136168352, nargs = 0, arg_vector =
0xffbecc44), line 3104 in eval.c
[14] Ffuncall(nargs = 1, args = 0xffbecc40), line 2961 in eval.c
[15] Fbyte_code(bytestr = 1621741376, vector = -2137082688, maxdepth = 2),
line 679 in bytecode.c
[16] funcall_lambda(fun = -2136167200, nargs = 1, arg_vector =
0xffbecf24), line 3104 in eval.c
[17] Ffuncall(nargs = 2, args = 0xffbecf20), line 2961 in eval.c
[18]
jit lock sit-for provokes redisplay provokes imenu
In trying to monitor a problem with imenu and to find out why emacs seems so slow and unresponsive while editing, I also noticed that it is getting called repeatedly after emacs has been idle for a while. I currently have these timers active: timer-idle-list is a variable defined in `C source code'. Its value is ([t 0 0 125000 t show-paren-function nil t] [t 0 0 50 0.5 blink-cursor-start nil t] [t 0 0 50 t jit-lock-context-fontify nil t] [nil 0 30 0 t jit-lock-stealth-fontify nil t]) After ~30s of idle time, I see imenu-update-menubar being called continuously by emacs. At a guess, imenu is being triggered because jit-lock has kicked in. At the time, I had several frames open, including one containing a finished *compilation* buffer and another containing a large C++ buffer. Also, the minibuffer (in a separate frame) was showing a message every time imenu-update-menubar was called. This is the backtrace when I paused emacs. Unfortunately, I thought it useful to compile with Sun cc (rather than gcc like most people) and so I am debugging with sunstudio/dbx. I don't know how to debug what Lisp forms are being evaluated. However, frame 38 shows that some bytecode called Fredisplay. The only lisp code I can find that calls redisplay is subr.el's sit-for. It is worth noting that jit-lock-stealth-fontify calls sit-for. Putting message forms in it suggests that redisplay is a consequence of its sit-fors. Changing its calls of sit-for to pass t for NODISP does not seem to stop the repeated calls of imenu-update-menubar. Changing its calls of (sit-for ...) to (not (input-pending-p)) does stop them, though of course changes the behaviour of jit-lock. Any thoughts before I recompile with gcc? =[1] re_match_2_internal(bufp = 0x4c0bc4, string1 = 0x1ea4228 [...] ..., size2 = 217774, pos = 2267, regs = 0x4b5ce4, stop = 14692), line 5360 in regex.c [2] re_search_2(bufp = 0x4c0bc4, str1 = 0x1ea4228 [...] ..., size2 = 217774, startpos = 2267, range = -2267, regs = 0x4b5ce4, stop = 14692), line 4383 in regex.c [3] search_buffer(string = 1623676992, pos = 14693, pos_byte = 14693, lim = 1, lim_byte = 1, n = -1, RE = 1, trt = 541931520, inverse_trt = 541931520, posix = 0), line 1109 in search.c [4] search_command(string = 1623676992, bound = 541931520, noerror = 541931568, count = 541931520, direction = -1, RE = 1, posix = 0), line 947 in search.c [5] Fre_search_backward(regexp = 1623676992, bound = 541931520, noerror = 541931568, count = 541931520), line 2192 in search.c [6] Ffuncall(nargs = 4, args = 0xffbeaa90), line 2926 in eval.c [7] Fbyte_code(bytestr = 1621914496, vector = -2136224256, maxdepth = 8), line 679 in bytecode.c [8] funcall_lambda(fun = -2136177120, nargs = 1, arg_vector = 0xffbead8c), line 3104 in eval.c [9] Ffuncall(nargs = 2, args = 0xffbead88), line 2961 in eval.c [10] Fbyte_code(bytestr = 1621914448, vector = -2137086912, maxdepth = 3), line 679 in bytecode.c [11] funcall_lambda(fun = -2136176640, nargs = 0, arg_vector = 0xffbeb074), line 3104 in eval.c [12] Ffuncall(nargs = 1, args = 0xffbeb070), line 2961 in eval.c [13] Fbyte_code(bytestr = 1621914272, vector = -2137086720, maxdepth = 2), line 679 in bytecode.c [14] funcall_lambda(fun = -2136175552, nargs = 1, arg_vector = 0xffbeb290), line 3104 in eval.c [15] apply_lambda(fun = -2136175552, args = -1586393080, eval_flag = 1), line 3026 in eval.c [16] Feval(form = -1586393072), line 2288 in eval.c [17] Flet(args = -1586398248), line 1039 in eval.c [18] Feval(form = -1586393056), line 2193 in eval.c [19] Fprogn(args = -1585935904), line 434 in eval.c [20] Feval(form = -1585935960), line 2193 in eval.c [21] Fif(args = -1585935976), line 382 in eval.c [22] Feval(form = -1585935984), line 2193 in eval.c [23] Feval(form = -1586392776), line 2304 in eval.c [24] Fprogn(args = -1586399152), line 434 in eval.c [25] funcall_lambda(fun = -1586399160, nargs = 0, arg_vector = 0xffbebc6c), line 3095 in eval.c [26] Ffuncall(nargs = 1, args = 0xffbebc68), line 2972 in eval.c [27] run_hook_with_args(nargs = 1, args = 0xffbebc68, cond = to_completion), line 2574 in eval.c [28] Frun_hooks(nargs = 1, args = 0xffbebd9c), line 2437 in eval.c [29] Ffuncall(nargs = 2, args = 0xffbebd98), line 2896 in eval.c [30] call1(fn = 542022568, arg1 = 542148848), line 2696 in eval.c [31] safe_run_hooks_1(hook = 0), line 2037 in keyboard.c [32] internal_condition_case(bfun = 0x1bea68 = `emacs`keyboard.c`safe_run_hooks_1(Lisp_Object hook), handlers = 541931568, hfun = 0x1beab8 = `emacs`keyboard.c`safe_run_hooks_error(Lisp_Object data)), line 1473 in eval.c [33] safe_run_hooks(hook = 542148848), line 2065 in keyboard.c [34] update_menu_bar(f = 0x936a00, save_match_data = 0), line 9173 in xdisp.c [35] prepare_menu_bars(), line 9059 in xdisp.c [36] redisplay_internal(preserve_echo_area = 1), line 10874 in xdisp.c [37] redisplay_preserve_echo_area(from_where = 2), line 11480 in xdisp.c [38]
Error when applying hunk in Diff buffer
To reproduce: C-x C-f ChangeLog RET C-x v v Remove a line C-x v = SPC Move to the *vc-diff* buffer and the change you have made, then: C-c C-a I get a buffer read-only error. It looks like vc is trying to use the wrong buffer. For me, the *vc-diff* buffer contains: *** ChangeLog.~1.481.~ Mon Jul 17 09:47:44 2006 --- ChangeLog Thu Jul 20 11:59:52 2006 *** *** 1,7 2006-07-14 Eli Zaretskii [EMAIL PROTECTED] * configure.in (PKG_CHECK_MODULES): Redirect the output of - $PKG_CONFIG --exists $2 to config.log. * configure: Regenerated. 2006-07-14 Kim F. Storm [EMAIL PROTECTED] --- 1,6 In GNU Emacs 22.0.50.2 (sparc-sun-solaris2.8, Motif Version 2.1.0) of 2006-07-19 on perth X server distributor `Hummingbird Ltd.', version 11.0.100015 configured using `configure '--prefix=/rvcarma/marshals/software/slash/usr/local' '--with-x-toolkit=motif' 'CFLAGS=-g'' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Error when applying hunk in Diff buffer
To reproduce: C-x C-f ChangeLog RET C-x v v Remove a line C-x v = SPC C-x v = runs vc-diff (no SPC) It prompts you to save the file - you just removed a line. I am a pedant. For me, the *vc-diff* buffer contains: *** ChangeLog.~1.481.~ Mon Jul 17 09:47:44 2006 --- ChangeLog Thu Jul 20 11:59:52 2006 *** With vc-diff I get: *** ChangeLog 15 Jul 2006 10:13:39 +1200 1.481 --- ChangeLog 20 Jul 2006 23:16:33 +1200 *** ... With dired-diff I get something like you: *** /home/nickrob/emacs/ChangeLog.~1.481.~2006-07-15 10:13:39.0 +1200 --- /home/nickrob/emacs/ChangeLog 2006-07-20 23:16:33.0 +1200 *** ... Then C-c C-a gives a read-only error because ChangeLog.~1.481.~ _is_ read only and diff-apply-hunk changes the first file to the second. So that seems right to me. Not really. In any case, earlier emacs would detect that that part of the patch was already applied and offer to reverse it. A very useful feature indeed. That code still appears to be in diff-apply-hunk, but it presumably doesn't get a chance because of the bug. I included the contents of *vc-diff* in case it is related to a recent problem with vc-diff-internal when diff doesn't support -L. You imply, but don't say, that the bug doesn't appear for you with C-x v =. If that is the case, the fact that your *vc-diff* buffer does not contain different ChangeLog file names suggests my guess might be correct. Simon. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Error when applying hunk in Diff buffer
I'm not sure what exactly is the issue here, but I seem to remember that diff-mode does rely on the labels inserted by -L in order to implement applying and reversing of hunks. It could be that this feature can therefore not work correctly under Solaris 8. The -L feature is only needed if VC performs a local diff though. So perhaps switching off local diffs (by setting vc-cvs-stay-local to nil) might help. I'll copy Stefan on this, perhaps he can say something. Hi Andre, it can work on Solaris 8, and has done all the way up to 21.3. Maybe it's something as simple as diff-mode now using the first file name from the diff? The second is the only one that corresponds to the buffer if -L is not used. (Unless diff-mode is meant to support the arbitrary application of a diff to an arbitrary buffer, in which case neither file name in the diff corresponds.) Sorry, I don't really have the time to report bugs, let alone investigate/fix them myself. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Error in menu-bar-update-hook: (error Point before start of prope rties)
I occasionally see this error in the minibuffer, after which it seems menu-bar-update-hook is set to nil. Normally, in my session, it would be: (imenu-update-menubar msb-menu-bar-update-buffers) This time, I think it was immediately following a paste in a C++ buffer with Font Lock mode (and a whole lot of other things no doubt) turned on. I'm guessing it's caused by imenu, but anyone else seen this or have a hint that would help track it down? This is with CVS as of July 17 + Martin Rudalics' mouse-autoselect-window patch. In GNU Emacs 22.0.50.3 (sparc-sun-solaris2.8, Motif Version 2.1.0) of 2006-07-17 on perth X server distributor `Hummingbird Ltd.', version 11.0.100015 configured using `configure '--prefix=/rvcarma/marshals/software/slash/usr/local' '--with-x-toolkit=motif' 'CFLAGS=-g'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: en_GB.ISO8859-1 value of $LC_CTYPE: en_GB.ISO8859-1 value of $LC_MESSAGES: C value of $LC_MONETARY: en_GB.ISO8859-1 value of $LC_NUMERIC: en_GB.ISO8859-1 value of $LC_TIME: en_GB.ISO8859-1 value of $LANG: en_GB.ISO8859-1 locale-coding-system: iso-8859-1 default-enable-multibyte-characters: t Major mode: Fundamental Minor modes in effect: delete-selection-mode: t mouse-sel-mode: t msb-mode: t partial-completion-mode: t show-paren-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Font Lock on-the-fly misfontification in C++
Put the following in a fubar.cpp:
class Fubar :
public Foo, // Foo fontified as a type, at first
public Bar// Bar fontified as a type, at first
{
Foo bar(Snafu snafu, // Types, function, variable fontified, at first
Foo foo,
Bar bar);
Foo bar(Snafu *snafu, // Types, function, variable fontified, at first
Foo foo,
Bar bar);
};
Then emacs -Q fubar.cpp. I see Foo, Bar and Snafu fontified as types even
where declaring functions and variables. The corresponding functions and
variables are fontified correctly. This is great!
Then do the following.
1. Append a space to the first (or second) commented line. Bug:
fontification of Foo (or Bar) is removed from that line.
2. Append a space to the third commented line. Bug: fontification of Foo
and bar is removed from that line.
3. Append a space to the fourth commented line. Bug: fontification of Foo,
bar, Snafu and snafu is removed from that line.
Somewhat spookily, if you then repeat (2), then the fourth commented line
(3) gets fontified correctly after the deferral delay.
I think this is some sort of problem with Jit Lock mode multiline
fontification, at least for (2) and (3), since Lazy Lock mode works ok.
In GNU Emacs 22.0.50.2 (sparc-sun-solaris2.8, Motif Version 2.1.0)
of 2006-07-19 on perth
X server distributor `Hummingbird Ltd.', version 11.0.100015
configured using `configure
'--prefix=/rvcarma/marshals/software/slash/usr/local'
'--with-x-toolkit=motif' 'CFLAGS=-g''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: en_GB.ISO8859-1
value of $LC_CTYPE: en_GB.ISO8859-1
value of $LC_MESSAGES: C
value of $LC_MONETARY: en_GB.ISO8859-1
value of $LC_NUMERIC: en_GB.ISO8859-1
value of $LC_TIME: en_GB.ISO8859-1
value of $LANG: en_GB.ISO8859-1
locale-coding-system: iso-8859-1
default-enable-multibyte-characters: t
Major mode: Emacs-Lisp
Minor modes in effect:
tooltip-mode: t
tool-bar-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
unify-8859-on-encoding-mode: t
utf-translate-cjk-mode: t
auto-compression-mode: t
line-number-mode: t
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Compile-goto-error can signal wrong-type-argument
Hi Stefan, thanks for the response. I had to apply the patch by hand, since I've been away and the patch was against an older revision that the one I now have post-update. I have only used this feature with popup windows, and the patch doesn't make any difference to me with those. I'm using the MOTIF toolkit. I am still able to click on the OK button even when in a directory that does not contain the file. Looking into it, maybe it is because x-file-dialog does not support PREDICATE? Or am I misreading code? Simon. -Original Message- From: Stefan Monnier [mailto:[EMAIL PROTECTED] Sent: 11 July 2006 15:21 To: Marshall, Simon Cc: 'Emacs Pretest Bug (emacs-pretest-bug@gnu.org)' Subject: Re: Compile-goto-error can signal wrong-type-argument Marshall, == Marshall, Simon [EMAIL PROTECTED] writes: This is a buggette in CVS head as of 2006-06-19. src/emacs -Q Start a compilation which is going to raise some errors. Then mouse-1 on an error to get the popup window Find this error in (default ...) for you to navigate to the file. (The error message doesn't contain enough info for Emacs to be able to work it out itself.) So far, so good. In the popup, navigate to the wrong directory and click on OK without going through the process of finding the file entry and selecting it first. (You can't - you're in the wrong directory!) Does the patch below give a cleaner behavior (it should prevent you from selecting a directory in which the file doesn't exist). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Configure gripes about gnome-config
$ /usr/local/bin/pkg-config --exists foo sh: gnome-config: not found $ Systems without GNOME probably don't have gnome-config. Does it check for the presence of GNOME before it runs gnome-config? If so, this is not a bug--your setup is broken. If not, that seems like a bug. If the code that uses gnome-config comes from Autoconf, it is a bug in Autoconf. If that code comes from configure.in, the bug is in configure.in. Does your system have GNOME? Yes, the Solaris8 box has the GNOME 2.0 desktop, which appears to work. Note that configure checks for the existence of pkg-config (not gnome-config), which it finds. Configure does not run gnome-config, it runs pkg-config, which runs gnome-config (at least on my system - as you can see in the above shell snippet). So, to reiterate, configure finds pkg-config (in /usr/local/bin) and then uses it: if $PKG_CONFIG --exists $ALSA_MODULES ; then It is at this point that we get the error wrt gnome-config. My comment was perhaps the definition of PKG_CHECK_MODULES in configure.in could be modified, ie: if $PKG_CONFIG --exists $2 ; then Changed to redirect stderr from $PKG_CONFIG to /dev/null. But it might be that the correct fix is not to use pkg-config, or to use it in a different way. I don't know. Simon. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Lingering input pending with motif menu bar
I can reproduce this with --with-x-toolkit=MOTIF, but not LUCID. Note that
Motif is provided by Solaris. I don't have GNU/Lesstif (sp?) to try it
with. Fingers crossed that this is also the cause of some other oddities
I've seen with the menu bar that I've not been able to document enough to
report...
src/emacs -Q
Options Enter Debugger on Quit/C-g
Tools Games Towers of Hanoi
I get split windows, with the top of the *Hanoi* buffer in the upper window
and the *Backtrace* buffer in the lower window, containing:
Debugger entered--Lisp error: (quit I can tell you've had enough)
signal(quit (I can tell you've had enough))
hanoi-sit-for(0)
hanoi-n(nil nil (217 . 61) (503 . 113) (477 . 87) 1151672642.537304)
hanoi-n((0) ((217 . 3)) (217 . 61) (477 . 87) (503 . 113)
1151672642.537304)
hanoi-n((0 0) ((295 . 5) (217 . 3)) (217 . 61) (503 . 113) (477 . 87)
1151672642.537304)
hanoi-n((0 0 0) ((373 . 7) (295 . 5) (217 . 3)) (217 . 61) (477 . 87) (503
. 113) 1151672642.537304)
hanoi-internal(3 (0 0 0) 1151672642.537304)
hanoi(3)
call-interactively(hanoi)
Tools Games Life also stops immediately, though Snake and Tetris do not.
M-x hanoi and M-x life work normally.
Debugging it, I see:
(dbx) where
=[1] readable_events(flags = 3), line 3551 in keyboard.c
[2] get_input_pending(addr = 0x4bfd20, flags = 3), line 6599 in
keyboard.c
[3] Finput_pending_p(), line 10006 in keyboard.c
...
Which is the return at this statement:
if (!(
#ifdef USE_TOOLKIT_SCROLL_BARS
(flags READABLE_EVENTS_FILTER_EVENTS)
#endif
event-kind == FOCUS_IN_EVENT)
#ifdef USE_TOOLKIT_SCROLL_BARS
!((flags READABLE_EVENTS_IGNORE_SQUEEZABLES)
event-kind == SCROLL_BAR_CLICK_EVENT
event-part == scroll_bar_handle
event-modifiers == 0)
#endif
)
return 1;
Which it hits the first time through the outer do-while loop. The event is:
(dbx) print *event
*event = {
kind= HELP_EVENT
code= 0
part= scroll_bar_move_ratio
modifiers = 1
x = 541935616
y = 541935616
timestamp = 4280257056U
padding = (0x200030, 0x1)
frame_or_window = -2138585600
arg = 541935616
}
I'm not sure what a HELP_EVENT is, but it doesn't look right. How can I
help?
In GNU Emacs 22.0.50.3 (sparc-sun-solaris2.8, Motif Version 2.1.0)
of 2006-06-26 on perth
X server distributor `Hummingbird Ltd.', version 11.0.100015
configured using `configure
'--prefix=/rvcarma/marshals/software/slash/usr/local'
'--with-x-toolkit=motif' 'CFLAGS=-g''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: en_GB.ISO8859-1
value of $LC_CTYPE: en_GB.ISO8859-1
value of $LC_MESSAGES: C
value of $LC_MONETARY: en_GB.ISO8859-1
value of $LC_NUMERIC: en_GB.ISO8859-1
value of $LC_TIME: en_GB.ISO8859-1
value of $LANG: en_GB.ISO8859-1
locale-coding-system: iso-8859-1
default-enable-multibyte-characters: t
Major mode: Emacs-Lisp
Minor modes in effect:
tooltip-mode: t
tool-bar-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
unify-8859-on-encoding-mode: t
utf-translate-cjk-mode: t
auto-compression-mode: t
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Configure gripes about gnome-config
I forgot to raise this earlier, but reconfiguring reminds me. $ ./configure checking build system type... sparc-sun-solaris2.8 checking host system type... sparc-sun-solaris2.8 checking for gcc... no checking for cc... cc ... checking for alsa = 1.0.0... sh: gnome-config: not found no sh: gnome-config: not found At least, configure could hide the absense of this script. Simon. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Compile-goto-error can signal wrong-type-argument
This is a buggette in CVS head as of 2006-06-19. src/emacs -Q Start a compilation which is going to raise some errors. Then mouse-1 on an error to get the popup window Find this error in (default ...) for you to navigate to the file. (The error message doesn't contain enough info for Emacs to be able to work it out itself.) So far, so good. In the popup, navigate to the wrong directory and click on OK without going through the process of finding the file entry and selecting it first. (You can't - you're in the wrong directory!) I get: Debugger entered--Lisp error: (wrong-type-argument stringp nil) set-buffer(nil) (save-current-buffer (set-buffer (compilation-find-file marker ... ...)) (save-restriction (widen) (goto-char ...) (dolist ... ... ...))) (with-current-buffer (compilation-find-file marker (caar ...) (cadr ...)) (save-restriction (widen) (goto-char ...) (dolist ... ... ...))) (if (and (nth 3 loc) (marker-buffer ...)) nil (with-current-buffer (compilation-find-file marker ... ...) (save-restriction ... ... ...))) (unless (and (nth 3 loc) (marker-buffer ...)) (with-current-buffer (compilation-find-file marker ... ...) (save-restriction ... ... ...))) (let* ((columns compilation-error-screen-columns) (last 1) (loc ...) (end-loc ...) (marker ...)) (setq compilation-current-error (point-marker) overlay-arrow-position (if ... compilation-current-error ...) loc (car loc)) (unless (and ... ...) (with-current-buffer ... ...)) (compilation-goto-locus marker (nth 3 loc) (nth 3 end-loc)) (setcdr (nthcdr 3 loc) t)) compilation-next-error-function(0 nil) next-error-internal() compile-goto-error((mouse-2 (#window 16 on *compilation* 26077 (81 . 111) 85721490 nil 26077 (11 . 8) nil (4 . 7) (7 . 13 call-interactively(compile-goto-error) At the very least, Emacs should raise a more descriptive error. Simon. In GNU Emacs 22.0.50.1 (sparc-sun-solaris2.8, X toolkit) of 2006-06-19 on perth X server distributor `Hummingbird Ltd.', version 11.0.100015 configured using `configure '--with-x-toolkit=lucid' 'CFLAGS=-g'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: en_GB.ISO8859-1 value of $LC_CTYPE: en_GB.ISO8859-1 value of $LC_MESSAGES: C value of $LC_MONETARY: en_GB.ISO8859-1 value of $LC_NUMERIC: en_GB.ISO8859-1 value of $LC_TIME: en_GB.ISO8859-1 value of $LANG: en_GB.ISO8859-1 locale-coding-system: iso-8859-1 default-enable-multibyte-characters: t Major mode: C++/l Minor modes in effect: tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t abbrev-mode: t ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Font-lock misfontifies foo::bar in C++
src/emacs -Q foo.cpp
In the foo.cpp buffer, insert the text:
void foo::bar() // wrong - foo in font-lock-constant-face (otherwise ok)
{
foo ;// ok - no fontification
foo:// ok - foo in font-lock-constant-face (also used
for labels)
foo:: ;// ok - foo not fontified (but maybe could be as a type)
foo::bar // wrong - foo in font-lock-constant-face
The text foo in foo::bar is fontified in font-lock-constant-face, rather
than font-lock-type-face. In C++, at least, anything before a :: is a
namespace or class name. Note that mis-fontification happens when the b
of bar is typed.
Sorry, no fix. Cc-fonts.el is too scary for my diminishing elisp skills -
and I'm wary of breaking something else anyway.
Simon.
In GNU Emacs 22.0.50.1 (sparc-sun-solaris2.8, X toolkit)
of 2006-06-19 on perth
X server distributor `Hummingbird Ltd.', version 11.0.100015
configured using `configure '--with-x-toolkit=lucid' 'CFLAGS=-g''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: en_GB.ISO8859-1
value of $LC_CTYPE: en_GB.ISO8859-1
value of $LC_MESSAGES: C
value of $LC_MONETARY: en_GB.ISO8859-1
value of $LC_NUMERIC: en_GB.ISO8859-1
value of $LC_TIME: en_GB.ISO8859-1
value of $LANG: en_GB.ISO8859-1
locale-coding-system: iso-8859-1
default-enable-multibyte-characters: t
Major mode: C++/l
Minor modes in effect:
tooltip-mode: t
tool-bar-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
unify-8859-on-encoding-mode: t
utf-translate-cjk-mode: t
auto-compression-mode: t
line-number-mode: t
abbrev-mode: t
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
mouse-autoselect-window needs a delay
Title: mouse-autoselect-window needs a delay This isn't a bug as such, but a suggestion for feature refinement. I like the concept of mouse-autoselect-window, since it allows me to attempt to mimic my WM's focus-follows-mouse frame policy for Emacs windows. But there's always a but. If you have a split window but the invocation of a command forces you to move the mouse across a different window, you will probably end up applying the command to the wrong window. For example, suppose a frame shows 2 different windows, each containing a different C buffer. Suppose you want to comment out a region in the buffer in the lower window. You select the region, move the mouse up to the menu bar, select C Comment Out Region, and watch in frustration as the operation is performed on the buffer in the upper window. The focus had changed as you moved to the menu bar. WMs that support focus-follows-mouse together with raise-on-focus have a similar issue. (Focus-follows-mouse is probably best with raise-on-focus.) They typically deal with that issue by (a) having a delay, (b) requiring the mouse to be stationary, or (c) both, before transferring focus and raising. That way, focus is less likely to be transferred when the user does not wish it. My current WM implements (a) with something like a 0.5s delay. So, I'm suggesting that (a) and/or (b) be implemented for mouse-autoselect-window. Perhaps the variable could have a numeric value, meaning a delay. A value of t might be equivalent to a value of 0. A mouse-[123] in a window would still immediately change focus. Comments? Simon. In GNU Emacs 22.0.50.1 (sparc-sun-solaris2.8, Motif Version 2.1.0) of 2006-06-15 on perth X server distributor `Hummingbird Ltd.', version 11.0.100015 configured using `configure '--prefix=/rvcarma/marshals/software/slash/usr/local' '--with-x-toolkit=motif' 'CFLAGS=-g'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: en_GB.ISO8859-1 value of $LC_CTYPE: en_GB.ISO8859-1 value of $LC_MESSAGES: C value of $LC_MONETARY: en_GB.ISO8859-1 value of $LC_NUMERIC: en_GB.ISO8859-1 value of $LC_TIME: en_GB.ISO8859-1 value of $LANG: en_GB.ISO8859-1 locale-coding-system: iso-8859-1 default-enable-multibyte-characters: t ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Has anyone used Purify with Emacs?
Ah, I didn't spot that, I was looking for purify. Note that Rational's Purify is not limited to memory allocated by the program calling malloc, so the entry Running Emacs built with malloc debugging packages is a little misleading. If you're not prepared to mention non-free 3rd party products to make life easier for Emacs testers, perhaps ... memory usage debugging packages would be better. I took the etc/DEBUG hints and sort-of managed to build a sort-of runnable emacs. I think the building difficulty is down to the new (?) bootstrapping build environment. In the end, I had to configure emacs without using purify; make make install; then reconfigure and build with purify. The purifyed emacs eventually hung on this step: % emacs -batch -f batch-byte-compile XXX.el EMACSLOADPATH=/rvcarma/marshals/software/purify/leim/../lisp LC_ALL=C ../src/emacs -batch --no-init-file --no-site-file --multibyte -l /rvcarma/marshals/software/purify/leim/../lisp/international/titdic-cnv \ -f batch-miscdic-convert -dir quail /rvcarma/marshals/software/purify/leim/MISC-DIC; \ echo changed changed.misc when loading vc-cvs. I interrupted at this point and found that the temacs/emacs was runnable. However, purify reports so many UMRs that it is useless, and the emacs is too slow to be usable. Apologies for the vagueness here - I'll rebuild from scratch if you really think it is worthwhile documenting for etc/DEBUG. Simon. -Original Message- From: Eli Zaretskii [mailto:[EMAIL PROTECTED] Sent: 17 June 2006 20:21 To: Marshall, Simon Cc: emacs-pretest-bug@gnu.org Subject: Re: Has anyone used Purify with Emacs? From: Marshall, Simon [EMAIL PROTECTED] Date: Fri, 16 Jun 2006 09:34:08 +0100 Unfortunately, the resulting dumped emacs SEGVs on startup in: (dbx) run -Q Running: emacs -Q (process id 6750) signal SEGV (no mapping at the fault address) in _p938static at 0xae5ec 0x000ae5ec: _p938static+0x0030: ld [%l0], %o0 So, has anyone got emacs built with Purify? Did you try reading the related section of etc/DEBUG? (To avoid praising proprietary packages, it doesn't mention Purify; the section's name is Running Emacs built with malloc debugging packages.) If your experience suggests that something in that section needs updating, by all means please tell how to change the text. This message has been scanned for viruses by MailControl - www.mailcontrol.com ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Has anyone used Purify with Emacs?
Thanks for the work on 22.1 guys. This isn't a bug report, yet, it's a question. I figured I'd try emacs from CVS (I don't know of any official pretest releases), and I figured I'd use Rational's Purify tool (not to be confused with Emacs notion of purify as being part of the dumping process) to build Emacs to see if the tool reported any memory corruptions, leaks, etc. I can build temacs with purify; the running temacs reports a huge number of UMRs (uninitialised memory read) within set_internal() at the line: if (BUFFER_LOCAL_VALUEP (valcontents) = || SOME_BUFFER_LOCAL_VALUEP (valcontents)) and also Fbyte_code() at the line: if (SYMBOLP (sym) !EQ (val, Qunbound) !XSYMBOL (sym)-indirect_variable !XSYMBOL (sym)-constant = !MISCP (XSYMBOL (sym)-value)) amongst others. I don't know if these are valid or Purify is being duped by some Emacs memory trickery. Unfortunately, the resulting dumped emacs SEGVs on startup in: (dbx) run -Q Running: emacs -Q (process id 6750) signal SEGV (no mapping at the fault address) in _p938static at 0xae5ec 0x000ae5ec: _p938static+0x0030: ld [%l0], %o0 So, has anyone got emacs built with Purify? In GNU Emacs 22.0.50.1 (sparc-sun-solaris2.8, Motif Version 2.1.0) of 2006-06-14 on perth X server distributor `Hummingbird Ltd.', version 11.0.100015 configured using `configure '--prefix=/rvcarma/marshals/software/slash/usr/local' '--x-includes=/rvcarma/marshals/lesstif-0.93.36/usr/local/include:/rvcarma/m arshals/slash/usr/local/include/X11:/usr/openwin/include' '--x-libraries=/rvcarma/marshals/lesstif-0.93.36/usr/local/lib:/rvcarma/mars hals/slash/usr/local/lib/X11:/usr/openwin/lib' '--with-x-toolkit=motif'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: en_GB.ISO8859-1 value of $LC_CTYPE: en_GB.ISO8859-1 value of $LC_MESSAGES: C value of $LC_MONETARY: en_GB.ISO8859-1 value of $LC_NUMERIC: en_GB.ISO8859-1 value of $LC_TIME: en_GB.ISO8859-1 value of $LANG: en_GB.ISO8859-1 locale-coding-system: iso-8859-1 default-enable-multibyte-characters: t Major mode: Text Minor modes in effect: delete-selection-mode: t mouse-sel-mode: t msb-mode: t partial-completion-mode: t show-paren-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Detached minibuffer cropped text
Start emacs like this: xrdb -load ^D emacs -Q --eval '(setq minibuffer-frame-alist (quote ((width . 80) (height . 1))) initial-frame-alist (quote ((minibuffer' The detached minibuffer has insufficient space to display text. There isn't room to display the lower few pixels of minibuffer text. In GNU Emacs 22.0.50.1 (sparc-sun-solaris2.8, Motif Version 2.1.0) of 2006-06-15 on perth X server distributor `Hummingbird Ltd.', version 11.0.100015 configured using `configure '--prefix=/rvcarma/marshals/software/slash/usr/local' '--with-x-toolkit=motif' 'CFLAGS=-g'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: en_GB.ISO8859-1 value of $LC_CTYPE: en_GB.ISO8859-1 value of $LC_MESSAGES: C value of $LC_MONETARY: en_GB.ISO8859-1 value of $LC_NUMERIC: en_GB.ISO8859-1 value of $LC_TIME: en_GB.ISO8859-1 value of $LANG: en_GB.ISO8859-1 locale-coding-system: iso-8859-1 default-enable-multibyte-characters: t Major mode: Emacs-Lisp Minor modes in effect: delete-selection-mode: t mouse-sel-mode: t msb-mode: t partial-completion-mode: t show-paren-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent input: down-mouse-3 mouse-3 drag-mouse-1 down-mouse-1 mouse-1 double-down-mouse-1 down-mouse-3 mouse-3 mouse-1 select-window help-echo select-window down-mouse-1 mouse-1 double-down-mouse-1 double-mouse-1 triple-down-mouse-1 triple-mouse-1 down-mouse-1 mouse-1 down-mouse-1 mouse-1 ; ; SPC backspace ; SPC s p a c e down down return return down-mouse-1 mouse-1 backspace down-mouse-1 mouse-1 backspace down-mouse-1 mouse-1 backspace backspace down-mouse-1 mouse-1 double-down-mouse-1 mouse-movement mouse-movement double-drag-mouse-1 down-mouse-1 mouse-1 double-down-mouse-1 double-mouse-1 8 0 down-mouse-1 mouse-1 double-down-mouse-1 double-mouse-1 1 down-mouse-1 mouse-1 double-down-mouse-1 double-mouse-1 triple-down-mouse-1 triple-mouse-1 down-mouse-1 mouse-1 escape SPC select-window help-echo C-x 5 2 switch-frame drag-n-drop help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo menu-bar help-menu report-emacs-bug Recent messages: Loading advice...done Loading paren...done Loading complete...done Loading msb...done Loading mouse-sel...done Loading delsel...done Loading lazy-lock...done Quit Mark set [3 times] Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
vc-diff uses unknown -L switch
I forgot to say previously - thanks for the work on 22.1 guys. Anyway, the bug with emacs from CVS trunk (is this correct for 22.1???) updated 2006-06-15. On Solaris 8 with a file under CVS, if I do C-x v = I get: /usr/bin/diff: illegal option -- L usage: diff [-bitw] [-c | -e | -f | -h | -n] file1 file2 diff [-bitw] [-C number] file1 file2 diff [-bitw] [-D string] file1 file2 diff [-bitw] [-c | -e | -f | -h | -n] [-l] [-r] [-s] [-S name] directory1 directory2 It seems vc-diff-internal is using -L flags for diff. Labels don't seem to be supported by Solaris 8 diff. In GNU Emacs 22.0.50.1 (sparc-sun-solaris2.8, Motif Version 2.1.0) of 2006-06-15 on perth X server distributor `Hummingbird Ltd.', version 11.0.100015 configured using `configure '--prefix=/rvcarma/marshals/software/slash/usr/local' '--with-x-toolkit=motif' 'CFLAGS=-g'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: en_GB.ISO8859-1 value of $LC_CTYPE: en_GB.ISO8859-1 value of $LC_MESSAGES: C value of $LC_MONETARY: en_GB.ISO8859-1 value of $LC_NUMERIC: en_GB.ISO8859-1 value of $LC_TIME: en_GB.ISO8859-1 value of $LANG: en_GB.ISO8859-1 locale-coding-system: iso-8859-1 default-enable-multibyte-characters: t Major mode: Emacs-Lisp Minor modes in effect: delete-selection-mode: t mouse-sel-mode: t msb-mode: t partial-completion-mode: t show-paren-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent input: 5 f ~ / s l tab u s r tab l o c tab s h tab e m tab l i s tab backspace backspace backspace e m tab backspace backspace tab switch-frame drag-n-drop switch-frame 2 1 . 3 / l i s tab v c . e l tab return drag-n-drop switch-frame select-window help-echo switch-frame switch-frame select-window switch-frame switch-frame switch-frame select-window menu-bar index From: vc-default-diff-tree vc-diff-internal mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 mouse-1 switch-frame down-mouse-1 mouse-movement mouse-1 double-down-mouse-1 double-mouse-1 escape w switch-frame help-echo help-echo help-echo help-echo menu-bar help-menu report-emacs-bug Recent messages: Loading vc...done Running cvs in the background... Loading log-view... Loading easy-mmode...done Loading log-view...done Running cvs in the background... done (-c) Mark saved where search started Mark set Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
C-down-mouse-1 and msb.el
With earlier emacs releases, with emacs -q and C-down-mouse-1 would immediately popup a buffer menu. With M-x msb-mode and C-down-mouse-1, you would immediately get the msb buffer menu. Now, with CVS 2006-06-15 emacs -Q and M-x msb-mode, C-down-mouse-1 does not popup a menu until mouse-1 is released, and then beeps with a Quit if you do not choose an item from the menu. (The only way to get rid of the msb menu is to click outside it. If you turn on debug-on-quit, then you will see a Entering debugger... message although you will not enter the debugger.) I think there are 2 bugs: (a) the msb menu should popup immediately; (b) the msb menu should not behave as if a quit has occurred when getting rid of the menu. It looks like this change has caused (a): 2006-05-02 Chong Yidong [EMAIL PROTECTED] * msb.el (msb): If EVENT is a down event, read and discard the up event. === RCS file: /sources/emacs/emacs/lisp/msb.el,v retrieving revision 1.53 retrieving revision 1.54 diff -c -r1.53 -r1.54 *** msb.el 6 Feb 2006 14:33:34 - 1.53 --- msb.el 2 May 2006 19:27:09 - 1.54 *** *** 473,478 --- 473,483 See the function `mouse-select-buffer' and the variable `msb-menu-cond' for more information about how the menus are split. (interactive e) + ;; If EVENT is a down-event, read and discard the + ;; corresponding up-event. + (and (eventp event) +(memq 'down (event-modifiers event)) +(read-event)) (let ((old-window (selected-window)) (window (posn-window (event-start event (unless (framep window) (select-window window)) Commenting out that change restores the old behaviour of immediately popping up the menu, but presumably that change was made to fix something else. It doesn't completely restore the old behaviour though; bug (b) is still there. In GNU Emacs 22.0.50.1 (sparc-sun-solaris2.8, Motif Version 2.1.0) of 2006-06-15 on perth X server distributor `Hummingbird Ltd.', version 11.0.100015 configured using `configure '--prefix=/rvcarma/marshals/software/slash/usr/local' '--with-x-toolkit=motif' 'CFLAGS=-g'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: en_GB.ISO8859-1 value of $LC_CTYPE: en_GB.ISO8859-1 value of $LC_MESSAGES: C value of $LC_MONETARY: en_GB.ISO8859-1 value of $LC_NUMERIC: en_GB.ISO8859-1 value of $LC_TIME: en_GB.ISO8859-1 value of $LANG: en_GB.ISO8859-1 locale-coding-system: iso-8859-1 default-enable-multibyte-characters: t Major mode: Emacs-Lisp Minor modes in effect: delete-selection-mode: t mouse-sel-mode: t msb-mode: t partial-completion-mode: t show-paren-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
