Re: Balsa can't download a mail with a long line, gets stuck in endless dup-creating loop.

[Jack <ostroffjh sbcglobal net>]

OK - at home, and using Balsa.

On 2012.10.25 03:07, Rob Landley wrote:
> On 10/24/2012 06:51:15 PM, Jack wrote:
> > Because web mail is too painful for me, I'll just add a few comments  
> > up top.
> >
> > I have occasionally noticed problems with word wrap, but much of the
> > time,
> > either I'm on webmail, or I'm replying (in balsa) to something sent
> > in
> > webmail.
> > I think part of the issue is that a series of several lines, all
> > about
> >  the same
> > length looks like a paragraph, but isn't really.  There is a hard
> > break between
> > each, instead of being flowed only by the display.
>
> Why? Strange design...
I haven't looked at the code, so my description was based on my  
experience, and I don't consider it strange at all, even if I wish the  
usual behavior were different.

> That said, if they're going to _treat_ it as a paragraph maybe it  
> should act like one? Email paragraphs have blank lines between them,  
> if you don't see one of those you need to flow ahead.
(I reflowed the above, since it leads to better re-wrapping in the next  
reply...)  I've seen cases where a single CRLF marks a paragraph break,  
and some where a double CRLF (i.e., blank line) marks a break.  I don't  
know if either is completely standard, and I assume which you see  
depends on the mail software that sent it.  On occasion, I've seen some  
mail software that doesn't wrap for display, so a  paragraph may  
require scrolling far to the  right to read it all.

> It also CREEPS ME OUT that I type for a while and then when I stop  
> typing for a second or so it decides to change the wordwrapping  
> decisions for its previous lines, so that the whole paragraph changes  
> when I pause to think about what to type next. It's distracting and  
> disturbing, but also inconsistent and unnecessary. It says that there  
> are two codepaths that control word wrapping. Why the extra  
> unnecessary code?
I've never seen Balsa do this.  I can imagine a case where it might,  
but it would be if you were typing relatively fast on a very slow  
processor, so it wanted to re-wrap as soon as some line got too long,  
but it didn't get the chance until you stopped typing long enough for  
the "re-wrapping" thread to get some time.  Note: I'm not suggesting  
this is really what's going on, but a way to think about it.  I do  
believe that something funny is going on, since I don't believe that is  
really how Balsa SHOULD behave.

> >  Inserting  into one of those lines add's a wrap to that paragraph  
> > only, and if that  paragraph is only one line, you get what you are  
> > complaining about.  I do make frequent use of "reflow" (select the  
> > paragraph, perhaps without the last line, and hit CTL-R.
> >
> > In ubuntu, the deps are just the runtime libraries.  When you build  
> > balsa yourself, you need the -devel version so you have the headers  
> > available.
(I've reflowed the above two, which initially looked like the first  
paragraph above.

> I've noticed this thing. It's the fact it needs so MANY of them, and  
> there's no easy way I've found to say "give me the -dev versions of  
> all the dependencies for this package", unless maybe I'm installing a  
> source .deb which is a rathole I haven't gone down yet.
That's ALWAYS (or maybe almost always) an issue when compiling from  
source on a binary distribution.  Programs that use cmake instead of  
automake/autogen/configure are perhaps a bit better, in that the list  
of dependencies is a bit easier to see.  It needs header files (and  
thus -dev packages) of any package that contains a library it's going  
to link to.

> >  For example, if the ubuntu packaged version of balsa needs ssh,  
> > then to build balsa, you need ssh-devel (just for the idea, I don't  
> > know if that's a real package).

> Hence the long list of blah-devel packages I've already installed,  
> yes. I just can't get one big list of them from anywhere, and am  
> somewhat disturbed at the sheer quantity of environmental  
> dependencies. (If I built a beyond linux from scratch variant I'd  
> have to install something like 40 prerequisite packages to use balsa.)
Not just LFS (which I ran for a while many years ago.) Any source based  
distro (I currently use Gentoo) will have all the dependencies  
installed, since its standard package install does the full  
configure/compile process.  I'll send you directly a copy of the Gentoo  
ebuild for Balsa, which might give you a better list - although it  
won't show you the nested dependencies.

> > These are not nested dependencies, but development versions of the  
> > package so

> The nested dependencies are "getting the list of non-dev packages  
> this thing uses so I can look for corresponding -dev packages". (I  
> learned a lot about making RPM do tricks until Red Hat abandoned the  
> desktop for Sun's old enterprise market, and I learned a bit about  
> portage until it collapsed under its own weight, and for dpkg I just  
> went "screw it" and installed aptitude and try to ignore the horrible  
> layers of apt-get and dpkg-query under the surface.)
(On my wife's Ubuntu box, I use synaptic.  I haven't done a command  
line apt command in years.)  The nested dependencies are not the  
packages listed as dependencies in the configuration of balsa's  
package.  Nested dependencies are the dependencies of the direct  
dependencies.  However, now that I think about it, you should only need  
the -devel of a nested dependency if Balsa needs to link to it directly  
and thus needs the header files.

> > you have the headers balsa needs to compile and link, not just to  
> > run.
> I know what a development package is, thanks. I'm incovenienced by  
> the sheer quantity of them which balsa requires. Its environmental  
> dependencies are more elaborate than I expected for something  
> claiming to be lightweight. They seem not to factor in "my 1 megabyte  
> program requires 600 megabytes of library code" as a complexity cost.
I think it's an unfortunate side effect of just about all modern  
systems.  "They" keep saying (for some definition of "they") not to  
reinvent the wheel, and to use libraries.  This means dependencies.   
Massive environments like gnome and kde make it much worse.  For Balsa  
not to use some library, it either has to not do that functionality or  
actually include that functionality in its own code.  "Lightweight" is  
a very relative term.

> >  You do also have the issue of dependencies of dependencies, but  
> > other than reading the .configure script, finding a new one each  
> > time you do .configure is the standard approach.
> I noticed. The packages I listed were just the ones I manually  
> installed, not the ones the dependencies added. (I.E. those  
> half-dozen packages actually installed something like 40 packages,  
> and balsa still wants more).


> > Your send problem seems strange.  When I get a send error (usually  
> > due to my ISP) I just un-flag and then send queued mail.
> For some reason the composer's send button now says "queue" and then  
> I have to "send queued messages" from the pull-down menu.
I've added the "exchange" (i.e., send and receive) button to my task  
bar, so I don't need menus for this)  I also don't think I've ever seen  
a "queue" button in Balsa.

> It wasn't doing that earlier. This is unrelated to the "it ignores  
> the first message in the outbox whenever it does send" problem.

> > If it's still not going, I'd try to figure out why.  Try the command  
> > line flag to debug the pop connection.
> I didn't know there was one. And outgoing mail is debugging the smtp  
> connection, pop is only for incoming messages.
Do a "balsa --help" to see the (relatively short) list of command line  
options.  pop and imap debugging are avaialable.  For smtp debugging, I  
quote from a message to this list from last March: "It is - regretfully  
- handled in a different way. Mark Preferences/Misc/Debug checkbox."