January 2001 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Should XEmacs look for "./poe.el" on the load-path? 23 years, 5 months

Michael Sperber

>>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes: >>>>> "SJT" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes: >>>>> "mb" == Martin Buchholz <martin(a)xemacs.org> writes: SJT> This is decidedly counterintuitive to me. I would expect SJT> that "./" is an explicit reference to the current directory, SJT> and locate-library should only find the file there. mb> But do you also believe that mb> (load-library "mule/foo.el") mb> should search load-path? SJT> Yes. I have always thought that ./foo is an abbreviation for SJT> `pwd`/foo, and similarly for ../foo (although you can't define that SJT> similarly without self-reference). Ie, these are _absolute_ paths. SJT> That's the way the shell works, for example. Martin> Running the fictitious command Martin> $ mule/foo Martin> does not search PATH. It also uses _absolute_ paths, using your Martin> non-standard terminology, just like Martin> $ ./foo I agree with both of you. `locate-file' has at least one other bug connected with absolute file names. Unfortunately, there's quite a bit of code which expects (load-library "mule/foo.el") to search the load-path. So I suggest fixing ./ with locate-file, but leaving the other case alone. I'll do it along with the other bug, if you guys want me to. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

2 participants
1 comments

Re: Core Dump on make install latest 21.2 from CVS 23 years, 5 months

Michael Sperber

>>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes: >>>>> "SJT" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes: >>>>> "mb" == Martin Buchholz <martin(a)xemacs.org> writes: SJT> This change can be interpreted as making the treatment of Mule SJT> consistent between core and packages. Martin> But it's what the packages do that's broken. Users should think of a Martin> single set of packages, some of which have attributes, such as Martin> requiring mule, not two sets of packages. Well sure, but there we are now: Currently, Mule and no-Mule are completely different things, and the package system is broken. Once these two things are fixed (provided they ever will), then we can---and will---unify these things. I'm only suggesting that we reflect the current situation accurately, and solve the technical problem we're having right now. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

3 participants
2 comments

Re: Core Dump on make install latest 21.2 from CVS 23 years, 5 months

Michael Sperber

>>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes: >>>>> "MS" == Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes: MS> Yo Martin, Stephen, MS> could I get some feedback on this? >>>>> "Moiself" == Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes: Moiself> OK, I can see that. I hate the fact, however, that mule/ lives under Moiself> lisp/ --- it's not a true reflection of the dependencies here. It Moiself> would be much more natural, IMHO, to have a mule-lisp/ directory Moiself> alongside lisp/. Martin> Actually, I think that might be moving in the wrong direction. I Martin> don't like how mule is singled out for being odd, for examples in Martin> makefiles. I'd like to have no special treatment for mule files. >> From a user's perspective, it makes perfect sense to have Martin> lisp/ Martin> lisp/mule Martin> lisp/ldap Martin> lisp/C-LEVEL-FEATURE Martin> where perhaps the directory lisp/C-LEVEL-FEATURE is only added to Martin> load-path when FEATURE is available. Well, I think coupling filename syntax with symbol syntax even more tightly in this manner is a really bad idea. It would make more sense to add some metainformation to those directories. (My package redesign draft has provisions for this.) Note that we're talking about Core Lisp here, not packages, and that, as Stephen pointed out, Mule is different from the rest. Presently, we're also not just talking about simple feature availability here: a Mule XEmacs is an entirely different beast from a non-Mule one. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

4 participants
4 comments

Re: Core Dump on make install latest 21.2 from CVS 23 years, 5 months

Michael Sperber

>>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes: >>>>> "MS" == Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes: >>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes: >>>>> "MS" == Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes: >>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes: >>>>> "SJT" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes: >>>>> "mb" == Martin Buchholz <martin(a)xemacs.org> writes: Martin> I'm not sure I understand what the technical problem is right now. I Martin> assume we're still trying to solve the excessive stats problem. MS> Yup. Martin> What was wrong with my technical suggestion of Martin> - adding core lisp/ as a hierarchy of depth 0. Martin> - if mule, adding lisp/mule as another hierarchy of depth 0. Martin> - adding package hierarchies using a different depth. MS> Because then, the Lisp code treats the two directories as being MS> side-by-side whereas the physical relationship is "subdirectory of." Martin> This is a far smaller sin than renaming a directory, and is an Martin> implementation detail a user will never notice. MS> Your stated wish was not to treat mule/ specially, but your suggestion MS> does just that. Martin> No, other features could be treated the same way. You're losing me. Sure, they could be. But they shouldn't be. The same holds for what I suggest. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: Core Dump on make install latest 21.2 from CVS 23 years, 5 months

Michael Sperber

>>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes: >>>>> "MS" == Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes: >>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes: >>>>> "SJT" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes: >>>>> "mb" == Martin Buchholz <martin(a)xemacs.org> writes: SJT> This change can be interpreted as making the treatment of Mule SJT> consistent between core and packages. Martin> But it's what the packages do that's broken. Users should think of a Martin> single set of packages, some of which have attributes, such as Martin> requiring mule, not two sets of packages. MS> Well sure, but there we are now: Currently, Mule and no-Mule are MS> completely different things, and the package system is broken. Once MS> these two things are fixed (provided they ever will), then we MS> can---and will---unify these things. I'm only suggesting that we MS> reflect the current situation accurately, and solve the technical MS> problem we're having right now. Martin> I'm not sure I understand what the technical problem is right now. I Martin> assume we're still trying to solve the excessive stats problem. Yup. Martin> What was wrong with my technical suggestion of Martin> - adding core lisp/ as a hierarchy of depth 0. Martin> - if mule, adding lisp/mule as another hierarchy of depth 0. Martin> - adding package hierarchies using a different depth. Because then, the Lisp code treats the two directories as being side-by-side whereas the physical relationship is "subdirectory of." Your stated wish was not to treat mule/ specially, but your suggestion does just that. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

2 participants
1 comments

Re: Anyone using b39 non-Solaris + SIGIO + widgets + Motif? 23 years, 5 months

Raymond Toy

>>>>> "Andy" == Andy Piper <andyp(a)bea.com> writes: Andy> At 15:55 08/01/01 -0500, Raymond Toy wrote: Andy> problem under cygwin + motif, but then SIGIO is broken on that Andy> platform. I also do not have the problem under Linux + >> Athena but then Andy> it may be Motif related. >> >> >> Would it help you if I built without Motif? Andy> As a datapoint probably One more datapoint. I built LessTif 0.92.6[1] and told xemacs to use that instead of Sun's Motif. The progress gauge doesn't need me to wiggle the mouse around to move. It works basically as expected and it shows up nicely. Hurray! Yet another item for the PROBLEMS file? Ray Footnotes: [1] Using Motif 2.0 library. Couldn't get Lesstif to build the Motif 2.1 library. I think Sun's Motif is 2.1.

2 participants
1 comments

Should XEmacs look for "./poe.el" on the load-path? 23 years, 5 months

Stephen J. Turnbull

In the process of figuring out why Vin can't build mew, I discovered that "xemacs -l ./poe.el" will search the load path and find an installed APEL package. locate-library works[sic] this way as well. This is decidedly counterintuitive to me. I would expect that "./" is an explicit reference to the current directory, and locate-library should only find the file there. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

2 participants
4 comments

Re: Core Dump on make install latest 21.2 from CVS 23 years, 5 months

Michael Sperber

Yo Martin, Stephen, could I get some feedback on this? >>>>> "Moiself" == Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes: Moiself> OK, I can see that. I hate the fact, however, that mule/ lives under Moiself> lisp/ --- it's not a true reflection of the dependencies here. It Moiself> would be much more natural, IMHO, to have a mule-lisp/ directory Moiself> alongside lisp/. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

3 participants
4 comments

Re: Core Dump on make install latest 21.2 from CVS 23 years, 5 months

Michael Sperber

>>>>> "Stephen" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes: >>>>> "ms" == Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes: ms> would be much more natural, IMHO, to have a mule-lisp/ ms> directory alongside lisp/. Stephen> Agreed, in principle. What's keeping me thinking is trying to figure Stephen> out the impacts on other parts of XEmacs. Stephen> Note how your paths-load-paths-depth -> paths-core-load-paths-depth Stephen> change hosed the package build. Mule is much more pervasive. Absolutely. On the other hand, it kaboomed right quick, so we should know about any problems shortly after such a change. I do promise fast turnaround for fixing any problems that occur. Stephen> I realize this is a different kind of change, but this is the first Stephen> time I've thought about it. I like the analogy to xemacs-packages vs Stephen> mule-packages vs site-packages; risk should be low. But with 6 weeks Stephen> to release, I'm nervous, OK? It's a big change, and you don't usually Stephen> do Mule, right? Well, I guess I'll at least compile'n run with this now. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

resizing bug ? 23 years, 5 months

Fabrice Popineau

Open up a vanilla xemacs, split the scratch buffer in two parts using 'C-x 2', resize the frames's height down using the mouse, and then up. The 2 parts that used to be equal are not anymore. If you resize down enough, the upper window disappears (null height ?). Bug ? -- Fabrice Popineau

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 2001