July 2002 - XEmacs-Beta - XEmacs Mailing List Archives

Jerry James

There is some code that predates the mailing list archives available on list-archive.xemacs.org that I would like to understand better. The code itself and the changelogs only tell me what, not why. I'm hesitant to make some changes that I think I need without understanding the rationale behind the current state of the code. Are there any pre-Spring 1998 mail archives, in any form whatever? Thanks, -- Jerry James http://www.ittc.ku.edu/~james/

1 participants
0 comments

Latest 21.5 CVS no longer uses mswindows_insert_directory in native windows 22 years, 4 months

Adrian Aichner

xemacs.mak got rid of HAVE_MSW_C_DIRED, but still seems to compile dired-msw.c and link in dired-msw.obj. However, in files.el, (fboundp 'mswindows-insert-directory) nils. Consequently, M-x dired is real SLOW in native Windows XEmacs and DEPENDS on CYGWIN ls! What's the story? -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/

2 participants
1 comments

accept credit cards and lower your rates 7155COIV2-593N-13 22 years, 4 months

l.hammer1＠aol.com

1 participants
0 comments

Re: [21.5] Re: Problem in dumping Xemacs 22 years, 4 months

Dhruva Krishnamurthy

Hi, With your path, I got over that error. Now it is the case with "SHInvokePrinterCommandW", "SHEmptyRecycleBinW", "SHQueryRecycleBinW". I feel there are lot of problems with Win32API portability. We shoudl be more carefull before using those. I have a suggestion. In the make or configure we should find out whether those API's are available on the OS. We can have a executable which will take the function name and DLL name and return TRUE or FALSE based on whether it is present in the DLL or not. Using this info, generate the related files (intl-*-encap-win32.*). I am in the process of weeding out the unsupported methods. Will get back later if I have more. The whole process is slow as I have to do a make clean after each modification and make again to reflect my changes. with regards, dhruva On 04 Jul 2002 21:41:24 +0100, "Jonathan Harris" <jhar(a)tardis.ed.ac.uk> said: > > Dhruva Krishnamurthy wrote: > > I am trying to build XEmacs 21.5.7 on NT 4 SP5 using MSVC++6.0. > > I had mailed earlier about the error I get in accessing > > "GetLongPathNameW". > ... > > 3. For NT, there is a suggested work around (which I guess Andy knows). > > If not, please refer the URL: > > http://www.geocities.com/SiliconValley/2060/articles/longpaths.html > > GetLongPathNameW is unused in XEmacs. I don't have NT 4.0 around to > test, > but this simple patch should fix the problem. > > There is a function mswindows-long-file-name that looks like it already > uses > a similar algorithm to your suggested workaround. > > Unfortunately I can't commit this myself, since I'm currently getting: > ... > cvs commit: Examining tests/mule > cvs commit: Examining tests/tooltalk > ' from cvs serverng: unrecognized response `ok > > from the CVS server. > > > src/ChangeLog addition: > > 2002-07-04 Jonathan Harris <jonathan(a)xemacs.org> > > * intl-auto-encap-win32.c: > * intl-auto-encap-win32.h: > * intl-encap-win32.c: > Remove GetLongPathNameW - API not available on Win95/NT4 > > xemacs-21.5 source patch: > Diff command: cvs -q diff -u > Files affected: src/intl-encap-win32.c src/intl-auto-encap-win32.h > src/intl-auto-encap-win32.c > > Index: src/intl-auto-encap-win32.c > =================================================================== > RCS file: /pack/xemacscvs/XEmacs/xemacs/src/intl-auto-encap-win32.c,v > retrieving revision 1.6 > diff -u -u -r1.6 intl-auto-encap-win32.c > --- src/intl-auto-encap-win32.c 2002/05/06 14:15:41 1.6 > +++ src/intl-auto-encap-win32.c 2002/07/04 19:33:24 > ＠＠ -2578,14 +2578,7 ＠＠ > return GetShortPathNameA ((LPCSTR) lpszLongPath, (LPSTR) > lpszShortPath, cchBuffer); > } > > -DWORD > -qxeGetLongPathName (const Extbyte * lpszShortPath, Extbyte * > lpszLongPath, DWORD cchBuffer) > -{ > - if (XEUNICODE_P) > - return GetLongPathNameW ((LPCWSTR) lpszShortPath, (LPWSTR) > lpszLongPath, cchBuffer); > - else > - return GetLongPathNameA ((LPCSTR) lpszShortPath, (LPSTR) > lpszLongPath, cchBuffer); > -} > +/* Error if GetLongPathName used: Win98/2K+ only */ > > /* Skipping GetEnvironmentStrings because misnamed ANSI version of the > function */ > > Index: src/intl-auto-encap-win32.h > =================================================================== > RCS file: /pack/xemacscvs/XEmacs/xemacs/src/intl-auto-encap-win32.h,v > retrieving revision 1.6 > diff -u -u -r1.6 intl-auto-encap-win32.h > --- src/intl-auto-encap-win32.h 2002/05/06 14:15:43 1.6 > +++ src/intl-auto-encap-win32.h 2002/07/04 19:33:24 > ＠＠ -1829,11 +1829,8 ＠＠ > #endif > DWORD qxeGetShortPathName (const Extbyte * lpszLongPath, Extbyte * > lpszShortPath, DWORD cchBuffer); > > -#ifdef ERROR_WHEN_NONINTERCEPTED_FUNS_USED > #undef GetLongPathName > -#define GetLongPathName error use qxeGetLongPathName or > GetLongPathNameA/GetLongPathNameW > -#endif > -DWORD qxeGetLongPathName (const Extbyte * lpszShortPath, Extbyte * > lpszLongPath, DWORD cchBuffer); > +#define GetLongPathName error Win98/2K+ only > > /* Skipping GetEnvironmentStrings because misnamed ANSI version of the > function */ > > Index: src/intl-encap-win32.c > =================================================================== > RCS file: /pack/xemacscvs/XEmacs/xemacs/src/intl-encap-win32.c,v > retrieving revision 1.7 > diff -u -u -r1.7 intl-encap-win32.c > --- src/intl-encap-win32.c 2002/06/20 21:18:36 1.7 > +++ src/intl-encap-win32.c 2002/07/04 19:33:25 > ＠＠ -216,7 +216,7 ＠＠ > > yes GetBinaryType > yes GetShortPathName > -yes GetLongPathName > +no GetLongPathName Win98/2K+ only > skip GetEnvironmentStrings misnamed ANSI version of the function > yes FreeEnvironmentStrings > yes FormatMessage > > -- Dhruva Krishnamurthy Home: http://www.geocities.com/gnued/

2 participants
1 comments

Re: fatal error (fwd) 22 years, 4 months

dominique

Hi, I figured it out with the mouse. I you wont hear from me it means this version doesnt crash. thanks and bye domi

1 participants
0 comments

fatal error (fwd) 22 years, 4 months

dominique

I cleaned it by hand (removed both versions and reinstalled the newest one). The problem is still there. bye Dominik ---------- Forwarded message ---------- Date: Thu, 4 Jul 2002 14:29:24 +0200 (MEST) From: Dominique <domi(a)vision.ee.ethz.ch> To: xemacs-beta(a)xemacs.org Subject: fatal error Hi, Running xemacs (with no arguments) I get: Fatal error (11). Your files have been auto-saved. Use `M-x recover-session' to recover them. # bind (frame-being-created) make-frame(nil #<x-device on ":0.0" 0x1cf6>) frame-initialize() # bind (debugger debug-on-error command-line-args-left) command-line() # (unwind-protect ...) normal-top-level() # (condition-case ... . error) # (catch top-level ...) [1]+ Segmentation fault xemacs-21.1.14 How do I clean what I built? Make remove/uninstal or something. You dont describe that. I see now 2 xemacses installed. One 21.1.4 that I got from suse8 and 21.1.14 that I downloaded. How can I sort those things up (have read all FAQs) bye Domi -- -------------------------------------------------------------------- Dominik Szczerba, Dr. Phone: +41 1 632 66 68 Computer Vision Lab, ETH Fax: +41 1 632 11 99 Gloriastr. 35 email: domi(a)vision.ee.ethz.ch CH-8092 Zurich http://www.vision.ee.ethz.ch/~domi --------------------------------------------------------------------

3 participants
5 comments

Forward declaration in console-msw.h was: [Failure] XEmacs 21.5-b7 "broccoflower", i686-pc-cygwin 22 years, 4 months

Stephen J. Turnbull

>>>>> "David" == David Bush <David.Bush(a)intel.com> writes: David> In console-msw-impl.h the structure is actually defined. David> In console-msw.h in is more like a forward declaration. David> I'm surprised that this hasn't caused anyone else problems. It's been reported once already. But it looks like a compiler bug to me, because it _is_ a forward declaration. Opinion from an up-to-date language lawyer would be appreciated, but Harbison & Steele 1987 states: The use of a type-specifier of the syntactic classes structure-type-reference or union-type-reference without a preceding definition in the same or enclosing scope is allowed when the size of the structure is not required, including when declaring 1. pointers to the structure 2. a typedef name as a synonym for the structure The use of the specifier introduces an "incomplete" definition of the type and type tag in the innermost block containing the use. For this definition to be completed, a structure-type-definition or union-type-definition must occur later in the same scope. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py

1 participants
0 comments

Re: [Failed] XEmacs 21.5-b7 "broccoflower", i386-unknown-freebsd4.6 22 years, 4 months

Stephen J. Turnbull

>>>>> "Yoshiaki" == Yoshiaki Kasahara <kasahara(a)nc.kyushu-u.ac.jp> writes: Yoshiaki> '--with-xfs' '--with-xim=no' Yoshiaki> input-method-xlib.c:88: #error neither XIM_XLIB nor USE_XFONTSET is defined?? Is this really worth fixing? The menus should have gotten face support years ago---I think they're the only display element left that doesn't have it. Either configure with --xim=xlib or adding #undef USE_XFONTSET to config.h.in should get you a build. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py

2 participants
3 comments

My family needs your assistance 22 years, 4 months

pedroangola2002＠netscape.net

From: Pedro Savimbi This letter may come to you as a surprise due to the fact that we have not yet met. The message could be strange but real if you pay some attention to it. I could have notified you about it at least for the sake of your integrity. Please accept my sincere apologies. In bringing this message of goodwill to you, I have to say that I have no intentions of causing you any pains. I am Mr. Pedro Savimbi, son of the late rebel leader Jonas Savimbi of Angola who was killed on the 22nd of February 2002 . I managed to get your contact details through the internet myself Time is of the importance and I was desperately looking for a person to assist me in this confidential business. My late father, Jonas Savimbi was able to deposit a large sum of money in different security firms in Europe and Ghana. My father is presently death and the movement of his family members (including me) is restricted. We are forbidden to either travel abroad or out of our localities. Presently our movement are monitored. Right now there is a rush for all my Father's wealth but home and Abroad by the Government who are claiming that most of the wealth was got by Arms smuggling and therefore illegal and by my father,s extended family and relations. You can know more about my father by checking his profile at URL below: www.kwacha.com/edoc2.htm His wealth has been estimated to be $500 million to over $1 billion and being close to my father I happen to be in possession of documents and information of some of the wealth.Approx. $250 million and only my trusted mother knows that I have this information. Presently, the US$100,000,000.00 (One Hundred Million Dollars) cash and precious materials my father moved to Ghana before his death is deposited with some security firm . Before you can get access to it I have to give you the some hits. I am therefore soliciting your help to travel to Ghana in west Africa to recieve this money and transfer into your account before my government get wind of this fund .You know my father was a rebel leader in Angola before his death. My reason for doing this is because it will be difficult for the Angolan government to trace my father's money to an individual's account, especially when such an individual has no relationship,I decided to keep that money for my family use. At present the money is kept with some Security Companies in Ghana I am currently and temporarily living in Angola and as refugee status,I intend to communication with you as regards this transaction on a satellite phone to avoid intervention by anybody. Moreover, the political climate in Angola at the moment being so sensitive and unstable.With this password and information and I will send you a power of attorney to the security firm, When you are ready I will give you the information needed before you can get access to 7,000kg of AU gold dust, 8500kg of pure Diamond and raw cash of USD100 million America dollars. you will then proceed to Ghana for collection. PLEASE YOUR CONFIDENTIALITY IN THIS TRANSACTION IS HIGHLY REQUIRED. Yours sincerely, Pedro Savimbi.

1 participants
0 comments

Fwd: Re: [21.5] Re: Problem in dumping Xemacs 22 years, 4 months

Dhruva Krishnamurthy

Hi, I resolved all build errors. I do not have a CVS account nor do I know how to send a DIFF in a proper format. I have made changes to the files mentioned by Harris to fix all build issues on NT. The "xemacs.mak" also needed some modification to make it work. Changes to 3 files in src: 1. Applied the patch sent by Harries. 2. Remove or correct few other Win32 API calls not supported on NT. Changes in xemacs.mak: 1. Removed -ZI option for debug mode - For some reason it is not recognised. However, the compiler option says it is supported. This fix was made to just build XEMACS. 2. Changed options to "XCOPY" from /y to /r ( I had reported this problem long back and Andy had added this option as a comment ). For a newbie, I guess this flag should get set by checking the OS type and not expect him/her to modify the make files. 3. ＠type construct in xemacs.mak is not recognised by VC++6.0. This was used in the xemacs.mak to generate the config options file. I had to remove everything under "installation::" construct. I made this to build xemacs. I know it is not a solution but mere avoidance. I am sending an attachment, I am sorry if I am flooding your mail boxes. Kindly bear with me. with best regards, dhruva Note: Building with MinGW on windows is an back breaking job. I modified a lot of files to get the configure going. Unknowing I overwrote the same folder trying to resolve the build with MSVC++ 6.0. I will come up with MinGW related issues shortly. On Fri, 5 Jul 2002 06:27:47 +0000, "Dhruva Krishnamurthy" <seagull(a)fastmail.fm> said: > Hi, > With your path, I got over that error. Now it is the case with > "SHInvokePrinterCommandW", "SHEmptyRecycleBinW", "SHQueryRecycleBinW". > I feel there are lot of problems with Win32API portability. We shoudl > be more carefull before using those. > I have a suggestion. In the make or configure we should find out > whether those API's are available on the OS. We can have a executable > which will take the function name and DLL name and return TRUE or FALSE > based on whether it is present in the DLL or not. Using this info, > generate the related files (intl-*-encap-win32.*). I am in the process > of weeding out the unsupported methods. Will get back later if I have > more. The whole process is slow as I have to do a make clean after each > modification and make again to reflect my changes. > > with regards, > dhruva > > On 04 Jul 2002 21:41:24 +0100, "Jonathan Harris" <jhar(a)tardis.ed.ac.uk> > said: > > > > Dhruva Krishnamurthy wrote: > > > I am trying to build XEmacs 21.5.7 on NT 4 SP5 using MSVC++6.0. > > > I had mailed earlier about the error I get in accessing > > > "GetLongPathNameW". > > ... > > > 3. For NT, there is a suggested work around (which I guess Andy knows). > > > If not, please refer the URL: > > > http://www.geocities.com/SiliconValley/2060/articles/longpaths.html > > > > GetLongPathNameW is unused in XEmacs. I don't have NT 4.0 around to > > test, > > but this simple patch should fix the problem. > > > > There is a function mswindows-long-file-name that looks like it already > > uses > > a similar algorithm to your suggested workaround. > > > > Unfortunately I can't commit this myself, since I'm currently getting: > > ... > > cvs commit: Examining tests/mule > > cvs commit: Examining tests/tooltalk > > ' from cvs serverng: unrecognized response `ok > > > > from the CVS server. > > > > > > src/ChangeLog addition: > > > > 2002-07-04 Jonathan Harris <jonathan(a)xemacs.org> > > > > * intl-auto-encap-win32.c: > > * intl-auto-encap-win32.h: > > * intl-encap-win32.c: > > Remove GetLongPathNameW - API not available on Win95/NT4 > > > > xemacs-21.5 source patch: > > Diff command: cvs -q diff -u > > Files affected: src/intl-encap-win32.c src/intl-auto-encap-win32.h > > src/intl-auto-encap-win32.c > > > > Index: src/intl-auto-encap-win32.c > > =================================================================== > > RCS file: /pack/xemacscvs/XEmacs/xemacs/src/intl-auto-encap-win32.c,v > > retrieving revision 1.6 > > diff -u -u -r1.6 intl-auto-encap-win32.c > > --- src/intl-auto-encap-win32.c 2002/05/06 14:15:41 1.6 > > +++ src/intl-auto-encap-win32.c 2002/07/04 19:33:24 > > ＠＠ -2578,14 +2578,7 ＠＠ > > return GetShortPathNameA ((LPCSTR) lpszLongPath, (LPSTR) > > lpszShortPath, cchBuffer); > > } > > > > -DWORD > > -qxeGetLongPathName (const Extbyte * lpszShortPath, Extbyte * > > lpszLongPath, DWORD cchBuffer) > > -{ > > - if (XEUNICODE_P) > > - return GetLongPathNameW ((LPCWSTR) lpszShortPath, (LPWSTR) > > lpszLongPath, cchBuffer); > > - else > > - return GetLongPathNameA ((LPCSTR) lpszShortPath, (LPSTR) > > lpszLongPath, cchBuffer); > > -} > > +/* Error if GetLongPathName used: Win98/2K+ only */ > > > > /* Skipping GetEnvironmentStrings because misnamed ANSI version of the > > function */ > > > > Index: src/intl-auto-encap-win32.h > > =================================================================== > > RCS file: /pack/xemacscvs/XEmacs/xemacs/src/intl-auto-encap-win32.h,v > > retrieving revision 1.6 > > diff -u -u -r1.6 intl-auto-encap-win32.h > > --- src/intl-auto-encap-win32.h 2002/05/06 14:15:43 1.6 > > +++ src/intl-auto-encap-win32.h 2002/07/04 19:33:24 > > ＠＠ -1829,11 +1829,8 ＠＠ > > #endif > > DWORD qxeGetShortPathName (const Extbyte * lpszLongPath, Extbyte * > > lpszShortPath, DWORD cchBuffer); > > > > -#ifdef ERROR_WHEN_NONINTERCEPTED_FUNS_USED > > #undef GetLongPathName > > -#define GetLongPathName error use qxeGetLongPathName or > > GetLongPathNameA/GetLongPathNameW > > -#endif > > -DWORD qxeGetLongPathName (const Extbyte * lpszShortPath, Extbyte * > > lpszLongPath, DWORD cchBuffer); > > +#define GetLongPathName error Win98/2K+ only > > > > /* Skipping GetEnvironmentStrings because misnamed ANSI version of the > > function */ > > > > Index: src/intl-encap-win32.c > > =================================================================== > > RCS file: /pack/xemacscvs/XEmacs/xemacs/src/intl-encap-win32.c,v > > retrieving revision 1.7 > > diff -u -u -r1.7 intl-encap-win32.c > > --- src/intl-encap-win32.c 2002/06/20 21:18:36 1.7 > > +++ src/intl-encap-win32.c 2002/07/04 19:33:25 > > ＠＠ -216,7 +216,7 ＠＠ > > > > yes GetBinaryType > > yes GetShortPathName > > -yes GetLongPathName > > +no GetLongPathName Win98/2K+ only > > skip GetEnvironmentStrings misnamed ANSI version of the function > > yes FreeEnvironmentStrings > > yes FormatMessage > > > > > > -- > Dhruva Krishnamurthy > Home: http://www.geocities.com/gnued/ -- Dhruva Krishnamurthy Home: http://www.geocities.com/gnued/

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 July 2002