September 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: w3 on native-build mswindows 26 years, 2 months

William M. Perry

Jonathan Harris <jhar(a)tardis.ed.ac.uk> writes: > The enclosed patch against package version 1.06 of w3 makes w3 mostly > work on the native mswindows build of XEmacs. The patched function > url-basepath has actually changed since 1.06 so this patch won't apply, > but that's OK beause I'm really just asking for advice. > > The problem that the patch fixes is that w3 calls XEmacs path handling > functions on URL paths. That doesn't work under mswindows because these > path handling functions convert path separators into '\\' because that is > the native path separator on Win32. The attached patch replaces two > occurrences in url-basename of such calls with manual string-matches. I would say that the file munging routines under win32 should NOT change the path separators. They should leave them the same as what they got. So: (file-name-directory "/foo/bar/baz") => "/foo/bar" (file-name-directory "\\foo\\bar\\baz") => "\\foo\\bar" (file-name-nondirectory "/foo/bar/baz") => "baz" > Alternatively, is there a better approach than manually replacing > selective calls to XEmacs path handling functions with string matches? I would ask someone to implement the above... at least for the file-name-(non)*directory functions. -bill p.

2 participants
1 comments

Re: Showstopper update, please read 26 years, 2 months

Jan Vroonhof

Ben Wing <ben(a)xemacs.org> writes: > <LI><P>(<B>De facto Owner: Jan Vroonhof, maybe Darryl Okahata</B>) Complete, well-defined, > well-tested and properly integrated.</P> I would very much like the defacto owner (i.e. the one who actually provides the tarballs) to be somebody with direct access to the ftp sites. The ideal one would be steve since he is in charge of package-get-base.el too[1]. However I can continue to write the scripts (I think sumo.el is already enough), readme's etc. Jan [1] Humble suggestion: Can we please update package-get-base.el in CVS very often (even if there is no XEmacs release to commit?) P.S. Is somebody making sure the packages will be in a reasonable state at release time? i.e. does ediff have the custom bug fixes applied? I know package releases are supposed to be decoupled from XEmacs releases now but there a lot of peopleto will install them when they upgrade. It would be nice if most major bugs were fixed then.

2 participants
1 comments

Bug in file-truename 26 years, 2 months

Barry A. Warsaw

XEmacs 21.0-b53 on Solaris 2.6 There is a reproducible bug in file-truename. When the filename argument names a non-existing file, symbolic links in existing directories earlier in the path are not chased. This in turn breaks functions like find-file-noselect and can cause two buffers to bogusly be created for the same real file (even when find-file-compare-truenames is t) Example: Say the canonical path exists /projects/python/develop/bwarsaw and I have a symbolic link ~/projects/python -> /projects/python/develop/bwarsaw Inside this directory is another directory src/Misc. I visit a non-existing file using the path ~/projects/python/src/Misc/foobar. The foobar buffer is created. Now both buffer-file-name and buffer-file-truename for this buffer are /home/bwarsaw/projects/python/src/Misc/foobar. However, this is broken, because buffer-file-truename *should* be /projects/python/develop/bwarsaw/src/Misc/foobar. If I save the file, and find-alternate-file it back, then buffer-file-truename contains the correct truename. -Barry

1 participants
0 comments

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

Jan Vroonhof

Christoph Wedler <wedler(a)fmi.uni-passau.de> writes: > If I quite an EDiff session, i.e., if the control frame is killed, I get > the following error in my console (the frame is killed, though): > > xemacs: X Error of failed request: BadWindow (invalid Window parameter) > Major opcode of failed request: 40 (X_TranslateCoords) > Resource id in failed request: 0x1c003c1 We just had a whole thread about this last week. A patch was provided. Maybe it is not in the current beta yet. Jan

1 participants
0 comments

Re: Showstopper update, please read 26 years, 2 months

Greg Klanderman

>>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: Jan> Jan> P.S. Is somebody making sure the packages will be in a reasonable Jan> state at release time? i.e. does ediff have the custom bug fixes Jan> applied? I know package releases are supposed to be decoupled from Jan> XEmacs releases now but there a lot of peopleto will install them when Jan> they upgrade. It would be nice if most major bugs were fixed then. just checked - ediff does not appear to have that fixed. greg

1 participants
0 comments

[Bug] 21.0 FL; mouse events & event-matches-key-specifier-p 26 years, 2 months

Christoph Wedler

Mouse events seem never to match their key specifiers, why not? In the info pages, `event-matches-key-specifier-p' is explained on the same page as `define-key'... Here the contents of buffer *trace-output* ====================================================================== 1 -> event-matches-key-specifier-p: event=#<buttondown-event button2> key-specifier=button2 1 <- event-matches-key-specifier-p: nil ====================================================================== 1 -> event-matches-key-specifier-p: event=#<buttondown-event button2> key-specifier=(button2) 1 <- event-matches-key-specifier-p: nil ====================================================================== 1 -> event-matches-key-specifier-p: event=#<buttondown-event button2> key-specifier=button2up 1 <- event-matches-key-specifier-p: nil ====================================================================== 1 -> event-matches-key-specifier-p: event=#<buttondown-event button2> key-specifier=(button2up) 1 <- event-matches-key-specifier-p: nil ====================================================================== Everything is fine with key bindings ====================================================================== 1 -> event-matches-key-specifier-p: event=#<keypress-event help> key-specifier=help 1 <- event-matches-key-specifier-p: t ====================================================================== - Christoph

1 participants
0 comments

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

Didier Verna

Christoph Wedler <wedler(a)fmi.uni-passau.de> writes: > If I quite an EDiff session, i.e., if the control frame is killed What do you mean killed ? How do you actually quit the session ? --didier

1 participants
0 comments

[Bug] 21.0 FL; EDiff quit (frame deletion) => X-Error 26 years, 2 months

Christoph Wedler

If I quite an EDiff session, i.e., if the control frame is killed, I get the following error in my console (the frame is killed, though): xemacs: X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 40 (X_TranslateCoords) Resource id in failed request: 0x1c003c1 Serial number of failed request: 99609 Current serial number in output stream: 99609 - Christoph

1 participants
0 comments

Re: FTP/EFS problems? 26 years, 2 months

Remek Trzaska

>>>>> "Matthew" == Matthew O Persico <mpersico(a)erols.com> writes: Matthew> When I try to do an EFS/FTP edit remotely to Matthew> /persicom＠worknode:, it says something about the conenction Matthew> not being as pty? This is just a tip of the iceberg. Making EFS work properly is not an easy task in Windows. The problems I encountered include: * Finding an ftp client accepting input not only from stdin. The one in C:\WINDOWS is a bad one. I tried ftp.exe from ntemacs faq webpage, from Andy's local.tgz (for unknown reason it transported binaries in ascii mode), God knows where else from. Finally, I have found one that works so-so, but I really lost track where this one came from. I can make it available if anyone is interested. * Path syntax differences. For example, put //C/temp/foo /usr/path/bar won't work in any ftp.exe I have. Maybe we should bug cygnus to make a special ftp client that groks that and include it in cygwin. Maybe efs should first copy a local file to /tmp/efsfoo, and then ftp would get it from there. * cygwin's /tmp not being ftp's /tmp. It happens when cygwin root is mounted somewhere else than C:\. It led to lots of crashes (of the whole operating system) in my case until I finally realized what was going on. `ln -s //C/tmp /tmp' helped here. Similar thing: cygwin installed on another drive, not C:. Remek -- Remek Trzaska http://www.npac.syr.edu/users/remek Research Scientist Northeast Parallel Architectures Center at Syracuse University, NY

2 participants
1 comments

Re: Are long line caches useful? 26 years, 2 months

Hrvoje Niksic

jareth(a)camelot.co.jp (P. E. Jareth Hein) writes: > Also, implementing a proper line cache could help speed up MULE in > its searching for character positions... Yes, but the point of the cache is something completely different... -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Oh lord won't you buy me a color TV...

1 participants
0 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 September 1998