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

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."

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]