On 3 May 2005, at 10:24, Kim F. Storm wrote:
OK, we're still not completely done - because cua-mode breaks things
again.
Does this patch give good results?
No it doesn't, because clipboard-yank takes no arguments, yet you pass
it 'arg'.
+((eq this-original-command 'clipboard-yank)
+
David Reitter <[EMAIL PROTECTED]> writes:
> On 29 Apr 2005, at 08:40, YAMAMOTO Mitsuharu wrote:
>
>> Is (setq x-select-enable-clipboard nil) what you want? I tried to use
>> with this setting for a while and noticed that the patch below may be
>> needed.
>
> OK, we're still not completely done -
David Reitter <[EMAIL PROTECTED]> writes:
> Wouldn't it be a better solution to make sure clipboard-kill-ring-save
> and clipboard-yank respect cua-mode?
Well, cua-mode is optional, so it must try to respect clipboard- commands,
not the other way round.
Can you try this patch:
*** cua-base.el 0
became:
TERM = xterm
Breakpoint 1 at 0x811e0a6: file emacs.c, line 460.
Function "x_error_quitter" not defined.
The function still exists in the source. Can you investigate
why it does not exist in your binary? I can only guess
it was inlined and optimized out of existence. But
Richard Stallman <[EMAIL PROTECTED]> writes:
> became:
>
> TERM = xterm
> Breakpoint 1 at 0x811e0a6: file emacs.c, line 460.
> Function "x_error_quitter" not defined.
>
> The function still exists in the source. Can you investigate
> why it does not exist in your binary? I can on
I'm not sure if this is related to the thread below, but, in GNU Emacs
21.3.50.1 (i386-mingw-nt5.1.2600) of 2005-01-30 on NONIQPC, the positioning
of a frame with `top' parameter = -14 places the frame about 4
character-heights too low on the display. Instead of the bottom of the frame
being 14 pix
Hi Tim, Hi Nick, Hi Emacs, Hi Martin!
On Fri, 29 Apr 2005, Tim Van Holder wrote:
>As of a few days ago, the cc-mode in cvs emacs seems to preprocess the
>source file in order to determine the C macros present.
Please Note: `c-macro-expand', despite its name, is _NOT_ part of CC
Mode. Its name p
$B&#&#&#&#&#&#&#&#&#&#&#&#&#&#&#&#&#&#&#&#&#&#&#(B
$B&#?7CeN">pJs8x3+!*!!%4!<%k%G%s%&%$!<%/FMF~9f(B $B!!&#(B
$B&#&#&#&#&#&#&#&#&#&#&#&#&#&#&#&#&#&#&#&#&#&#&#(B
$B!!$D$$$K%4!<%k%G%s%&%#!<%/$KFMF~$7$F$7$^$$$^$7$?$,!"(B
$B$$$C$7$g$K2a$4$9Aj%a
Hi,
Although it might be an unrecommended operation, the following
line in my ~/.emacs file crashes Emacs.
(setq cursor-in-non-selected-windows t)
Here is a backtrace:
#0 0xe002 in ?? ()
#1 0x080f69f8 in buffer_slot_type_mismatch (offset=6) at buffer.c:4361
#2 0x08125e2c in store_symval_
Alan Mackenzie writes:
> >As of a few days ago, the cc-mode in cvs emacs seems to preprocess the
> >source file in order to determine the C macros present.
Actually to generate a list of #define directives.
> Please Note: `c-macro-expand', despite its name, is _NOT_ part of CC
> Mode. Its na
Richard Stallman wrote:
I installed a change I think ought to fix your problem.
Okay, I give... what was the fix?
-Dave
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Sorry for the long delay about this. This was my bad - there is no bug.
I was mistakenly loading a previous, local version of printing.el into the
newer version of Emacs.
Thanks,
Drew
-Original Message-
From: Drew Adams [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 02
emacs -q
M-x goto-char RET 1 RET
C-p
an error occurs: Args out of range: 0, 0
The backtrace is:
Debugger entered--Lisp error: (args-out-of-range 0 0)
get-char-property(0 invisible)
line-move-invisible-p(0)
line-move-1(-1 nil nil)
line-move(-1 nil nil 1)
byte-code(" $" [arg try-vscrol
> Stuff like mouse-extend mainly. But I noticed that it's enough to just
> (require 'mouse-sel), but not activate the mode - so that's what I'm doing
> now. That's obviously a workaround, not a fix...
If doing nothing more than (require 'mouse-sel) already modifies the
behavior of Emacs, it's a bu
> If you do something like
> M-x cvs-examine RET /home/tmp/emacs RET
> go on one line, then use
> C-u C
> to get a Log edit buffer, then do a kill-buffer of the original *cvs*
> buffer, switch to some arbitrary buffer and do
> M-x cvs-examine RET /home/tmp/emacs RET
> again, then the *cvs-commit* b
> The function still exists in the source. Can you investigate
> why it does not exist in your binary? I can only guess
> it was inlined and optimized out of existence. But that's
> supposed to be prevented by NO_INLINE which should expand to
> __attribute__((noinline)).
Richard Stallman <[EMAIL PROTECTED]> writes:
> > The function still exists in the source. Can you investigate
> > why it does not exist in your binary? I can only guess
> > it was inlined and optimized out of existence. But that's
> > supposed to be prevented by NO_INLINE which
> "David" == David Kastrup <[EMAIL PROTECTED]> writes:
> This bug report will be sent to the Free Software Foundation,
> not to your local site managers!
> Please write in English if possible, because the Emacs maintainers
> usually do not have translators to read other languages for them.
>
Symptoms:
create a file named "foo.cpp" with this content (excluding the dashed lines, of
course):
foo()
{
if(x)
{
y();
}
}
Start emacs: "emacs -Q foo.cpp"
Enable selective-display: C-u C-x $
Move
Richard Stallman <[EMAIL PROTECTED]> writes:
> 'backtrace_list' appears to only contain two items, and it looks like
> the first one is semi-corrupted also.
>
> It does look that way. The innermost element of backtrace_list should
> have been made by the innermost Lisp-level function call
Stefan Monnier <[EMAIL PROTECTED]> writes:
>> "David" == David Kastrup <[EMAIL PROTECTED]> writes:
>
> Ahh... I think I finally got it. Does the patch below fix the problem?
> I believe it should. The only problem is that I can't figure out what this
> code was supposed to do, so it may brea
[Apologies if this appears more than once]
Symptoms:
create a file named "foo.cpp" with this content (excluding the dashed lines, of
course):
foo()
{
if(x)
{
y();
}
}
Start emacs: "emacs -Q foo.cpp"
Periodically (once every week or so), when going to get new mail with
VM, Emacs will crash on me. I've now started running it under gdb,
here is the latest backtrace. It rarely seems to happen outside VM,
but seems to be to with Emacs internals.
Stephen
#0 0x42028811 in kill () from /lib/i
> Date: Tue, 3 May 2005 21:00:50 + (GMT)
> From: Alan Mackenzie <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org, emacs-devel@gnu.org
>
> `c-macro-expand' actually lives in the file
> .../list/progmodes/cmacexp.el. This file was last updated 3 years 8
> months ago by Eli
Okay, I give... what was the fix?
Why ask me to spend time explaining?
Get the latest sources and see what has changed.
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Katsumi Yamaoka <[EMAIL PROTECTED]> writes:
> Hi,
>
> Although it might be an unrecommended operation, the following
> line in my ~/.emacs file crashes Emacs.
>
> (setq cursor-in-non-selected-windows t)
Thanks. I have installed changes to fix this.
--
Kim F. Storm <[EMAIL PROTECTED]> http://ww
Problem:
(define-minor-mode bar "" nil "[OE]" nil)
(documentation-property 'bar 'variable-documentation)
=>
"Non-nil if Bar m[OE]d[OE] is enabled.
Use the command `bar' to change this variable."
Fix:
--- easy-mmode.el 26 Apr 2005 19:12:23 +0200 1.59
+++ easy-mmode.el 04 May
Timmy Douglas wrote:
I was just reading a newsgroup earlier today and when I went to the
next message:
Program received signal SIGPIPE, Broken pipe.
0xb772cca7 in *__GI___sigsuspend (set=0x8329ce0) at sigsuspend.c:69
69 sigsuspend.c: No such file or directory.
in sigsuspend.c
(gdb) bt
28 matches
Mail list logo
