October 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Reminder about patches for XEmacs Lisp packages with maintainers 25 years, 9 months

SL Baur

I will *never* apply patches to packages that are actively maintained. If you send them only to me or xemacs-patches they won't be applied, *period*. Please Cc the maintainer listed in the prolog at the top of the file for his approval or disapproval. We are migrating towards Lisp package authors having direct control over their source code in the CVS repository. We will be moving further in that direction in the months to come.

1 participants
0 comments

Re: Why using (push-mark) ? 25 years, 9 months

Hrvoje Niksic

SL Baur <steve(a)xemacs.org> writes: > Setting the mark on these movement commands is different than all > the other movement commands which don't. It's inconsistent and > stupid (IMO). Only the problem is that I like setting the mark, as long as the region is not active. 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. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- there's a beast upon my shoulder / and a fiend upon my back

1 participants
0 comments

Re: Why using (push-mark) ? 25 years, 9 months

SL Baur

Kyle Jones <kyle_jones(a)wonderworks.com> writes in xemacs-beta(a)xemacs.org: ... > I'm not talking about hideously complicated semantics here. All > you need to know and remember to avoid mayhem is that M-< and M-> > set the mark. This is too much to learn? Yes. We apparently agree to disagree on issues like this. Signaling errors when attempting to move beyond buffer boundaries is idiotic behavior, but enshrined for all-time as "standard". I've been overruled on this issue, but that doesn't stop from attacking other windmills. Setting the mark on these movement commands is different than all the other movement commands which don't. It's inconsistent and stupid (IMO). I'd suggest coming up with new functions for `beginning-of-buffer' and `end-of-buffer' which do not set the mark and allowing users to bind them to M-> and M-< if they see fit.

2 participants
1 comments

xemacs/gdb integration? 25 years, 9 months

Aakre, Louise

Hello, Does an xemacs/gdb integration exist? If so, can you point me to a web page or faq with info? Note: I tried to mail this to faq(a)xemacs.org but was not able to send successfully. Thanks for your assistance, Louise Aakre AT&T Wireless Services

2 participants
1 comments

Re: files with extension .EL ?? 25 years, 9 months

SL Baur

Rick Campbell <rick(a)campbellcentral.org> writes in xemacs-beta(a)xemacs.org: ... > They're present in the hopes someone will hack on them. They have > extension .EL instead of .el so batch-update-directory doesn't puke > and die on them since they're pure poison. > Does this hack work with (partially?) case-insensitive file systems, > e. g. vfat? You tell me and we'll both know. Case-insensitive file systems deserve to lose, but I'm willing to entertain suggestions. > I don't do mule so it shouldn't really affect me, but I can't help > but think that another naming convention would be better. Maybe > .el.broken? I really don't care what the names are so long the files get installed.

1 participants
0 comments

Re: GCC2 merging (was "native language support now available") 25 years, 9 months

Hrvoje Niksic

SL Baur <steve(a)xemacs.org> writes: > >> > They gained a short-term advantage by not asking contributors > >> > for legal papers, the way I do; that endangers the ability to > >> > enforce the GPL for XEmacs.[1] [...] > [1] Copyright assignment papers or not, I don't know of anyone "in > the XEmacs camp" who has any desire whatsoever to endanger the GPL > status of XEmacs. As far as I'm concerned un-GPLing XEmacs would > have to occur over my dead body. What he means is: if Microsoft were to enhance XEmacs and not give out the source, it would be very hard for any of us to sue them because of the copyright being spread over many different persons and companies. Not that I endorse his disgusting attitude; I'd just like to clarify his meaning. -- 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.

2 participants
1 comments

Re: Why using (push-mark) ? 25 years, 9 months

Hrvoje Niksic

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > >>>>> "Kyle" == Kyle Jones <kyle_jones(a)wonderworks.com> writes: > > >>>>> Hrvoje writes: > > >> As I said, we're plain lucky that our users never notice this > >> gorgeous feature. > > Please respect the preferences of others. I don't feel as you do. Grr. "our users" == majority of users. Of course I respect your choice, even if I am not articulating that respect too clearly. :-) > I just happen to value the convenience of having those functions > change the mark so that I don't have to remember to do so, more than > the inconvenience of having to organize my thoughts about the mark > so that I don't make (what are as far as I can see) irrelevant > cursor movements after setting mark. Users like you (and, of course, Kyle, but she is totally unique in other ways) are the reason I am wary about making such changes. As important as it is not to screw new users, it is more important to not break usage patterns for the old ones, in equally subtle ways. > True, this can cause data loss. Nothing that C-y or M-x undo won't > solve, Yes, but that's not the point. The point is that it is hard to notice this feature; you start by thinking that it was you who did something wrong. See some of my discussion with Kyle. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Bumper sticker on the stealth bomber: "IF YOU CAN READ THIS, THEN WE WASTED 50 BILLION BUCKS."

1 participants
0 comments

Re: Why using (push-mark) ? 25 years, 9 months

Hrvoje Niksic

Kyle Jones <kyle_jones(a)wonderworks.com> writes: > > Yup. Like I thought. Potentially damaging and very subtle. :-( > > Yes! Just like C-w. Useful. Deadly. But not "potentially damaging and very subtle". C-w is *visible*. > I can't argue with you if you want to make the interface safe for > small children. We simply will not agree. You misunderstood what I meant by "subtle". C-w is anything but subtle. But it is still quite possible that we will not agree. > I'm not talking about hideously complicated semantics here. All you > need to know and remember to avoid mayhem is that M-< and M-> set > the mark. This is too much to learn? It is totally non-obvious and requires conscious memorization. As I said, I've memorized it, but I've never really gotten used to it. That kind of non-intuitiveness has nothing to do with safety for small children. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Try to use "ad nauseam" at least once per flame. It doesn't mean anything; but it gives that polished feel to your postings.

1 participants
0 comments

Re: [PATCH] SIGPIPE redux -- please review 25 years, 9 months

SL Baur

Kyle Jones <kyle_jones(a)wonderworks.com> writes in xemacs-beta(a)xemacs.org: > I think the patch introduces a descriptor leak. Not according to my tests. I repeatedly hit the code in the patch and didn't see any increase in fds in /proc. Would this be O/S dependent? > The lstream needs to be closed, but we either must avoid flushing > its buffers them or ignore the SIGPIPE when we flush them. The > latter will do for now, but we should add a "no flush" flag to > lstreams so that the lstream close method can avoid trouble when we > know the remote endpoint of a socket has gone away. Unless there's an O/S which does leak descriptors, I think the patch I posted is good enough. The condition certainly seems rare enough that even if some system did leak descriptors it wouldn't be that bad, and it's certainly better than a coredump. > Alternately an Lstream_discard_buffers function might work as well > and have other uses. Of the two suggestions, a "no flush" flag sounds like the better idea. > I'm pretty sure that I fixed the Gnus SIGPIPE crashes last year, but > it probably got undone with process.c got ripped apart during the > Windows frenzy. I don't know. > That would explain the deja vu feeling related to these crashes. I did get Deja Vu looking over the code where the crash was occurring. I'm reasonably certain this was fixed at some point. Without my patch, it is definitely broken on the system I'm testing on.

1 participants
0 comments

Irchat contains strong Crypto.. 25 years, 9 months

Jan Vroonhof

irchat seems to contain strong crypto (idea.el). [1] Moreover the package also does not work as 'irchat-version' is not present. I suggest we pull the package. If the CVS is in the US that also needs to be dealt with :-( Jan [1] idea is also patented.

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