July 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: [PATCH] More validation error fixes, add sourceforge logo. 24 years, 4 months

Adrian Aichner

>>>>> "jsja" == John S J Anderson <jacobs(a)xemacs.org> writes: Hi John, I certainly did not mean to offend anybody. You brought in genpage and I can see its merits for the maintenance of our website. I have put genpage in its own directory and inported it on a vendor branch. This should make upgrades to newer versions of genpage real easy. We will just have to merge in my local modifications afterward. My changes are minor and I will submit them to the author of genpage. Do you know whether PHP would provide us with comparable functionality? I hope you will remain active will xemacs website development and maintenance. I will document in more detail how things work on sourceforge. Refer to my previous articles on xemacs-webmaint and xemacs-beta for now. I have commented below. Best regards, Adrian >>>>> "APA" == Adrian Aichner <aichner(a)ecf.teradyne.com> writes: APA> I am concerned that using APA> <base href="http://www.xemacs.org/"> APA> in template.html (all page contents get wrapped into this APA> template) is more a curse than a blessing. jsja> [snip] APA> AFAIK, "base href" is a feature to be used when web documents are APA> sent off via e-mail, to provide a base for all relative links. jsja> Not according to any HTML spec I've ever seen. If you can provide a jsja> citation for that, I'd be pleased to see it. It _is_ a way to provide jsja> a base for all relative links, but there's nothing about it being jsja> specific for email, AFAIK. Like I said, I'd _really_ appreciate jsja> knowing the source of this information. The best I've been able to find quickly is this: http://www.w3.org/TR/html401/struct/links.html#h-12.4.1 APA> Using this feature as a means of website design is an error, I APA> believe. It is the cause for all the broken links in APA> "Architecting XEmacs". jsja> Calling it an error is an error, IMNSHO. The reason for the jsja> broken links in the Architecting section is because those jsja> documents were prepared by a third party (someone paid by jsja> Ben, IIRC), and never properly integrated into the web site. s/an error/problematic/ Including a base href via the template.html into documents on various directory hierarchy levels changes the meaning of relative links. All relative links become relative to that one location, which defeats modular, self-contained linking within a sub-directory. I've been there, done that, and learned my lessons from that. APA> I would like to get some feedback from yall, especially the ones APA> who decided to use APA> <base href="http://xemacs.sourceforge.net/"> jsja> (Totally my decision, in case you hadn't got that yet.) So I gathered :-) Again, I don't mean to offend you. Let's come to a technical solution for the problems at hand. APA> What was the motivation? jsja> The reason for using <BASE> is so image links in the jsja> template will work at all relative directory levels of the jsja> site. Consider what would happen with the <IMG jsja> SRC="Images/xemacs.gif"> when viewing jsja> <URL:http://www.xemacs.org/About/index.html> if that BASE jsja> tag wasn't there. I would use absoulte links like <IMG SRC="/Images/xemacs.gif"> to access global features like images, and other shared resources. It would be immediately obvious that this is a link rooted at the top of the hierarchy. Without base href relative links are relative, absolute links are absolute. Isn't that a feature worth preserving? jsja> Yes, there are other solutions possible. They all felt jsja> kludge-y to me; while using the <BASE> tag felt relatively jsja> clean. Do you still think so? jsja> john. Best regards, Adrian jsja> -- jsja> ------------------------------------------------------------------------ jsja> John S Jacobs Anderson \ <URL:http://www.xemacs.org> jsja> You'll have to pry my Emacs from my cold \ jacobs(a)xemacs.org jsja> dead oversized control-pressing left pinky finger. -- Randal L. Schwartz

2 participants
1 comments

Re: [jgd@lanl.gov] I think the xemacs FTP package directory is fouled up... 24 years, 4 months

Steve Youngs

* Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes: MS> I believe I've solved it, but I haven't finished testing yet. (The MS> patch posted here awhile ago doesn't cut it.) APA> I realize my little patch wasn't really a solution. APA> Yell if you need a guinea pig on NT, Michael. > Thanks. Here is the fix: > Index: efs.el At first glances (about 2 minutes of testing) everything seems to be fine. There were no errors/warnings with Options -> Manage Packages -> List and Install. However the patch to package-get.el that I got here a little while ago (was that your patch, Adrian?) was still needed. Otherwise I still got the "Opening Input: blah blah... file or directory does not exist" error. -- |---<Regards, Steve Youngs>-----------[GnuPG KeyID: EFD82ED2]---| | It's a funny thing about life; if you refuse to accept | | anything but the best, you very often get it | |-----------------------------<mailto:youngs_s＠ozlinx.com.au>---|

1 participants
0 comments

Re: [PATCH] More validation error fixes, add sourceforge logo. 24 years, 4 months

Adrian Aichner

>>>>> "Vin" == Vin Shelton <acs(a)xemacs.org> writes: >>>>> On 27 Jul 2000, Adrian Aichner <aichner(a)ecf.teradyne.com> said: APA> I'd like to get some feedback from people surfing APA> http://xemacs.sourceforge.net/ APA> So far I have NONE. Vin> 1. Clicking on the "Mailing List Archives" link yielded: Vin> The requested URL /Lists/Archive/index.cgi was not found on Vin> this server. Yes, this is not done at all. Vin> Similarly, following the link to "Join the xemacs-beta mailing Vin> list" yielded: Vin> The requested URL /Lists/index.html was not found on this Vin> server. Vin> It looks like all of the /Lists links are dead. Yep. Vin> 2. I notice the footers all claim to be part of http://www.xemacs.org Vin> (and indeed points there), but that's not really correct. I'm Vin> confused about this because the link at the top left of every page Vin> says www.xemacs.org, but it points to sourceforge. Yes. We're currently sitting between the chairs. I am concerned that using <base href="http://www.xemacs.org/"> in template.html (all page contents get wrapped into this template) is more a curse than a blessing. I have changed it to <base href="http://xemacs.sourceforge.net/"> for the sourceforge site. AFAIK, "base href" is a feature to be used when web documents are sent off via e-mail, to provide a base for all relative links. Using this feature as a means of website design is an error, I believe. It is the cause for all the broken links in "Architecting XEmacs". All local links in these documents are suddenly taken to be relative to <base href="http://xemacs.sourceforge.net/"> not to http://xemacs.sourceforge.net/Architecting XEmacs Throwing out <base href="http://xemacs.sourceforge.net/"> is a tedious task, which perl would probably do for me. I would like to get some feedback from yall, especially the ones who decided to use <base href="http://xemacs.sourceforge.net/"> What was the motivation? Best regards, Adrian Vin> 3. It looks like all of the links on Architecting XEmacs are dead. Vin> Thanks for doing this, Adrian. Vin> - vin

1 participants
0 comments

Re: [jgd@lanl.gov] I think the xemacs FTP package directory is fouled up... 24 years, 4 months

Michael Sperber

>>>>> "APA" == Adrian Aichner <aichner(a)ecf.teradyne.com> writes: >>>>> "MS" == Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes: >>>>> "APA" == Adrian Aichner <aichner(a)ecf.teradyne.com> writes: APA> This problem is still alive and kicking. APA> Unfortunately I don't have time to look into it. MS> I believe I've solved it, but I haven't finished testing yet. (The MS> patch posted here awhile ago doesn't cut it.) APA> I realize my little patch wasn't really a solution. APA> Yell if you need a guinea pig on NT, Michael. Thanks. Here is the fix: Index: efs.el =================================================================== RCS file: /afs/informatik.uni-tuebingen.de/pu/cvs/elisp/efs/efs.el,v retrieving revision 1.58 retrieving revision 1.59 diff -u -c -r1.58 -r1.59 *** efs.el 2000/04/15 13:33:34 1.58 --- efs.el 2000/07/16 11:01:35 1.59 *************** *** 4689,4695 **** switches file lsargs noparse parse noerror msg nowait cont) (if result ! (efs-error host user (format "CWD %s failed: " line)) (efs-send-cmd host user (list (if nlist 'nlist 'dir) "" (cdr temp) lsargs) --- 4689,4698 ---- switches file lsargs noparse parse noerror msg nowait cont) (if result ! (if noerror ! (if cont ! (efs-call-cont cont nil)) ! (efs-error host user (format "CWD %s failed: " line))) (efs-send-cmd host user (list (if nlist 'nlist 'dir) "" (cdr temp) lsargs) -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: [jgd@lanl.gov] I think the xemacs FTP package directory is fouled up... 24 years, 4 months

Adrian Aichner

>>>>> "MS" == Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes: >>>>> "APA" == Adrian Aichner <aichner(a)ecf.teradyne.com> writes: APA> This problem is still alive and kicking. APA> Unfortunately I don't have time to look into it. MS> I believe I've solved it, but I haven't finished testing yet. (The MS> patch posted here awhile ago doesn't cut it.) I realize my little patch wasn't really a solution. Yell if you need a guinea pig on NT, Michael. I am more than willing to test your solution. Best regards, Adrian MS> -- MS> Cheers =8-} Mike MS> Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: [jgd@lanl.gov] I think the xemacs FTP package directory is fouled up... 24 years, 4 months

Michael Sperber

>>>>> "APA" == Adrian Aichner <aichner(a)ecf.teradyne.com> writes: APA> This problem is still alive and kicking. APA> Unfortunately I don't have time to look into it. I believe I've solved it, but I haven't finished testing yet. (The patch posted here awhile ago doesn't cut it.) -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

(no subject) 24 years, 4 months

Jesper Andersen

1 participants
0 comments

Re: Successful XEmacs/Gnu merge 24 years, 4 months

Kevin Esler

Adrian Aichner writes: > Here's some feedback: > > The file must > (provide 'clearcase) > instead of > (provide 'ccase) > > otherwise > (require 'clearcase) > will lead: > Required feature clearcase was not provided > > Basically all of clearcase.el should undergo a substitution from "ccase" > to "clearcase". This is all done and in /main/144, which I've copied to the usual place. I also put the menus back to the way they were, using :activate instead of :visible. -- Kevin Esler Rational Software ClearCase Product Group 20 Maguire Road Tel: (781) 676-2626 Lexington, MA 02421 Fax: (781) 676-2600 mailto:esler＠Rational.com WWW: http://www.Rational.com/

2 participants
1 comments

Re: XEmacs/Gnus problem with charset=iso-8859-1, 8-bit 24 years, 4 months

Mike FABIAN

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > >>>>> "MF" == Mike Fabian <mfabian(a)suse.de> writes: > > MF> The reason for that seems to be that the default value for the > MF> variable 'buffer-file-coding-system' in XEmacs is iso-2022-jp" > > MF> ~$ xemacs -q -vanilla -eval "(message \"%s\" > MF> buffer-file-coding-system)" -batch iso-2022-jp > > >>>>> "mb" == Martin Buchholz <martin(a)xemacs.org> writes: > > mb> I think the intent is that buffer-file-coding-system is to > mb> default to iso-2022-8, as you suggest. > > This is with 21.2.34, not 21.1.10, but: > > bash-2.04$ xemacs -q -vanilla -eval "(message \"%s\" buffer-file-coding-system)" -batch > iso-2022-8 > bash-2.04$ LANG=ja xemacs -q -vanilla -eval "(message \"%s\" buffer-file-coding-system)" -batch > iso-2022-jp > > I suspect Mike runs with his env LANG set to Japanese. Thank you, I didn't think about that. You are right, I have LANG set to 'ja_JP'. If I set LANG to 'C' or 'de_DE' the default of buffer-file-coding-system becomes 'iso-2022-8', i.e. 21.1.10 behaves the same as 21.2.34 in that respect. > But this is still a bug that runs deeper than just setting the default > right. If the default for 'buffer-file-coding-system' is set to 'iso-2022-8', Gnus works correctly for at least 8-bit German and Japanese. For other languages I can't tell. > It may be a problem with Gnus, I don't know. Probably not only with Gnus. I had a similar problem about 1 year ago with VM. Suddenly all German messages in my VM INBOX had been converted to iso-2022-jp. I didn't find out why back than, but now I think it was very likely the same problem with the value of 'buffer-file-coding-system'. With VM it is even worse, because it hits your whole INBOX at once. That may be difficult to reverse, if your INBOX contains many different languages. With Gnus and the nnml backend (1 file per message), changing the default value of 'buffer-file-coding-system' affects only the messages coming in after that. > But somebody somewhere should be saving that MIME information and > setting the b-f-c-s properly, Maybe that would help for the nnml backend, but probably not for nnfolder or VM. > or else the default should not be touched by the language > environment picked up from the LANG variable. Maybe this is the best solution. Is there any reason why this shouldn't work in all cases? If the message is saved unchanged, exactly as it came in, Gnus and VM should be able to use the MIME information to decode and display it correctly. But if the encoding of the message body has been changed to something else when XEmacs saved it, it is no wonder that Gnus displays garbage. -- Mike Fabian <mfabian(a)suse.de>

2 participants
1 comments

Re: [PATCH] More validation error fixes, add sourceforge logo. 24 years, 4 months

Vin Shelton

>>>>> On 27 Jul 2000, Adrian Aichner <aichner(a)ecf.teradyne.com> said: APA> I'd like to get some feedback from people surfing APA> http://xemacs.sourceforge.net/ APA> So far I have NONE. 1. Clicking on the "Mailing List Archives" link yielded: The requested URL /Lists/Archive/index.cgi was not found on this server. Similarly, following the link to "Join the xemacs-beta mailing list" yielded: The requested URL /Lists/index.html was not found on this server. It looks like all of the /Lists links are dead. 2. I notice the footers all claim to be part of http://www.xemacs.org (and indeed points there), but that's not really correct. I'm confused about this because the link at the top left of every page says www.xemacs.org, but it points to sourceforge. 3. It looks like all of the links on Architecting XEmacs are dead. Thanks for doing this, Adrian. - vin

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