September 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Patch for gnuclient handling DOS absolute paths 27 years

Raymond Toy

>>>>> "Jonathan" == Jonathan Harris <jhar(a)tardis.ed.ac.uk> writes: Jonathan> Note that this patch is reversed. Oops. Sorry. Jonathan> HAVE_MS_WINDOWS indicates support for the win32 GUI. You shuld be Jonathan> conditioning this stuff on __CYGWIN32__ and !WINDOWSNT I think because Jonathan> it's the wrong thing for the native mswindows build. Ok. I'll fix that. Jonathan> This seems wrong for the cygwin build for the reason that Darryl Okahata Jonathan> gives in xemacs-beta; converting c:\foo into /c/foo is no good, it Jonathan> should be converted to //c/foo. Also it looks like it treats \foo as a Jonathan> relative path? See my reply to Darryl. My mistake. Yes it does treat \foo as a relative path, and it is because you need the drive to fully specify the path, right? >> There is still one bug: I get a Windows error message saying some >> component of the path cannot be found. But xemacs loads up the file >> correctly anyway. Jonathan> I see that on the native build too. I think that it may be because Jonathan> gnulient and xemacs are console rather than GUI apps. I found one workaround for this: In the file association, turn off the DDE association. I don't do windows, so all of this has been quick guess work. Thanks for all of the suggestions. Ray

1 participants
0 comments

Re: [crash] redisplay after widening 27 years

Hrvoje Niksic

Gunnar Evermann <Gunnar.Evermann(a)nats.informatik.uni-hamburg.de> writes: > XEmacs 20.4 doesn't crash because a more complete update of the > frame is forced (SET_FRAME_CLEAR;) at the beginning of Frecenter > (which Hrvoje removed for 21.0). This isn't done in the > (Lisp-)recenter of 21.0. If I understand you correctly, the "quick fix" would be to add SET_FRAME_CLEAR to Fredisplay_frame, wouldn't it? > The right fix should in my opinion be done in widen_buffer (and > maybe plus some change in the redisplay code). Here we have to > either adjust the start-marker or make redisplay do that later on. If you could send out a patch, it would be great. Thanks for the analysis. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- If anything goes wrong, blame the random-number generator!

1 participants
0 comments

Re: [crash] redisplay after widening 27 years

Gunnar Evermann

SL Baur <steve(a)xemacs.org> writes: > Ditto for me, with Linux and Mule and pgcc 1.0.3 and 1.1. > > If somebody can fix it in the very near future, the fix will go into > 21.0, otherwise it won't. Ah, that's an interesting challenge! I had been looking for a reason to study redisplay anyway. I'm pretty sure what causes the problems but have not figured out a clean way to fix it, yet. I'll describe what I have found, maybe this helps some (if not or this was totally obvious to the redisplay gurus out there then just ignore this post): In the following discussion I use Collin's original procedure: - XEmacs -vanilla - move to the apostrophe in don't (pos=36) - C-Space M-> C-x nn - answer the novice-warning with y - C-x nw - now the display is wrong (if you want the crash type C-l) First of all the problem occurs in 20.4 as well, but doesn't produce a crash (see below). The real problem is redisplay's failure to display the buffer correctly after widening (I mean the 'implicit' redisplay not the one triggered by C-l). After narrowing the startp marker/variable points to position 36 (which is right) but after widening it still points at 36 although bufbegv now is 1. Now startp doesn't point at the right place (the beginning of the first line) anymore and only the second half of the line is displayed (probably the line start cache is also wrong at this point). XEmacs 20.4 doesn't crash because a more complete update of the frame is forced (SET_FRAME_CLEAR;) at the beginning of Frecenter (which Hrvoje removed for 21.0). This isn't done in the (Lisp-)recenter of 21.0. I haven't bothered checking how the crash actually happens -- if we can fix the first redisplay everything should be OK. The right fix should in my opinion be done in widen_buffer (and maybe plus some change in the redisplay code). Here we have to either adjust the start-marker or make redisplay do that later on. If I manually set the marker to 1 during the 'implicit' redisplay, everything works... Probably I'll look into this some more over the weekend, but if somebody sees the light already, go ahead send a patch. Have a nice weekend, everyone. Gunnar -- Gunnar Evermann Natural Language Systems Group, University of Hamburg EMail: Gunnar.Evermann(a)nats.informatik.uni-hamburg.de

1 participants
0 comments

Re: Patch for gnuclient handling DOS absolute paths 27 years

Jonathan Harris

Raymond Toy wrote: > > Here is a small patch to gnuclient to make it understand absolute DOS > pathnames that contain the drive letter. Without this patch, > gnuclient would just prepend the current directory to the path and > tell xemacs to load that. With this patch, gnuclient recognizes the > paths of the form "<drive>:\path" and converts it to "/<drive>/path". > (Perhaps this should be conditionalized on MS_WINDOWS and CYGWIN > instead of just MS_WINDOWS?) Note that this patch is reversed. HAVE_MS_WINDOWS indicates support for the win32 GUI. You shuld be conditioning this stuff on __CYGWIN32__ and !WINDOWSNT I think because it's the wrong thing for the native mswindows build. This seems wrong for the cygwin build for the reason that Darryl Okahata gives in xemacs-beta; converting c:\foo into /c/foo is no good, it should be converted to //c/foo. Also it looks like it treats \foo as a relative path? > This allows gnuclient to be associated with files so I can > double-click on them in explorer and have gnuclient load them instead > of yet another (slow) invocation of xemacs. Andy, doesn't filemanger association and drag'n'drop work for the cygwin build? > There is still one bug: I get a Windows error message saying some > component of the path cannot be found. But xemacs loads up the file > correctly anyway. I see that on the native build too. I think that it may be because gnulient and xemacs are console rather than GUI apps. Jonathan. -- Jonathan Harris | jhar(a)tardis.ed.ac.uk London, England | Jonathan.Harris(a)symbian.com

2 participants
1 comments

ralloc fix again 27 years

Andy Piper

This superceds my ral.patch 1998-09-02 Andy Piper <andyp(a)parallax.co.uk> * check_cygwin_setup.sh: fix a couple of buglets. 1998-09-02 Andy Piper <andyp(a)parallax.co.uk> * emacs.c (main_1): init_ralloc() if initialised and we have REL_ALLOC * ralloc.c: uncomment __morecore. --------------------------------------------------------------------------- " .sigs are like your face - rarely seen by you and uglier than you think" Dr Andy Piper, Technical Architect, Parallax Solutions Ltd mail: andyp(a)parallax.co.uk web: www.parallax.co.uk/~andyp

2 participants
2 comments

Re: strange regexp in postscript-mode 27 years

Karl M. Hegbloom

>>>>> "Gunnar" == Gunnar Evermann <Gunnar.Evermann(a)nats.informatik.uni-hamburg.de> writes: Gunnar> Please apply this patch to postscript.el The new regexp is Gunnar> still not perfect but definitely better (i.e. equivalent Gunnar> but faster). Gunnar> - '("(\\([^)]\\|\\\\.\\|\\\\\n\\)*)" Gunnar> + '("(\\([^)]*\\))" . font-lock-string-face) I don't think those are completely equivalent, though perhaps the second one will work fine... The first one matches anything that starts with a paren, and then things up to another paren including \. escapes and \ line continuations. The second expression doesn't handle escapes or line continues... but perhaps that's not really required anyhow. I've not learned much postscript yet. :-)

1 participants
0 comments

Re: Patch for gnuclient handling DOS absolute paths 27 years

Darryl Okahata

Raymond Toy <toy(a)rtp.ericsson.se> wrote: > Here is a small patch to gnuclient to make it understand absolute DOS > pathnames that contain the drive letter. Without this patch, > gnuclient would just prepend the current directory to the path and > tell xemacs to load that. With this patch, gnuclient recognizes the > paths of the form "<drive>:\path" and converts it to "/<drive>/path". Perhaps I'm being dense, but I don't see how this is going to work. While gnuclient does have problems with DOS absolute paths and path separators (this part of your patch is good), I don't see how changing (for example), "c:/foo" into "/c/foo" is going to work; with this, gnuclient is going to look for file "foo" in directory "/c" of the current drive, and not in "c:/". [ The cygwin gnuclient may need a similar change ("c:/" --> "//c/"), but note that cygwin needs TWO (2) leading slashes; one slash won't work. ] -- Darryl Okahata darrylo(a)sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day.

1 participants
0 comments

Re: [crash] redisplay after widening 27 years

SL Baur

Colin Rafferty <craffert(a)ms.com> writes in xemacs-beta(a)xemacs.org: ... > Anyway, this happens to me for my optimised and debugged version on > IRIX, and my optimised version at home on Linux. All of these were > non-Mule. > The IRIX versions were compiled with SGI's compiler, and Linux with > gcc 2.7.2. Ditto for me, with Linux and Mule and pgcc 1.0.3 and 1.1. If somebody can fix it in the very near future, the fix will go into 21.0, otherwise it won't. The fate of whether I can get an XEmacs 21 out this month will be determined tomorrow morning US/Pacific time, I'll pass on news as soon as I know.

1 participants
0 comments

Re: [Bug] 21.0 FL; EDiff quit (frame deletion) => X-Error 27 years

Christoph Wedler

>>>>>"dv" == Didier Verna <verna(a)inf.enst.fr> writes: dv> Christoph Wedler <wedler(a)fmi.uni-passau.de> writes: >> If I quite an EDiff session, i.e., if the control frame is killed dv> What do you mean killed ? How do you actually quit the session ? Killed = deleted (same as C-x 5 0). I quit a EDiff session by pressing "q". - Christoph

2 participants
1 comments

Re: Packages at release 27 years

Raymond Toy

>>>>> "Rick" == Rick Campbell <campbell(a)cyberpass.net> writes: Rick> I agree. I think that the packaging is a very positive development as Rick> it offers more flexibility. However, I feel even more strongly that Rick> one of XEmacs' major features is that it comes bundled with so much Rick> stuff that (a) most people don't feel any need to keep extra packages Rick> (I'm using the term loosely here) around, and (b) the installed Rick> packages tend to interact well. My intention, regarding local Rick> support, is to install with SUMO and leave things alone until the next Rick> release. I suspect that a lot of others will do the same. I intend to do the same thing. There's no way for me to know what people are using today, so the safest and easiest thing for my to do is to grab everything and install. If that's missing stuff, then the individual users can get there own. Ray

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