Re: insinuation bug/misfeature/suggestion in RMAIL
On August 8, [EMAIL PROTECTED] said: First, a bug report, sort of. I use RMAIL but almost never the RMAIL summary mode. Insinuating into RMAIL causes trouble, as bbdb-insinuate-rmail includes (define-key rmail-summary-mode-map : 'bbdb/rmail-show-sender) among other stuff. Of course, (require 'rmailsum) before loading bbdb takes care of that, but it does not seem like a very clean solution. Was this from a non-CVS version of BBDB? Currently, BBDB-cvs has: (eval-when-compile (require 'bbdb) (require 'bbdb-com) (require 'rmail) ;(require 'rmailsum) ; not provided, dammit! (if (not (fboundp 'rmail-make-summary-line)) (load-library rmailsum)) ;; just to avoid a warning (if (not (boundp 'rmail-buffer)) (defvar rmail-buffer nil))) Which is ugly as hell, but should have cured the bug you mentioned. Cheers, Waider. -- [EMAIL PROTECTED] / Yes, it /is/ very personal of me. I'm the guy behind the guy next to the guy who thinks he's the guy but actually works for the guy who really is just a huge dork. Yeah, it sucks. - Rands --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ bbdb-info@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bbdb-info BBDB Home Page: http://bbdb.sourceforge.net/
Re: insinuation bug/misfeature/suggestion in RMAIL
Ronan Waide [EMAIL PROTECTED] writes: On August 8, [EMAIL PROTECTED] said: First, a bug report, sort of. I use RMAIL but almost never the RMAIL summary mode. Insinuating into RMAIL causes trouble, as bbdb-insinuate-rmail includes (define-key rmail-summary-mode-map : 'bbdb/rmail-show-sender) among other stuff. Of course, (require 'rmailsum) before loading bbdb takes care of that, but it does not seem like a very clean solution. Was this from a non-CVS version of BBDB? Currently, BBDB-cvs has: (eval-when-compile (require 'bbdb) (require 'bbdb-com) (require 'rmail) ;(require 'rmailsum) ; not provided, dammit! (if (not (fboundp 'rmail-make-summary-line)) (load-library rmailsum)) ;; just to avoid a warning (if (not (boundp 'rmail-buffer)) (defvar rmail-buffer nil))) This shuts the byte-compiler up at compilation time. It does not do much good at run time, if I do not have rmail **and** rmailsum loaded. Or I am missing something major here. --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ bbdb-info@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bbdb-info BBDB Home Page: http://bbdb.sourceforge.net/
Re: insinuation bug/misfeature/suggestion in RMAIL
Ronan Waide [EMAIL PROTECTED] writes: On August 10, [EMAIL PROTECTED] said: I am also (personally) not thrilled with the attitude of refusing to support CVS Emacs. I understand the reasoning behind it---trying to catch up with a moving target plus lack of resources. My major gripe with trying to support CVS Emacs (or CVS XEmacs, for that matter) is simply that it's not stable (this has also applied to several dot releases of Emacs, in particular the 20.x series which seemed to break multibyte characters with almost every release). I get someone sending me a mail about a bug this week, and next week it's not a bug anymore because it was a bug in Emacs, not BBDB, and it's been fixed at source. Regardless of issues of moving targets or lack of resources, trying to maintain a complex piece of code on top of an unstable platform is a complete waste of time. True and I agree. That's part of what I meant by moving target. A reasonable way out of this, however [especially since there are I think a number of CVS Emacs users on this list, so you get a some testing base] is to try and track down the problem, sit on it for a couple of weeks (major CVS trouble/bugs/glitches usually get caught in a day or a couple of days at the worst) and then incorporate the change. It would be nice if an official policy regarding BBDB was stated someplace. I disagree. Official policies are for products and politicians. BBDB is neither; BBDB is, and always has been, hackerware, and while much has been done to make it less menacing to those unfamiliar with lisp, it's still a rat's nest of surprises and dead ends and really, if you're doing anything non-trivial with it, you'll have to get your hands dirty with lisp at some point. I did not mean that one should have a 100 page policy manual, with a full-time lawyer. However, being the maintainer [or whatever your official title is] you are in effect in charge of what changes are made, if ever (short of forking another version and local hacks). Hence it is nice to know which changes you will not consider, more or less as a matter of policy. My own official policy Understood. This was precisely what I was looking for. I don't object to maintaining BBDB; on the contrary, I volunteered for the job when noone else seemed to be interested. I do object to anything that makes it more of a chore than it already is. Which I think is a rough summary of what I've said above. Thanks for volunteering... And now, we return you to our regularly scheduled list traffic. I'll drink to that. :) Cheers, --Boris --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ bbdb-info@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bbdb-info BBDB Home Page: http://bbdb.sourceforge.net/
Re: insinuation bug/misfeature/suggestion in RMAIL
Let me begin by reiterating that I am thankful for anyone who invests significant effort in maintaining bbdb. Ronan Waide [EMAIL PROTECTED] writes: Let me restate: I said: been fixed at source. Regardless of issues of moving targets or lack of resources, trying to maintain a complex piece of code on top of an unstable platform is a complete waste of time. To which you replied: ...try and track down the problem, sit on it for a couple of weeks (major CVS trouble/bugs/glitches usually get caught in a day or a couple of days at the worst) and then incorporate the change. What part of this isn't a complete waste of my time? What part of this couldn't be better served by someone who already runs CVS Emacs on a daily basis and uses BBDB? Did I say anything about YOU having to do all the work? I do run CVS Emacs on a daily basis and use BBDB. I do not feel comfortable sending in changes when I am unsure if they really work for everyone. I am not in position to test them for a multitude of platforms, flavors, and versions of Emacs. Like I said, I won't turn down patches that are non-invasive fixes for CVS Emacs; I *will* turn down patches that are simply trying to use new features that I would otherwise have to backport or conditionally compile or whatever, and I will turn down code that breaks my running system in favour of making CVS Emacs happy. Fine. Now, please. I think I've made it clear that I'm quite stubbornly adherent to this point, so can we let this be the last mail on the topic? I'd rather hear more from people with bugs that need fixing and means of reproducing them (hello emacs_user...) than discuss niceties of how I'm willing to spend my time. I absolutely have to have the last word It's a little glitch in my soft/hard/wetware. :) Did not mean to step on anyone's toes... --Boris --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ bbdb-info@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bbdb-info BBDB Home Page: http://bbdb.sourceforge.net/
Re: insinuation bug/misfeature/suggestion in RMAIL
On August 8, [EMAIL PROTECTED] said: [-] stuff. IMHO, none of this stuff should be executed in a mode hook, but on load of the mode file. What you have to bear in mind is that much of this code predates things like advice (and possibly eval-on-load), and has not significantly changed since it was written for emacs 18. In particular, bbdb-vm and bbdb-gnus tend to be the most up-to-date sections as they're what I and one of the other main contributors use on a daily basis. I'm looking at changing this situation somewhat, but I'm not making any promises up front! If you wish to contribute patches, etc. feel free to do so bearing in mind that whatever you contribute needs to work on both Emacs and XEmacs. BBDB is allegedly baselined against Emacs 19, but I don't entirely believe that's true any more, and there's a lot of v18 cruft in there that really needs to go, but the bottom line is that I can't accept code that doesn't at least work in current (released, not CVS) versions of both emacs flavours. Cheers, Waider. -- [EMAIL PROTECTED] / Yes, it /is/ very personal of me. I have a problem compiling the brainsplat module under the pre-sliced option terminator; I am using the mutability framewedger on the standard infernalisation build - Telsa --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ bbdb-info@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bbdb-info BBDB Home Page: http://bbdb.sourceforge.net/
Re: insinuation bug/misfeature/suggestion in RMAIL
Ronan Waide [EMAIL PROTECTED] writes: On August 8, [EMAIL PROTECTED] said: stuff. IMHO, none of this stuff should be executed in a mode hook, but on load of the mode file. What you have to bear in mind is that much of this code predates things like advice (and possibly eval-on-load) First, my apologies: it's eval-after-load, not eval-on-load. I just checked---more or less current semantics appears to have been there since 19.29 for eval-after-load. File advice.el seems to indicate that there was even a version that worked in Emacs 18, but some other comments say in current form it would not work. [...] not significantly changed since it was written for emacs 18. In particular, bbdb-vm and bbdb-gnus tend to be the most up-to-date sections as they're what I and one of the other main contributors use on a daily basis. [...] contribute needs to work on both Emacs and XEmacs. BBDB is allegedly baselined against Emacs 19, but I don't entirely believe that's true any more, and there's a lot of v18 cruft in there that really needs to go, but the bottom line is that I can't accept code that doesn't at least work in current (released, not CVS) versions of both emacs flavours. I wonder what is the right policy concerning compatibility---would not claim to know the Right Answer(TM). I have seen people take two opposite attitudes: Only the current (stable) version is the one one should support and one should support all the version possible that does not require rewriting Emacs :). It would be nice if an official policy regarding BBDB was stated someplace. I am also (personally) not thrilled with the attitude of refusing to support CVS Emacs. I understand the reasoning behind it---trying to catch up with a moving target plus lack of resources. If I ever make any contribution, I would not be much use for verifying Xemacs compatibility---do not use it and do not have a recent copy of it. Perhaps we could put together a list of people willing to try things for different mailer/emacs version combinations (and gnus, of course, and whatever else is relevant). Finally, getting back to the original question: I will send in a possible patch that's not likely to mess anything up too much. I am just trying to see how far to go in my (proposed) solution. Cheers, --Boris --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ bbdb-info@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bbdb-info BBDB Home Page: http://bbdb.sourceforge.net/
Re: insinuation bug/misfeature/suggestion in RMAIL
On August 10, [EMAIL PROTECTED] said: I am also (personally) not thrilled with the attitude of refusing to support CVS Emacs. I understand the reasoning behind it---trying to catch up with a moving target plus lack of resources. My major gripe with trying to support CVS Emacs (or CVS XEmacs, for that matter) is simply that it's not stable (this has also applied to several dot releases of Emacs, in particular the 20.x series which seemed to break multibyte characters with almost every release). I get someone sending me a mail about a bug this week, and next week it's not a bug anymore because it was a bug in Emacs, not BBDB, and it's been fixed at source. Regardless of issues of moving targets or lack of resources, trying to maintain a complex piece of code on top of an unstable platform is a complete waste of time. Having said that, I don't go out of my way to avoid supporting CVS Emacs, but I do take exception to using new whizbang lisp features simply because they're available. If the existing lisp code does the job sufficiently well I see no reason to break it, and there's already far too much version-testing function-aliasing crap in BBDB without adding more to it. It would be nice if an official policy regarding BBDB was stated someplace. I disagree. Official policies are for products and politicians. BBDB is neither; BBDB is, and always has been, hackerware, and while much has been done to make it less menacing to those unfamiliar with lisp, it's still a rat's nest of surprises and dead ends and really, if you're doing anything non-trivial with it, you'll have to get your hands dirty with lisp at some point. My own official policy, much as I hold that phrase in distaste, is that if you give me a reasonable patch (e.g. fixes a bug, implements a feature cleanly, etc.) then I will merge it in. If you give me an unreasonable patch (reformats code, reimplements existing code in a better way, etc.) I will discard it, quite probably without comment. If you consistently provide good code, you get CVS write access; if, having gotten CVS write access, you consistently break things or otherwise annoy me, you lose CVS write access. I generally don't do feature requests unless someone's made a good stab at coding it up already, although some of the other CVS writers have done impressive work in this respect, and if you've got an entire file full of new self-encapsulated features (e.g. the bbdb-letters code that was recently discussed on the list) I will probably at least add it to the bits/ directory if I think it's not quite fit for BBDB proper. I don't object to maintaining BBDB; on the contrary, I volunteered for the job when noone else seemed to be interested. I do object to anything that makes it more of a chore than it already is. Which I think is a rough summary of what I've said above. And now, we return you to our regularly scheduled list traffic. Cheers, Waider. -- [EMAIL PROTECTED] / Yes, it /is/ very personal of me. what have i become? / my sweetest friend everyone i know / goes away in the end - NIN, hurt (the downward spiral) --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ bbdb-info@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bbdb-info BBDB Home Page: http://bbdb.sourceforge.net/
