January 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Bad addresses in wide reply. 24 years, 3 months

ShengHuo ZHU

>>>>> "Jérôme" == Jérôme Lacoste <lacostej(a)oslo.geco-prakla.slb.com> writes: Jérôme> Pterodactyl Gnus v0.96 Jérôme> XEmacs 21.1 (patch 3) "Acadia" [Lucid] (sparc-sun-solaris2.6) of Tue Jun 29 1999 on ardbeg Jérôme> 200 news.sinet.slb.com InterNetNews NNRP server INN 2.2.1 25-Aug-1999 ready (posting ok). Jérôme> I received a mail (cf RECEIVED MAIL section), with a header containing Jérôme> a lot of addresses. An error appeared when I tried to make a Wide Jérôme> reply (cf WIDE REPLY BUFFER section) : the mail server didn't accept Jérôme> the recipients (cf trace of SMTP session BUFFER). Jérôme> Gnus apparently processed badly the recipients, Jérôme> The error appears on the recipient Jérôme> "'Lacoste, Jerome (ORK)'" <lacostej(a)oslo.geco-prakla.slb.com>, Jérôme> which is shorten to "'Lacoste, Jérôme> Thus creating a parsing error (a '" is missing). [...] Jérôme> # start of WIDE REPLY BUFFER # Jérôme> ############################## Jérôme> To: "Eriksen, Kim Moore" <kim.moore.eriksen(a)folkehelsa.no> Jérôme> Cc: "'Ashton, Alan (ORK)'" <alan.ashton(a)unitor.com>, Jérôme> "'Bach-Gansmo, Tore (NRF)'" <tore.bach-gansmo(a)radiol.uu.se>, Jérôme> "'Bavridge, Nick'" <nickb(a)euroil.no>, Jérôme> "'Bjørkevoll, Johan (ORK)'" <johan.bjorkevoll(a)dnb.no>, Jérôme> "'Bressand, Jean Yves (ORK)'" <jyb(a)paellingsen.no>, Jérôme> "'Carriere, Stephane (ORK)'" <stephane.carriere(a)total.telemax.no>, Jérôme> "'Cooper, Colin (NRF)'" <ccolin(a)online.no>, Jérôme> "'Dalton, David'" <ddalton(a)se-as.no>, Jérôme> "'Davies, Jerry (NRF)'" <jdavies(a)eunet.no>, Jérôme> "'Deck, Bertrand (ORK)'" <bertrand.deck(a)hydro.com>, Jérôme> "'Demarest, Andre (ORK)'" <andre.v.demarest(a)no.pwcglobal.com>, Jérôme> "'Dinning, Jeff'" <jeff.dinning(a)get2net.dk>, Jérôme> "'Fogalele, Robin (ORK)'" <robin_fogalele(a)dmr.ca>, Jérôme> "'Gjertsen, Roar (NRF)'" <roar.gjertsen(a)iss-shipping.com>, Jérôme> "'Guvåg, Per Arne (ORK)'" <per.1395(a)online.no>, Jérôme> "'Hall, Keith (ORK)'" <keith.hall(a)winge.no>, Jérôme> "'Hodne, Per (NRF)'" <per.hodne(a)oslore.no>, Jérôme> "'Howells, J. Huw (ORK)'" <huw_jonathan_howells(a)dmr.com>, Jérôme> "'Johansson, Bradley (ORK)'" <bradley.johansson(a)avis.no>, Jérôme> "'Jones, Philip (ORK)'" <philip.jones1(a)chase.com>, Jérôme> "'Kittilsen, Jon (NRF)'" <jokittil(a)c2i.net>, "'Lacoste, "'Larsen, Jérôme> Øyvind (ORK)'" <oey-lar(a)online.no>, "'Laugerud, Jérôme> Eirik M. (ORK)'" <laueir(a)dph.no>, "'Lie, [...] It is a bug in `rmail-dont-reply-to'. The bug has been fixed in Gnu Emacs 20.4, while the bug still exists in XEmacs mail-lib (currently 1.24). (let ((rmail-dont-reply-to-names "test")) (require 'mail-utils) (rmail-dont-reply-to "a＠b, \"Last, First\" <test＠somewhere>")) => "a＠b, \"Last" It should be (as what does in Emacs 20.4) => "a＠b" -- Shenghuo

2 participants
1 comments

[mule-base] TUTORIAL.ja 24 years, 3 months

Yoshiki Hayashi

I just send a patch to update TUTORIAL.ja but XEmacs can't find newer version. mule-base package contains old Mule TUTORIAL.ja which comes earlier in data-directory-list. So I want it to be removed to get version distributed with XEmacs itself. -- Yoshiki Hayashi

1 participants
0 comments

Re: Don't set coding-system in shell-mode 24 years, 3 months

Ben Wing

Yoshiki Hayashi wrote: > Ben Wing <ben(a)666.com> writes: > > > Martin Buchholz wrote: > > > > > I approve the patch, if this really works (it somewhat surprises me). > > > It did not work when I originally wrote this code. Does this also > > > work correctly for ttys? I mean, is the tty coding system properly > > > autodetected using determine_real_coding_system? > > > > > > Blue Sky: Can > > > > > > cat test.euc > > > cat test.jis > > > > > > possibly work `correctly'? > > Yes, because you can always distinguish that two > coding-system. When escape sequence `ESC [ $ B' is found, > it's most likely that coding-system is iso-2022-jp. When > two byte sequence has its MSB set, then it is probably > euc-jp. > > > > We know that the Latin equivalent > > > > > > cat test.iso8859-2 > > > cat test.iso8859-1 > > > > > > cannot. > > Because there's no particular characteristics in that > coding-system. It's just 8bit byte sequences. So it > depends on what language-environment you are in. If you > only use those two, it may be possible to disguinsh them > with some good heuristics. > > > Why not? Shell mode could reset things so as to force autodetection for the > > output of each command issued. Even your second example could work if those > > files had proper ISO2022 or X-Compound-Text or whatever escape sequences in > > them, or magic XEmacs coding-system: stuff, etc. to indicate the coding > > system. (Granted, not likely.) > > Here's a list of candidate to Mule-izing shell-mode. > 1. autodetect every time. > 2. autodetect only first time. > 3. set default coding-system and allow C-x RET c to alter > default value. > > Now I found doing this > cat test.ascii > cat test.sjis > will set process-output-coding-system to raw-text, I don't > think 2 is a good plan (my original one). > I think 3 is best as most user use only one coding-system. > I'll send patch to do this. Moved to xemacs-beta. I disagree. We always want to be automatic when possible -- i.e. option 1. We don't want to burden the user with extra work -- i.e. #3. > > > Besides that, it would be nice to have convenience way to > set coding-system of next command in shell-mode. Maybe > command to change process coding-system for permanently > would be nice, too. > > -- > Yoshiki Hayashi -- In order to save my hands, I am cutting back on my responses, especially to XEmacs-related mail. You _will_ get a response, but please be patient. If you need an immediate response and it is not apparent in your message, please say so. Thanks for your understanding.

3 participants
10 comments

Re: Info-directory-list 24 years, 3 months

Michael Sperber

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)iskon.hr> writes: Hrvoje> sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: Hrvoje> I propose that the new variable be named Hrvoje> Info-default-directory-list, because GNU Emacs calls it that Hrvoje> way (and also defaults it to nil.) >> >> NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!! Hrvoje> OK ok, it was just a proposal. >> The current setup really wants complete control over the various >> -path and -directory-list variables. Hrvoje> That's perfectly fine. All I ask for is that the actual Info code Hrvoje> takes into account a separate variable for user's private Hrvoje> customizations, *at access time*. The variable need not be called Hrvoje> Info-default-directory-list if you think that name is tainted. And all I'm saying is that the solution to this problem better generalize to the various other -path and -directory-list variables to which identical issues apply. Anything else will result in yet another maintenance nightmare. I know 'cause I've been exactly there. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: Info-directory-list 24 years, 3 months

Hrvoje Niksic

sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > Hrvoje> I propose that the new variable be named > Hrvoje> Info-default-directory-list, because GNU Emacs calls it that > Hrvoje> way (and also defaults it to nil.) > > NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!! OK ok, it was just a proposal. > The current setup really wants complete control over the various > -path and -directory-list variables. That's perfectly fine. All I ask for is that the actual Info code takes into account a separate variable for user's private customizations, *at access time*. The variable need not be called Info-default-directory-list if you think that name is tainted. > The answer to this question has to be, "Just stick your info files > in the right place". Well. Modifying Info-directory-list seems to be working nicely. All I'm asking for is a user-specific version of that variable that is untouched by auto-loads and that can be customized at will. Again, the variables would both be considered at access-time, *not* when info.el is loaded. No weird startup problems there. Yes, the users really need and ask for such a thing.

1 participants
0 comments

Re: "Symbol X has different size in shared object" bug reappears 24 years, 3 months

Daniel Pittman

On 05 Jan 2000, Hrvoje Niksic <hniksic(a)iskon.hr> wrote: > Daniel Pittman <daniel(a)danann.net> writes: > >> The quick fix[1] is to edit /etc/ld.so.conf and move the entry for >> /usr/X11R6/lib/ before the entry for /usr/X11R6/lib/Xaw3d/. > > This does work. Of course, now I get the ugly plain Athena buttons, > but that's OK. When I decide I want 3D Athena, I'll say > `--with-athena=3d' to configure, and things will (hopefully) work > nicely. Yes. It will refuse to build, even, if you don't have matching header. Also, libXaw3d.so will be used allowing the Debian hack to go back safely :) > We might want to document these things in PROBLEMS, as clearly and > legibly as possible. Yes. That seems a sensible plan, I think. It's certainly shown up a few times :) Daniel -- The most potent weapon in the hands of the oppressor is the mind of the oppressed. -- Steve Biko

1 participants
0 comments

Re: Info-directory-list 24 years, 3 months

Hrvoje Niksic

Mike Fabian <mike.fabian(a)gmx.de> writes: > I just tried in GNU Emacs 20.3.1 and it doesn't seem to default to nil > there, it was set to > > ("/usr/local/lib/info/" "/usr/local/info/" "/usr/info/") > > after starting emacs with `emacs -q'. Eek. Then they suck too. For Customize to withstand changes of default value, we really need a list variable that is nil by default. > A slightly weird behaviour of XEmacs with respect to > Info-directory-list is that it does use the value of environment > variable INFOPATH, but appends it's contents to the end of > Info-directory-list. Therefore, info-files in the > .../lib/xemacs/xemacs-packages/info/ directory shadow info-files of > the same names in directories from INFOPATH. Is this intentional? I think it's intentional. The `XEmacs' stuff is supposed to come first. When using info from within XEmacs, a beginner is likely to be looking for information on XEmacs itself. > I didn't like that, because newer info-files installed somewhere in > my HOME directory were shadowed by the older ones which came with > XEmacs. "Shadowed" implies that you can't see the ones that come latter. Is that really the case? What should happen is that they are listed later, but you should still be able get them by following the right link.

1 participants
0 comments

Re: Info-directory-list 24 years, 3 months

Michael Sperber

>>>>> "Mike" == Mike Fabian <mike.fabian(a)gmx.de> writes: Mike> A slightly weird behaviour of XEmacs with respect to Mike> Info-directory-list is that it does use the value of environment Mike> variable INFOPATH, but appends it's contents to the end of Mike> Info-directory-list. Therefore, info-files in the Mike> .../lib/xemacs/xemacs-packages/info/ directory shadow info-files of Mike> the same names in directories from INFOPATH. Is this Mike> intentional? Sure, the hard question is whose intentions. This is historical behavior, and I re-implemented it purely for the sake of compatibility. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: "Symbol X has different size in shared object" bug reappears 24 years, 3 months

Daniel Pittman

On Wed, 05 Jan 2000, Martin Buchholz <martin(a)xemacs.org> wrote: > The rpath of the executable is supposed to be properly set to be > compatible with link time library search paths. Why isn't that > working the way it should? Debian fscked with the thing because the old xaw-wrappers which set LD_PRELOAD to the 3d Athena library you wanted was not as good as the new one. Especially as it only did this on request, not for everything. The new one, of course, puts libXaw on the rpath first but not on the link path. Everything gets the 3d library if linked against the flat library. Which is just grand. :( After all, looking pretty for most things and breaking a few is OK, is it not? > We do have the option of using AC_TRY_RUN to see if an executable will > actually run in our chosen environment. We could have tricky code > that checks compile-time headers, link-time libraries, and run-time > libraries for compatibility... I was starting to wonder about using the dlopen() function and friends to check that the Xaw library was sane. I don't know how possible it is; I have not used dlopen() on Linux before.... Daniel -- There are only two kinds of modern mathematics books -- those you cannot read beyond the first page and those you cannot read beyond the first sentence. -- C. N. Yang, 1957

1 participants
0 comments

Re: Info-directory-list 24 years, 3 months

Michael Sperber

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)iskon.hr> writes: Hrvoje> sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: Hrvoje> Info-directory-list should not be customizable at all. >> >> You're right. I suspect this perversion (Info-directory-list isn't >> even defcustom'ed) came about, because the documentation used to say >> `Info-default-directory-list' at that place, which never worked >> right either. Hrvoje> OK. Hrvoje> Now, what we need is a variable that *can* be customized, and that is Hrvoje> nil by default. Info would then use something like Hrvoje> (append <that-variable> Info-directory-list) for its directory search. Hrvoje> Code will be fully backward compatible wrt user customizations because Hrvoje> modifications of Info-directory-list will still work. Hrvoje> I propose that the new variable be named Info-default-directory-list, Hrvoje> because GNU Emacs calls it that way (and also defaults it to nil.) NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!! We *had* that variable once, and this sort of methodology greatly confuses users because of the staging implications, which is why I took it out. (The variable `Info-default-directory-list' must be set at a *certain* time, and given the way staging work, that time is pretty non-deterministic.) The current setup really wants complete control over the various -path and -directory-list variables. The answer to this question has to be, "Just stick your info files in the right place". Given the elaborate layout, this is not a problem. What you want eventually is to build a layer of abstraction over directory list which allows you to specify how to compose the actual directory list *at access time*. I've done most of the design work, but I have yet to find the time to hack it. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

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