C++ unclosed namespace detection whishlist

[Steven T. Hatton]

Symptoms:

I've heard tell that vim will give a warning in the form lf changing
the buffer color when a namespace is opened, but not closed in C++
mode.  I've been stung a couple of times by missing the closing '}' at
the end of a file in which a namespace is opened.  It is one of the
least obvious mistakes to make when editing C++ code in Emacs.  Even
worse than forgetting the ';' at the end of a class definition.  I'm
wondering if Emacs C++ mode could provide a more obtrusive indication
that a namespace has been left open in a file.


In GNU Emacs 22.0.50.2 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2005-06-08 on ljosalfr
Distributor `The X.Org Foundation', version 11.0.60802000
configured using `configure '--prefix=/home/hattons/opt/org/gnu/emacs-cvs''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: POSIX
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8
  default-enable-multibyte-characters: t

Major mode: C++

Minor modes in effect:
  delete-selection-mode: t
  pc-selection-mode: t
  show-paren-mode: t
  senator-minor-mode: t
  which-function-mode: t
  semantic-idle-summary-mode: t
  semantic-idle-scheduler-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  tooltip-mode: t
  auto-compression-mode: t
  menu-bar-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
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  next-error-follow-minor-mode:  Fol
  abbrev-mode: t

Recent input:
C-x C-f  

   

  S T H _ P R O J E C T _   
  
  
n a m e M-/ SPC p r 
o j e c t SPC {  } M-x r e p o r t SPC e m 
 

Recent messages:
Loading eldoc...done
Loading jit-lock...done
For information about the GNU Project and its goals, type C-h C-p.
Loading cc-mode...done
Loading semantic-c...done
Loading autoinsert...done
Loading semantic-edit...done
Mark set [6 times]
Loading dabbrev...done
Loading emacsbug...done


___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: DOC select-frame: argument doc. missing

[Luc Teirlinck]

Richard Stallman wrote:

   Indeed, the value of that argument seems to be unused.
   So I guess it is a relic of something.

   If you look at the change logs, you could probably tell what happened.

It appears that at one time in the past, the argument _was_ used.  I
believe that one could pass t for no_enter to prevent the newly
selected frame from getting the focus.

Sincerely,

Luc.


___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: debugger with pop-up-frames non-nil: keeps creating new frames

[Stefan Monnier]

> I'm saying that in the case of `q' or `c', I don't want the keep
> displaying the frame, instead I want it iconified.

> In the case of `c', I definitely want to keep displaying the debugger. Why
> would you want it to disappear? Using `c' doesn't mean you're done with the
> debugger. I can always use `q' when I'm done with the debugger.

`q' doesn't just leave the debugger, it also aborts the current execution,
whereas `c' continues it (without necessarily setting things up to re-enter
the debugger in the future).

> Because `q' and `c' both really leave the debugger so you don't want
> to keep an empty *Backtrace* buffer/window/frame staring at you.

> `c' does not leave the debugger at all. It simply completes evaluation of a
> sexp.

That depends on the circumstance.  See below.

> Again, quitting the debugger should delete the buffer, window and frame (if
> one-window-p) - iconifying serves no purpose. What is wrong with deleting
> the buffer/window/frame?

What's unclear about "losing the size&position info"?

> And `d' and`c' should not be considered to "leave" the debugger at all - the
> debugger buffer/window/frame should continue to be displayed.

With the current code, `d' indeed keeps the backtrace buffer displayed.

> I don't understand this. I use `d' and `c' all the time. I use `c' when I
> don't want to drill down into the eval of a sexp; I just want to see its
> result. But that still leaves me in the middle of a trace, and I continue
> with `d' or `c' to evaluate the next sexp (or I quit with `q', if I'm done).

I think I'm beginning to understand a bit more what you're complaining
about.  IIUC you use debug-on-error extensively, whereas I use edebug for
those situations.  I mostly only use the `debug' debugger via
debug-on-error, debug-on-signal, debug-on-quit, or an explicit call to
(debug).

> Of course, if the sexp to be eval'd with `c' is the only one, then
> evaluation is finished, and you end up with an empty buffer.  That is the
> only case when it would be OK to remove the buffer/window/frame after `c'
> is finished.

Indeed, except it's not easy to distinguish the different cases.  I'll send
a patch later.

> so the last patch I sent you tries to hide it, but it is the reason
> why I consider `d' to "leave" the debugger.

> OK. Is that how it worked previously also? `d' caused function `debug' to
> return (exit) at each step?

Yes, it's always worked this way.

>> You're still in the debugger; why delete and re-create the window?

Probably for simple implementation reasons.  And maybe also so that the
code itself is run in an environment unaffected by the debugger.
I.e. without the extra window.


Stefan


___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Wrong display and hang with zero-length overlay display string

[Ralf Angeli]

On MS Windows the following code will generate a buffer which displays
"aaa" and after that a lot of whitespace.  If you scroll around a bit
Emacs will hang with 100% CPU usage.  Typing `C-g' does not help.

(progn
  (pop-to-buffer (get-buffer-create "*test*"))
  (insert "aaa\nbbb\nccc\n")
  (let ((ov (make-overlay 5 8)))
(overlay-put ov 'display "")))

On X11 the code works correctly and displays

aaa

ccc

-- 
Ralf



___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

No borders around images under cursor

[Juri Linkov]

When the cursor type is `bar', putting the cursor over an image has
no visual indication.  This can be considered a bug when moving the
cursor in the Face Customization buffer over rows of face attributes
vertically on the column with checkbox images has no visual feedback
on cursor motion at all.
 
This behavior is observable only with small font sizes.  With bigger
font sizes there is a visible border line only on the top of the image.
With very big fonts there is a thick line above the image and a thin
line at the bottom.

So perhaps when the cursor type is `bar', the image should have
a border only on the left, by analogy with the cursor on characters:
the cursor type `box' inverts the colors on the whole character,
while `bar' displays a bar on the left of the character.

There are also differences in cursor display on transparent images.
`box' displays all borders around the transparent image, but `bar'
fills the transparent parts with the cursor colors.  Perhaps it should
display a border on the left.

BTW, there is a function `set-cursor-color' in frames.el, but its
counterpart function `set-cursor-type' is missing.  The following
patch fills this omission:

Index: lisp/frame.el
===
RCS file: /cvsroot/emacs/emacs/lisp/frame.el,v
retrieving revision 1.221
diff -u -r1.221 frame.el
--- lisp/frame.el   19 May 2005 15:40:37 -  1.221
+++ lisp/frame.el   8 Jun 2005 22:14:34 -
@@ -908,6 +908,16 @@
   (modify-frame-parameters (selected-frame)
   (list (cons 'cursor-color color-name
 
+(defun set-cursor-type (cursor-type)
+  "Set the text cursor type of the selected frame to CURSOR-TYPE.
+When called interactively, prompt for the name of the type to use.
+To get the frame's current cursor type, use `frame-parameters'."
+  (interactive (list (intern (completing-read "Cursor type: "
+ '("box" "hollow" "bar" "hbar")
+ nil t
+  (modify-frame-parameters (selected-frame)
+  (list (cons 'cursor-type cursor-type
+
 (defun set-mouse-color (color-name)
   "Set the color of the mouse pointer of the selected frame to COLOR-NAME.
 When called interactively, prompt for the name of the color to use.

-- 
Juri Linkov
http://www.jurta.org/emacs/



___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: DOC select-frame: argument doc. missing

[Luc Teirlinck]

Richard Stallman wrote:

   Indeed, the value of that argument seems to be unused.
   So I guess it is a relic of something.

   If you look at the change logs, you could probably tell what happened.

The only mention in the changelogs is from 1990:

1990-03-08  Joseph Arceneaux  ([EMAIL PROTECTED])

* xterm.c (x_focus_screen): no longer static.
(x_error_handler):  Use XDefaultIOError.

* screen.c (Ffocus_screen):  New subr, removed Fscreen_has_focus.
(Fselect_screen):  New, optional parameter no_enter.
(Frestore_screen_configuration):
(Fdelete_screen):  Pass second parm Qnil to Fselect_screen.

* window.c (Fdisplay_buffer, Fset_window_configuration):  Pass
second parm Qnil to Fselect_screen.

screen.c is apparently not even in the Attic any more.

Sincerely,

Luc.


___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

RE: debugger with pop-up-frames non-nil: keeps creating new frames

[Drew Adams]

> No; it does not deiconify.

Oh, I think I know what it is: that's because of Richard's new
code which
uses just `select-window' instead of `pop-to-buffer' and thus fails to
de-iconify.

Good. Sounds like progress.

> If it did, I would consider that too to be a bug - why would
one want the
> debugger frame to first be iconified and then be deiconified
each time you
> issue a debugger command?

Yes, it'd also be a bug.  But it'd be fixed by the last patch I sent.

>> I don't understand:
>> - Why bury-buffer iconifies.
> Because of the case where you hit `q' or `c' or ...
rather than `d'.
> I don't understand what you are saying here.

I'm saying that in the case of `q' or `c', I don't want the
keep displaying
the frame, instead I want it iconified.

In the case of `c', I definitely want to keep displaying the debugger. Why
would you want it to disappear? Using `c' doesn't mean you're done with the
debugger. I can always use `q' when I'm done with the debugger.

In the case of `q', I've quit the debugger. I don't want to iconify the
(empty) debugger buffer (frame) - I want to delete it altogether. Why would
you want an iconified empty debugger frame?

> It iconifies with every command, including `d'. But, aside
from `d', why
> should it iconify with `q' or `c'?

Because `q' and `c' both really leave the debugger so you don't
want to keep
an empty *Backtrace* buffer/window/frame staring at you.

`c' does not leave the debugger at all. It simply completes evaluation of a
sexp.

`q' leaves the debugger. It should leave it completely. Not only do I not
want an empty *Backtrace* buffer/window/frame staring at me; I also do not
want an iconified empty *Backtrace* frame hanging around. It's even harder
to get rid of interactively than a raised frame.

> If you hit `q', perhaps iconifying is OK. However, I think
quit-window or
> killing the buffer and deleting the window (and frame) would
be better than
> iconifying the frame.

Have you read the patches I sent and the corresponding code?
It includes
a comment explaining why.

Yes, I've read them.

Again, quitting the debugger should delete the buffer, window and frame (if
one-window-p) - iconifying serves no purpose. What is wrong with deleting
the buffer/window/frame?

And `d' and`c' should not be considered to "leave" the debugger at all - the
debugger buffer/window/frame should continue to be displayed.

> Even if iconifying were OK for `q', why do that when you hit
`c'? You are
> still using the debugger window/buffer/frame, no?

Sometimes, but usually no.  Or at least I won't get back into
the debugger immediately (contrary to `d').

I don't understand this. I use `d' and `c' all the time. I use `c' when I
don't want to drill down into the eval of a sexp; I just want to see its
result. But that still leaves me in the middle of a trace, and I continue
with `d' or `c' to evaluate the next sexp (or I quit with `q', if I'm done).

Of course, if the sexp to be eval'd with `c' is the only one, then
evaluation is finished, and you end up with an empty buffer. That is the
only case when it would be OK to remove the buffer/window/frame after `c' is
finished. If you want to remove it when the buffer is empty, that would be
OK. That would take care of both `q' and `c' - there is no reason for the
buffer to exist if it is empty, so emptiness should be a necessary &
sufficient test to trigger its deletion.

In Emacs 20 the *Backtrace* frame doesn't disappear after even `q', but I
can always do `C-x 0' to delete the frame. (My version of `delete-window'
deletes the frame if one-window-p.) It's a *lot* less annoying to just do
`C-x 0' when I'm done with the debugger than it is to wrestle with flashing
or iconifying frames at each debugger step.

> Why would you want to bury or iconify the buffer with `c'? It should
> remain displayed, so you can use it.

You can't really use it any more: at that point it's empty (until you
re-enter the debugger).

I don't understand this at all. I don't see an empty buffer until I'm back
up tot the top level. After I use `c', the buffer shows the result of the
current evaluation, plus all of the trace steps still to be done, below it.

Here's what I see before and after `c' on the sexp buffer-live-p(nil) when
debugging describe-variable:

Before `c':

Debugger entered--entering a function:
* buffer-live-p(nil)
* byte-code("...")
* describe-variable(features)
  call-interactively(describe-variable)

After `c':

Debugger entered--returning value: nil
  buffer-live-p(nil)
* byte-code("...")
* describe-variable(features)
  call-interactively(describe-variable)

The buffer is not empty.

> Actually the code is used when we leave the debugger.
  It's just that
> when you use `d' you only leave the debugger temporarily.

> I don't see why you (or the 

Re: scan-lists sees comment delimiter inside string

[Stefan Monnier]

> With parse-sexp-ignore-comments t and point in between "( in

> (setq foo "(;)")

> forward-sexp gets me

> forward-sexp: Scan error: "Unbalanced parentheses".

> Obviously, this is because scan-lists finds the semicolon and does not
> check whether it's inside a string.  Could someone please add the
> necessary conjunct?

It's not as trivial a change as it may seem since figuring out whether we're
inside a string (or comment for that matter) or not often requires "parsing"
the buffer from the beginning and this parsing can fail if the syntax table
doesn't match 100% the language in use.

I do think it'd be good to do it and I suggest we beginning by introducing
new commands move-forward-sexp and move-backward-sexp (which are
"user-level" sexp movement commands) which could try to DTRT like you
suggest, while keeping the behavior of forward-sexp the way it is now.

If such a thing is done maybe forward-sexp-function should be used in
move-forward-sexp rather than in forward-sexp itself.

But then transpose-sexps should also be changed to use move-forward-sexp
since it should obey forward-sexp-function.

Patches are welcome, but I really hope they won't be part of the next
release, which is already about to enter its second year of so-called
"feature freeze".


Stefan


___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

PayPal - Webform update information

[PayPal.com]

Title: PayPal update






   



  


  






  
Dear 
PayPal member,
  


  
  

Due to recent activity, including possible 
unauthorised transactions placed on your account, we have temporarily 
suspended activity on your account in order to allow us to investigate 
this matter further. If you believe that this action may have been taken 
in error, or, if you feel that your account may have been tampered with, 
please respond to this message so that we can provide additional 
information and work with you to resolve this issue. 
After responding to the message, we ask 
that you allow at least 72 hours for the case to be investigated. 
Emailing us before that time will result in delays. We apologise in 
advance for any inconvenience this may cause you and we would like to 
thank you for your cooperation as we review this matter. 
 
If you are the rightful holder of the 
account you must click the link below and then complete all steps 
from the following page as we try to update your account billing 
records.
 

https://www.paypal.com/cgi-bin/webscr?cmd=_login-run
However, failure to update your records 
will result in account supension. Please update your records on or 
before:

   Buy from an online auction
   Pay on a merchant website
   Send money to anyone with an 
  email address

Sincerely,
Audrey
PayPal Resolution Services
PayPal, an eBay Company


   
Thank you for using PayPal


  
  
   

© 2005 Copyright 1999-2005 PayPal. All rights reserved

 

 
  










___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: debugger with pop-up-frames non-nil: keeps creating new frames

[Stefan Monnier]

>> If I do (setq special-display-regexps '("[ ]?[*][^*]+[*]")), then when I hit
>> `d' in the debugger, the debugger frame iconifies.

> Doesn't it de-iconify right after (thus flashing)?  That's very odd.

> No; it does not deiconify.

Oh, I think I know what it is: that's because of Richard's new code which
uses just `select-window' instead of `pop-to-buffer' and thus fails to
de-iconify.

> If it did, I would consider that too to be a bug - why would one want the
> debugger frame to first be iconified and then be deiconified each time you
> issue a debugger command?

Yes, it'd also be a bug.  But it'd be fixed by the last patch I sent.

>> I don't understand:
>> - Why bury-buffer iconifies.
> Because of the case where you hit `q' or `c' or ... rather than `d'.
> I don't understand what you are saying here.

I'm saying that in the case of `q' or `c', I don't want the keep displaying
the frame, instead I want it iconified.

> It iconifies with every command, including `d'. But, aside from `d', why
> should it iconify with `q' or `c'?

Because `q' and `c' both really leave the debugger so you don't want to keep
an empty *Backtrace* buffer/window/frame staring at you.

> If you hit `q', perhaps iconifying is OK. However, I think quit-window or
> killing the buffer and deleting the window (and frame) would be better than
> iconifying the frame.

Have you read the patches I sent and the corresponding code?  It includes
a comment explaining why.

> Even if iconifying were OK for `q', why do that when you hit `c'? You are
> still using the debugger window/buffer/frame, no?

Sometimes, but usually no.  Or at least I won't get back into the debugger
immediately (contrary to `d').

> Why would you want to bury or iconify the buffer with `c'? It should
> remain displayed, so you can use it.

You can't really use it any more: at that point it's empty (until you
re-enter the debugger).

> Actually the code is used when we leave the debugger.  It's just that
> when you use `d' you only leave the debugger temporarily.

> I don't see why you (or the code) would consider `d' to "leave" the
> debugger, even temporarily. In what sense is the user leaving it?

The debugger is entered by calling the function `debug' and is exited when
the `debug' function returns.  The code in question is executed at the end
of `debug' just before exiting.  I.e.  technically, `d' causes Emacs to
leave the debugger while setting up the evaluator to "immediately" re-enter
the debugger.

This is admittedly irrelevant to the user, so the last patch I sent you
tries to hide it, but it is the reason why I consider `d' to "leave"
the debugger.

> Even if one considers `d' to "leave" the debugger, that way of "leaving" it
> requires a completely different behavior from quitting it (`q)', IMO.

Agreed, thus my patch.

> If you look at what happens in a single-frame case, the code
> deletes/creates a window at each step.
> I don't see why it should do that either.

The why is not really relevant: it's what it does (by wrapping the body of
`debug' within a save-window-excursion).

> You're still in the debugger; why delete and re-create the window? Does
> that perhaps represent some kind of optimization? It's invisible to the
> user in this case, so I don't mind, but I don't understand why it should
> be done.

Yes, it's invisible as long as Emacs doesn't refresh the display between the
time when you hit `d' and the next function call which causes Emacs to
re-enter the debugger.  Sadly, contrary to what happens for window where
window creation/deletion is propagated to the display upon redisplay, frame
creation/deletion is effected immediately so the iconify/deiconify causes
flashing whereas the deletion&re-creation of the window is usually
not visible.

> I still don't see why any of the debugger commands should delete and
> recreate, or iconify and deiconify, or erase and redraw ... windows and
> frames. As long as you are in the debugger, it should remain displayed, IMO.
> When you quit, the debugger buffer and its window or frame (if one-window-p)
> should be deleted completely.

There's no way to know, when you quit, that you're quitting "for ever".
In practice, when I hit `q' it's quite frequent that I'll be getting back to
the debugger pretty soon.
Deleting the buffer+window+frame means losing the size&placement
information, which I find very annoying.


Stefan


___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

scan-lists sees comment delimiter inside string

[martin rudalics]

With parse-sexp-ignore-comments t and point in between "( in

(setq foo "(;)")

forward-sexp gets me

forward-sexp: Scan error: "Unbalanced parentheses".

Obviously, this is because scan-lists finds the semicolon and does not
check whether it's inside a string.  Could someone please add the
necessary conjunct?



___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

RE: debugger with pop-up-frames non-nil: keeps creating new frames

[Drew Adams]

> If I do (setq special-display-regexps '("[ ]?[*][^*]+[*]")),
then when I hit
> `d' in the debugger, the debugger frame iconifies.

Doesn't it de-iconify right after (thus flashing)?  That's very odd.

No; it does not deiconify.

If it did, I would consider that too to be a bug - why would one want the
debugger frame to first be iconified and then be deiconified each time you
issue a debugger command?

> That is, I use the same steps 1-6 as before, except this time
*Backtrace*
> is considered a special-display buffer: emacs -q, load the patched cvs
> debug.elc, set variables pop-up-frames and
display-buffer-reuse-frames to
> `t'.

Yes, the special-display buffer case is what I've been using
for years ;-)

Me too. But it doesn't work correctly now.

Do you use Windows? In my environment (Windows XP), it simply iconifies;
period. I then have to reach into the task bar and manually deiconify it,
just to continue. At the next step, it iconifies again, I manually deiconify
again... Very annoying.

> I also tried substituting `quit-window' for `bury-buffer' in
the code.  That
> solves the iconification problem, but the frame is
effectively erased and
> redrawn at each debugger `d', producing a flashing effect.

With bury-buffer I see the flashing.

Do you use Windows? If not, that might be the difference.

In any case, flashing is not good either. If it were, I would just hack the
code to use quit-window and be done with it.

> I don't understand:
>  - Why bury-buffer iconifies.

Because of the case where you hit `q' or `c' or ... rather than `d'.

I don't understand what you are saying here. It iconifies with every
command, including `d'. But, aside from `d', why should it iconify with `q'
or `c'?

If you hit `q', perhaps iconifying is OK. However, I think quit-window or
killing the buffer and deleting the window (and frame) would be better than
iconifying the frame. On Windows, when a frame is iconified, the user sees
it zip across the display into the task bar to become an icon. This is not
something you want to see when you quit the debugger. And the icon then
remains in the task bar - when you quit the debugger, you do not want the
debugger frame to continue to exist, whether raised or as an icon.

Even if iconifying were OK for `q', why do that when you hit `c'? You are
still using the debugger window/buffer/frame, no? Why would you want to bury
or iconify the buffer with `c'? It should remain displayed, so you can use
it.

>  - Why we would want to use bury-buffer here at all? Why not
leave it, since
> we are still in the debugger? What was wrong with the way it
worked before
> (say, in Emacs 20)?

Actually the code is used when we leave the debugger.  It's
just that when
you use `d' you only leave the debugger temporarily.

I don't see why you (or the code) would consider `d' to "leave" the
debugger, even temporarily. In what sense is the user leaving it? If any
debugger command means "do not leave; I'm still using the debugger" it's `d'
(digging deeper into a function call).

Even if one considers `d' to "leave" the debugger, that way of "leaving" it
requires a completely different behavior from quitting it (`q)', IMO.

If you look at what happens in a single-frame case, the code
deletes/creates a window at each step.

I don't see why it should do that either. You're still in the debugger; why
delete and re-create the window? Does that perhaps represent some kind of
optimization? It's invisible to the user in this case, so I don't mind, but
I don't understand why it should be done.

In the frame case, it produces flashing (when it doesn't iconify), which is
unacceptable.

Just like the iconify/deiconify flashing you see
with quit-window.

The two should not have similar behaviors in this respect. Deleting and
re-creating a window is not noticeable by the user. Iconifying, or erasing
and then redrawing, a frame is more than noticeable: it is annoying.

Can you try the additional patch below?

It now appears fixed for `d', but both `c' and `q' still iconify the buffer
(and leave it iconified, at least in Windows). With `q', you get a (useless,
no, bothersome) iconified buffer with nothing in it, since you have quit.

I still don't see why any of the debugger commands should delete and
recreate, or iconify and deiconify, or erase and redraw ... windows and
frames. As long as you are in the debugger, it should remain displayed, IMO.
When you quit, the debugger buffer and its window or frame (if one-window-p)
should be deleted completely.



___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

makefile-mode font-lock bugs and annoyances

[Glenn Morris]

Since it doesn't seem to be going away (despite this thread where
nobody liked it:
;
and several poeple asked for the changes to be reverted), here is a
list of problems with the latest makefile-mode.


Font-lock bugs:

1. In constructs such as:

ARCH   = $(shell uname -s)

"shell" is highlighted as a variable when it is not. Emacs-21.3 gets
this right.


2. Highlighting of conditional constructs is broken:

ifdef FOO
   blah
else
   blah blah
endif

i) FOO does not get highlighted as a variable. Emacs-21.3 gets this
right.
ii) ifdef / else / endif do not get highlighted as keywords.
Emacs-21.3 gets this right.


Annoyances. These are all IMO.

1. makefile-shell-face is incredibly ugly.

Eg in the following:

   cd $(bindir) ; \
   rm -f $(targets)

I see a spoldge of grey background extending from "cd" through to the
right-hand edge of the display on that line, and from column 0 in the
"rm" line to the end of the text. Yuck. Moreover, I don't think it
serves any useful purpose.


2. With something like:

clean :
  -rm -f *.mod *.o $(targets)

The "-" before "rm" gets highlighted in font-lock-type-face. This is
just silly.


3. $@ gets highlighted with makefile-targets-face. I'd prefer it to be
   treated as a variable, as it used to be, because... it's a
   variable.


4. Ditto for $^, which gets font-lock-constant-face at present.


___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

x-clipboard-yank doesn't decode utf-8 string

[Zhang Wei]

The following line has been put in my .emacs:

  (setq x-select-request-type '(UTF8_STRING COMPOUND_TEXT TEXT STRING)

When I select some text from Mozilla-firefox using left mouse
button, but without issuing cut/copy command explicitly, then I paste
in emacs with middle mouse button or C-y, everything is OK,
which means the X PRIMARY selection method works fine.

But if I issue cut/copy command explicitly after
selection (select Edit/copy from Mozilla-firefox's menu, or C-c),
and then paste in emacs using Edit/paste menu item, what I got is
undecoded utf string, something like this "\u60a8\u4e0a\u6b21",
it seems that the X CLIPBOARD selection method does not work.

The following patch could fix this problem, but I'm not sure if
it is the best way.

--
*** x-win.el2005-05-30 02:44:48.0 +0800
--- x-win.el.new2005-06-08 23:38:30.330605432 +0800
***
*** 2446,2452 
(interactive)
(let ((clipboard-text
 (condition-case nil
!(x-get-selection 'CLIPBOARD)
   (error nil)))
(x-select-enable-clipboard t))
  (if (and clipboard-text (> (length clipboard-text) 0))
--- 2446,2452 
(interactive)
(let ((clipboard-text
 (condition-case nil
!(x-selection-value 'CLIPBOARD)
   (error nil)))
(x-select-enable-clipboard t))
  (if (and clipboard-text (> (length clipboard-text) 0))


In GNU Emacs 23.0.0.1 (i686-pc-linux-gnu, GTK+ Version 2.6.4)
 of 2005-05-30 on dorm
Distributor `The XFree86 Project, Inc', version 11.0.4031
configured using `configure 'CFLAGS=-g' 'prefix=/usr' '--with-x-toolkit=gtk''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: zh_CN.GBK
  locale-coding-system: chinese-gbk
  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: debugger with pop-up-frames non-nil: keeps creating new frames

[Drew Adams]

And, yes, I think the default value for
`display-buffer-reuse-frames' should
be `t'. People upgrading from versions of Emacs that don't have this
variable will expect more or less unchanged behavior
without having to explicitly set this variable to `t'.

As far as I can tell, the current default of nil provides unchanged
behavior.  The change was in version 1.302 of windows.c.
Why do you think it is the contrary?
(Such a change could be an improvement nonetheless.)

It's hard for me to answer what it should be, since I'm still having the
trouble I reported. What I meant was that in Emacs 20, frames are reused
without this variable, and there is no flaky debugging behavior. Also, based
on the doc string for this variable, I believe that frame reuse was the
behavior before the variable existed. Perhaps there was an Emacs version
between Emacs 20.7 and 22 that had the reverse behavior; I don't know. In
any case, whether or not this was the behavior previously, reusing frames as
the default makes sense to me.




___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: typo in faces.el

[Kim F. Storm]

Frederik Fouvry <[EMAIL PROTECTED]> writes:

> Symptoms:
>
> I suspect the face name modeline-higilight is a typo for
> modeline-highlight.  Patch below.

Since both mode-line-inactive and mode-line-highlight are
new faces in 22.x, do we really need to have face aliases
for them?

-- 
Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk



___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

typo in faces.el

[Frederik Fouvry]

Symptoms:

I suspect the face name modeline-higilight is a typo for
modeline-highlight.  Patch below.

Index: lisp/faces.el
===
RCS file: /cvsroot/emacs/emacs/lisp/faces.el,v
retrieving revision 1.313
diff -c -r1.313 faces.el
*** lisp/faces.el   6 Jun 2005 12:18:20 -   1.313
--- lisp/faces.el   8 Jun 2005 14:37:22 -
***
*** 1863,1869 
  ;; Make `modeline' an alias for `mode-line', for compatibility.
  (put 'modeline 'face-alias 'mode-line)
  (put 'modeline-inactive 'face-alias 'mode-line-inactive)
! (put 'modeline-higilight 'face-alias 'mode-line-highlight)
  
  (defface header-line
'((default
--- 1863,1869 
  ;; Make `modeline' an alias for `mode-line', for compatibility.
  (put 'modeline 'face-alias 'mode-line)
  (put 'modeline-inactive 'face-alias 'mode-line-inactive)
! (put 'modeline-highlight 'face-alias 'mode-line-highlight)
  
  (defface header-line
'((default


In GNU Emacs 22.0.50.4 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2005-06-07 on cc.at.coli.uni-sb.de
Distributor `The XFree86 Project, Inc', version 11.0.40201000


___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Bootstrap fails due to flyspell.el change.

[Richard Stallman]

On second thought: it's probably better to solve the problem by using
define-minor-mode to implement flyspell-mode.  Does anyone see any
problems with the patch below?

It looks good to me.


___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: DOC select-frame: argument doc. missing

[Richard Stallman]

Indeed, the value of that argument seems to be unused.
So I guess it is a relic of something.

If you look at the change logs, you could probably tell what happened.


___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Bootstrap fails due to flyspell.el change.

[Lute Kamstra]

Lute Kamstra <[EMAIL PROTECTED]> writes:

[...]

> On second thought: it's probably better to solve the problem by using
> define-minor-mode to implement flyspell-mode.  Does anyone see any
> problems with the patch below?

Committed.  You may have to delete lisp/loaddefs.el to make
bootstrapping work again.

Lute.


___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug