October 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: efs-load/require sllloooooowwww 26 years, 1 month

Michael Sperber

>>>>> "Andy" == Andy Piper <andyp(a)parallax.co.uk> writes: Andy> sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: >> Actually, the xemacs-nt folks have been very secretive about what the >> actual problems with EFS on NT are. However, I've received some mails >> about this, and I absolutely intend to do what I can to fix the >> problems once I understand them and their proposed solutions. This >> will have to wait until after the 21.0 release, though, I'm afraid. Andy> Err, I think you are wrong about this Michael. I have seen several Andy> posts to xemacs-review and xemacs-beta and you relating the problem Andy> and providing patches over an extended period of time. I think it is a Andy> fundamental mistake for EFS not to work with NT on 21.0. Maybe I am. All mails I know about (not counting merely telling me that there are problems) are one by Jonathan, and a very recent one by Adrian. Someone (Jonathan?) told me that there had been considerable discussion about this on xemacs-nt (which I don't read), but that there was no universal agreement on what needed to be done. Jonathan's patch may fix this. Andy> Please reconsider. I personally think this should be on Ben's Andy> showstopper list since we can fix it right now. This has nothing to do with reconsideration. I simply don't have the time right now, and we can fix the problem independently of the release. I'll get to it as soon as I possibly can. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

2 participants
1 comments

DLL support, Re: Emacs' Future 26 years, 1 month

Jan Vroonhof

The following message is a courtesy copy of an article that has been posted to comp.emacs as well. Dave Love <d.love(a)dl.ac.uk> writes: > -- is still expected to happen at some stage (says Handa). Oh, and > 20.5 should support dynamic loading of object files consistently with > XEmacs' implementation -- Bill Perry be praised, as always. Hmmm.. Somebody is just contributing a whole new DLL support module to XEmacs. It would be a pity that if for once there is effort going on to keep the two more or less in line the XEmacs side would screw it up. IMHO this a major reason to stay with the old method for XEmacs or alternatively that the new implementation be sent to RMS for inclusion in stead. Jan

4 participants
3 comments

Re: Why using (push-mark) ? 26 years, 1 month

Jan Vroonhof

Hrvoje Niksic <hniksic(a)srce.hr> writes: > For example, I often press M-< and then decide that I want to get back > where I was before. `C-x C-x' or `C-u C-SPC' works perfectly for > that, thanks to mark-pushing. Which exactly the root of the problem. The mark is used for two different things, i.e. remembering old cursor positions and marking one edge of a region. Sometimes these clash. A much cleaner solution would be to separate the two functions better. For instance I like the fact that I can return to where I was after an isearch but I would also very much like to just mark the beginning of the reason and then jumping to (near) the end by isearching. Jan

1 participants
0 comments

Re: GCC2 merging (was "native language support now available") 26 years, 1 month

Kai Haberzettl

SL Baur <steve(a)xemacs.org> writes: > ftp://altair.xemacs.org/rms-jwz.tar.gz Hmmm. That file is not there. Kai -- The other day I was playing poker with Tarot cards. I got a full house and four people died. --Steven Wright

2 participants
1 comments

Re: Why using (push-mark) ? 26 years, 1 month

Hrvoje Niksic

Kyle Jones <kyle_jones(a)wonderworks.com> writes: > > As I said, we're plain lucky that our users never notice this > > gorgeous feature. > > ummm, _I'm_ one of your users. You can't notice the feature because you are a) a long-time Emacs user, and b) run with zmacs-regions == nil. I'm not sure which one is more important. > Do I have to unsubscribe to xemacs-beta and feign ignorance to have > a voice that matters? Why do the "loyal customers" have to battle > just to keep the tool we love, just so you can attract new > customers? I don't understand these questions. I think my point was clear enough. > transient-mark-mode/zmacs-regions broke all kinds of stuff, all so > that some folks could see the region. A visible region could have > been implemented without the crock that we have today. Now that we > have the crock you're going to make it worse by changing the marking > rules under zmacs-regions. I'm not arguing that the actual change should be done yet (that would be Didier). I'm trying to establish that the current behaviour is far from obvious, so we disagree at the very start. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Mix 2 table spoons sugar with 1 spoon salt. Put it in a bottle and stick a fuse into it. Say "Shit!" when it doesn't detonate.

4 participants
4 comments

Re: Irchat contains strong Crypto.. 26 years, 1 month

William M. Perry

Rick Campbell <rick(a)campbellcentral.org> writes: > [1 <text/plain; US-ASCII (7bit)>] > From: SL Baur <steve(a)xemacs.org> > Date: 14 Oct 1998 01:16:20 -0700 > > XEmacs is small fry and we have done such civil disobedience in the > grey area of Mailcrypt since before my time. It contains crypto hooks > and thus is barred by the EAR. > > IANAL, but I think that you're wrong about this. The coupling is very > loose -- it runs a seperate program that contains crypto, but one could > put another filter in it's place and still have the package do useful > things. > > I don't recall all of the details, but someone claiming to be a lawyer > (Duncan??) on cypherpunks a few years back said that packages like > mailcrypt and my own PGP Augmented Messaging were outside the scope of > (at the time) ITAR and (I would assume) EAR as far as they address > ``hooks'' in software. Well, I would still think things like 'ssl.el' would be out. It has no other purpose in life than to provide ssl encryption. Via an external program still, but... :) Then there are my patches to add native SSLeay support that got lost ages ago, that would DEFINITELY be bad mojo. :) -Bill P.

1 participants
0 comments

Re: GCC2 merging (was "native language support now available") 26 years, 1 month

Hrvoje Niksic

Rick Campbell <rick(a)campbellcentral.org> writes: > [1. text/plain] > > From: Hrvoje Niksic <hniksic(a)srce.hr> > Date: 14 Oct 1998 11:23:49 +0200 > > Rick Campbell <rick(a)campbellcentral.org> writes: > > > I still believe that an FSF suit against Microsoft would be a > > joke. > > Why do you think so? The NeXT did quit. > > I'm not understanding you. What do you mean by ``The NeXT did > quit.'' -- I'm assuming that you refer to a lawsuit of which I'm not > aware. I am referring to the incident when NeXT created an ObjC backend for Gcc and wanted to distribute binaries only. FSF threatened to sue, and NeXT gave in, apparently because their lawyers informed them that they would lose the lawsuit. As a result, Gcc now supports ObjC. Although this incident is in no way equivalent to being tested in court, I consider it a compliment to the legal strength of the GPL. This is also how I envision an argument between FSF and Microsoft -- noone goes to court unless they feel they can win. > If your statement involves relating NeXT to Microsoft in terms of > power and size, I'll argue against that point of view. There's nothing to argue against. I'm just describing what happened in a real-life case when GPL was threatened by a corporation. I concede that with Microsoft things could turn out for the worse. > In any case, I think that a lawsuit by FSF against Microsoft would > be a joke because I'm cynical enough to think that money and power > are bigger factors in determining outcome than being in the right. Maybe. I don't know. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Call CIA and tell them that you have placed a bomb in a 7-11 shop! Be sure to let them trace you. Spend 10 years in jail and then regret it.

1 participants
0 comments

Re: GCC2 merging (was "native language support now available") 26 years, 1 month

SL Baur

Rick Campbell <rick(a)campbellcentral.org> writes in xemacs-beta(a)xemacs.org: > To put the question back to you. What if Microsoft were to view > XEmacs as a spec and, without using any GPLed code, implement a fully > compatible, fully functional 95/98/NT implementation. How would we be > hurt? By having the emacs user community grow too large?! We don't have enought resources to do development as it is let alone provide detailed support.

2 participants
1 comments

Re: Why using (push-mark) ? 26 years, 1 month

Didier Verna

Kyle Jones <kyle_jones(a)wonderworks.com> writes: > I wrote these queswion because at this moment I'm feeling majorly > picked upon. My opinion has less value apparently because I > understand how Emacs works. So instead of encouraging users to > become more like me, i.e. grokking things beyond the obvious, > we're doing the opposite. I find this terribly distressing--- > far more distressing than the change of a particular behavior, > which would be of no consequence to me anyway. First, your opinion has much value and you know this. Second, making things *look* unlogical at a first glance is not the way to encourage users to become like you. It's encouraging them to use something else. When something appears to work not logically (I didn't say "not obviously"), the most common reaction is not to investigate the manual, but to think that there's a bug. The documentation and the doc-strings are here to let people know that they can do complex things. > I agree that the behavior is not IMMEDIATELY obvious or logical. > Many things aren't. But as you learn more, non-obvious things > start to make more sense. Thus my point about not catering to > ignorance. But the point I try to raise is precisely that "obvious" and "logical" are different things. I have nothing against non-obvious behavior as long as this behavior doesn't fuck up the obvious one, which is the case right now. Let me make this clear: let's consider an XEmacs feature, the ability to move around and mark a place in the buffer. This feature has obvious aspects and non obvious ones. The obvious one (the most intuitive) is that after you set the mark somewhere, the region is hilighted, and when you move around, the region extents between the place you marked and the current point. Well. You can experiment this with the basic motion commands, `next-line' and the like. Now suddendly, you try to use M-> and M-<, and you discover that the beginning of the region you had marked before has changed. _THIS IS NOT LOGICAL IN ANY WAY_. What happens here is that in order to achieve a more complex behavior (a *non-obvious* one), you fuck up the logic of the simple behavior. This is the ONLY thing against which I'm fighting. Now, second step. You learn about the non-obvious behavior and you find it interesting. You decide to use it. In order to use this behavior, you need a special feature, namely, you need to allow some functions to push the mark (Stephen, for instance, does even want to push the mark even if it's already set). This is something non-obvious at all, and consequently *you* should have to position some non-obvious variable in order to get it. Not the other way around. Am I clearer ? To summarize: in any kind of software, each feature has different levels of complexity. This is good because experimented users do want to be able to achieve complex things. However, for each feature, the immediate level of complexity should *always* be the simplest one in order to let people learn progressively how to use the software. Finally, if you want to use the feature in a more complex manner, *you* should have to say so in some manner. And most important: if, in order to make things work in the non-obvious way, you have break the logic of the obvious way, then the feature is completely bogus. As far as our particular matter is concerned, I have absolutely nothing against beginning-of-buffer pushing the mark, and doing so even if the region is already active, but this is a damned *non-obvious* thing and consequently shouldn't be the default because by default, *it's not logic*. On the contrary, if you want to enable this non-obvious feature, you should have to say it explicitely, like (setq long-moves-override-mark t), and then - you get the behavior you want - you don't impose a non-obvious behavior onto the other, especially the newcomers - you don't break the logic of the feature, because now, the mark is indeed pushed, but this is logic since you requested it. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

1 participants
0 comments

Re: Package build error in "Pyrenean-pre4" 26 years, 1 month

Paul Bibilo

SL Baur writes: > Paul Bibilo <peb(a)delcam.com> writes in xemacs-beta(a)xemacs.org: > > > I CVS updated everything, removed all my .elc's, and rebuilt > > everything with a non-mule XEmacs. > > > I had problems building the following package files. > [Ediff and mew problems deleted] > > I'm not making new package kits because these are build fixes. They > have been committed to CVS. Please do a cvs update in comm/mew and > prog/ediff and things should work a bit better. > Done. Everything OK now, thanks. -- Paul

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 October 1998