KK> "John A. Turner" <turner(a)blueskystudios.com&gt; writes: KK> Well, I meant it strongly enough to indicate that I'm annoyed KK> that an odd definition of "progress" is present, and I think KK> such annoyance is justified. mb> I agree. Um, I have had _no_ problem with the progress bar, also a gutter widget, since the Xaw3d problems with it were fixed. So gutters and tabs should be separated in this discussion. Tabs are not making progress, IMO, but that is at least partly problems in the upstream implementation. Not to say we shouldn't be as careful about imposing buggy 3rd party implementations on testers and users as we are about stuff we maintain. Rather, to point out that if using the 3rd party implementation is the Right Thing, we should expect coordination delays. Coordination delays are the flip side of reusability, which is what free software is all about, right? I don't know what to do about the tabs, though; I lean to saying "this is an experimental feature that should be #ifdef'd properly and off by default in beta releases until we feel there's some stability." (Sorry, Andy.) KK> Andy, I don't mean to offend you personally, but one does have KK> to wonder what experimentation with a fix happens before it KK> lands in CVS. Is it any surprise that such wonderment exists, KK> when tabs literally don't work at all? IIRC, Andy mostly works under the Windows platform, where tabs "just work". Regardless of this particular case, in a multiplatform development process, this kind of thing is going to happen. I don't see why alpha quality code shouldn't be committed to CVS on a new feature; it just shouldn't be configured in by default---people who want to work on the feature should have to turn it on explicitly. Am I missing something, or does this basically keep development moving while not imposing on testers who don't need this particular new feature? mb> The control of quality on free software projects is a hard mb> problem, given that hacking on new features is generally mb> cooler. We'll see if the commercialization of free software mb> will make a difference. And personally, I'm trying to make a mb> difference. Anybody have a contact with Anal-Compulsives Anonymous? :-) mb> - We'd like to solve any redisplay/gutter code stability mb> problems. Make sure it's the gutter and not the tabs code. mb> Andy, I'd like to see these things for the gutter feature: mb> - documentation Oops, did I forget to submit that patch? I've done a lot of this, at least a skeleton of the info docs. I wanted to add an example; sorry, I guess I did let it slide. I will submit a patch by the end of today. mb> - turn off by default for non-beta releases. Or, we could mb> hold a vote in xemacs-beta or even comp.emacs.xemacs as to mb> whether this feature is one they are using. Unfortunately, mb> getting an unbiased result of such a vote is tough. As mentioned above, I think tabs ought to be turned off by default even for beta releases until they stabilize a bit more. Martin, when the development branch release maintainer is unwilling to run with an unstable feature on by default, don't you think imposing it on others is a bad idea? If you turn it off by default at the /.configure stage, then you and the large group of users who all have put (setq use-tabs-p 'hell-no) in their ~/.emacs can take it out, and will automatically see the tabs again when they're considered stable enough to promote from alpha to beta. I'm sure that many people like me will continue to use it in at least one of their XEmacs sessions, and it doesn't cost us much---use it once, then run ./config.status --recheck. (Does ./config.status allow you to change configure flags?) I've been bitten several times, where I turned off an annoyingly buggy feature that I actually wanted, or could have provided useful feedback on, but didn't actually start using it until much later because it was defeated in ~/.emacs. We should try to arrange things so that beta testers only turn off features because they dislike them, not because they're afraid they'll wipe out several hours' work twice in the same day or aggravate eyestrain. -- 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."

At 04:27 PM 2/16/00 -0800, Martin Buchholz wrote: The problem is that I have to do things under both mswindows and about 3 variants of widgets under X. It always works for me under windows (hence generally no complaints on xemacs-nt) but for the X stuff I have to rely on other people to report problems. Stephen Turbill has done some great documentation. The API needs to be changed a little first before finalizing it. Please don't judge it until I at least think it is stable. I don't think it is there yet, but it is close, despite the breakage people are seeing. Unfortunately the working or not of the tabs is usually a symptom of the underlying core widget code it is basically the core I am trying to get right, not the tabs themselves (apart from the frequent breakage from the X widget). andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

At 03:21 AM 2/18/00 +0900, Stephen J. Turnbull wrote: Yes, I'm not sure how well this is going to work once we try and put multiple things in the gutter. I've been considering allowing the definition to be a list of strings also, but I don't know how well this would work. The current scenario is almost identical to the way buffers work (the code is taken entirely from there, not from the modeline code). Its still great that there's anything at all. Will do. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd