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



On 10/25/2012 09:05:44 AM, Jack wrote:
> 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.

Wordwrapping in general seems to be something Balsa needs a bit of work 
on. The above is just me hitting "a" and letting it pick the wrapping.

I like Balsa, but pretty much everything else I've used has done this 
part better.

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

I'm talking about the case where Balsa is replying. It had to parse the 
mail to quote it. If balsa had to split a line to insert the >, it can 
probably safely assume that the following line is part of the same 
paragraph. If quoting level changes, or there's a blank line, that 
forces a new paragraph.

When you insert words, you can either consider the next line part of 
this paragraph if there isn't a blank line or an indent level 
change, or you can look at the first word of the line after 
that and if it could be appended to this line without hitting the 
wordwrap limit then it's definitely part of this paragraph, 
otherwise call that a paragraph break.

But the bigger problem is that Balsa doesn't _track_ paragraphs during 
composition. If I cursor up into my paragraph and add words, I get lots 
of individual words on their own line. Complaining that it forgets 
where the paragraph breaks were in what it just flowed during the 
actual composition part (discarding information it could have already 
had) implies it's tracking paragraphs at all.

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

Displaying other people's email is a separate problem from mail 
composition. Both need tweaking.

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

It's a netbook and it keeps clocking itself down to 800mhz to save 
power, but It's dual processor (one of which is essentially idle) so 
you'd have to have green threads rather than pthreads for a thread to 
get starved. (Unless some kind of lock contention's going on.) And 
I've upgraded it to 8 gigs of ram so it's not swapping.

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

I selected the above all the way back to the start of the quote and hit 
ctrl-R.  Nothing happened.

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

I used to maintain a package called "busybox" where I made sure there 
were no external dependencies. Admittedly that's a special case, but 
complexity is a cost and external dependencies are a type of complexity 
that tends not to get measured.

If you want a large and active developer base, make the project easy to 
build, at least listing the packages you use on your website.
Not everybody's as crazy as I am, and thus never transition from 
users to developers if the overhead of sticking a single printf into 
the thing is 4 hours of build setup.

> >>  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 ran Gentoo on a server for a year or so, but I went so long between 
upgrades (6 months) that the ebuilds it rsynced no longer mentioned the 
versions of several packages I was using, which confused portage enough 
that it damaged gcc halfway through a compiler upgrade. It only took a 
couple symlinks to fix it (it was looking for the gcc binaries and 
libraries out of the wrong version directory), but portage's database 
had gotten confused and it was never quite the same afterwards.

Since reinstalling is _designed_ to be an extremely tedious process, I 
never bothered to do it again. (Gentoo has no sane installer and is 
_proud_ of that fact. Gentoo wants to be more work to install than 
Linux From scratch is because that keeps the riff-raff away.)

I hung around Daniel Robins' Funtoo project for a while, but it never 
quite gelled as anything other than a fork of Gentoo. (Maybe it has 
since, I haven't checked in a year.)

Also back around 2006 when "Debian Stale" had gone 5 years without a 
laxative, a large portion of the eternal Debian flamefest wandered over 
to Gentoo instead. The Debian guys eventually left ("I heard Gentoo was 
so much nicer than Debian but ever since we showed up it's been 
asbestos underwear as far as the eye can see, we were misled!") but 
Gentoo's developer base never really recovered. (Maybe it has since I 
stopped following it closely?)

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

I can sit down and grind through the rest of the stuff in configure, 
but the lack of a web page saying "here's how to compile it on the most 
widely used distro" is a bit of a downside from an ongoing maintenance 
perspective.

Autoconf is a horrible tool. Checking for prerequisites should disable 
functionality rather than break the build (the build breaks anyway). 
Stopping at the first missing prerequisite rather than collecting a 
list of everything that's missing and presenting it all at once is just 
sad.

Then again if the FSF was any good at this "software" thing, we'd be 
using The Hurd.

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

Except a gui doesn't solve the problem.

I've used various gui front-ends, including synaptic. In theory 
aptitude is a curses style front end, and it gives you a menu if you 
run it without commands. That's not what I'm looking for out of it, 
though.

Synaptic is no better than "aptitude search blah | grep "[-]dev" for 
what I'm trying to do. If you dunno what to put for "blah", it can't 
help you.

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

Or if configure thinks it needs the header files, which isn't always 
the case. I remember the git build on an embedded system was:

  ./configure --without-tcltk --without-python --without-iconv
  make NO_PERL=1
  make NO_PERL=1 install

Sad that it detects that tcltk is missing and then _breaks_the_build_ 
rather than switching it off unless you supply the --without option, 
but there isn't a --without-perl. When I dinged 'em about not having a 
--without-perl they said that ./configure was only for windows users, 
and Linux users should just set the NO_* environment variables. Sigh.

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

I do embedded development. We honestly don't have this problem.

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

The founder of the Gnucash project is a local, and I've heard him tell 
the story of how that project grew so many dependencies it was 
impossible for anybody to actually compile it.

I'm not running Balsa under Gnome or KDE. I'm running it under the 
desktop Debian switched its default to a month or two back, but what 
desktop I'm using should be irrelevant. It's an X11 app.

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

I'm learning that Balsa's definition of lightweight is a relative, yes.

> >>  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's entirely possible Cannonical screwed this up, but more likely it's 
running in a different environment and being confused that I shot dbus 
in the head and don't consider NetworkMangler's opinion of whether or 
not I'm connected to be authoritative (and thus Firefox refusing to 
connect to the webserver I run ON LOOPBACK because I'm not associated 
with a wireless network is not something I have a lot of patience for).

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

Already checked, it wasn't telling me anything useful that I noticed.  
I need to build from source so I can stick printfs into the thing...

*shrug* It's on the todo list.

Rob


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