Re: Info-scroll-up/down on mode-line

[Glenn Morris]

Nick Roberts wrote:

> Info-scroll-up/down are bound on the mode-line (over the node name)
> to mouse-1 and mouse-3. However, in a split window configuaration
> with Info at the top and the bottom window selected, clicking there
> scrolls the _bottom_ window, and Emacs gets confused if this is
> already at the top or bottom.

Maybe:

*** info.el 01 Apr 2007 23:11:10 -0700  1.500
--- info.el 23 Apr 2007 00:02:02 -0700  
***
*** 2602,2607 
--- 2602,2608 
  in other ways.)"
  
(interactive)
+   (select-window (posn-window (event-start last-input-event)))
(if (or (< (window-start) (point-min))
  (> (window-start) (point-max)))
(set-window-start (selected-window) (point)))
***
*** 2627,2632 
--- 2628,2634 
  beginning of a node, that goes to the previous node or back up to the
  parent node."
(interactive)
+   (select-window (posn-window (event-start last-input-event)))
(if (or (< (window-start) (point-min))
  (> (window-start) (point-max)))
(set-window-start (selected-window) (point)))



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

Why does a globalized mode check all buffers?

[Lennart Borgman (gmail)]

I had some trouble with Emacs hanging and a globalized minor mode so I 
checked `define-globalized-minor-mode'. It looks a bit strange to me. 
Why should a globalized mode check every buffer after a change in major 
mode in one buffer, for example?


Or am I misreading the macro?


In GNU Emacs 22.0.98.1 (i386-mingw-nt5.1.2600)
 of 2007-04-22


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

Re: Why does a globalized mode check all buffers?

[Lennart Borgman (gmail)]

Lennart Borgman (gmail) wrote:
I had some trouble with Emacs hanging and a globalized minor mode so I 
checked `define-globalized-minor-mode'. It looks a bit strange to me. 
Why should a globalized mode check every buffer after a change in major 
mode in one buffer, for example?


Or am I misreading the macro?



Ah, yes, I was.


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

Re: html-mode demanding a bit too tight

[Glenn Morris]

Kevin Ryde wrote:

> If I'm not mistaken the html-mode regexp in magic-mode-alist demands a
> "
>or
>   
> could be considered html too.

Since plain "http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: GTK build: some menus in the menu bar stay highlighted

[Stephen Berman]

On Sun, 22 Apr 2007 20:36:31 +0200 Jan Djärv <[EMAIL PROTECTED]> wrote:

> The GNUS menus are defined with easy-menu, thats about all I can
> think of that differs from "regular" menus.  Can you define a small
> menu with easy.menu and see if the problem is there then?

It turns out the problem is not confined to easymenu: I made the
following file,

,[ srb-km.el ]
| (define-key global-map [menu-bar SRB]
|   (cons "SRB" (make-sparse-keymap "SRB")))
`

and then did this:

emacs -Q -l srb-km.el

which brings up the *scratch* buffer with a menu bar whose first menu
is labelled `SRB'.  When I move the mouse over this menu bar, menu
label SRB, and only this menu label, gets sticky highlighting (again,
only with the GTK Style QtCurve under KDE).

Steve Berman



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

Re: Display problems with overlays (on w32 only?)

[Glenn Morris]

"Lennart Borgman (gmail)" wrote:

> In the attached images I have one overlay one character long that has a 
> red underline.
[...]
> In the second picture I have added another overlay, with a slightly blue 
> background. This overlay is 10 characters long and includes a new line. 
> The first overlay with the red underline is still just one character 
> long, but the red underline now displays in the whole range of the 
> second overlay. (The two oeverlays starts at the same character.)

Yes, but what shade of blue?

emacs -q --no-site-file

Press [RET] on "i" in "This buffer is for..."

At end of buffer, evaluate this:

(setq o1 (make-overlay 1 2))
(overlay-put o1 'face '(:underline t :foreground "red"))
(setq o2 (make-overlay 1 10))
(overlay-put o2 'face '(:background "green"))

Works as it should for me. This is on GNU/Linux.



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

Re: redisplay

[martin rudalics]

> In my Emacs (GNU Emacs 22.0.98.2 (i686-pc-linux-gnu, GTK+ Version
> 2.10.6) of 2007-04-20 on escher) I see two behaviors:
>
> 1. Evalling the above sexp in *scratch* with C-j or in any buffer with
> M-: results in what the OP reported: "produces a blank frame while the
> popup dialog is active, i.e., (redisplay t) fails to wait for
> redisplay to finish."
>
> 2. Evalling the sexp with C-x C-e in any buffer results in what RMS
> reported.

On my Emacs - 22.0.97.1 (i386-mingw-windows98.3000) - I only see the
second behavior.  GTK+ related?



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

Re: pending-undo-list is not buffer local

[martin rudalics]

>  > I think for the reason above that it should be buffer local and I also
>  > think that it should be permanent buffer local then.
>
> I think this wouldn't make much sense since `buffer-undo-list' isn't
> permanently buffer-local either.
>
> It is, practically speaking.  It is buffer-local, and changing major
> modes does not clear it out.

Like `buffer-file-name'.  Would it make sense to introduce a variable,
say `buffer-file-name-extension', assign its initial value from
`buffer-file-name', make it a permanent buffer-local, and hope that the
value of the new variable always correctly reflects the extension of
`buffer-file-name' without any additional provisions?

Various parts of Emacs manipulate `buffer-undo-list' in various ways.
`revert-buffer' may reset it.  Some applications temporarily bind it to
t to avoid, for example, recording text property changes.  Finally undo
recording may be switched off.  Should `pending-undo-list' be affected
by all these and how?



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

Fonts do not work correctly in cc-mode

[Matzi Kratzi]

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

Quite often, but not always, cc-mode does not fontify the "head" of a
function definition correctly.

static uint8 CheckIE_ActivateUTC_Req(LL_Data_Ind_t *ActivateUTC_Req_p,
ActivateUTC_ReqAddr_t
*ActivateUTC_ReqAddr_p)
{
...
}

"uint8 CheckIE_ActivateUTC_Req" is black. I want "uint8" to be green
and "CheckIE_ActivateUTC_Req" to be blue.

If I use M-x font-lock-fontify-buffer when I see this, emacs will
fontify it correctly. If I add a space somewhere inside
CheckIE_ActivateUTC_Req and then immediately delete it, emacs will
also fontify it correctly.


If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
   `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
c:/Download/emacs-070423/etc/DEBUG for instructions.


In GNU Emacs 22.0.98.1 (i386-mingw-nt5.0.2195)
of 2007-04-23 on E001560B82878
Windowing system distributor `Microsoft Corp.', version 5.0.2195
configured using `configure --with-gcc (3.4)'

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: SVE
 locale-coding-system: cp1252
 default-enable-multibyte-characters: t

Major mode: C/l

Minor modes in effect:
 encoded-kbd-mode: t
 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

Recent input:
 C-s c h e c k  SPC 
M-x r e p o r t SPC b u SPC  
 

Recent messages:
("C:\\Download\\emacs-070423\\bin\\emacs.exe" "-Q")
Loading encoded-kb...done
For information about the GNU Project and its goals, type C-h C-p.
Loading url-util...done
psr.c has auto save data; consider M-x recover-this-file
Loading cc-mode...done
Mark saved where search started
Loading emacsbug...done


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

Re: Info-scroll-up/down on mode-line

[Nick Roberts]

 > Maybe:
 > 
 > *** info.el  01 Apr 2007 23:11:10 -0700  1.500
 > --- info.el  23 Apr 2007 00:02:02 -0700  
 > ***
 > *** 2602,2607 
 > --- 2602,2608 
 >   in other ways.)"
 >   
 > (interactive)
 > +   (select-window (posn-window (event-start last-input-event)))
 > (if (or (< (window-start) (point-min))
 >(> (window-start) (point-max)))
 > (set-window-start (selected-window) (point)))
 >...


Sometimes I see it like below.  Also I wonder if the window should be selected
or save-selected-window used.

-- 
Nick   http://www.inet.net.nz/~nickrob


*** info.el 02 Apr 2007 17:11:22 +1200  1.500
--- info.el 23 Apr 2007 21:01:49 +1200  
***
*** 2587,2593 
   (goto-char (point-max)
(t (error "No previous nodes"
  
! (defun Info-scroll-up ()
"Scroll one screenful forward in Info, considering all nodes as one 
sequence.
  Once you scroll far enough in a node that its menu appears on the screen
  but after point, the next scroll moves into its first subnode, unless
--- 2587,2593 
   (goto-char (point-max)
(t (error "No previous nodes"
  
! (defun Info-scroll-up (e)
"Scroll one screenful forward in Info, considering all nodes as one 
sequence.
  Once you scroll far enough in a node that its menu appears on the screen
  but after point, the next scroll moves into its first subnode, unless
***
*** 2601,2607 
  item.  (That case won't normally result from this command, but can happen
  in other ways.)"
  
!   (interactive)
(if (or (< (window-start) (point-min))
  (> (window-start) (point-max)))
(set-window-start (selected-window) (point)))
--- 2601,2608 
  item.  (That case won't normally result from this command, but can happen
  in other ways.)"
  
!   (interactive (list last-input-event))
!   (select-window (posn-window (event-start e)))
(if (or (< (window-start) (point-min))
  (> (window-start) (point-max)))
(set-window-start (selected-window) (point)))


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

Re: Emacs manual node Query Replace needs cross ref to Unconditional Replace

[Eli Zaretskii]

> From: "Drew Adams" <[EMAIL PROTECTED]>
> Date: Tue, 17 Apr 2007 16:49:41 -0700
> 
> 3. Actually, it looks as if the proper target for the missing cross
> reference (in both nodes mentioned) should be node Replacement and Case.

Thanks, I did just that.


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

Re: [unicode-2] whitespace-auto-cleanup always replaces leading spaces with tabs

[Braden McDaniel]

On Sun, 22 Apr 2007 11:16:45 +0200, martin rudalics wrote:

>> If I start with -Q and then set whitespace-global-mode to non-nil and
>  > set both whitespace-check-leading-whitespace and
>  > whitespace-check-indent-whitespace to nil, leading sequences of 8
>  > spaces still get highlighted.
> 
> What happens if you set (customize) `whitespace-check-indent-whitespace'
> _before_ you toggle `whitespace-global-mode'?

No difference; sequences of 8 spaces in indentation are still highlighted.

>  > I see. But I think this has gotten sidetracked from the real bug that
>  > was introduced here. Indeed, the fact that
>  > whitespace-check-indent-whitespace has never done what I want is
>  > exactly the reason I have it set to nil (along with
>  > whitespace-check-leading-whitespace; I'm not clear on how these two
>  > differ).
> 
> `whitespace-check-leading-whitespace' only serves for removing leading
> empty lines from the buffer, hence it doesn't enter here.

Okay.

>  > So the bug that has been introduced recently is whatever causes
>  > whitesapce checking to flag indentation whitespace even though
>  > whitespace-check-indent-whitespace is nil.
> 
> I'm not sure what you mean here.  Above you said that it "has never done
> what you want" here you talk about a recently introduced bug.

Two different things:

 * whitespace-check-indent-whitespace--when non-nil--doesn't play
   nicely with indent-tabs-mode; this has been the case for as long as
   I know.
 * Setting whitespace-check-indent-whitespace to nil simply doesn't
   work. That is, it doesn't turn off checking (and correcting)
   indentation whitespace.  This is (relatively) new.

> Please
> tell me whether and when this worked correctly.  I could try to track
> the changes that occurred since then.

Unfortunately I don't have a working copy around that hasn't been updated 
to a point that includes this problem. I'm not sure when I updated prior 
to my most recent update (April 1); it was a while. I'm in the process of 
checking out some older revisions to try to find when this worked; but so 
far no luck. I can say that it works with emacs 21.4.1.

-- 
Braden McDaniel   e-mail: <[EMAIL PROTECTED]>
Jabber: <[EMAIL PROTECTED]>



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

Re: Display problems with overlays (on w32 only?)

[Jason Rumney]

Lennart Borgman (gmail) wrote:


In the attached images I have one overlay one character long that has 
a red underline. In the first picture there is only this overlay at 
that point and the display is correct.


In the second picture I have added another overlay, with a slightly 
blue background.

This doesn't match with what your images show.



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

Re: patch for locate.el when called with prefix arg

[Luc Teirlinck]

Miles Bader wrote;

   The old code didn't have an "arg" argument, so there's no argument
   compatibility to maintain -- and indeed that argues for introducing
   reasonable arguments now.

For backward compatibility and for other reasons, the new arg _needs_
to be optional.  That means that a nil arg _must_ mean to just respect
the value of `locate-prompt-for-command', so there is at least some
compatibility to maintain.  On top of that, it seems natural to have
one value of ARG that allows the caller to just pass on its prefix
arg.  In as far as adding two additional values to just force one
behavior or the other, regardless of `locate-prompt-for-command', to
give a potential caller an additional way to that, rather than
passing no arg and binding ``locate-prompt-for-command' around the
call, I do not see the urgency to do that before the release.

In as far as the behavior of `C-x ESC ESC' is concerned, I do not
immediately see why the behavior you describe is better, nor why it is
that hugely important, nor why it would have to be taken care of
before the release, if at all.

Sincerely,

Luc.


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

Re: html-mode demanding a bit too tight

[Stefan Monnier]

> In a recent build of the cvs, visiting the file minimal.html below
> selects sgml-mode, where I hoped to get html-mode.  According to the

Again, the best fix seems to be to make sure the ".html" extension
is heeded.


Stefan


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

Re: Display problems with overlays (on w32 only?)

[Lennart Borgman (gmail)]

Glenn Morris wrote:

"Lennart Borgman (gmail)" wrote:

In the attached images I have one overlay one character long that has a 
red underline.

[...]
In the second picture I have added another overlay, with a slightly blue 
background. This overlay is 10 characters long and includes a new line. 
The first overlay with the red underline is still just one character 
long, but the red underline now displays in the whole range of the 
second overlay. (The two oeverlays starts at the same character.)


Yes, but what shade of blue?

emacs -q --no-site-file

Press [RET] on "i" in "This buffer is for..."

At end of buffer, evaluate this:

(setq o1 (make-overlay 1 2))
(overlay-put o1 'face '(:underline t :foreground "red"))
(setq o2 (make-overlay 1 10))
(overlay-put o2 'face '(:background "green"))

Works as it should for me. This is on GNU/Linux.


Thanks, but I should have sent some code in addition to my explanation. 
The above works for me to, but can you please test the code below. That 
code gives the error. The important thing is the newline characters.


(defvar o1 nil)
(defvar o2 nil)
(defun test-me()
  (interactive)
  (let ((buf (get-buffer-create "*OVERLAY Error*")))
(switch-to-buffer-other-window buf)
(with-current-buffer buf
  (erase-buffer)
  (insert "123\n\n  890")
  (if o1
  (move-overlay o1 3 5)
(setq o1 (make-overlay 3 5)))
  (overlay-put o1 'face '(:underline "red"))
  (if o2
  (move-overlay o2 3 9)
(setq o2 (make-overlay 4 9)))
  (overlay-put o2 'face '(:background "#77"))
  (other-window -1)
  )))

(test-me)
;;(delete-overlay o2)


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

Re: html-mode demanding a bit too tight

[Lennart Borgman (gmail)]

Stefan Monnier wrote:

In a recent build of the cvs, visiting the file minimal.html below
selects sgml-mode, where I hoped to get html-mode.  According to the


Again, the best fix seems to be to make sure the ".html" extension
is heeded.



I agree. If you look at EmacsWiki for example you can see that a good 
number of users gets confused by the mode selection caused by that 
magic-mode-alist overrides auto-mode-alist.


I think that should be reversed before release. Didn't we discuss that 
before?


The only real drawback I can see is that magic-mode-alist does not 
deserve it's name that much if we do that change. 8-)



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

Re: patch for locate.el when called with prefix arg

[Richard Stallman]

There seem to be many places in the Lisp code that violate this.  For
instance, both Calc and org mode seem to violate this systematically.

It may be feasible to fix org.  Fixing calc is probably a big job and
has to wait.


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

Re: Info-scroll-up/down on mode-line

[Richard Stallman]

Info-scroll-up/down are bound on the mode-line (over the node name) to
mouse-1 and mouse-3.  However, in a split window configuaration with Info at
the top and the bottom window selected, clicking there scrolls the _bottom_
window, and Emacs gets confused if this is already at the top or bottom.

See how mouse-drag-mode-line-1 handles this:

(defun mouse-drag-mode-line-1 (start-event mode-line-p)
  "Change the height of a window by dragging on the mode or header line.
START-EVENT is the starting mouse-event of the drag action.
MODE-LINE-P non-nil means dragging a mode line; nil means a header line."
  ;; Give temporary modes such as isearch a chance to turn off.
  (run-hooks 'mouse-leave-buffer-hook)
  (let* ((done nil)
 (echo-keystrokes 0)
 (start (event-start start-event))
 (start-event-window (posn-window start))
 (start-event-frame (window-frame start-event-window))
 (start-nwindows (count-windows t))
 (minibuffer (frame-parameter nil 'minibuffer))
 should-enlarge-minibuffer event mouse y top bot edges wconfig 
growth)

Then it does everything on start-event-window.

Can you implement the same method in Info-scroll-up and
Info-scroll-down?


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

Re: python.el

[Richard Stallman]

> If not, please could you explain in more detail what you mean?

There are potential problems due to my previous employer with things I
wrote until I left in April 2006.  I'm contractually obliged to inform
the FSF about that, whether or not I consider it spurious or actually
care about GNU.

That sounds like a real issue.  Did we install code
that you wrote during that time?


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

Re: filling long html href

[Richard Stallman]

I'd be inclined to make paragraph-start match all tags (as it does
now) except the ones described as "text level" elements by the specs,
like  etc, because they're not paragraph breaks in the resulting
browser display.

How would you write paragraph-start to do that?
I think it is very hard, perhaps impossible.
That is why I suggest you try actually writing it.



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

Re: patch for locate.el when called with prefix arg

[Richard Stallman]

Please install your patch.

Now we have to make a decision for `locate-with-filter' and
`locate-in-alternate-database'.  These two commands currently pass
their interactive arg on to locate, which is undocumented and probably
unintentional, but could nevertheless be considered a "feature".

Now there are three things we could do.  We could do something now and
something else after the release, if appropriate.

The three choices are: no longer pass the arg on, pass the arg on and
leave it undocumented, sticking with the current state of affairs (no
visible difference to the user), pass on and properly document.
Problem with the last two: I do not know how well tested the
unintentional "feature" is.

I think BOTH of these functions should pass the arg along.
Then behavior will be unchanged.  After the release we could
document this feature and then get any bugs fixed.


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

Re: pending-undo-list is not buffer local

[Lennart Borgman (gmail)]

martin rudalics wrote:
 >  > I think for the reason above that it should be buffer local 
and I also

 >  > think that it should be permanent buffer local then.
 >
 > I think this wouldn't make much sense since `buffer-undo-list' isn't
 > permanently buffer-local either.
 >
 > It is, practically speaking.  It is buffer-local, and changing major
 > modes does not clear it out.

Like `buffer-file-name'.  Would it make sense to introduce a variable,
say `buffer-file-name-extension', assign its initial value from
`buffer-file-name', make it a permanent buffer-local, and hope that the
value of the new variable always correctly reflects the extension of
`buffer-file-name' without any additional provisions?

Various parts of Emacs manipulate `buffer-undo-list' in various ways.
`revert-buffer' may reset it.  Some applications temporarily bind it to
t to avoid, for example, recording text property changes.  Finally undo
recording may be switched off.  Should `pending-undo-list' be affected
by all these and how?


I actually assume that the logic around pending-undo-list is correct. 
That part will not break.


I am a bit worried that the wrong pending-undo-list will be used because 
of buffer switching, but not very much, since buffer-undo-list is buffer 
local and those two are used together. (It have to be tested of course.)



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

Re: patch for locate.el when called with prefix arg

[Chong Yidong]

Richard Stallman <[EMAIL PROTECTED]> writes:

> Please install your patch.

I installed the patch.



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

Re: Info-scroll-up/down on mode-line

[Chong Yidong]

Nick Roberts <[EMAIL PROTECTED]> writes:

> Info-scroll-up/down are bound on the mode-line (over the node name) to
> mouse-1 and mouse-3.  However, in a split window configuaration with Info at
> the top and the bottom window selected, clicking there scrolls the _bottom_
> window, and Emacs gets confused if this is already at the top or bottom.

Thanks, I checked in a fix for this.



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

Re: html-mode vs inconsistent eol types

[Stefan Monnier]

>> Agreed, and the file contents shouldn't make any difference in this
>> respect since the file's extension is explicit.

> But they do, since magic-mode-alist describes itself as overriding
> auto-mode-alist. Maybe you mean this is a Bad Thing?

The "should" was not meant to describe what *does* happen, but what an ideal
Emacs would do.


Stefan


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

Re: python.el

[Chong Yidong]

Glenn Morris <[EMAIL PROTECTED]> writes:

> Anyway, back to the topic at hand: there's a potential legal problem
> with python.el. Is all the code you wrote for python.el affected, or
> just the 2006-08-20 changes? Before that, there are no changes from
> python.el from you until we get to 2004-12-02.
>
> If it's just the 2006-08-20 stuff: Stefan, is there anyway this can
> easily be removed and still leave a working python.el? Dave, would
> that be acceptable to you?
>
> Otherwise, our only recourse AFAICS is to remove python.el before the
> (imminent) release of Emacs 22.

I suggest simply removing python.el.  We can add it back for Emacs
22.2 if/when the unspecified legal issues get ironed out.

What do people think?



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

Re: Display problems with overlays (on w32 only?)

[Jason Rumney]

Thanks, but I should have sent some code in addition to my 
explanation. The above works for me to, but can you please test the 
code below. That code gives the error. The important thing is the 
newline characters.


The behaviour is the same on w32 as it is on X. What made you say it was 
on w32 only?




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

Re: Display problems with overlays (on w32 only?)

[Lennart Borgman (gmail)]

Jason Rumney wrote:


Thanks, but I should have sent some code in addition to my 
explanation. The above works for me to, but can you please test the 
code below. That code gives the error. The important thing is the 
newline characters.


The behaviour is the same on w32 as it is on X. What made you say it was 
on w32 only?


I asked, I did not say is was. I have only access to w32 most of the 
time so I could not test.



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

Re: python.el

[Kim F. Storm]

Chong Yidong <[EMAIL PROTECTED]> writes:

> I suggest simply removing python.el.  We can add it back for Emacs
> 22.2 if/when the unspecified legal issues get ironed out.
>
> What do people think?

Since python.el is new in Emacs 22, removing it is inconventient, but ok.

IIUC, then Dave Love's original python.el does not work with Emacs 22,
so we need to ask people to use a different reason

Maybe we (who?) could put a copy of the current python.el on emacswiki.org

We should add a brief note about it to NEWS (in the "About external
Lisp packages" section):


*** NEWS23 Apr 2007 14:07:12 +0200  1.1464
--- NEWS23 Apr 2007 18:19:13 +0200  
***
*** 31,38 
--- 31,42 
  Some specific packages that are known to cause problems are:
  
  ** Semantic (used by CEDET, ECB, JDEE): upgrade to latest version.
+ 
  ** cua.el, cua-mode.el: remove old versions.
  
+ ** python.el: upgrade to the Emacs 22.1 compatible version available from
+ http://www.emacswiki.org
+ 
  
  * Installation Changes in Emacs 22.1



-- 
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

Re: Display problems with overlays (on w32 only?)

[Chong Yidong]

"Lennart Borgman (gmail)" <[EMAIL PROTECTED]> writes:

> In the attached images I have one overlay one character long that has
> a red underline.

In the code you provide, the overlay is two characters long, not one.
If you make the overlay span 3 to 4, everything works fine.

> (defun test-me()
>   (interactive)
>   (let ((buf (get-buffer-create "*OVERLAY Error*")))
> (switch-to-buffer-other-window buf)
> (with-current-buffer buf
>   (erase-buffer)
>   (insert "123\n\n  890")
>   (if o1
>   (move-overlay o1 3 5)
> (setq o1 (make-overlay 3 5)))
>   (overlay-put o1 'face '(:underline "red"))
>   (if o2
>   (move-overlay o2 3 9)
> (setq o2 (make-overlay 4 9)))
>   (overlay-put o2 'face '(:background "#77"))
>   (other-window -1)
>   )))



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

Re: Display problems with overlays (on w32 only?)

[Lennart Borgman (gmail)]

Chong Yidong wrote:

"Lennart Borgman (gmail)" <[EMAIL PROTECTED]> writes:


In the attached images I have one overlay one character long that has
a red underline.


In the code you provide, the overlay is two characters long, not one.
If you make the overlay span 3 to 4, everything works fine.


Ah, yes, but that was just to show that it is not necessary that it is 
one character long. (When I reported it first that was all I knew. I 
thought it was best to do it as quickly as possible.)


Sorry for beeing unclear.



(defun test-me()
  (interactive)
  (let ((buf (get-buffer-create "*OVERLAY Error*")))
(switch-to-buffer-other-window buf)
(with-current-buffer buf
  (erase-buffer)
  (insert "123\n\n  890")
  (if o1
  (move-overlay o1 3 5)
(setq o1 (make-overlay 3 5)))
  (overlay-put o1 'face '(:underline "red"))
  (if o2
  (move-overlay o2 3 9)
(setq o2 (make-overlay 4 9)))
  (overlay-put o2 'face '(:background "#77"))
  (other-window -1)
  )))




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





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

Re: patch for locate.el when called with prefix arg

[Luc Teirlinck]

I suggest the following small changes to the Changelog (mainly for the
benefit of people who might want to find out when the optional arg for
locate was introduced), as well as the adding of an additional comment
to locate.el, to make clear that the use of `current-prefix-arg' in
`locate-prompt-for-search-string' is legitimate.

These changes are so trivial that I thought of just committing them,
but I am unsure about the exact procedure, given the pretest, which is
why I post them.

===File ~/changelog-diff
*** ChangeLog   23 Apr 2007 11:17:11 -0500  1.11042
--- ChangeLog   23 Apr 2007 11:46:01 -0500  
***
*** 8,16 
  2007-04-23  Luc Teirlinck  <[EMAIL PROTECTED]>
  
* locate.el (locate-local-prompt): New var.
(locate-prompt-for-search-string): New function.
!   (locate): Make locate-local-prompt buffer-local.  Use
!   locate-prompt-for-search-string.
(locate-with-filter): New optional arg.  Use
locate-prompt-for-search-string.
(locate-update): Bind locate-prompt-for-command.
--- 8,17 
  2007-04-23  Luc Teirlinck  <[EMAIL PROTECTED]>
  
* locate.el (locate-local-prompt): New var.
+   (locate-prompt-for-command): Doc fix.
(locate-prompt-for-search-string): New function.
!   (locate): New optional arg.  Make locate-local-prompt
!   buffer-local.  Use locate-prompt-for-search-string.
(locate-with-filter): New optional arg.  Use
locate-prompt-for-search-string.
(locate-update): Bind locate-prompt-for-command.


===File ~/locate-diff===
*** locate.el   23 Apr 2007 11:17:12 -0500  1.43
--- locate.el   23 Apr 2007 11:40:14 -0500  
***
*** 245,250 
--- 245,251 
 (skip-chars-backward "." pt)
 (point)
  
+ ;; Function for use in interactive declarations.
  (defun locate-prompt-for-search-string ()
(if (or (and current-prefix-arg
   (not locate-prompt-for-command))



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

Re: Display problems with overlays (on w32 only?)

[Chong Yidong]

"Lennart Borgman (gmail)" <[EMAIL PROTECTED]> writes:

> Chong Yidong wrote:
>> "Lennart Borgman (gmail)" <[EMAIL PROTECTED]> writes:
>>
>>> In the attached images I have one overlay one character long that has
>>> a red underline.
>>
>> In the code you provide, the overlay is two characters long, not one.
>> If you make the overlay span 3 to 4, everything works fine.
>
> Ah, yes, but that was just to show that it is not necessary that it is
> one character long. (When I reported it first that was all I knew. I
> thought it was best to do it as quickly as possible.)

It also shows that the bug can be trivially worked around.  I don't
think we should make any changes to the redisplay code, at least not
for this class of bug.



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

Re: patch for locate.el when called with prefix arg

[Luc Teirlinck]

Richard Stallman wrote:

   I think BOTH of these functions should pass the arg along.
   Then behavior will be unchanged.  After the release we could
   document this feature and then get any bugs fixed.

`locate-with-filter' now passes the arg along, all bugs and
misfeatures I was referring to have been fixed and I believe the doc
is clear too.  So for this function things are completely solved.

In as far as `locate-in-alternate-database' is concerned, I can not
test this function since it only works for GNU locate and I have
slocate installed.  Since the docstring does not mention a prefix arg,
I am not even sure that this function can handle one at all.

So the currently committed patch does not pass the arg along.

IF somebody would be able to check that the following patch works OK
in the four combinatorial cases (prefix arg vs no prefix arg,
`locate-prompt-for-command' nil vs t), one could commit the patch
below.  Even so, updating with `g' would probably not work correctly
in the resulting buffer, because it would use the wrong database.
Since I can not check anything and it is not a regression, I will not
try to fix this.

Patch IF somebody can check it as specified above and ONLY in that
case (DANGER otherwise.  Without anybody checking it, I would rather
leave things exactly as they are now.  I do not believe that this is a
widely used command.):

===File ~/locate-diff-new===
*** locate.el   23 Apr 2007 11:17:12 -0500  1.43
--- locate.el   23 Apr 2007 12:16:53 -0500  
***
*** 245,250 
--- 245,251 
 (skip-chars-backward "." pt)
 (point)
  
+ ;; Function for use in interactive declarations.
  (defun locate-prompt-for-search-string ()
(if (or (and current-prefix-arg
   (not locate-prompt-for-command))
***
*** 667,682 
  file))
  
  ;; Only for GNU locate
! (defun locate-in-alternate-database  (search-string database)
"Run the GNU locate command, using an alternate database."
(interactive
!   (list
!(progn
!;; (require 'locate)
!(read-from-minibuffer "Locate: " nil nil
!  nil 'locate-history-list))
!(read-file-name "Locate using Database: " )
!))
(or (file-exists-p database)
(error "Database file %s does not exist" database))
(let ((locate-make-command-line
--- 668,680 
  file))
  
  ;; Only for GNU locate
! (defun locate-in-alternate-database (search-string database arg)
"Run the GNU locate command, using an alternate database."
(interactive
!(list
! (locate-prompt-for-search-string)
! (read-file-name "Locate using Database: " )
! current-prefix-arg))
(or (file-exists-p database)
(error "Database file %s does not exist" database))
(let ((locate-make-command-line
***
*** 685,691 
   (list (concat "--database="
 (expand-file-name database))
 string))
! (locate search-string)))
  
  (defun locate-do-redisplay (&optional arg test-for-subdir)
"Like `dired-do-redisplay', but adapted for `*Locate*' buffers."
--- 683,689 
   (list (concat "--database="
 (expand-file-name database))
 string))
! (locate search-string nil arg)))
  
  (defun locate-do-redisplay (&optional arg test-for-subdir)
"Like `dired-do-redisplay', but adapted for `*Locate*' buffers."



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

Re: patch for locate.el when called with prefix arg

[Luc Teirlinck]

If somebody else would install the `locate-in-alternate-database' patch
(AFTER carefully testing it), please be careful not to add the line:

   + ;; Function for use in interactive declarations.

twice, since I also included that in a previously proposed (but not
yet installed) trivial and riskless patch.

(Sorry, had to resend this message for address error.)

Sincerely,

Luc Teirlinck.



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

(void-function nil) error without backtrace

[Robert Widhopf-Fenk]

Hi,

I spend a considerable time to track down the following bug.

Whenever I enable debug-on-error when running VM I get a backtrace
with the following content:

,--
| Debugger entered--Lisp error: (void-function nil)
|  (nil)
`--

This is the WHOLE backtrace, well sometimes it is longer,
but never helpful!

See also the discussion in gnu.emacs.help (many thanks to Tim X) on
'How to debug "Debugger entered--Lisp error: (void-function nil)"'
at http://tinyurl.com/2uavle.

It was caused by a wrong toolbar item spec for the prop :button
and can be reproduced with GNU Emacs 22.0.92.1 and 21.4.1 on
Debian when adding the following to ~/.emacs:

(setq debug-on-error t)
(tool-bar-add-item "help" 'error 'buglet
   ':button '(:toggle nil)
   ':help "(void-function nil) buglet")

I am not sure how the backtrace should look like, but something like

,--
| Debugger entered--Lisp error: (void-function nil)
|  (nil)
| (tool-bar-redisplay)
| ...
`--

Would have saved me some days.

Robert.


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

Re: Tumme fails with default custom settings

[Mathias Dahl]

Tassilo Horn <[EMAIL PROTECTED]> writes:

> Here, the thumbs are displayed properly, and RET opens a
> *tumme-display-image* buffer with a scaled image. (The original icon
> is 64x64, and the buffer shows about a 350x350 version)

> When I type `f' a small, empty square is displayed -- not the
> image. `s' gets me back to the scaled image.

I was able to recreate this, but only for "small" images. Not sure yet
if there is a certain limit or if it is variable. The same problem can
be seen if you do C-u RET instead of RET in the thumbnail buffer.

I cannot say if this ever worked because I think that each time I have
tested this command I have done it with an image which is larger than
the Emacs window.

Also, I'd say it is a bug in Tumme that images that actually would fit
in the window, are resized. The idea when I implemented the automatic
resize feature was to autofit large images...

/Mathias



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

Re: patch for locate.el when called with prefix arg

[Luc Teirlinck]

>From my previous patch:

   Patch IF somebody can check it as specified above and ONLY in that
   case (DANGER otherwise.  Without anybody checking it, I would rather
   leave things exactly as they are now.  I do not believe that this is a
   widely used command.):

And if somebody cares about `locate-in-alternate-database' enough to
do that, then one might _in addition to_ my patch, _also_ give that
function an autoload cookie.  Otherwise, you probably will not be able
to call it, unless you priorly called another version of locate.

Sincerely,

Luc Teirlinck.


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

Re: C- doesn't respect current keyboard layout, OS X Carbon

[Aidan Kehoe]

 Ar an tríú lá is fiche de mí Aibréan, scríobh YAMAMOTO Mitsuharu: 

 > I don't have German keyboards and I can't reproduce this with my US
 > keyboard.  Could you see if each of the following setting/patch
 > changes the behavior?
 > 
 > 1) (setq mac-pass-control-to-system nil)
 > 
 > 2) Patch to macterm.c:

Neither the Lisp nor the C patch change the behaviour. 

Interestingly, it seems to be a difference between custom layouts and the
layouts that shipped with the system. If I switch to the British or US
layout, the problem goes away; that is, the control key behaves as expected,
given the selected key layout. 

-- 
On the quay of the little Black Sea port, where the rescued pair came once
more into contact with civilization, Dobrinton was bitten by a dog which was
assumed to be mad, though it may only have been indiscriminating. (Saki)


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

Re: patch for locate.el when called with prefix arg

[Luc Teirlinck]

   It may be feasible to fix org.  Fixing calc is probably a big job and
   has to wait.

>From grepping, I have the impression that there are plenty of other
places that have similar problems.  The docstring of `current-prefix-arg'
does not contain any usage instructions and `(elisp)Prefix Command Arguments'
is unclear, in the two places were it mentions the variable:

 Normally, commands specify which representation to use for the prefix
  argument, either numeric or raw, in the `interactive' specification.
  (*Note Using Interactive::.)  Alternatively, functions may look at the
  value of the prefix argument directly in the variable
  `current-prefix-arg', but this is less clean.

and:

-- Variable: current-prefix-arg
 This variable holds the raw prefix argument for the _current_
 command.  Commands may examine it directly, but the usual method
 for accessing it is with `(interactive "P")'.

Sincerely,

Luc.



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

Re: GTK build: some menus in the menu bar stay highlighted

[Jan Djärv]

Stephen Berman skrev:

On Sun, 22 Apr 2007 20:36:31 +0200 Jan Djärv <[EMAIL PROTECTED]> wrote:


The GNUS menus are defined with easy-menu, thats about all I can
think of that differs from "regular" menus.  Can you define a small
menu with easy.menu and see if the problem is there then?


It turns out the problem is not confined to easymenu: I made the
following file,

,[ srb-km.el ]
| (define-key global-map [menu-bar SRB]
|   (cons "SRB" (make-sparse-keymap "SRB")))
`

and then did this:

emacs -Q -l srb-km.el

which brings up the *scratch* buffer with a menu bar whose first menu
is labelled `SRB'.  When I move the mouse over this menu bar, menu
label SRB, and only this menu label, gets sticky highlighting (again,
only with the GTK Style QtCurve under KDE).


When Emacs updates the menu bar, it usually just puts empty menus behind the 
menu bar entries.  This is to avoid updating the whole menu tree every time we 
just change buffer.  When we click on the menu bar, Emacs does update the 
whole menu tree (i.e. updates deep).


It seems that QtCurve can not handle non-deep menu bar entries.  If I click on 
the SRB menu entry in your example, thus forcing a deep update, the highlight 
problem goes away.


When Emacs creates the menu bar for the first time, it does so deep, so the 
error is not seen for the standard Emacs menu bar entries.


A special handling is for Gtk+ detached menus.  If there is a detached menu, 
Emacs always updates deep, since the detached menu could possibly change.


So we can se this bug easy.

C-h i

The Info menu now has the sticky highlight.
But if you kill that buffer, detach the File menu, and then to C-h i again. 
the sticky highlightning is gone.


I'd say this is a bug in QtCurve.  I can not find a way to undo that effect 
from within Emacs.  Apart from the obvious, always update menus deep.  But I 
don't think we want to do that just for one theme.  Not that I think it would 
break anything, it would just make menu bar updating a bit slower.


Jan D.



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

Re: GTK build: some menus in the menu bar stay highlighted

[Stephen Berman]

On Mon, 23 Apr 2007 22:09:36 +0200 Jan Djärv <[EMAIL PROTECTED]> wrote:

> When Emacs updates the menu bar, it usually just puts empty menus
> behind the menu bar entries.  This is to avoid updating the whole menu
> tree every time we just change buffer.  When we click on the menu bar,
> Emacs does update the whole menu tree (i.e. updates deep).
>
> It seems that QtCurve can not handle non-deep menu bar entries.  
[...]
> I'd say this is a bug in QtCurve.  I can not find a way to undo that
> effect from within Emacs.  Apart from the obvious, always update menus
> deep.  But I don't think we want to do that just for one theme.  Not
> that I think it would break anything, it would just make menu bar
> updating a bit slower.

Your analysis seems plausible to me, and I agree Emacs shouldn't be
changed to accommodate QtCurve.  Do you know if the Emacs treatment of
updating the menu bar is more or less unique to Emacs?  I haven't
observed "sticky highlighting" with QtCurve with any other Gtk+ apps
under KDE (e.g., Gimp, Eclipse).  If it is standard procedure in Gtk+
to always do deep updating of the menu bar, then that could account
for the asymmetry (and also for why QtCurve fails to handle the Emacs
case).

Steve Berman



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

Re: patch for locate.el when called with prefix arg

[Chong Yidong]

Luc Teirlinck <[EMAIL PROTECTED]> writes:

> I suggest the following small changes to the Changelog (mainly for the
> benefit of people who might want to find out when the optional arg for
> locate was introduced), as well as the adding of an additional comment
> to locate.el

Checked in, thanks.


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

Re: Info-scroll-up/down on mode-line

[Richard Stallman]

*** info.el 01 Apr 2007 23:11:10 -0700  1.500
--- info.el 23 Apr 2007 00:02:02 -0700  
***
*** 2602,2607 
--- 2602,2608 
  in other ways.)"

(interactive)
+   (select-window (posn-window (event-start last-input-event)))
(if (or (< (window-start) (point-min))
  (> (window-start) (point-max)))
(set-window-start (selected-window) (point)))

You would need to reselect the previous selected window.

But even with that, this may not be a good idea.
I think I tried such a method in mouse.el, and it had
some other problem, which is why I implemented the method now used.


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

Re: patch for locate.el when called with prefix arg

[Richard Stallman]

I was trying to keep changes as minimal as possible while still fixing
all bugs and misfeature.

I agree, that is a good approach.


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

Re: html-mode demanding a bit too tight

[Richard Stallman]

I agree. If you look at EmacsWiki for example you can see that a good 
number of users gets confused by the mode selection caused by that 
magic-mode-alist overrides auto-mode-alist.

I think that should be reversed before release. Didn't we discuss that 
before?

I really don't like the idea of changing what magic-mode-alist does.
Especially now.

It would be safer to introduce another variable which checks the magic
number but gives precedence to auto-mode-alist.  Then we could
move specific elements to that new variable; we would not have to change
the meaning of _all_ of the elements.  That is safer.


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

Re: Fonts do not work correctly in cc-mode

[Richard Stallman]

Quite often, but not always, cc-mode does not fontify the "head" of a
function definition correctly.

static uint8 CheckIE_ActivateUTC_Req(LL_Data_Ind_t *ActivateUTC_Req_p,
 ActivateUTC_ReqAddr_t
*ActivateUTC_ReqAddr_p)
{
...
}

With that formatting I am not surprised it fails,  Try writing it like this:

static uint8
CheckIE_ActivateUTC_Req(LL_Data_Ind_t *ActivateUTC_Req_p,
ActivateUTC_ReqAddr_t, *ActivateUTC_ReqAddr_p)
{
...
}


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

Re: pending-undo-list is not buffer local

[Richard Stallman]

Like `buffer-file-name'.  Would it make sense to introduce a variable,
say `buffer-file-name-extension', assign its initial value from
`buffer-file-name', make it a permanent buffer-local, and hope that the
value of the new variable always correctly reflects the extension of
`buffer-file-name' without any additional provisions?

I don't understand what this has to do with.


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

Re: pending-undo-list is not buffer local

[Richard Stallman]

Various parts of Emacs manipulate `buffer-undo-list' in various ways.
`revert-buffer' may reset it.  Some applications temporarily bind it to
t to avoid, for example, recording text property changes.  Finally undo
recording may be switched off.  Should `pending-undo-list' be affected
by all these and how?

We have no need to worry about this now.
If and when someone implements a more powerful undo facility,
we will see what kind of support it needs.


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

Re: Strange undo problem

[Richard Stallman]

But it would help with links between description of `modification-hooks' 
for text and overlays, since they are a bit different.

Good idea, thanks.


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

Re: html-mode demanding a bit too tight

[Kevin Ryde]

"Lennart Borgman (gmail)" <[EMAIL PROTECTED]> writes:
>
> If you look at EmacsWiki for example you can see that a good
> number of users gets confused by the mode selection caused by that
> magic-mode-alist overrides auto-mode-alist.

I suppose at least the xml and sgml tests are little bit too
aggressive.

No doubt crazy people who use those formats use equally crazy
filenames, so a test on content is good, but you kind of want them
after the filename tests, so .html means html.  Or for example if
there was a specific scrollkeeper .omf mode then hit that before the
generic xml.

Maybe if magic-mode-alist were combined into auto-mode-alist it'd be
easier to control conflicts or precedence among content vs filename
tests.  (Not that you want to get too fancy about such things ...)


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

Re: patch for locate.el when called with prefix arg

[Luc Teirlinck]

>From my previous message:

   In as far as `locate-in-alternate-database' is concerned, I can not
   test this function since it only works for GNU locate and I have
   slocate installed.  Since the docstring does not mention a prefix arg,
   I am not even sure that this function can handle one at all.

   So the currently committed patch does not pass the arg along.

   IF somebody would be able to check that the following patch works OK
   in the four combinatorial cases (prefix arg vs no prefix arg,
   `locate-prompt-for-command' nil vs t), one could commit the patch
   below

Thinking more about this, I now believe that a numeric arg to this
function makes little sense, even assuming that it _would_ work OK,
nor does using this function at all with `locate-prompt-for-command'
set to t make much sense.  This function is nothing more than an
interface for specifying the `d' option.  If you want to specify the
exact command line given to locate, then you can quite as well specify
the `-d' option right then.  This is actually more convenient than
specifying the database at a separate prompt.  Moreover, if you
specify the `-d' option explicitly, `g' will work correctly, whereas
if you use `locate-in-alternate-database', it probably will not.

So I do not believe that there is any need to test the patch for
`locate-in-alternate-database' which I proposed.  I believe that it is
better to just forget about that patch.

Sincerely,

Luc Teirlinck.


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

makefile filling indented comment

[Kevin Ryde]

In a recent cvs build, with a Makefile containing

foo:
# `|| true' prevents old Bash versions
# from getting confused
# by an error.
echo hi

and with point at the start of the second line, a fill

M-q

does nothing, where I hoped it would join and fill the three comment
lines.

The comment lint indentation above is with spaces, I think that's
allowed (by gnu make at least, as described under "Makefile Contents"
in its manual, and accepted when run).

If the indentation is tabs instead it doesn't work either.  It'd be
nice if it did.  I know tabbed comments create shell commands, and so
are often not what you want, but the force of pressing tab is pretty
strong (for instance emacs lisp/Makefile.in has one under
"compile-always").  Occasionally it's nice to let a comment echoed
while doing the make too.

Perhaps a change as simple as the following (but I'm not a big user of
the native fill prefix stuff, so don't really know if it's enough).

*** make-mode.el	12 Mar 2007 10:16:19 +1100	1.121
--- make-mode.el	23 Apr 2007 16:41:26 +1000	
***
*** 1304,1310 
(save-excursion
  (beginning-of-line)
  (cond
!  ((looking-at "^#+\\s-*")
;; Found a comment.  Return nil to let normal filling take place.
nil)
  
--- 1304,1310 
(save-excursion
  (beginning-of-line)
  (cond
!  ((looking-at "^[ \t]*#+\\s-*")
;; Found a comment.  Return nil to let normal filling take place.
nil)
  


In GNU Emacs 22.0.98.2 (i586-pc-linux-gnu, GTK+ Version 2.8.20)
 of 2007-04-18 on blah
configured using `configure  'CFLAGS=-O' '--prefix=/down/emacs/b/inst' 
'--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: en_AU
  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: C- doesn't respect current keyboard layout, OS X Carbon

[YAMAMOTO Mitsuharu]

> On Mon, 23 Apr 2007 21:24:10 +0200, Aidan Kehoe <[EMAIL PROTECTED]> said:

> Interestingly, it seems to be a difference between custom layouts
> and the layouts that shipped with the system. If I switch to the
> British or US layout, the problem goes away; that is, the control
> key behaves as expected, given the selected key layout.

So, is your Irish layout different from what is bundled with Mac OS X?
Could you precisely explain what "I've installed a variant of the OS X
Irish layout (which is itself a variant of the British layout)" in the
original message means?

 YAMAMOTO Mitsuharu
[EMAIL PROTECTED]


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

Re: patch for locate.el when called with prefix arg

[Miles Bader]

Luc Teirlinck <[EMAIL PROTECTED]> writes:
> I do not see the urgency to do that before the release.

_None_ of this is important enough to do before the release.  Given that
there's some disagreement about the right change to make, I think it's
better to hold off doing anything to the locate command until after the
release.

-Miles

-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]


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

Re: patch for locate.el when called with prefix arg

[Miles Bader]

I wrote:
> _None_ of this is important enough to do before the release.  Given that
> there's some disagreement about the right change to make, I think it's
> better to hold off doing anything to the locate command until after the
> release.

hmm, I see the patch is already applied; oh well...

-Miles
-- 
Next to fried food, the South has suffered most from oratory.
-- Walter Hines Page


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

Re: patch for locate.el when called with prefix arg

[Luc Teirlinck]

   _None_ of this is important enough to do before the release.

The changes fixed several annying bugs and Richard asked explicitly
for my patch to be committed.

Sincerely,

Luc.




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

Re: python.el

[Chong Yidong]

> There are potential problems due to my previous employer with things I
> wrote until I left in April 2006.  I'm contractually obliged to inform
> the FSF about that, whether or not I consider it spurious or actually
> care about GNU.

Do these "potential problems" apply also to, e.g., this patch that you
sent to emacs-pretest-bug in 2004?

http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-05/msg00055.html

  From:Dave Love
  Subject: python.el update
  Date:Thu, 06 May 2004 17:46:33 +0100

  These changes to python.el are relative to a previous revision
  (before one or more rounds of compilation changes) and won't now
  apply cleanly, but I'm not currently in a position to merge and test
  them.  They rely on a new file of Python code living in `etc' (also
  attached).



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

Fwd: Fonts do not work correctly in cc-mode

[Matzi Kratzi]

-- Forwarded message --
From: Matzi Kratzi <[EMAIL PROTECTED]>
Date: Apr 24, 2007 5:37 AM
Subject: Re: Fonts do not work correctly in cc-mode
To: [EMAIL PROTECTED]


I could, but I rather not.

Here is the smallest test-file I can produce. Try remove "  uint8 i;"
and the fonts will work as expected (in my opinion)..

test-file starts below:

static boolean Ctester_FoobarenFOO_Ack(LL_Data_Ind_t *FoobarenFOO_Ack_p,
  FoobarenFOO_AckAddr_t
*FoobarenFOO_AckAddr_p)
{
 uint8 *Data_p = &(FoobarenFOO_Ack_p->Data[BARFOO_BAR_HEADER_SIZE]);
 uint8 FoobarenFOO_AckAddrIEI[] = {USER_DATA_IP_ADDRESS_IEI,
   UDP_PORT_IEI,
   GA_FOO_CAUSE_IEI};
 uint8 i;
 uint8 Index = 0;
 uint8 NoOf_IE = sizeof (FoobarenFOO_AckAddrIEI);

 for (i = 0; i < NoOf_IE; i++)
 {
   if (Data_p[Index] == FoobarenFOO_AckAddrIEI[i])
   {
 FoobarenFOO_AckAddr_p->Addr[i] = &Data_p[Index];
 Index += Data_p[Index + sizeof(uint8)] + sizeof(uint8) + sizeof(uint8);
   }
   else
   {
 FoobarenFOO_AckAddr_p->Addr[i] = NIL;
   }
 }

 return TRUE; //Always accept so far.
}


static boolean Ctester_DefoobarenFOO_Req(LL_Data_Ind_t *FOO_Data_p,
DefoobarenFOO_ReqAddr_t
*DefoobarenFOO_ReqAddr_p)
{
}


static boolean Ctester_FOO_Data(LL_Data_Ind_t *FOO_Data_p,
   FOO_DataAddr_t *FOO_DataAddr_p)
{
}
testfile ends above

On 4/24/07, Richard Stallman <[EMAIL PROTECTED]> wrote:

Quite often, but not always, cc-mode does not fontify the "head" of a
function definition correctly.

static uint8 CheckIE_ActivateUTC_Req(LL_Data_Ind_t *ActivateUTC_Req_p,
 ActivateUTC_ReqAddr_t
*ActivateUTC_ReqAddr_p)
{
...
}

With that formatting I am not surprised it fails,  Try writing it like this:

static uint8
CheckIE_ActivateUTC_Req(LL_Data_Ind_t *ActivateUTC_Req_p,
ActivateUTC_ReqAddr_t, *ActivateUTC_ReqAddr_p)
{
...
}




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

Re: GTK build: some menus in the menu bar stay highlighted

[Jan Djärv]

Stephen Berman skrev:

On Mon, 23 Apr 2007 22:09:36 +0200 Jan Djärv <[EMAIL PROTECTED]> wrote:


When Emacs updates the menu bar, it usually just puts empty menus
behind the menu bar entries.  This is to avoid updating the whole menu
tree every time we just change buffer.  When we click on the menu bar,
Emacs does update the whole menu tree (i.e. updates deep).

It seems that QtCurve can not handle non-deep menu bar entries.  

[...]

I'd say this is a bug in QtCurve.  I can not find a way to undo that
effect from within Emacs.  Apart from the obvious, always update menus
deep.  But I don't think we want to do that just for one theme.  Not
that I think it would break anything, it would just make menu bar
updating a bit slower.


Your analysis seems plausible to me, and I agree Emacs shouldn't be
changed to accommodate QtCurve.  Do you know if the Emacs treatment of
updating the menu bar is more or less unique to Emacs?  I haven't
observed "sticky highlighting" with QtCurve with any other Gtk+ apps
under KDE (e.g., Gimp, Eclipse).  If it is standard procedure in Gtk+
to always do deep updating of the menu bar, then that could account
for the asymmetry (and also for why QtCurve fails to handle the Emacs
case).


We could for the Gtk+ case add one dummy entry, or perhaps the real tear-off 
entry will do.  I'll try that when I come back to the machine where QtCurve is 
installed.


Emacs treatment is quite unique.  Most applications have (mostly) static menu 
trees that just get initialized once.


Jan D.


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

Re: C- doesn't respect current keyboard layout, OS X Carbon

[Aidan Kehoe]

 Ar an ceathrú lá is fiche de mí Aibréan, scríobh YAMAMOTO Mitsuharu: 

 > > On Mon, 23 Apr 2007 21:24:10 +0200, Aidan Kehoe
 > > <[EMAIL PROTECTED]> said:
 > 
 > > Interestingly, it seems to be a difference between custom layouts
 > > and the layouts that shipped with the system. If I switch to the
 > > British or US layout, the problem goes away; that is, the control
 > > key behaves as expected, given the selected key layout.
 > 
 > So, is your Irish layout different from what is bundled with Mac OS X?
 > Could you precisely explain what "I've installed a variant of the OS X
 > Irish layout (which is itself a variant of the British layout)" in the
 > original message means?

http://www.parhasard.net/keyboard/ExtendedAidan.layout is a variant of the
Irish layout, created as described here:
http://developer.apple.com/technotes/tn2002/tn2056.html .

I copied to that file to /Library/Keyboard Layouts , as Apple documents to
be a legitimate way to install such a layout. I then logged out, logged in
again, selected that layout in System Preferences -> International(?) (I’m
not certain it’s called that in English, but something similar), leaving the
British layout also available in the list, since it didn’t allow me to have
the custom layout on its own (for some unknown reason). 

-- 
On the quay of the little Black Sea port, where the rescued pair came once
more into contact with civilization, Dobrinton was bitten by a dog which was
assumed to be mad, though it may only have been indiscriminating. (Saki)


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