Re: Improving attachment viewing
Jon Steinhart <[EMAIL PROTECTED]> wrote: >What I have in mind is twofold. First, I'd like to be able to optionally >scan with message parts listed. Second, I'd like to be able to have an >option to show/next/prev that says "show the cur/next/prev message part". I just use mhlist next when I want that. But mostly, I'm with Bill in preferring the plain listing. Screen real estate is too valuable to clutter with attachment detail when you are scanning the list. -NWR
Re: Improving attachment viewing
On Tue, Nov 19, 2002 at 08:42:42PM -0800, Bill Wohler wrote: > This might be an intriguing option to some, but it should not be the > default. Agreed. I'd use it sometimes. Matt > If you're passed on the right, you're in the wrong lane. Or in Britain or some ex-British colony!
Re: Improving attachment viewing
> I've changed the Subject and included [EMAIL PROTECTED] > since we've spent the last year improving MIME handling in Gnus since > raw MH wouldn't work for us. We should be able to provide some > suggestions which would allow us to use more MH and less Gnus. Peter? > Satyaki? Yeah, should have changed the subject myself. What I have in mind is twofold. First, I'd like to be able to optionally scan with message parts listed. Second, I'd like to be able to have an option to show/next/prev that says "show the cur/next/prev message part". If the next/prev message part doesn't exist, then it should show the first/last part of the next/prev message. In other words, I just want to be able to read using a consistent interface, and the existing next/prev would let me skip attachments if I didn't want to see them. Also, I'd like to be able to show message.part > file rather than have to do the clunky mhstore thing. Jon
Re: nmh 1.1?
[EMAIL PROTECTED] wrote: > It has been fixed. I was just grousing that the fix has been in CVS for > a couple years but not in the Redhat distributions. Rather than grouse, switch to Debian GNU/Linux: nmh 1.0.4+dev-20010317-1 -- Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and mh-e. Vote Libertarian! If you're passed on the right, you're in the wrong lane.
Improving attachment viewing
I've changed the Subject and included [EMAIL PROTECTED] since we've spent the last year improving MIME handling in Gnus since raw MH wouldn't work for us. We should be able to provide some suggestions which would allow us to use more MH and less Gnus. Peter? Satyaki? Jon Steinhart <[EMAIL PROTECTED]> wrote: > My interest in m_getfld is because I'd like to experiment with the way > that attachments are shown. It'd be interesting to get a bit of > discussion on this. Basically, I don't like the way that message parts > are treated differently than messages. To me, there's little > difference between receiving a message with two attachments and three > messages. I'd like to see an indented scan that shows something like > > 5785+ 11/19 Eric Gillespie Re: The continuing install-mh saga< .1 > .2 > > ant then be able to do show/next/prev on stuff. I find it really > annoying to have all body parts displayed in a single batch, > especially those that involve some interaction to get rid of, like > closing an image viewer. This might be an intriguing option to some, but it should not be the default. I wouldn't enable it. There is too much crap out there that would pollute the scan listing and make it awkward to read mail quickly. I can safely say that I do not view the majority of attachments I receive and considering them as separate messages would simply add the to (often oppressive) pile of mail. Consider all the midi and html attachments in spam, and winmail.dat attachments, and vCards, and multipart/encrypted which you would want to present as a single message rather than the pieces. To name just a few. You'll be sure to generate some good ideas though. Capture them in a Feature Request at Savannah. -- Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and mh-e. Vote Libertarian! If you're passed on the right, you're in the wrong lane.
Re: nmh 1.1?
> >Every time I get a new Redhat installation, I need to update inc 1.0.4 > >because it doesn't properly handle POP passwords (without a .netrc file). > >It would be nice if the released nmh didn't have this bug (which is > >arguably a bug in glibc ruserpass which they refuse to fix). > > So, are you saying this has been fixed in RC1, or it hasn't? It has been fixed. I was just grousing that the fix has been in CVS for a couple years but not in the Redhat distributions. The problem was an incompatibility between the ruserpass() in glibc and every other ruserpass() on the planet (and the glibc guy thinks that everyone else is wrong). If you have no .netrc file on Linux, inc core dumps or it uses the wrong password, I don't remember which right now. If you have no .netrc file in any of the other OSes or if you use sbr/ruserpass.c then it prompts you for the POP password. RC1 appears to always use sbr/ruserpass.c even if libc provides its own ruserpass(), so this issue is resolved. Thanks, -Paul
Re: The continuing install-mh saga
> Jon Steinhart <[EMAIL PROTECTED]> writes: > > > Also, I didn't mean to start a flame war with my questions > > about the code. It's my opinion that nmh has about twice as > > much code as is really needed to do the job. That excess > > fluff makes the code harder to understand and maintain. So > > I'm gonna trim it out whenever I see it. Not to show off, > > but to make the code easier to deal with. > > If you want something to do as far as duplication reduction goes, > check out mhbuildsbr.c and mhparse.c. Have a barf bag handy. > > -- > Eric Gillespie <*> [EMAIL PROTECTED] Funny. My main reason for looking at stuff is because I want to add features, and right now there's nothing that I want to do there. The changes that I made to handle sending attachments at least keep the user from having to see that stuff. See doc/README-ATTACHMENTS in the CVS if you don't know about this. My interest in m_getfld is because I'd like to experiment with the way that attachments are shown. It'd be interesting to get a bit of discussion on this. Basically, I don't like the way that message parts are treated differently than messages. To me, there's little difference between receiving a message with two attachments and three messages. I'd like to see an indented scan that shows something like 5785+ 11/19 Eric Gillespie Re: The continuing install-mh saga< .2 ant then be able to do show/next/prev on stuff. I find it really annoying to have all body parts displayed in a single batch, especially those that involve some interaction to get rid of, like closing an image viewer. Jon
Re: The continuing install-mh saga
Jon Steinhart <[EMAIL PROTECTED]> writes: > Also, I didn't mean to start a flame war with my questions > about the code. It's my opinion that nmh has about twice as > much code as is really needed to do the job. That excess > fluff makes the code harder to understand and maintain. So > I'm gonna trim it out whenever I see it. Not to show off, > but to make the code easier to deal with. If you want something to do as far as duplication reduction goes, check out mhbuildsbr.c and mhparse.c. Have a barf bag handy. -- Eric Gillespie <*> [EMAIL PROTECTED] Build a fire for a man, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life. -Terry Pratchett
Re: nmh 1.1?
>Is there any reason that 1.1-RC1 hasn't been promoted to a real 1.1? Mostly, because I'm a lame-ass. "soon". I promise. There have been a few bugs (and patches) posted. >Every time I get a new Redhat installation, I need to update inc 1.0.4 >because it doesn't properly handle POP passwords (without a .netrc file). >It would be nice if the released nmh didn't have this bug (which is >arguably a bug in glibc ruserpass which they refuse to fix). So, are you saying this has been fixed in RC1, or it hasn't? --Ken
nmh 1.1?
Is there any reason that 1.1-RC1 hasn't been promoted to a real 1.1? Every time I get a new Redhat installation, I need to update inc 1.0.4 because it doesn't properly handle POP passwords (without a .netrc file). It would be nice if the released nmh didn't have this bug (which is arguably a bug in glibc ruserpass which they refuse to fix). -Paul
Re: Working on the install-mh change questions
On November 18, 2002 at 20:43, Jon Steinhart wrote: >Oh, some details. > > 1. A second getenv() call would not break the code. The copy was really > unnecessary. As pointed out earlier, making the copy may be needed depending on the implementation of getenv() for a given platform. And for all we know, the person who original wrote the code had an environment where it was required. > 2. It's hard for me to imagine a situation where getpwuid() would #1 get > called a second time and #2 for a different uid, which is the only that > a problem would occur. It is hard for us to imagine alot of things, but I never fault a programmer for being extra paranoid. Paranoia makes programs more robust against unforseen events, and can pay off big time when such events occur. > 3. If there's a NULL passwd->pw_dir then libc is broken and should be fixed. > Better that this gets pointed out and fixed rather than covered up so tha >t > it stays unnoticed and broken. > >Oh, and I've wasted some of my volunteer time trying to figure out what the >code did before changing it. I'd waste less if there was less code. Best way >to accomplish this is to get rid of the code that doesn't do anything. Again, it is safe to be paranoid. It is not unheard of where an OS's libc have bugs, and software that properly checks all data is okay in my book. I'll give a real-world example related to nmh: When I did some changes to nmh code to get it to compile on cygwin, there was a system call that did NOT return the proper value. The call was broken or was stubbed and had not been implemented by the cygwin maintainers. Plus, if you take security seriously, one should always check data retrieved from components you do not have direct control over. Even if you think, "this will never happen," the day it does, you'll kick yourself in the head and have a possible security vulnerability on your hands. It's like when people say, "the data will never be larger than X," so they hard-code an array size, and when the data is larger than X, and buffer overflows occur. I do agree that MH/nmh does have duplicate code in areas that can be reduced down into reusable components (especially some of the time stuff when I played with making nmh compile under cygwin). I also agree that there are areas in the code that makes a new person wondering why in the hell certain code exists. However, in my experience, when I do not have complete knowledge of an existing code base, I hesitate to remove any code that "appears" to be unnecessary. For all I know, the original author encountered some abhorent scenario that requires the code to exist. Remember, the MH/nmh code base is *very* old, so there is alot of environmental experience that we have never been exposed to. In cases where I think something should not exist, I typically add a comment in the code like "/* XXX: Why is this here? */" or "/* XXX: What the heck does this do? */", and seek advice from other maintainers, and if possible the original author, on the purpose of the code, like exactly what you have done by asking about the code to this list. But, do not be surprised that other may disagree with you. Then, if people agree a chunk of code can be axed, after it is removed, make sure to test it. My $0.02, --ewh
Re: The continuing install-mh saga
Jon Steinhart <[EMAIL PROTECTED]> wrote: > but should it > really be called install-nmh? No, nmh is pronounced MH. Note that Richard Coleman wisely called the new commands mhbuild, mhstore, and so on, not nmhbuild, nmhstore, etc. nmh is, and should continue to be, backwards-compatible so it won't confuse old users and break old scripts. Another reason to minimize the use of nmh in the names is that I think it would be very cool to merge the two branches in the future. Maybe the the next nmh release could be MH 7.0. -- Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and mh-e. Vote Libertarian! If you're passed on the right, you're in the wrong lane.
Re: The continuing install-mh saga
Jon Steinhart wrote: should it really be called install-nmh? Hmmm... in that case, we might also want to rename the .mh_profile file, the commands like mhlist/mhshow/etc.? I'd suggest keeping the name install-mh. IMO, new users are just gonna need to understand that nmh is "new MH" and that they'll see "mh" around sone places. Jerry -- Jerry Peek, [EMAIL PROTECTED], http://www.jpeek.com/
Re: Working on the install-mh change questions
Jon, > I'd waste less if there was less code Refactoring code so that there is less of it is a good thing. Throwing away defensive copies or code that does something that could "never happen" that is under someone else's control is a bad thing. If the code that could "never happen" isn't within a few lines of your current code, it could (and will) happen. It is not "slow and sloppy" but absolutely vital. -- Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and mh-e. Vote Libertarian! If you're passed on the right, you're in the wrong lane.
Re: The continuing install-mh saga
>Now, I hate to make this even more complicated, but should it >really be called install-nmh? The change from mh to nmh has >left a lot of stuff like this that could confuse a new user >because you sort of have to know the history to know what >things are called. I can't see a reason why we shouldn't have both (symlink). --Ken
The continuing install-mh saga
Wow! It's amazing how something so simple can be such a problem. OK, since I started this, I'll change it so that install-mh lives in bin with a link to it from lib, and I'll change the manual page to be in section 1 instead of section 8. Now, I hate to make this even more complicated, but should it really be called install-nmh? The change from mh to nmh has left a lot of stuff like this that could confuse a new user because you sort of have to know the history to know what things are called. Also, I didn't mean to start a flame war with my questions about the code. It's my opinion that nmh has about twice as much code as is really needed to do the job. That excess fluff makes the code harder to understand and maintain. So I'm gonna trim it out whenever I see it. Not to show off, but to make the code easier to deal with. Jon
