Error in menu-bar-update-hook: (error Point before start of prope rties)

2006-07-19 Thread Marshall, Simon
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

Font Lock on-the-fly misfontification in C++

2006-07-19 Thread Marshall, Simon
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, //

RE: Same frame-positioning bug as before: negative top/left values on Windows

2006-07-19 Thread Drew Adams
Hi Fran, I took a quick look. It's different from before, but wrong, IMO. In fact, it's worse. I don't know if the difference is due to your fix or not. Frames are now too far to the right, when I expect them to be flush with the left edge of the display, and too far below the top edge of the

Re: sh-mode font-lock error

2006-07-19 Thread Glenn Morris
Stefan Monnier wrote: I believe the patch below (just installed) fixes it, Sorry, but the patch has no effect on this case AFAICS. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Same frame-positioning bug as before: negative top/left values on Windows

2006-07-19 Thread Ralf Angeli
* Drew Adams (2006-07-19) writes: This problem occurs even for emacs -Q: the initial frame is about 5cm from the left edge and about 6cm from the top edge of the display. Before, it was flush with both top and left display edges. Frame positioning is now left to Windows unless you specified