January 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: rssh.el interactions with ange-ftp/efs 25 years, 10 months

WJCarpenter

SR> If memory serves me right, at the time, the Internet Engineering SR> Draft that defined the URL syntax allowed for no way to specify SR> the username that you wished to use to access the remote file. kifer> I dunno about the IED, but Netscape has been supporting the kifer> ftp://user＠machine/path syntax for many years now. There is no These things are well-specified in RFC-1738, published in December 1994. See, in particular, section 3.1 et seq. -- bill(a)carpenter.ORG (WJCarpenter) PGP bill(a)bubblegum.net 0x91865119 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3

1 participants
0 comments

Building a Binary Distribution 25 years, 10 months

David Maslen

I've been using xemacs21-b62 for a little while know and I'm pretty pleased with it for my daily use. I'd like to install it on my laptop, and I don't want to rebuild it from source there. Is there a make option to produce a tarball for an easy install in the /usr/local/ directory on my laptop? I didn't see one. There must be other people wanting to do this, what's the usual proceedure? It could be worth my while to mention I'm using Debian Linux, so if anyone has gone to the trouble of creating a patch for the debian packaging system, I'd be grateful for a copy. -- Binary Bar - Australia's first free access internet bar/cafe/gallery. 243 Brunswick Street, Fitzroy, Melbourne, Australia. 3pm - 1am http://www.binary.net.au/ Running on Debian/GNU Linux

1 participants
0 comments

Re: Beware of modules. 25 years, 10 months

Hrvoje Niksic

Olivier Galibert <galibert(a)pobox.com> writes: > Do you realize that if external third party C modules become the > rule, we can't change anything to the Mule implementation or the > lisp system? That we couldn't have ported to win32? That the "gung > ho" changes would have been impossible to make? I don't think we need to worry about binary compatibility at all. It's clear that, given the current state of affairs, it is impossible to maintain anything close to that. As for the source compatibility, the only sane way of handling modules I can think of is to define and document a *minimum* set of primitives that are allowed in modules. But not even these should be cast in stone, I think -- modules are pretty much meddling with the implementation (more convenient meddling, but still meddling), and we should always have a right to change it.

1 participants
0 comments

Re: rssh.el interactions with ange-ftp/efs 25 years, 10 months

Hrvoje Niksic

Richard Stallman <rms(a)gnu.org> writes: > Why propose so much effort just to use an alternative to ftp? ftp > seems to work; what benefit would we have from the option to use > another alternative? Many people are dissatisfied with FTP's inherent insecurity due to passwords being transmitted over the network in clear text. This is a serious breach of security and a possible breach of privacy, and a good enough reason for many users to abandon FTP completely.

2 participants
1 comments

Re: enhanced pop3.el 25 years, 10 months

Adrian Aichner

>>>>> "Andy" == Andy Piper <andyp(a)parallax.co.uk> writes: Andy> At 13:35 15/01/99 +0100, Adrian Aichner wrote: >> However, password caching does not work. Andy> Have you set pop3-cache-password to t? Yes I did (via customize-variable) and I verified it to be t. BUT, pop3-password remained an undefined variable for me. Why? Thanks, Adrian Andy> andy Andy> --------------------------------------------------------------------------- Andy> " .sigs are like your face - rarely seen by you and uglier than you think" Andy> Dr Andy Piper, Technical Architect, Parallax Solutions Ltd Andy> mail: andyp(a)parallax.co.uk web: www.parallax.co.uk/~andyp -- Adrian Aichner European Design Center Teradyne GmbH Semiconductor Test Group Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-217 (What is a Fax?) D-81673 MUENCHEN E-mail adrian.aichner(a)teradyne.com

1 participants
0 comments

Re: Beware of modules. 25 years, 10 months

William M. Perry

Olivier Galibert <galibert(a)pobox.com> writes: > On Fri, Jan 15, 1999 at 01:26:18PM -0800, J. Kean Johnston wrote: > > So I guess the answer to OG's question is a resounding "YES", we will > > "plug into C code". > > Which means that we're going to have compatibility problems each time we > change something in the internal C interfaces. This is already a > terrible pain for the lisp code, and you want to extend that to the C > code? Yes. :) > Do you realize that if external third party C modules become the rule, we > can't change anything to the Mule implementation or the lisp system? > That we couldn't have ported to win32? That the "gung ho" changes would > have been impossible to make? And the most likely person to be writing 3rd party modules in the near future (me for Emacs/W3 and various other stuff) is fully aware of that. For most of these things, a simple recompile would be in order For major changes, that is what major version numbers and version checking are for. :) -Bill P.

1 participants
0 comments

Re: Beware of modules. 25 years, 10 months

Marat Boshernitsan

Olivier Galibert <galibert(a)pobox.com> writes: > On Fri, Jan 15, 1999 at 01:10:33AM -0800, Marat Boshernitsan wrote: > > I need even more extensibility than XEmacs lisp gives me, > > and modules do just that. > > Nice. Now my question is, is being able to add C functions callable > from lisp enough for you, or do you need to "plug" into the C code > itself one way or another? > > OG. Yes. Just being able to add my own list primitives written in C is enough in my case. I do need a bit of support from runtime for things like allocating new lisp objects, but that's pretty much it. Marat.

1 participants
0 comments

Re: Deleting broken in Python, or why delete-key-deletes-forward sucks 25 years, 10 months

Hrvoje Niksic

Glynn Clements <glynn(a)sensei.co.uk> writes: > Is this really the right approach, or is it a workaround for > delete-key-deletes-forward not being console-local (or whatever the > correct term is)? I don't remember anymore. I do remember, however, that `delete-key-deletes-forward' was supposed to be a user choice, which means that key-above-enter should delete backwards no matter how you set it. The current behaviour is in agreement with that philosophy.

1 participants
0 comments

Benchmarking XEmacs (was Re: Beware of modules.) 25 years, 10 months

SL Baur

Hrvoje Niksic <hniksic(a)srce.hr> writes in xemacs-beta(a)xemacs.org: ... > Totally off-topic, but if someone mentions the "30%" figure once > again, I'll SCREAM! It's a myth. Subjectively, Mule is at least 3 > times slower than non-Mule -- Not to me, but I won't push the matter. XEmacs/Mule is slower, but not three times slower. On any kind of decent Pentium the performance is acceptable, PIC and all. > and Martin's benchmarks confirmed that "30% slowdown" is an insulting > euphemism. What Subject: did he post them under? The last benchmarks I did showed Mule slowdown ~10-50% depending upon the benchmark.

2 participants
1 comments

Re: BAD BAD bloat (was Re: What to do with modules now ...) 25 years, 10 months

Pete Ware

I think the benefits of making XEmacs modular are identical to the benefits of splitting the lisp code into packages. [That is an intentionally ambiguous statement] I think the more that can be done to define the core XEmacs the easier it is to have developers in particular areas. --pete

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