Mike Small <[email protected]> writes: > I'm thinking I'm in this category of being > unorthodox in that I'm depending on the > implementation of internal undocumented > Gnus functions.
Actually I don't know who is unorthodox here :) My take is: 1) all functions should be documented, and 2) there is nothing wrong relying on (any) existent code that is good and does what you want If you are worried they will change, which I don't think they will - or, if they will, the interface (the input mapping to output) should remain the same, in which case you *want* the changes anyway as they are probably efficiency motivated or bugfixes - but if you are nonetheless worried they will change, just dump the code in a file - if upgrade breaks your stuff, compare and see what changed. But I only advice you this because I think it won't happen. So it is only to relax you :) For one (for many I should say) I use *tons* of all kind of functions from any and all modules, and with 50+ files of Elisp I had to change one or two things which were total details when I upgraded most recently. So, don't worry about it! > Thanks for the tips on documentation and coding > style. I've applied some of that. What I've not > followed (e.g. documenting the argument and not hard > coding the from value) I ignored only because > I don't see myself publishing this function to > others. Er, other than on this news group, that is. Remember, regardless of who the audience is, if you behave like a pro, that's what you become - more, do it every day it doesn't even take that long even. Never show any weaknesses to your opponent, the grandmaster says. Nor to yourself, his top student says. > My usual case is to want the html rendering. > It's only Anu's Word a Day where I want the text > alternative. I was manually switching it over to > text for a while, but wanted to have it happen > automatically. I read his emails every weekday so > a manual step would be annoying. OK, how about: when you see that post in the summary buffer, you open it with another key? That way you don't even hit an extra key, just *another* key. E.g., instead of RET, assign M-RET to do this. That has the advantage of being flexible as well - perhaps some new situation arrives, where you want the distinction again? In principle and practice I'm a big fan of DWIM-hacking but this seems to me too unbalanced - i.e., one sender vs. everything else - to be sensible. But I'm not telling you what to do, of course. -- underground experts united http://user.it.uu.se/~embe8573 _______________________________________________ info-gnus-english mailing list [email protected] https://lists.gnu.org/mailman/listinfo/info-gnus-english
