> From: "Drew Adams" <[EMAIL PROTECTED]>
> Date: Sat, 15 Jul 2006 09:00:58 -0700
>
> I did try it, with both nil and t as values of focus-follows-mouse,
> and I don't see _any_ change in behavior whatsoever.
>
> You're right. I didn't test it with different values of the option.
Thanks,
> The change in Emacs-22 is that the diff can be done locally
> (with `diff') rather than via `cvs'. If you remove the file
> .~.~, then it'll force VC to ask `cvs' to do the
> diff and you'll get a header just like the one we get with -L
> (this use of -L is specifically to reproduce the head
"Mathias Dahl" <[EMAIL PROTECTED]> writes:
>> No, I meant only for the test case you gave.
>> As before tumme doesn't display the *tumme* buffer.
>
> Okay.
updated today from cvs, made maintainer clean, bootstrapped (don't know
whether it's necessary though after `make maintainer-clean') and it's
Dieter Wilhelm <[EMAIL PROTECTED]> writes:
> emacs -Q -D
> M-x tumme [some dir]
>
> tumme doesn't show the *tumme* buffer, just the dired buffer. Below
> is the *Message* buffer content after the tumme call
>
> Loading tumme...
> Loading regexp-opt...done
> Loading tumme...done
> Loading image-fil
Mathias Dahl <[EMAIL PROTECTED]> writes:
I have tried to debug this without any luck. My current theory is that
for some reason the last `forward-char' is called when point is at the
end of the buffer. See if the following change in `tumme-line-up'
fixes the problem for you:
*** 20,26
> Then if I try pressing C-. I get the error: "C-. is undefined". This
> happens when using emacs from CVS updated a few minutes ago.
Seems completely normal: C-. is also unbound here under X11.
> The same thing works fine when using emacs-21.4
C-. is also unbound in my copy of Emacs-21.4.
What
Thanks, I documented that this variable has no effect on Windows.
Thx.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Stefan Monnier <[EMAIL PROTECTED]> writes:
> > Then if I try pressing C-. I get the error: "C-. is undefined". This
> > happens when using emacs from CVS updated a few minutes ago.
>
> Seems completely normal: C-. is also unbound here under X11.
The recipe I gave tried to bind it to `ind
Any news on this bug?
-Original Message-
From: Drew Adams [mailto:[EMAIL PROTECTED]
Sent: Sunday, June 25, 2006 9:08 AM
To: Emacs-Pretest-Bug
Subject: tooltip-mode disabled prevents messages in minibuffer
Evaluate this:
(require 'easymenu)
(defvar my-me
any news on this bug?
-Original Message-
From: Drew Adams [mailto:[EMAIL PROTECTED]
Sent: Sunday, July 09, 2006 6:16 PM
To: Emacs-Pretest-Bug
Subject: quitting ediff with pop-up-frames non-nil gives wrong-type arg
error
emacs -q
M-x set-variable
> I am using xterm-215 that emits escape sequences for some key
> combinations that did not emit any special sequence.
> For example C-. emits "\e[27;5;46~"
> Now if I do:
> emacs -q -nw
> M-: (define-key function-key-map "\e[27;5;46~" [(control ?\.)]) RET
> M-x global-set-key RET C-. RET indent
> The anomaly here is in the original error. I am not sure
> whether that error ought to be possible at all.
>
> How about if you run with a breakpoint at the line in
> intervals.c which gets that error? When you get there, look
> at the value of POS.
> Then examine the existing buffer proper
> Date: Mon, 17 Jul 2006 21:45:05 +0200
> From: Lennart Borgman <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED], [EMAIL PROTECTED], emacs-pretest-bug@gnu.org
>
> Eli Zaretskii wrote:
> >
> >> Could something has changed in the arithmetics on w32?
> >>
> >
> > Only if the two versions were c
Stefan Monnier <[EMAIL PROTECTED]> writes:
> > I am using xterm-215 that emits escape sequences for some key
> > combinations that did not emit any special sequence.
>
> > For example C-. emits "\e[27;5;46~"
>
> > Now if I do:
>
> > emacs -q -nw
> > M-: (define-key function-ke
> Date: Fri, 21 Jul 2006 19:59:58 +0300
> From: Eli Zaretskii <[EMAIL PROTECTED]>
> Cc: emacs-pretest-bug@gnu.org, [EMAIL PROTECTED]
>
> So the question is not why 21.3 succeeded whereas 22.0 fails, but
> rather how come the results returned by Emacs are one second off. I
> will try to look into
Stefan Monnier wrote:
> Well, I believe the one I just installed does fix it, this time.
It fixes the previously posted example, but now this snippet is messed
up:
#!/bin/bash
gbytes=`echo "$bytes_total" | gawk '{printf("%5.1f"), $1 / (1024^3)}'`
echo "The time is now `date`"
__
Index: delphi.el
===
RCS file: /sources/emacs/emacs/lisp/progmodes/delphi.el,v
retrieving revision 3.22
diff -w -u -b -u -r3.22 delphi.el
--- delphi.el 10 Feb 2006 09:00:30 - 3.22
+++ delphi.el 21 Jul 2006 17:44:56 -
@
> (dbx) frame 1
> Current function is update_interval
> (dbx) print pos
> pos = 30065
> (dbx) print i
> i = 0xb46710
> (dbx) print *i
> *i = {
> total_length = 357181U
> position = 144991U
> (*i).left = 0x110ba4c
> (*i).right= 0x1113f10
> up= {
>
> I wasn't aware that [(control ?\.)] was XEmacs syntax, I just copied
> it from flyspell.el ...
You could lobby to change define-key so it accepts this syntax for the
third argument as well. I think it'd make sense. IIRC the third argument
can only ever contain things like functions and key seq
>> Well, I believe the one I just installed does fix it, this time.
> It fixes the previously posted example, but now this snippet is messed up:
> #!/bin/bash
> gbytes=`echo "$bytes_total" | gawk '{printf("%5.1f"), $1 / (1024^3)}'`
> echo "The time is now `date`"
This was messed up already a mo
Stefan Monnier wrote:
> This was messed up already a month ago, right? I.e. it's not related
> to my recent changes?
Oh, could be. I just got back from vacation, so my previous version of
the CVS was a few weeks old. I'll check and see when this stopped
working...
_
* Ralf Angeli (2006-07-20) writes:
> * Drew Adams (2006-07-19) writes:
>
>> This problem occurs even for emacs -Q: the initial frame is about 5cm from
>> the left edge and about 6cm from the top edge of the display. Before, it was
>> flush with both top and left display edges.
>
> Frame positionin
> (define-key map "\e[27;5;9~" [?\C-\t])
[etc.]
Shouldn't this be [C-tab]?
(eq ?\C-\t ?\C-\C-i) => t
--
Johan Bockgård
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Ralf Angeli <[EMAIL PROTECTED]> writes:
> + left = w32_get_arg (Qnil, Qleft, "left", "Left", RES_TYPE_NUMBER);
> + if (!EQ (left, Qunbound))
> +CHECK_NUMBER (left);
> One gripe I have with it is that the CHECK_NUMBER macro does not seem
> to work. If I use a string for the `top' or `left'
Bug squashed, I think. The patch is below (I already committed it to
CVS); please see if this solves the problem.
It solves the problem for me, thanks Eli.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/li
This doesn't happen on Linux.
It is most likely a problem with the Windows port of Emacs.
Can somebody who is maintaining Emacs on Windows check this?
> From: "Drew Adams" <[EMAIL PROTECTED]>
> To: "Emacs-Pretest-Bug"
> Date: Fri, 21 Jul 2006 07:23:16 -0700
> MIME-Version: 1.0
> Content-Type: t
26 matches
Mail list logo
