April 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: [BUG] in minibuffer history ? 27 years

Greg Klanderman

see: (defcustom minibuffer-history-minimum-string-length 3 "*If this variable is non-nil, a string will not be added to the minibuffer history if its length is less than that value." :type '(choice (const :tag "Any" nil) integer) :group 'minibuffer) >>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> sb> Didier Verna <verna(a)inf.enst.fr> writes: >> xemacs -vanilla & >> M-x make-frame-on-display <:0> >> M-x make-frame-on-display <press Up> sb> >> I get "No preceding item in minibuffer history " sb> sb> Problem reproduced. sb> >> This doesn't occur if I give ":0.0" instead of ":0" sb> >> ?? sb> sb> ?? sb>

1 participants
0 comments

Re: cvs in xemacs question 27 years

Greg Klanderman

(setq vc-handle-cvs nil) maybe this should be the default greg >>>>> "Andy" == Andy Piper <andyp(a)parallax.co.uk> writes: Andy> Andy> When I edit XEmacs source files in Xemacs they are shown read-only - Andy> presumably because the repository is read-only. How do I switch this off? Andy> (Note C-c C-q is not what I want) Andy> Andy> andy Andy>

2 participants
2 comments

Re: Lstreams, coding and md5 (was: Re: [PATCH] menubar selection in mswindows) 27 years

Kirill M. Katsnelson

Some time ago, Hrvoje Niksic wrote... |+ | For the record: I *do* note that md5 checksums are useful for things | other than the internal buffer representation. But I don't think that | `md5' *function* should have that additional CODING-SYSTEM argument. | Couldn't it pick the coding system from a generally useful variable, | like coding-system-for-write? Am I making any sense? Buffer-local variable buffer-file-coding-system contains coding system for the current buffer. Kirill

1 participants
0 comments

Re: cvs in xemacs question 27 years

Oscar Figueiredo

>>>>> "Andy" == Andy Piper <andyp(a)parallax.co.uk> writes: Andy> At 01:20 PM 4/28/98 -0400, Greg Klanderman wrote: >> (setq vc-handle-cvs nil) >> >> maybe this should be the default >> greg Andy> Well, in theory I still wanted cvs support - so I could do diffs and Andy> the like, it was more the read-only file that I didn't want. IMHO its a Andy> bit presumptuous for cvs to make the file read-only based on the fact Andy> that you can't change the backend. I believe this is almost never what Andy> you want. This does not happen to me (with and without -q). Check the actual permissions on the files in your working directory and try running xemacs -q, you may have some setting that's wrong. Oscar

1 participants
0 comments

Re: device-type: #<EMACS BUG: ILLEGAL DATATYPE 27 years

Hrvoje Niksic

Didier Verna <verna(a)inf.enst.fr> writes: > * gdb xemacs > * break Fmake_device > * run -vanilla > > Breakpoint 1, Fmake_device (type=-268435457, connection=-1606340604, > props=-1606340604) at device.c:504 > > * call debug_print (type) > > #<EMACS BUG: ILLEGAL DATATYPE (#o 7) Save your buffers immediately and please > report this bug> > > What's going on ? Martin, any idea ? Use the `up' debugger command and try to locate the corruption. If your process is dead, you can still use `pobj' to gain useful information about the object. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- "Listen, kid, we're all in it together!" -- Harry Tuttle in _Brazil_

1 participants
0 comments

Re: [PATCH] compilation buffer lossage 27 years

Hrvoje Niksic

Didier Verna <verna(a)inf.enst.fr> writes: > Interesting. A friend of mine just reported this symptoms > yesterday. I found that it may have something to do with the locale > (he usually uses a french environment whereas I stay to > "C"). Calling (setenv LANG "C") fixed his problem. Hrovje, are you > using a particular locale environement ? No, I use the "C" locale. And the patch I mailed actually fixes the problem. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- What is mind? No matter. What is matter? Never mind.

1 participants
0 comments

Re: select-window focus problem [was: Re: minor compile.el bug] 27 years

Hrvoje Niksic

greg(a)alphatech.com (Greg Klanderman) writes: > Are we agreed that with f-f-m true, C-x 5 o (other-frame) is the > *only* command which should warp focus. Yes. But this is still a major behavioral change which you should document. For instance, it may be worth noting (in the manual) that if you want `select-frame' to actually select the WM frame, you must bind focus-follows-mouse to nil. Other than the `C-x 5 o' problem, I must once again state that your patch does The Right Thing. For instance, (progn (select-frame (other-frame)) (insert "foo")) inserts "foo" in the other buffer's frame, which is correct, and then reselects this frame for focus. Kudos to you. :-) > Is it ever called non-interactively? (eg, should it check and only > actually change focus when run interactively?) Good question. I think it should always and definitely change focus, as per documentation: C-x 5 o runs `other-frame' Documentation: Select the ARG'th different visible frame, and raise it. All frames are arranged in a cyclic order. This command selects the frame ARG steps away in that order. A negative ARG moves in the opposite order. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- * Q: What is an experienced Emacs user? * A: A person who wishes that the terminal had pedals.

1 participants
0 comments

Re: b37 FAIL 27 years

Hrvoje Niksic

Georg Nikodym <georgn(a)canada.sun.com> writes: > (verve) 1291$ dbx src/xemacs core > ... > program terminated by signal SEGV (no mapping at the fault address) > Current function is print_internal > 1203 (obj, printcharfun, escapeflag)); > (dbx) where > [1] 0x4b8(0xffbed528, 0xffbed524, 0x1, 0xffbed69c, 0x4, 0x4), at 0x4b7 > =>[2] print_internal(obj = UNION, printcharfun = UNION, escapeflag = 1), line 1203 in "print.c" > [3] print_cons(obj = UNION, printcharfun = UNION, escapeflag = 1), line 904 in "print.c" > [4] print_internal(obj = UNION, printcharfun = UNION, escapeflag = 1), line 1203 in "print.c" > [5] Fprin1(object = UNION, stream = UNION), line 502 in "print.c" > [6] Fbacktrace(stream = UNION, detailed = UNION), line 4927 in "eval.c" > [7] fatal_error_signal(sig = 11), line 243 in "emacs.c" > ---- called from signal handler with signal 11 (SIGSEGV) ------ > [8] 0x4b8(), at 0x4b7 > [9] Fprin1(object = UNION, stream = UNION), line 502 in "print.c" > [10] print_error_message(error_object = UNION, stream = UNION), line 669 in "print.c" > [11] Fdisplay_error(error_object = UNION, stream = UNION), line 700 in "print.c" > [12] funcall_recording_as(recorded_as = UNION, nargs = 2, args = 0xffbee4b8), line 3197 in "eval.c" > [13] Ffuncall(nargs = 3, args = 0xffbee4b8), line 3238 in "eval.c" > [14] Fbyte_code(bytestr = UNION, vector = UNION, maxdepth = UNION), line 416 in "bytecode.c" > [15] funcall_lambda(fun = UNION, nargs = 1, arg_vector = 0xffbee8bc), line 3599 in "eval.c" > [16] funcall_recording_as(recorded_as = UNION, nargs = 1, args = 0xffbee8b8), line 3200 in "eval.c" > [17] Ffuncall(nargs = 2, args = 0xffbee8b8), line 3238 in "eval.c" > [18] call1(fn = UNION, arg0 = UNION), line 3912 in "eval.c" > [19] cmd_error(data = UNION, dummy = UNION), line 195 in "cmdloop.c" > [20] condition_case_1(handlers = UNION, bfun = 0x1388c0 = &Feval(Lisp_Object form), barg = UNION, hfun = 0xd1198 = &`xemacs`cmdloop.c`cmd_error(Lisp_Object data, Lisp_Object dummy), harg = UNION), line 1636 in "eval.c" > [21] top_level_1(dummy = UNION), line 206 in "cmdloop.c" > [22] internal_catch(tag = UNION, func = 0xd12b8 = &`xemacs`cmdloop.c`top_level_1(Lisp_Object dummy), arg = UNION, threw = (nil)), line 1328 in "eval.c" > [23] initial_command_loop(load_me = UNION), line 285 in "cmdloop.c" This C backtrace is interesting. Something gets corrupted somewhere, XEmacs wants to exit and print the backtrace, but it gets hosed printing the backtrace. Could you please use `pobj' from your debugger of choice to see which object gets corrupted. It may help debugging the program... -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Jone's law: The man who smiles when things go wrong has thought of someone to blame it on.

1 participants
0 comments

[PATCH] better msw selection support 27 years

Andy Piper

I've generalised the selection support a lot more so that enabling and disabling of the menu items works amongst other things. msw selection now more closely emulates x selection (from an XEmacs perspective). andy 1998-04-29 Andy Piper <andyp(a)parallax.co.uk> * mouse.el: move x-selection-owner-p type things to selection-owner-p. * msw-init.el: copy zmacs stuff from x-init.el * msw-select.el (mswindows-own-selection) (mswindows-disown-selection) (mswindows-selection-owner-p): new functions. Very simple minded implementation of selectio ownership. * select.el (own-selection) (disown-selection) (activate-region-as-selection) (select-make-extent-for-selection) (valid-simple-selection-p): functions moved from x-select.el for generalized selection. * x-select.el: see select.el changes. * x-toolbar.el: use new selection functions.

1 participants
0 comments

Re: [BUG] in minibuffer history ? 27 years

SL Baur

Didier Verna <verna(a)inf.enst.fr> writes: > xemacs -vanilla & > M-x make-frame-on-display <:0> > M-x make-frame-on-display <press Up> > I get "No preceding item in minibuffer history " Problem reproduced. > This doesn't occur if I give ":0.0" instead of ":0" > ?? ??

1 participants
0 comments

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta April 1998