January 1999 - XEmacs-Beta - XEmacs Mailing List Archives

End of stream: #<buffer "*scratch*"> 25 years, 10 months

David Maslen

Perhaps someone can give me a hints as to tracking down this weirdness with xemacs21.0-b62, under debian linux. I have the same binary running on my desktop, without error. However; On my laptop if I run 'xemacs -nw' as any user other than root, then pressing c-z puts xemacs into the background, giving access to the shell. It looks a little different as the prompt doesn't appear at the bottom of the screen, but pretty much where the prompt was under xemacs. When I type fg to return to xemacs, it does, but no longer interprupts key strokes, c-l shows up as ^L for example. Also in the message box at the bottom of the screen xemacs prints, End of stream: #<buffer"*scratch*"> I don't really think this is an xemacs problem, but I thought I'd ask here as there are bound to be quite a few folks run xemacs under linux, and perhaps someone has seen this strange behaviour. My laptop is a 486, so all this is done in a shell. -- Binary Bar - Australia's first free access internet bar/cafe/gallery. 243 Brunswick Street, Fitzroy, Melbourne, Australia. 3pm - 1am http://www.binary.net.au/ Running on Debian/GNU Linux

2 participants
1 comments

Re: Building a Binary Distribution 25 years, 10 months

David Maslen

Colin Rafferty <craffert(a)ms.com> writes: > So if you mount laptop:/usr/local onto localhost:/mnt/local, you could > use the configure option: --prefix=/mnt/local. > Then just `make install. I found the easiest way was to type 'make install prefix=/tmp/xemacs' The enter /tmp/xemacs and make a tar files, to later be unpacked in /usr/local on the other machine. Given that I'm having this problem with c-z as any user other than root (please see my other posting), is it possible this approach has failed me somehow? -- Binary Bar - Australia's first free access internet bar/cafe/gallery. 243 Brunswick Street, Fitzroy, Melbourne, Australia. 3pm - 1am http://www.binary.net.au/ Running on Debian/GNU Linux

1 participants
0 comments

RunEmacs - "Could not start XEmacs or gnuclient" 25 years, 10 months

Oelke, Dan

I installed the *wonderful* binary installation of XEmacs on NT4(SP3), but have one nagging problem - when I use runemacs (which is what the default shortcuts are set to), I get the error message "Could not start XEmacs or gnuclient" I put in some extra code and compiled runemacs using cygwin-20 and found that it was the CreateProcess call that wasn't working correctly. Looking at the new_cmdline value, it looks right. Unfortunately I don't know enough about the start or sec_attr or child variables to know what to look for there. Any ideas??? Thanks, Dan ----------------------------------------------------- Dan Oelke doelke(a)opticalsolutions.com Optical Solutions, Inc. 612-249-3382

2 participants
1 comments

Re: XCAR/XCDR as lvalues 25 years, 10 months

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Yes [I'll reread again to be sure]. You mean > > #define XSETCAR(conscell, newcar) do { > CHECK_IMPURE (conscell); > XCAR (conscell) = newcar; > } while (0) Yes. > int > purified (Lisp_Object obj) > { > return POINTER_TYPE_P (XGCTYPE (obj)) && PURIFIED (XPNTR (obj)); > } I'll trivially recode this as a macro. > i.e. you might have eliminated the call to Fsetcar, but there is still > a function call involved. Note that the 'PURIFIED' macro ALSO involves > a function call. However that one will be hopefully be inlined when > compiled at -O3 It won't, because the function definition is in another file. However, I can recode that as a macro too. > So I think if you want to go that way, you should at the very least > eliminate the function calls from all those macros. Also the > POINTER_TYPE_P (XGCTYPE (obj) check is completely unneeded in > XSETCAR. Yup. I might make a CHECK_IMPURE_UNSAFE macro or something; I'll think about it. Thanks for the tips.

1 participants
0 comments

Re: XEmacs 21.0: Scrolling with Continuation Lines 25 years, 10 months

Christoph Wedler

>>>>>"AB" == Alastair Burt <burt(a)dfki.de> writes: AB> When I set truncate-lines to nil and scroll through a buffer I AB> sometimes find that the text disappears off the left hand side of AB> the screen. This is a bug, I think, rather than a feature, because AB> with the continuation lines in effect there is no need to do this; AB> the text would be visible, and editable, without this automatic AB> scrolling. At least, the behaviour does not match the docstring of `auto-show-mode'. *Help*> It takes effect only when `truncate-lines' is non-nil. My most important line in my ~/.emacs is (setq-default auto-show-mode nil) - Christoph

1 participants
0 comments

XEmacs 21.0: Scrolling with Continuation Lines 25 years, 10 months

Alastair Burt

When I set truncate-lines to nil and scroll through a buffer I sometimes find that the text disappears off the left hand side of the screen. This is a bug, I think, rather than a feature, because with the continuation lines in effect there is no need to do this; the text would be visible, and editable, without this automatic scrolling. --- Alastair

1 participants
0 comments

Re: XCAR/XCDR as lvalues 25 years, 10 months

Jan Vroonhof

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > #define XSETCAR(conscell, newcar) do { > CHECK_IMPURE (conscell); Which reminds me? Does anybody have real hard numbers as to how big an improvement the Fsetcar brings? Jan

1 participants
0 comments

Re: XCAR/XCDR as lvalues 25 years, 10 months

Jan Vroonhof

Hrvoje Niksic <hniksic(a)srce.hr> writes: > Fault handling stuff? That was half a joke. Again, have you read my > original message? Yes [I'll reread again to be sure]. You mean #define XSETCAR(conscell, newcar) do { CHECK_IMPURE (conscell); XCAR (conscell) = newcar; } while (0) However #define CHECK_IMPURE(obj) \ do { if (purified (obj)) pure_write_error (obj); } while (0) And int purified (Lisp_Object obj) { return POINTER_TYPE_P (XGCTYPE (obj)) && PURIFIED (XPNTR (obj)); } i.e. you might have eliminated the call to Fsetcar, but there is still a function call involved. Note that the 'PURIFIED' macro ALSO involves a function call. However that one will be hopefully be inlined when compiled at -O3 (the default level for gcc is still -O2 isn't it?) So I think if you want to go that way, you should at the very least eliminate the function calls from all those macros. Also the POINTER_TYPE_P (XGCTYPE (obj) check is completely unneeded in XSETCAR. Jan

1 participants
0 comments

Re: Beware of modules. 25 years, 10 months

SL Baur

>> >It was the Lisp directories that I wanted >consolidated, for >> speed. But that looks completely out of the >question now, so >> forget it. They still can be. It will require a little bit of fiddling and a run of XEmacs to regenerate the autoloads file, but it can be done. >> >> Why? I still think this is a worthy goal. > Packages. The package bundles create their subdir in the > packages directory. The auto-autoloads filenames will collide > without the subdirectories. If you just untar them in, yes. However, I think it's still doable to put all lisp into a single massive directory with some fiddling at the front end.

1 participants
0 comments

Re: XCAR/XCDR as lvalues 25 years, 10 months

Hrvoje Niksic

Kyle Jones <kyle_jones(a)wonderworks.com> writes: > > Fault handling stuff? That was half a joke. (...) > > I like your proposal. The serious one (XSETCAR/XSETCDR macros), or the fault handling? The problem with the latter is that it's very non-portable. Yes, it would work, but it would require quite a bit of Autoconf work. I've prepared a patch for trapping stack overflows in a similar fashion, but I haven't submitted it yet due to its poor portability. > If we could do use mprotect() on the pure[] array on ELF and other > systems that can't dump to a read-only area, that would be even > better. That would be OK with me, yes.

2 participants
1 comments

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