KMail - forwarding issues
AG
I am really beginning to get ticked off with KMail's forwarding
function. While there are three options for forwarding (i.e. as
attachment, in-line or redirect), I am finding it problematic to forward
emails in such a way that allows for the removal of the OP's details
while preserving the actual content one wants to forward.
Of the three options one seems to remove the content to be forwarded
while the other two seem to retain the OP's details in some way or
another. In forwarding an email in-line often the original content is
not retained (images or other attachments in the OP's mail are removed
and I'm left only with my own sig, for example). If redirected, the
OP's details are retained, as they are when the email is forwarded as an
attachment.
Is there a trick to forwarding emails in KMail so that all that happens
is that the OP's email content is preserved along with any attachments
but that the OP's details can be edited out?
I'm using version 1.13.5 on an up-to-date testing machine.
Cheers
AG
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4CBDE2D6...@gmail.com
Camaleón
(...)
> Is there a trick to forwarding emails in KMail so that all that happens
> is that the OP's email content is preserved along with any attachments
> but that the OP's details can be edited out?
AFAICT, no.
HTML editor is very limited (to say something) in KMail.
There was a long (and interesing thread¹) not so much ago, where people
asked for such functions that seem to be -still- missed. Response? "No".
That was one of the things that made me switch to Thunderbird. I
sincerely hope this can change in a near future :-/
¹http://lists.kde.org/?l=kdepim-users&m=128081380926897&w=4
Greetings,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Paul Cartwright
> That was one of the things that made me switch to Thunderbird. I
> sincerely hope this can change in a near future :-/
do you mean icedove? or the real thunderbird from Mozilla..
--
Paul Cartwright
Registered Linux user # 367800
Registered Ubuntu User #12459
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201010191601...@pcartwright.com
Camaleón
> On Tue October 19 2010, Camaleón wrote:
>> That was one of the things that made me switch to Thunderbird. I
>> sincerely hope this can change in a near future :-/
>
> do you mean icedove? or the real thunderbird from Mozilla..
Sorry, I'm still using my "non-debianized" brain part :-)
Icedove, of course. It allows the same features that Thunderbird.
Greetings,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
AG
> On Tue, 19 Oct 2010 19:26:30 +0100, AG wrote:
>
> (...)
>
>
>> Is there a trick to forwarding emails in KMail so that all that happens
>> is that the OP's email content is preserved along with any attachments
>> but that the OP's details can be edited out?
>>
> AFAICT, no.
>
> HTML editor is very limited (to say something) in KMail.
>
I don't use HTML in KMail, so I think that it is functional issue.
> There was a long (and interesing thread�) not so much ago, where people
> asked for such functions that seem to be -still- missed. Response? "No".
>
That's very accommodating of the user community feedback, isn't it?
> That was one of the things that made me switch to Thunderbird. I
> sincerely hope this can change in a near future :-/
>
> �http://lists.kde.org/?l=kdepim-users&m=128081380926897&w=4
>
>
I was actually thinking of giving Sylpheed Claws (is it still called
that??) a revisit since last I used it many, many moons back.
> Greetings,
>
>
Cheers.
AG
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Paul Cartwright
> I was actually thinking of giving Sylpheed Claws (is it still called
> that??) a revisit since last I used it many, many moons back.
I have stayed with kmail for years, through 3 different distros, because I
like it, especially with the KONTACT apps. I've tried evo & Sylpheed, but
they all seem to croak/crash/fail at IMAP & the kontact app suite.
Is pegasus still around? but the forward issue HAS bugged me forever..
I REALLY REALLY HATE leaving in someone elses email address when I forward
stuff..
--
Paul Cartwright
Registered Linux user # 367800
Registered Ubuntu User #12459
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201010191758...@pcartwright.com
Paul Cartwright
> Icedove, of course. It allows the same features that Thunderbird.
>
> Greetings,
I use thunderbird on my laptop, for when I travel.. Lately ( the last 6 weeks)
I've been using nomachine on my laptop to get to my desktop & use kmail & not
have to mess with forwarding emails, getting them twice, or not having them
on my desktop.
--
Paul Cartwright
Registered Linux user # 367800
Registered Ubuntu User #12459
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201010191801...@pcartwright.com
Mike Bird
> Is there a trick to forwarding emails in KMail so that all that happens
> is that the OP's email content is preserved along with any attachments
> but that the OP's details can be edited out?
I use KMail/Kontact in KDE 3.5 in Lenny.
Does pressing "T" ("Edit Message") and changing the "To" address
at the top come anywhere close to the functionality you need?
--Mike Bird
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201010191529.3...@yosemite.net
John A. Sullivan III
> On Tue, 19 Oct 2010 19:26:30 +0100, AG wrote:
>
> (...)
>
> > Is there a trick to forwarding emails in KMail so that all that happens
> > is that the OP's email content is preserved along with any attachments
> > but that the OP's details can be edited out?
>
> AFAICT, no.
>
> HTML editor is very limited (to say something) in KMail.
>
> There was a long (and interesing thread¹) not so much ago, where people
> asked for such functions that seem to be -still- missed. Response? "No".
>
> That was one of the things that made me switch to Thunderbird. I
> sincerely hope this can change in a near future :-/
>
> ¹http://lists.kde.org/?l=kdepim-users&m=128081380926897&w=4
There is a very lively discussion about a related problem (replying to
HTML mail) in https://bugs.kde.org/show_bug.cgi?id=86423
The end result is that the Trinity project
(http://trinity.pearsoncomputing.net) has offered to do the work to
implement it for a bounty. The spec is being finalized and we will
begin collecting for the bounty probably using chipin.com. It is a
sizable bounty as it is a very large project but, if enough people want
it, we finally have a path forward after years of neglect. If it's
important to you, I'd suggest subscribing to the bug and chipping in
toward the bounty - John
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1287527513.3358.3.camel@localhost
Paul Cartwright
> I use KMail/Kontact in KDE 3.5 in Lenny.
>
> Does pressing "T" ("Edit Message") and changing the "To" address
> at the top come anywhere close to the functionality you need?
no, it puts everything down at the bottom as an attachment. message formatting
is lost.
--
Paul Cartwright
Registered Linux user # 367800
Registered Ubuntu User #12459
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201010200505...@pcartwright.com
AG
> On Tue October 19 2010 11:26:30 AG wrote:
>
>> Is there a trick to forwarding emails in KMail so that all that happens
>> is that the OP's email content is preserved along with any attachments
>> but that the OP's details can be edited out?
>>
> I use KMail/Kontact in KDE 3.5 in Lenny.
>
> Does pressing "T" ("Edit Message") and changing the "To" address
> at the top come anywhere close to the functionality you need?
>
> --Mike Bird
>
>
>
Mike, unlike Paul, that options *does* seem to do the trick. I have
tested this with a couple of emails - one without attachments and the
second with, and interestingly enough it retains the material I want to
forward but seemingly converts it into an HTML format to send onwards.
For instance - if I wanted to forward text with some images, when I
receive and read that email the images will all be as separate
attachments which I have to manually open as image files. When I invoke
the "T" option as you suggest and change the address line to the new
recipient, the images are "opened"/ displayed at various points during
the text. This is - AFAIK - what happens in an HTML email format. I'd
prefer not to forward HTML-laden emails, but I suspect that that is how
I received it and it was just not displayed as such locally due to my
preference settings.
However, bottom line: so far this is the most viable solution to the
forwarding issue. I'm sorry to read that it doesn't work for you in a
similar way Paul.
Thanks Mike, I'll keep trying that as the solution and will monitor it.
AG
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Camaleón
> On Tue October 19 2010, Camaleón wrote:
>> Icedove, of course. It allows the same features that Thunderbird.
>>
>
> I use thunderbird on my laptop, for when I travel.. Lately ( the last 6
> weeks) I've been using nomachine on my laptop to get to my desktop & use
> kmail & not have to mess with forwarding emails, getting them twice, or
> not having them on my desktop.
There is no problem with forwarding, just keeping the HTML format for the
forwarded e-mail is what seems not possible.
Kmail is a great (the best I've ever tried) e-mail client. Is just its
html editor lacks some love and people who needs to work with html format
has to think it twice before using it :-)
Greetings,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Paul Cartwright
> However, bottom line: so far this is the most viable solution to the
> forwarding issue. I'm sorry to read that it doesn't work for you in a
> similar way Paul.
ok, I tried it again on another email that had an Encapsulated message. When I
hit "T" it attached that message. I double-clicked on the attached message,
which still included the OP email address, to & from.. and it was not inline
with the original pictures, like I received it.
--
Paul Cartwright
Registered Linux user # 367800
Registered Ubuntu User #12459
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201010200746...@pcartwright.com
Paul Cartwright
> forwarding issue. I'm sorry to read that it doesn't work for you in a
> similar way Paul.
maybe I didn't try it on a viable email correctly.. I'll take another look.
I tried it on an email that had multiple pictures INLINE, and when I hit "T"
all the pictured ended up as attachments.
--
Paul Cartwright
Registered Linux user # 367800
Registered Ubuntu User #12459
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201010200739...@pcartwright.com
Camaleón
> On 19/10/10 20:55, Camaleón wrote:
>> On Tue, 19 Oct 2010 19:26:30 +0100, AG wrote:
>>
>> (...)
>>
>>
>>> Is there a trick to forwarding emails in KMail so that all that
>>> happens is that the OP's email content is preserved along with any
>>> attachments but that the OP's details can be edited out?
>>>
>> AFAICT, no.
>>
>> HTML editor is very limited (to say something) in KMail.
>>
>>
> I don't use HTML in KMail, so I think that it is functional issue.
So, what is the exact problem are you facing? :-?
I thought you were talking about preserving the format (embedded images,
etc...) when forwarding e-mails inline but for plain text should not be
any issue.
Greetings,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Camaleón
> On Tue, 2010-10-19 at 19:55 +0000, Camaleón wrote:
(...)
>> There was a long (and interesing thread¹) not so much ago, where people
>> asked for such functions that seem to be -still- missed. Response?
>> "No".
>>
>> That was one of the things that made me switch to Thunderbird. I
>> sincerely hope this can change in a near future :-/
>>
>> ¹http://lists.kde.org/?l=kdepim-users&m=128081380926897&w=4
> <snip>
> There is a very lively discussion about a related problem (replying to
> HTML mail) in https://bugs.kde.org/show_bug.cgi?id=86423
Wow... I fail to see how a bug report with 2460 votes is still being
ignored.
> The end result is that the Trinity project
> (http://trinity.pearsoncomputing.net) has offered to do the work to
> implement it for a bounty. The spec is being finalized and we will
> begin collecting for the bounty probably using chipin.com. It is a
> sizable bounty as it is a very large project but, if enough people want
> it, we finally have a path forward after years of neglect. If it's
> important to you, I'd suggest subscribing to the bug and chipping in
> toward the bounty - John
Thanks for the heads up.
I will forward this information to other mailing lists so people gets
informed about its current status (the Trinity project side) so they can
collaborate if they wish. Nice to see there is still people caring about
what users care :-)
For me is late, I'm afraid. I'm now in GNOME and finally switched to
Icedove :-(
Greetings,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Mihira Fernando
> On Wed October 20 2010, AG wrote:
>> However, bottom line: so far this is the most viable solution to the
>> forwarding issue. I'm sorry to read that it doesn't work for you in a
>> similar way Paul.
> ok, I tried it again on another email that had an Encapsulated message. When I
> hit "T" it attached that message. I double-clicked on the attached message,
> with the original pictures, like I received it.
>
you try to forward it. This is due its limited support for HTML mails.
(Lack of HTML mail support is the reason I switched to Thunderbird
from this otherwise perfect mail client as well ).
Forwarding a Text only mail or mail with attachments the standard way
allows you to edit out any information that you do not which to forward.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ron Johnson
> On Tue October 19 2010, AG wrote:
>> I was actually thinking of giving Sylpheed Claws (is it still called
>> that??) a revisit since last I used it many, many moons back.
>
> I have stayed with kmail for years, through 3 different distros, because I
> like it, especially with the KONTACT apps.
That's an important factor..
> I've tried evo& Sylpheed, but
> they all seem to croak/crash/fail at IMAP& the kontact app suite.
Tbird/Icedove works fine with courier-IMAP.
> Is pegasus still around? but the forward issue HAS bugged me forever..
> I REALLY REALLY HATE leaving in someone elses email address when I forward
> stuff..
AFAICT, that's also what Tbird/Icedove and Outlook do.
--
Seek truth from facts.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ron Johnson
> On Tue October 19 2010, Camaleón wrote:
>> Icedove, of course. It allows the same features that Thunderbird.
>>
>> Greetings,
>
> I use thunderbird on my laptop, for when I travel.. Lately ( the last 6 weeks)
> have to mess with forwarding emails, getting them twice, or not having them
> on my desktop.
>
Run an IMAP server on your desktop? With DynDNS, port forwarding
and IMAPs you could access your email anywhere, and from most any
machine.
--
Seek truth from facts.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Paul Cartwright
> Run an IMAP server on your desktop? With DynDNS, port forwarding
> and IMAPs you could access your email anywhere, and from most any
> machine.
nomachine was quick & easy & gave me direct access to my desktop from my
laptop. Right now on my desktop I have squirrelmail working, but I like using
my kmail..
--
Paul Cartwright
Registered Linux user # 367800
Registered Ubuntu User #12459
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201010202102...@pcartwright.com
Paul Cartwright
> > but they all seem to croak/crash/fail at IMAP& the kontact app suite.
>
> Tbird/Icedove works fine with courier-IMAP.
yes, and I've used tbird on my laptop .
>
> > Is pegasus still around? but the forward issue HAS bugged me forever..
> > I REALLY REALLY HATE leaving in someone elses email address when I
> > forward stuff..
>
> AFAICT, that's also what Tbird/Icedove and Outlook do.
yes, but 99.9% of the time I'm on my desktop using kmail.. and I like the
Kontact integration...
--
Paul Cartwright
Registered Linux user # 367800
Registered Ubuntu User #12459
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201010202105...@pcartwright.com
Ron Johnson
> On Wed October 20 2010, Ron Johnson wrote:
>>> I've tried evo& Sylpheed,
>>> but they all seem to croak/crash/fail at IMAP& the kontact app suite.
>>
>> Tbird/Icedove works fine with courier-IMAP.
>
> yes, and I've used tbird on my laptop .
>>
>>> Is pegasus still around? but the forward issue HAS bugged me forever..
>>> I REALLY REALLY HATE leaving in someone elses email address when I
>>> forward stuff..
>>
>> AFAICT, that's also what Tbird/Icedove and Outlook do.
> yes, but 99.9% of the time I'm on my desktop using kmail.. and I like the
> Kontact integration...
>
If you can get LDAP fully functional (no mean feat for a hobbyist)
on your desktop then *maybe* KMail and Kontact on your laptop can
see the data on your main machine.
--
Seek truth from facts.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Paul Cartwright
> If you can get LDAP fully functional (no mean feat for a hobbyist)
> on your desktop then *maybe* KMail and Kontact on your laptop can
> see the data on your main machine.
I don't use kmail on my laptop, I use thunderbird. I get to my desktop from my
laptop via nomachine ( a remote desktop app), so I see my full desktop
screen, including the ability to use kmail.. I've only done this from my
lazyboy, via wireless router, not from outside the house, but it DOES work!
I never saw a need for LDAP, not sure how I would use it.. If I fired up
fedora on my laptop, used kmail, setup with IMAP for my accounts, where would
LDAP be used? Or am I thinking about it the wrong way..
--
Paul Cartwright
Registered Linux user # 367800
Registered Ubuntu User #12459
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201010210801...@pcartwright.com
Ron Johnson
> On Wed October 20 2010, Ron Johnson wrote:
>> If you can get LDAP fully functional (no mean feat for a hobbyist)
>> on your desktop then *maybe* KMail and Kontact on your laptop can
>> see the data on your main machine.
>
> I don't use kmail on my laptop, I use thunderbird. I get to my desktop from my
> laptop via nomachine ( a remote desktop app), so I see my full desktop
> screen, including the ability to use kmail.. I've only done this from my
> lazyboy, via wireless router, not from outside the house, but it DOES work!
> I never saw a need for LDAP, not sure how I would use it.. If I fired up
> fedora on my laptop, used kmail, setup with IMAP for my accounts, where would
> LDAP be used? Or am I thinking about it the wrong way..
>
Just as an IMAP server centralizes email for network access, an LDAP
(Lightweight Directory Access Protocol) database on your desktop
machine would store all your contacts.
--
Seek truth from facts.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Paul Cartwright
> Just as an IMAP server centralizes email for network access, an LDAP
> (Lightweight Directory Access Protocol) database on your desktop
> machine would store all your contacts.
so, I could use that instead of having separate contact lists ( and keeping
them synced), on my desktop & laptops...
--
Paul Cartwright
Registered Linux user # 367800
Registered Ubuntu User #12459
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201010211137...@pcartwright.com
Ron Johnson
> On Thu October 21 2010, Ron Johnson wrote:
>> Just as an IMAP server centralizes email for network access, an LDAP
>> (Lightweight Directory Access Protocol) database on your desktop
>> machine would store all your contacts.
>
> so, I could use that instead of having separate contact lists ( and keeping
> them synced), on my desktop& laptops...
>
Exactly.
--
Seek truth from facts.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Lisi
> > Is there a trick to forwarding emails in KMail so that all that happens
> > is that the OP's email content is preserved along with any attachments
> > but that the OP's details can be edited out?
>
> AFAICT, no.
Copy and paste the email content and attach the attachment?
I personally don't actually want all email clients to be identical. We have
choice. Those who like what Icedove does can use Icedove, those who love
Pine can use Pine, and those of us who love Kmail can use Kmail.
You can please all of the people some of the time, and some of the people all
of the time, but you cannot please all of the people all of the time. :-)
Lisi
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201010301541.0...@gmail.com
Camaleón
> On Tuesday 19 October 2010 20:55:07 Camaleón wrote:
>> > Is there a trick to forwarding emails in KMail so that all that
>> > happens is that the OP's email content is preserved along with any
>> > attachments but that the OP's details can be edited out?
>>
>> AFAICT, no.
>
> Copy and paste the email content and attach the attachment?
Kmail only allows to forward "as an attachment" the original e-mail but
many people do not know what to do with an e-mail attached and also, this
breaks the inline (in-situ, over the original e-mail) corrections or
annotations.
Besides, many people are scared about attachments (under "windows minds"
an attachment is a synonym of problems/viruses/scam/phishing) and they
just prefer to not openning the attachment so, in the event the forwarded
e-mail contains important information, they just completely miss it and e-
mail becomes useless (then you have to place a call and tell the
recipient user the e-mail was coming from you and contains important
information he has to read...). You can spend whole morning just to
achieve this >:-)
> I personally don't actually want all email clients to be identical. We
> have choice. Those who like what Icedove does can use Icedove, those
> who love Pine can use Pine, and those of us who love Kmail can use
> Kmail.
Yes, choice is important. But "real" choice is about having the ability
to select what do you want to use every time without the needing to
renounce a program (Kmail) at all just because is not able to properly
handle html.
> You can please all of the people some of the time, and some of the
> people all of the time, but you cannot please all of the people all of
> the time. :-)
You can please all the people all the time by allowing the user to be
able to be free of using the best e-mail format for every situation. And
so it does Thunderbird/Icedove but not Kmail :-(
Greetings,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Paul Cartwright
> > > Is there a trick to forwarding emails in KMail so that all that happens
> > > is that the OP's email content is preserved along with any attachments
> > > but that the OP's details can be edited out?
> >
> > AFAICT, no.
>
> Copy and paste the email content and attach the attachment?
>
> I personally don't actually want all email clients to be identical. We
> have choice. Those who like what Icedove does can use Icedove, those who
> love Pine can use Pine, and those of us who love Kmail can use Kmail.
what about redirect?? that'd the way I send most things that I forward to my
wife..
--
Paul Cartwright
Registered Linux user # 367800
Registered Ubuntu User #12459
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201010301102...@pcartwright.com
Paul Cartwright
> You can please all the people all the time by allowing the user to be
> able to be free of using the best e-mail format for every situation. And
> so it does Thunderbird/Icedove but not Kmail :-(
yes, I didn't finish reading the OP's original request, I forgot about the
>OP's details can be edited out?
I used thunderbird all last week, while I was on vacation, and I love the
ability to forward emails, while keeping the HTML formatting AND removing all
the offending Email To:'s and....
the question is, do I want to try to go to all the trouble of converting my
years of kmail mail, to MBOX format...
--
Paul Cartwright
Registered Linux user # 367800
Registered Ubuntu User #12459
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201010301134...@pcartwright.com
Camaleón
(...)
> the question is, do I want to try to go to all the trouble of converting
> my years of kmail mail, to MBOX format...
Yes, that's another handicap :-)
I love "maildir" and Kmail has the ability to play fine with both formats
(mbox and maildir) while Icedove only works (internally, for local mail)
with mbox and searching strings in Icedove is bit slow if mbox files are
big (measured in GiB :-P).
I finally had to renounce KMail at work, not just because I switched to
GNOME but for its inability of handling HTML as it should.
For you... well, if you are not "forced" to properly render HTML
messages, just keep Kmail, I've always found it to be a great MUA.
Greetings,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
John A. Sullivan III
> On Sat, 30 Oct 2010 11:34:18 -0400, Paul Cartwright wrote:
>
> (...)
>
> > the question is, do I want to try to go to all the trouble of converting
> > my years of kmail mail, to MBOX format...
>
> Yes, that's another handicap :-)
>
> I love "maildir" and Kmail has the ability to play fine with both formats
> (mbox and maildir) while Icedove only works (internally, for local mail)
> with mbox and searching strings in Icedove is bit slow if mbox files are
> big (measured in GiB :-P).
>
> I finally had to renounce KMail at work, not just because I switched to
> GNOME but for its inability of handling HTML as it should.
>
> For you... well, if you are not "forced" to properly render HTML
> messages, just keep Kmail, I've always found it to be a great MUA.
>
> Greetings,
>
> --
> Camaleón
>
>
for the bounty building to fix this problem in KMail -
https://bugs.kde.org/show_bug.cgi?id=86423 - scroll toward the end -
it's very long but the bounty details are at the end. Thanks - John
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1288454216.3356.23.camel@localhost
Lisi
> Kmail only allows to forward "as an attachment" the original e-mail
That is simply not correct. You can forward as attachment, in line, as a
digest or redirect. I always use in line for exactly the reasons you give.
Lisi
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201010302314.3...@gmail.com
Lisi
> On Tue October 19 2010, Mike Bird wrote:
> > I use KMail/Kontact in KDE 3.5 in Lenny.
> >
> > Does pressing "T" ("Edit Message") and changing the "To" address
> > at the top come anywhere close to the functionality you need?
>
> no, it puts everything down at the bottom as an attachment. message
> formatting is lost.
I always forward in line. I have KMail 1.9.9.
Lisi
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201010302322.0...@gmail.com
Lisi
> On 10/20/2010 05:16 PM, Paul Cartwright wrote:
> > On Wed October 20 2010, AG wrote:
> >> However, bottom line: so far this is the most viable solution to the
> >> forwarding issue. I'm sorry to read that it doesn't work for you in a
> >> similar way Paul.
> >
> > ok, I tried it again on another email that had an Encapsulated message.
> > When I hit "T" it attached that message. I double-clicked on the attached
> > message, which still included the OP email address, to& from.. and it
> > was not inline with the original pictures, like I received it.
>
> AFAIK, inline images makes the mail HTML and Kmail screws that up when
> you try to forward it. This is due its limited support for HTML mails.
> (Lack of HTML mail support is the reason I switched to Thunderbird
> from this otherwise perfect mail client as well ).
> Forwarding a Text only mail or mail with attachments the standard way
> allows you to edit out any information that you do not which to forward.
I have finally understood that the rest of you want HTML functionality. I
have always thought that KMail's lack of friendliness to HTML is one of its
strengths.
Lisi
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201010302325.0...@gmail.com
Stan Hoeppner
> the question is, do I want to try to go to all the trouble of converting my
> years of kmail mail, to MBOX format...
You may not have to, as it can be done automatically. If you have an
IMAP account somewhere simply copy all your email folders to the IMAP
server. Attach TB or another MUA to that account, and copy the emails
down again. After you're satisfied all is well, delete the old kmail
emails, and remove those from the IMAP server. Might take a little
longer than file conversion if the IMAP server is the other side of a
DSL line, but there'll be zero chance of conversion problems.
--
Stan
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4CCD1CE...@hardwarefreak.com
Camaleón
> On Saturday 30 October 2010 16:05:43 Camaleón wrote:
>> Kmail only allows to forward "as an attachment" the original e-mail
>
> That is simply not correct. You can forward as attachment, in line, as
> a digest or redirect. I always use in line for exactly the reasons you
> give.
How is that?
If you want to keep images and html formatting of the original message,
as soon as you reply/forward inline you lose all the "fancy" things.
A KDE bug with 2460 votes and a legion of angry users state so :-)
Greetings,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Lisi
> If you want to keep images and html formatting of the original message,
> as soon as you reply/forward inline you lose all the "fancy" things.
Sorry :-( I simply hadn't grasped that you were all complaining at the fact
that Kmail doesn't handle HTML. I have always regarded that as one of its
strengths!
I thought that you were all complaining that you can't forward in line and
without the email address of the original sender.
Personally I like the fact that KMail doesn't do pictures in the middle of the
email. I shall be very sorry when it starts to do so. It is the old dilemma
about whether something is a bug or a feature.
Lisi
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201010311018.3...@gmail.com
Lisi
> On 10/30/2010 06:25 PM, Lisi wrote:
> > I have finally understood that the rest of you want HTML functionality.
> > I have always thought that KMail's lack of friendliness to HTML is one of
> > its strengths.
>
> except be able to remove the offending To:'s . Thunderbird does that.
So use Thunderbird.
Lisi
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201010311011.5...@gmail.com
Camaleón
> On Sunday 31 October 2010 10:09:18 Camaleón wrote:
>> If you want to keep images and html formatting of the original message,
>> as soon as you reply/forward inline you lose all the "fancy" things.
>
> Sorry :-( I simply hadn't grasped that you were all complaining at the
> fact that Kmail doesn't handle HTML. I have always regarded that as one
> of its strengths!
>
> I thought that you were all complaining that you can't forward in line
> and without the email address of the original sender.
Ah, okay, no problem :-)
> Personally I like the fact that KMail doesn't do pictures in the middle
> of the email. I shall be very sorry when it starts to do so. It is the
> old dilemma about whether something is a bug or a feature.
I don't see how a "lack" (meaning, "inability of choice") can be a good
feature ;-(
Greetings,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Lisi
> I don't see how a "lack" (meaning, "inability of choice") can be a good
> feature ;-(
There _is_ choice - there are loads of email clients and most of them have
inline pictures.
But to give you an example of when a lack is a highly to be desired feature.
Someone on the corner of the road I live in installed a very bright security
light that was triggered by a motion sensor. The result was that as I
approached the corner I was suddenly blinded by a very bright light shining
straight into my eyes. It was fairly soon removed, presumably at the
insistance of the Police. It was its _presence_ that was the bug and its
absence a highly desirable feature.
So here. I regard the fact that my emails are blessedly HTML and picture free
as a strength, and a highly desirable feature.
Lisi
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201010311049.2...@gmail.com
Camaleón
> On Sunday 31 October 2010 10:32:24 Camaleón wrote:
>> I don't see how a "lack" (meaning, "inability of choice") can be a good
>> feature ;-(
>
> There _is_ choice - there are loads of email clients and most of them
> have inline pictures.
I wouldn't call it "choice" when you are forced to drop an e-mail client
you like just because it lack one feature that it should be there (it's a
GUI e-mail client, it allows creating html e-mails, so... why not having
a full featured html editor that allows forwarding/replying while keeping
the original format?).
Besides, there are "thounsand" users wanting such feature.
> But to give you an example of when a lack is a highly to be desired
> feature.
>
> Someone on the corner of the road I live in installed a very bright
> security light that was triggered by a motion sensor. The result was
> that as I approached the corner I was suddenly blinded by a very bright
> light shining straight into my eyes. It was fairly soon removed,
> presumably at the insistance of the Police. It was its _presence_ that
> was the bug and its absence a highly desirable feature.
I fail to see a direct relation between this example and Kmail html
issue, because you cannot go and turn off the light (you are not allowed
to do it so, but police) but you can still have plain text e-mail
forwarding _or_ html e-mail forwarding: here the choice is fully yours.
> So here. I regard the fact that my emails are blessedly HTML and
> picture free as a strength, and a highly desirable feature.
Having the option of using html e-mails does not mean you are forced to
go that path, it is up to you when using plain text e-mail or html. Now,
Kmail users do not have that choice.
Greetings,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Stan Hoeppner
> So here. I regard the fact that my emails are blessedly HTML and picture free
> as a strength, and a highly desirable feature.
Tbird has this great feature called "View Message Body As" with 3
options, one being plain text, the other two being varying levels of
HTML. My default view is plain text.
I always send plain text messages. If I wanted to I could forward an
HTML message inline as Tbird has all kinds of flexibility in this
regard. But why would I want to forward HTML garbage, inline or otherwise?
"Rich HTML" email was a neat thing until spammers, marketeers,
criminals, etc, ruined its use.
--
Stan
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4CCD50BB...@hardwarefreak.com
Paul Cartwright
> I always send plain text messages. If I wanted to I could forward an
> HTML message inline as Tbird has all kinds of flexibility in this
> regard. But why would I want to forward HTML garbage, inline or otherwise?
>
> "Rich HTML" email was a neat thing until spammers, marketeers,
> criminals, etc, ruined its use.
I get PLENTY of rich text emails, from friends & family, and I like to
forward them AS-IS to others.. They like it like that, nice pretty
pictures, just like the web sites. I grew up with mailx 25 years ago,
but then again I also had a rotary dial phone, and a 1965 Volkswagon
Bug.. things change:)
--
Paul Cartwright
Registered Linux user # 367800
Registered Ubuntu User #12459
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4CCD5BD4...@pcartwright.com
Klistvud
> On Sun, 31 Oct 2010 10:49:24 +0000, Lisi wrote:
>
> > On Sunday 31 October 2010 10:32:24 Camaleón wrote:
> >> I don't see how a "lack" (meaning, "inability of choice") can be a
> good
> >> feature ;-(
I don't think you can directly equate "choice" to "feature" just like
that. Not letting kids wield guns, or prostitute themselves, or work in
sweatshops, are "features" although actually limiting their "ability of
choice". Not allowing people to drive cars before taking a driver's
license, although limiting people's "choice", is likewise arguably a
"feature".
Now, something like HTML mail is either a feature or it is not.
Steering issues about "features" into issues of "liberty to choose" is,
in my view, counterproductive. If we begin talking about the "liberty
to choose", we'll soon have to install bumps in our roads because of
reckless people who "choose" to drive like lethal bullets, or will have
to endure excruciating check-ups at airports because of people who
"choose" to use airplanes for something else than simply getting from
one place to another, or will have to endure hefty, painfully slow
flash-infested mail... Oh, we already do all that? I rest my case.
> >
> > There _is_ choice - there are loads of email clients and most of
> them
> > have inline pictures.
>
> I wouldn't call it "choice" when you are forced to drop an e-mail
> client
> you like just because it lack one feature that it should be there
> (it's a
> GUI e-mail client, it allows creating html e-mails, so... why not
> having
> a full featured html editor that allows forwarding/replying while
> keeping
> the original format?).
That's precisely the problem. Approaching something on a why-not basis
instead of on a what-the-heck-for basis. Hey, why not make YAMC (yet
another mail client), basically re-inventing the wheel, instead of
joining the developers of a pre-existing mail client, and helping it
become 10x as fast, 100x as lightweight and 1000x as robust as all
other mail clients taken together? Hey, why not drop a stable, popular
and beloved DE such as KDE3 and, just for the heck of it, start a hazy,
bug-ridden, pre-production experiment called KDE4? Hey, why not have a
welcome page on our web site made of a *huge* java, or flash
application, stuffed full with blinking eye-sores and background music
and all imaginable bandwidth hogs, just to basically say "Welcome to
our site"? Hey, why encode e-mails as TEXT? It's so damn last-year,
let's encode it as MPEG-1 instead, or RealMedia -- or, hey -- as
uncompressed video! Yep, why not? Man, we could make the "Subject:"
field alone take up 125 MB if we just try hard enough!
>
> Besides, there are "thounsand" users wanting such feature.
Sad, isn't it?
> > But to give you an example of when a lack is a highly to be desired
> > feature.
> >
> > Someone on the corner of the road I live in installed a very bright
> > security light that was triggered by a motion sensor. The result
> was
> > that as I approached the corner I was suddenly blinded by a very
> bright
> > light shining straight into my eyes. It was fairly soon removed,
> > presumably at the insistance of the Police. It was its _presence_
> that
> > was the bug and its absence a highly desirable feature.
>
> I fail to see a direct relation between this example and Kmail html
> issue, because you cannot go and turn off the light (you are not
> allowed
> to do it so, but police) but you can still have plain text e-mail
> forwarding _or_ html e-mail forwarding: here the choice is fully
> yours.
Sounds great. Except, the choice is fully yours. Which, given that,
generally, 90% of the people will choose Windows over GNU/Linux, Word
.doc format over open document standards, royalty-ridden multimedia
formats over open ones, vendor lock-in over open hardware/drivers, or
even super-sized hamburgers over healthy foods, can be a problem in
itself.
>
> > So here. I regard the fact that my emails are blessedly HTML and
> > picture free as a strength, and a highly desirable feature.
>
> Having the option of using html e-mails does not mean you are forced
> to
> go that path, it is up to you when using plain text e-mail or html.
> Now,
> Kmail users do not have that choice.
Unfortunately, many of us have that path quite simply *thrust upon us*.
I wouldn't call that a choice by any stretch of the imagination. Ever
tried updating your mail over a tethered UMTS phone because your DSL
line just died or you're in the wild somewhere, with only your laptop
and your GSM phone? It's an enlightening experience, at a flaky 2-3
kps. Particularly when you realize that the bulk of that 45-minutes
download that has drained both your battery and your pre-paid GSM
account, has been taken by a couple of unsolicited multimedia-infested
HTML mails ...
Give a man the Garden of Eden, and you may be pretty sure he'll
eventually make a Middle-East Hell out of it. Oh, he did? I rest my
case.
I apologize if anybody's feelings have been hurt by this mail. It was
never my intention. I particularyl apologize to Camaleon, whom I value
as one of the best contributors to this list, in fact as one of the
list's pillars. My argument is not with you, Camaleon, it's with
certain modes of thinking that seem to be quite endemic and which I
profoundly disagree with.
--
Cheerio,
Klistvud
http://bufferoverflow.tiddlyspot.com
Certifiable Loonix User #481801 Please reply to the list, not to
me.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Paul Cartwright
Unfortunately, many of us have that path quite simply *thrust upon us*. I wouldn't call that a choice by any stretch of the imagination. Ever tried updating your mail over a tethered UMTS phone because your DSL line just died or you're in the wild somewhere, with only your laptop and your GSM phone? It's an enlightening experience, at a flaky 2-3 kps. Particularly when you realize that the bulk of that 45-minutes download that has drained both your battery and your pre-paid GSM account, has been taken by a couple of unsolicited multimedia-infested HTML mails ...
1. not download html emails, headers only
2. not download ANY email with attachments
3. not download any email over Xkb
I feel your pain.. I was just in a hotel all week, where the dsl connection was:
1. flakey & prone to disconnect
2. SLOW...
and of course my wifes Windows box on Tuesday wanted to download a 111MB virus program update and 11 Windows updates, and Thunderbird wanted to update to 3.1.6 !!!!!!!
Camaleón
> Dne, 31. 10. 2010 12:02:39 je Camaleón napisal(a):
>> >> I don't see how a "lack" (meaning, "inability of choice") can be a
>> >> good feature ;-(
>
> I don't think you can directly equate "choice" to "feature" just like
> that. Not letting kids wield guns, or prostitute themselves, or work in
> sweatshops, are "features" although actually limiting their "ability of
> choice". Not allowing people to drive cars before taking a driver's
> license, although limiting people's "choice", is likewise arguably a
> "feature".
I don't know how can you equate all that stuff with having html e-mail
unsless you also avoid using Internet (websites use html and not plain
text and we are all happy with that).
Come on, we cannot be so hypocrite. In no way html is a bad thing "per
se", it is an standard, it has it uses and people need that feature. 2400
people need that feature. You can start ignoring people wishes but then
you can forget that people fill bugs for another things, they'll just
search another alternatives to kmail or even KDE.
> Now, something like HTML mail is either a feature or it is not. Steering
> issues about "features" into issues of "liberty to choose" is, in my
> view, counterproductive. If we begin talking about the "liberty to
> choose", we'll soon have to install bumps in our roads because of
> reckless people who "choose" to drive like lethal bullets, or will have
> to endure excruciating check-ups at airports because of people who
> "choose" to use airplanes for something else than simply getting from
> one place to another, or will have to endure hefty, painfully slow
> flash-infested mail... Oh, we already do all that? I rest my case.
I think you are missing the point completely.
>> I wouldn't call it "choice" when you are forced to drop an e-mail
>> client
>> you like just because it lack one feature that it should be there (it's
>> a
>> GUI e-mail client, it allows creating html e-mails, so... why not
>> having
>> a full featured html editor that allows forwarding/replying while
>> keeping
>> the original format?).
>
> That's precisely the problem. Approaching something on a why-not basis
> instead of on a what-the-heck-for basis. Hey, why not make YAMC (yet
> another mail client), basically re-inventing the wheel, instead of
> joining the developers of a pre-existing mail client, and helping it
> become 10x as fast, 100x as lightweight and 1000x as robust as all other
> mail clients taken together? Hey, why not drop a stable, popular and
> beloved DE such as KDE3 and, just for the heck of it, start a hazy,
> bug-ridden, pre-production experiment called KDE4? Hey, why not have a
> welcome page on our web site made of a *huge* java, or flash
> application, stuffed full with blinking eye-sores and background music
> and all imaginable bandwidth hogs, just to basically say "Welcome to our
> site"? Hey, why encode e-mails as TEXT? It's so damn last-year, let's
> encode it as MPEG-1 instead, or RealMedia -- or, hey -- as uncompressed
> video! Yep, why not? Man, we could make the "Subject:" field alone take
> up 125 MB if we just try hard enough!
There is no need to reinvent nothing. Kmail has support for html e-mail
formatting, it just lacks some features to properly handle that format. A
bug or a feature... I do not care. I don't think Mutt needs to be able to
handle hmtl e-mails because is not a MUA designed for that purpose. But
Kmail _is_ and has a very poor support for html. To be fair, if Kmail DDs
do not want html, it would be better to dropt it at all.
>> Besides, there are "thounsand" users wanting such feature.
>
> Sad, isn't it?
Very sad. That behaviour could mean:
1/ Kmail DDs are not able to add that feature because they just do not
know how to make it possible.
2/ Kmail DDs are completely ignoring their users which does not sound
good, either.
>> I fail to see a direct relation between this example and Kmail html
>> issue, because you cannot go and turn off the light (you are not
>> allowed
>> to do it so, but police) but you can still have plain text e-mail
>> forwarding _or_ html e-mail forwarding: here the choice is fully yours.
>
> Sounds great. Except, the choice is fully yours.
Of course... so that I dropped KDE. Do you think that is the right way
for open source projects? Coomunication should flow from both extremes,
users <-> devels.
> Which, given that,
> generally, 90% of the people will choose Windows over GNU/Linux, Word
> .doc format over open document standards, royalty-ridden multimedia
> formats over open ones, vendor lock-in over open hardware/drivers, or
> even super-sized hamburgers over healthy foods, can be a problem in
> itself.
People is free to choose whatever they want because they have the
capability to do it so, that's the beatiful of freedom.
But if you are encouraging users to drop Kmail just because of that,
well, that is your POV. I prefer to help to correct those things that I
think are wrong.
>> Having the option of using html e-mails does not mean you are forced to
>> go that path, it is up to you when using plain text e-mail or html.
>> Now,
>> Kmail users do not have that choice.
>
> Unfortunately, many of us have that path quite simply *thrust upon us*.
> I wouldn't call that a choice by any stretch of the imagination. Ever
> tried updating your mail over a tethered UMTS phone because your DSL
> line just died or you're in the wild somewhere, with only your laptop
> and your GSM phone? It's an enlightening experience, at a flaky 2-3 kps.
> Particularly when you realize that the bulk of that 45-minutes download
> that has drained both your battery and your pre-paid GSM account, has
> been taken by a couple of unsolicited multimedia-infested HTML mails ...
Your are messing up things. Nobody is telling that you have to use html e-
mails, I am telling that having such option will not prevent users for
still using text e-mails.
In fact, you will still receive html spam and viruses regardless the MUA
you use and regardless its capabilities, so your argument is bit of no-
sense.
> Give a man the Garden of Eden, and you may be pretty sure he'll
> eventually make a Middle-East Hell out of it. Oh, he did? I rest my
> case.
>
> I apologize if anybody's feelings have been hurt by this mail. It was
> never my intention. I particularyl apologize to Camaleon, whom I value
> as one of the best contributors to this list, in fact as one of the
> list's pillars. My argument is not with you, Camaleon, it's with certain
> modes of thinking that seem to be quite endemic and which I profoundly
> disagree with.
No offense taken. I think good debates are always needed, mostly in the
FLOSS camp :-)
Greetings,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Klistvud
> On Sun, 31 Oct 2010 14:14:12 +0100, Klistvud wrote:
> >
> > I don't think you can directly equate "choice" to "feature" just
> like
> > that. Not letting kids wield guns, or prostitute themselves, or
> work in
> > sweatshops, are "features" although actually limiting their
> "ability of
> > choice". Not allowing people to drive cars before taking a driver's
> > license, although limiting people's "choice", is likewise arguably a
> > "feature".
>
> I don't know how can you equate all that stuff with having html e-mail
> unsless you also avoid using Internet (websites use html and not plain
> text and we are all happy with that).
I was not equating anything with anything, I was just trying to make a
distinction about features not always being choices and vice versa; and
about features not always making us better off.
>
> Come on, we cannot be so hypocrite.
We could at least try ... ;)
> I think you are missing the point completely.
>
Now you're beginning to sound exactly as my wife ... ;)
>
> People is free to choose whatever they want because they have the
> capability to do it so, that's the beatiful of freedom.
>
With freedom should come responsibility. However, that doesn't seem to
be the case. If I take a look around me -- of course, it may just be me
-- I see that, more often than not, people make choices for the worse.
Problem is, those poor choices of the so-called "majority" have
repercussions on all of us. In the end, I'm forced to endure HTML mail,
although I may despise it. I'm forced to endure flash although I may
despise it. If I want to be able to play music on a mobile phone or a
portable player, I'm forced to either use the patent-encumbered mp3
format or nothing -- open formats are not supported, or only
exceptionally. If I want to watch family photos on my home DVD
recorder, they have to be in the royalty-encumbered jpg format --
again, open formats are rarely supported. Gosh, even for just *taking*
a family photo I'll have a hard time finding a camera that doesn't use
patent-encumbered formats! If I want to buy a laptop that is at least
half-compatible with a Free OS, I must go to great lengths to check in
advance that all components will work at all, because the wise majority
is quite content with it working in Windows and couldn't care less.
And it's not just a matter of abstract principles, sometimes it
interferes with my life quite directly. For example, if I want to
exchange document files with my clients in order to make my living --
they require I use the proprietary Word .doc format. They've obviously
never even heard of .odt and the like. All these, and many other,
choices are being thrust upon me on a daily basis by the "savvy
majority", and they are all poor choices in my view.
> But if you are encouraging users to drop Kmail just because of that,
> well, that is your POV. I prefer to help to correct those things that
> I
> think are wrong.
I don't encourage users to do anything. I am just expounding the 2¢
worth of my POV.
>
> Your are messing up things. Nobody is telling that you have to use
> html e-
> mails, I am telling that having such option will not prevent users for
> still using text e-mails.
>
> In fact, you will still receive html spam and viruses regardless the
> MUA
> you use and regardless its capabilities, so your argument is bit of
> no-
> sense.
>
True, but if you think about what made HTML spam and viruses possible
in the first place, you'll come to the conclusion that it was the
introduction of HTML mail. It was the bane of the "feature-driven
design". It was the "hey, why-not" attitude. Many of us never wanted
it. I was on dial-up at the time and sure as hell didn't want it. I
thought that text-only mail standard was lean, bandwidth-efficient,
fast and lightweight, and something the Internet Consortium (or whoever
invented it) could really be proud of. Why ruin it?
Well, the savvy majority decided for us all. Now, we have to endure
HTML spam and viruses just like all those who made the wise decision to
introduce HTML "features" into e-mail.
Well, thanks for nothing.
P.S. Nothing of the above is aimed at Kmail specifically. Kmail is the
greatest mail client I've ever used, more complete, more intuitive, and
more stable than Balsa which I'm using now. I've only dropped it
because I switched to Gnome and don't want to burden my system with any
KDE libraries. I've used Kmail for a year or so and never even noticed
whether it had HTML support or no -- just goes to show how much I
needed it.
--
Cheerio,
Klistvud
http://bufferoverflow.tiddlyspot.com
Certifiable Loonix User #481801 Please reply to the list, not to
me.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Camaleón
> Dne, 31. 10. 2010 14:51:00 je Camaleón napisal(a):
>> I don't know how can you equate all that stuff with having html e-mail
>> unsless you also avoid using Internet (websites use html and not plain
>> text and we are all happy with that).
>
> I was not equating anything with anything, I was just trying to make a
> distinction about features not always being choices and vice versa; and
> about features not always making us better off.
Care to tell me just one thing that would make having a full featured
html formatting editor embedded in kmail harm users?
Sorry, but I fail to see how "adding" new options can be "bad" for users.
Will it make Kmail package breaks? No, I don't think so.
Will it make Kmail package increses its size? Maybe some megabytes, not a
big deal.
Will it prevent user for using plain text e-mails as they were used to?
No, it won't, users can still use their MUA in the way they prefer.
So, what is the damage this will make? I can't name it.
>> People is free to choose whatever they want because they have the
>> capability to do it so, that's the beatiful of freedom.
>>
>>
> With freedom should come responsibility. However, that doesn't seem to
> be the case. If I take a look around me -- of course, it may just be me
> -- I see that, more often than not, people make choices for the worse.
Let people learn from their errors. Forcing users to act as "they should"
will only make they reject to do it that way. It's a psychological fact:
the more interest you have in people behave in a concrete manner, the
more interest they'll have in acting the opposite.
> Problem is, those poor choices of the so-called "majority" have
> repercussions on all of us. In the end, I'm forced to endure HTML mail,
> although I may despise it. I'm forced to endure flash although I may
> despise it. If I want to be able to play music on a mobile phone or a
> portable player, I'm forced to either use the patent-encumbered mp3
> format or nothing -- open formats are not supported, or only
> exceptionally.
That must be you, sir. I'm not enforced to anything of this. I can browse
the web with lynx or I can use an addon to avoid loading javascript, pop-
ups or flash animations. You like flash? You got it. You don't like, you
can avoid it without any problem. Todays browsers can handle that for you
in an easy manner.
> If I want to watch family photos on my home DVD recorder,
> they have to be in the royalty-encumbered jpg format -- again, open
> formats are rarely supported. Gosh, even for just *taking* a family
> photo I'll have a hard time finding a camera that doesn't use
> patent-encumbered formats! If I want to buy a laptop that is at least
> half-compatible with a Free OS, I must go to great lengths to check in
> advance that all components will work at all, because the wise majority
> is quite content with it working in Windows and couldn't care less. And
> it's not just a matter of abstract principles, sometimes it interferes
> with my life quite directly. For example, if I want to exchange document
> files with my clients in order to make my living -- they require I use
> the proprietary Word .doc format. They've obviously never even heard of
> .odt and the like. All these, and many other, choices are being thrust
> upon me on a daily basis by the "savvy majority", and they are all poor
> choices in my view.
That seems to be a bit of rant again many things that have nothing to do
with the issue we are talking about. Ranting is free, though. I think
that a bit of ranting does not hurt from time to time, but in the end, I
prefer acting and helping users/developers to fix things they do not like
or they want to improve :-)
>> Your are messing up things. Nobody is telling that you have to use html
>> e-
>> mails, I am telling that having such option will not prevent users for
>> still using text e-mails.
>>
>> In fact, you will still receive html spam and viruses regardless the
>> MUA
>> you use and regardless its capabilities, so your argument is bit of no-
>> sense.
>>
>>
> True, but if you think about what made HTML spam and viruses possible in
> the first place, you'll come to the conclusion that it was the
> introduction of HTML mail.
I don't have -right now- any statistics about this, but IIRC, there is a
higher percentage of spam using plain text e-mail rather than html
format, because users avoid opening html messages (antivirus companies
and anti-malware campaings tell them to do so) so they are very cautelous
with these e-mails but have no problem with opening plain text ones.
> It was the bane of the "feature-driven
> design". It was the "hey, why-not" attitude. Many of us never wanted it.
If you don't want to use something, then do not use it but let other
users can make use of it if they want :-)
> I was on dial-up at the time and sure as hell didn't want it. I thought
> that text-only mail standard was lean, bandwidth-efficient, fast and
> lightweight, and something the Internet Consortium (or whoever invented
> it) could really be proud of. Why ruin it? Well, the savvy majority
> decided for us all. Now, we have to endure HTML spam and viruses just
> like all those who made the wise decision to introduce HTML "features"
> into e-mail. Well, thanks for nothing.
Okay... nothing prevents you for returning to your "sweet cavern" if you
are happy on it: cut down your dsl lease line, return to dial-up and
start using mutt and wget to browse the web and fetching e-mails ;-)
> P.S. Nothing of the above is aimed at Kmail specifically. Kmail is the
> greatest mail client I've ever used, more complete, more intuitive, and
> more stable than Balsa which I'm using now. I've only dropped it because
> I switched to Gnome and don't want to burden my system with any KDE
> libraries. I've used Kmail for a year or so and never even noticed
> whether it had HTML support or no -- just goes to show how much I needed
> it.
I have to agree with that: Kmail is the best MUA I've ever used (and I
had to deal with Outlook 2000/2007, Outlook Express, Windows Mail,
Thunderbird, Gmail webmail and Mutt).
Now I use Icedove/Thunderbird in GNOME, Mutt and also a newsreader (Pan)
to read and reply to this list :-)
Greetings,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Boyd Stephen Smith Jr.
>On Sun, 31 Oct 2010 16:51:05 +0100, Klistvud wrote:
>> Dne, 31. 10. 2010 14:51:00 je Camaleón napisal(a):
>>> I don't know how can you equate all that stuff with having html e-mail
>>> unsless you also avoid using Internet (websites use html and not plain
>>> text and we are all happy with that).
The web was founded on text/html. Email was founded on text/plain.
The web is a pull / request model. Email is a push / send model.
The web operates through multiple linked requests. Email expects everything
inside a single message.
The reason people dislike HTML email is because email is a different type of
medium, for which HTML is inappropriate.
>> I was not equating anything with anything, I was just trying to make a
>> distinction about features not always being choices and vice versa; and
>> about features not always making us better off.
>
>Care to tell me just one thing that would make having a full featured
>html formatting editor embedded in kmail harm users?
>
>Sorry, but I fail to see how "adding" new options can be "bad" for users.
Paradox of choice. Fewer options is easier to understand. If the new feature
is not the default, how will we show it off; if the new feature is the
default, the existing user base will complain.
>Will it prevent user for using plain text e-mails as they were used to?
>No, it won't, users can still use their MUA in the way they prefer.
Depends. Other clients in the past have grown test/html support in ways that
make it very difficult, if not impossible, to write well-formed text/plain
emails using them.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
b...@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
Camaleón
> In <pan.2010.10...@gmail.com>, Camaleón wrote:
>>On Sun, 31 Oct 2010 16:51:05 +0100, Klistvud wrote:
>>> Dne, 31. 10. 2010 14:51:00 je Camaleón napisal(a):
>>>> I don't know how can you equate all that stuff with having html
>>>> e-mail unsless you also avoid using Internet (websites use html and
>>>> not plain text and we are all happy with that).
>
> The web was founded on text/html. Email was founded on text/plain. The
> web is a pull / request model. Email is a push / send model. The web
> operates through multiple linked requests. Email expects everything
> inside a single message.
It is called "evolution".
The first hypertext applications were not very dynamic, I'd say, just
text and some links to jump to. Just look around now what the web has to
offer.
> The reason people dislike HTML email is because email is a different
> type of medium, for which HTML is inappropriate.
I can understand people dislike that things, but forcing their own POV to
the rest of the users is not a fair approach. In that reasoning, we could
still stay with "us-ascii" encoding and ditch "utf-8", but nowadays I
wouldn't find it quite appropiate.
>>> I was not equating anything with anything, I was just trying to make a
>>> distinction about features not always being choices and vice versa;
>>> and about features not always making us better off.
>>
>>Care to tell me just one thing that would make having a full featured
>>html formatting editor embedded in kmail harm users?
>>
>>Sorry, but I fail to see how "adding" new options can be "bad" for
>>users.
>
> Paradox of choice. Fewer options is easier to understand. If the new
> feature is not the default, how will we show it off; if the new feature
> is the default, the existing user base will complain.
But I'm not talking about "defaulting" KMail to html e-mails. Plain text
e-mails can be defauult choice, I have no objections to that. People is
smart enough to switch over text/html if properly indicated inside Kmail
UI (an actually I know it is) and even if the user cannot find it, he/she
can always ask in mailing lists or forums on how to change it.
>>Will it prevent user for using plain text e-mails as they were used to?
>>No, it won't, users can still use their MUA in the way they prefer.
>
> Depends. Other clients in the past have grown test/html support in ways
> that make it very difficult, if not impossible, to write well-formed
> text/plain emails using them.
I would call that a bug, sir (and a big one), and being a bug is
something that should be fixed :-)
Boyd Stephen Smith Jr.
>On Sun, 31 Oct 2010 13:51:04 -0500, Boyd Stephen Smith Jr. wrote:
>> In <pan.2010.10...@gmail.com>, Camaleón wrote:
>>>On Sun, 31 Oct 2010 16:51:05 +0100, Klistvud wrote:
>>>> Dne, 31. 10. 2010 14:51:00 je Camaleón napisal(a):
>>>>> I don't know how can you equate all that stuff with having html
>>>>> e-mail unsless you also avoid using Internet (websites use html and
>>>>> not plain text and we are all happy with that).
>>
>> The web was founded on text/html. Email was founded on text/plain. The
>> web is a pull / request model. Email is a push / send model. The web
>> operates through multiple linked requests. Email expects everything
>> inside a single message.
>
>It is called "evolution".
>
>The first hypertext applications were not very dynamic, I'd say, just
>text and some links to jump to. Just look around now what the web has to
>offer.
Yes, because HTML (in particular) was designed with that in mind. Gluing
together of disparate resources in a relatively full-featured client.
Email was NOT designed this way. It took decades before it could handle
attachments sanely. MUAs should not be expected to even be ABLE to fetch
resources that are outside of the current message. There are proposals I've
seen for using URIs in the HTML that resolve to other parts of the same MIME
structure, but they are not followed by (m)any MUAs, particularly composers,
and they all seemed a bit fragile as I was reading them.
>> The reason people dislike HTML email is because email is a different
>> type of medium, for which HTML is inappropriate.
>
>I can understand people dislike that things, but forcing their own POV to
>the rest of the users is not a fair approach. In that reasoning, we could
>still stay with "us-ascii" encoding and ditch "utf-8", but nowadays I
>wouldn't find it quite appropiate.
Use a different, more appropriate, medium if you want to use HTML. The push /
send model is not appropriate for the gluing together of disparate resources,
in particular untrusted resources.
When using the web, you are using a pull / request model. In this case,
server dictates the terms. The UA must accept and process whatever the server
deigns to deliver as part of the request, and the user must seek out a UA with
the right features in order to satisfy their needs.
In this model, "evolution" moves quickly, since new features are adopted by a
users in order to handle response from more servers.
When using email, you are using a push / send model. In this case, the
recipient dictates the terms. The MUA must only create and send data that the
recipient is willing to accept or the effort is wasted, and the user must seek
out a MUA that can reach the most recipients. (In a support context, more
recipients = more replies = more useful replies = better support. In a
marketing / community context, more recipients = more eyes = more inquiries =
more sales / members.)
In this model, "evolution" moves slowly, since new features are avoided by
users in order to reach the most recipients.
I have descent bandwidth, to doing a reasonable multipart/alternative message
will reach me. You send in text/html and your message just goes in the round
file. Others don't have the bandwidth to waste / spend; multipart/alternative
messages reach their round file. Still others will accept all 3 forms. If
you want the most people to see your message, you'll use text/plain.
>>>> I was not equating anything with anything, I was just trying to make a
>>>> distinction about features not always being choices and vice versa;
>>>> and about features not always making us better off.
>>>
>>>Sorry, but I fail to see how "adding" new options can be "bad" for
>>>users.
>>>
>> Paradox of choice. Fewer options is easier to understand. If the new
>> feature is not the default, how will we show it off; if the new feature
>> is the default, the existing user base will complain.
>
>But I'm not talking about "defaulting" KMail to html e-mails. Plain text
>e-mails can be defauult choice, I have no objections to that. People is
>smart enough to switch over text/html if properly indicated inside Kmail
>UI (an actually I know it is) and even if the user cannot find it, he/she
>can always ask in mailing lists or forums on how to change it.
That was 3 reasons, not 1. You still haven't addressed "Paradox of choice" (a
practical, documented usability problem) or "Fewer options is easier to
understand".
I must have snipped too much, but you mentioned UTF-8 vs. US-ASCII. UTF-8
doesn't replace US-ASCII, the replaces dozens of different ways to handle
bytes that are not in US-ASCII. Using UTF-8 rarely reduces the number of
people your message is seen by. If it is all US-ASCII character, then the
UTF-8 encoding is a no-op and everyone that could read it before can still
read it. If it is not all US-ASCII, then you've traded users of specific
other encodings for users that can read UTF-8. In certain forums, it *still*
might be best to use an encoding other that UTF-8, but not on a Debian forum.
(Since UTF-8 is so well supporting in Debian oldstable and above.)
Ron Johnson
> On Sat October 30 2010, Camale�n wrote:
>> You can please all the people all the time by allowing the user to be
>> able to be free of using the best e-mail format for every situation. And
>> so it does Thunderbird/Icedove but not Kmail :-(
>
> yes, I didn't finish reading the OP's original request, I forgot about the
>> OP's details can be edited out?
>
> I used thunderbird all last week, while I was on vacation, and I love the
> ability to forward emails, while keeping the HTML formatting AND removing all
> the offending Email To:'s and....
>
> the question is, do I want to try to go to all the trouble of converting my
> years of kmail mail, to MBOX format...
This is so confusing, since I've been using Icedove for *years*
while storing my (and my wife's and kids') email in an IMAP server.
--
Seek truth from facts.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ron Johnson
> Dne, 31. 10. 2010 12:02:39 je Camaleón napisal(a):
>> On Sun, 31 Oct 2010 10:49:24 +0000, Lisi wrote:
>>
>> > On Sunday 31 October 2010 10:32:24 Camaleón wrote:
>> >> I don't see how a "lack" (meaning, "inability of choice") can
>> be a good
>> >> feature ;-(
>
> I don't think you can directly equate "choice" to "feature" just
> like that. Not letting kids wield guns,
Kids wield guns on an extraordinarily frequent basis w/o injury to
anything but the intended non-human target (milk jug, deer,
squirrel, groundhog, duck, alligator, etc, etc).
--
Seek truth from facts.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Camaleón
> In <pan.2010.10...@gmail.com>, Camaleón wrote:
>>It is called "evolution".
>>
>>The first hypertext applications were not very dynamic, I'd say, just
>>text and some links to jump to. Just look around now what the web has to
>>offer.
>
> Yes, because HTML (in particular) was designed with that in mind.
> Gluing together of disparate resources in a relatively full-featured
> client.
>
> Email was NOT designed this way. It took decades before it could handle
> attachments sanely. MUAs should not be expected to even be ABLE to
> fetch resources that are outside of the current message. There are
> proposals I've seen for using URIs in the HTML that resolve to other
> parts of the same MIME structure, but they are not followed by (m)any
> MUAs, particularly composers, and they all seemed a bit fragile as I was
> reading them.
A html editor can be a very simple piece of software as html markup
language is. It has to follow a few of well-defined and static rules and
nothing more.
I am not saying that having a full-featured html editor (like Bluefish)
embedded into Kmail is the path to go (a MUA is not an application for
designing dynamic web content) but it should be just fine with basic html
4.01 syntax at least for displaying/dealing with images, tables, basic
css style and text formatting. Nothing more, no need to add extra
capabilities such javascript or flash interpreter, no need for adding
extra addons, just a basic editing that goes beyond the plain text.
In fact, Kmail currently allows displaying html content and perform basic
html editing and that doesn't seem that bad.
>>I can understand people dislike that things, but forcing their own POV
>>to the rest of the users is not a fair approach. In that reasoning, we
>>could still stay with "us-ascii" encoding and ditch "utf-8", but
>>nowadays I wouldn't find it quite appropiate.
>
> Use a different, more appropriate, medium if you want to use HTML. The
> push / send model is not appropriate for the gluing together of
> disparate resources, in particular untrusted resources.
You are talking here about external content (like linked or embedded
images) but an e-mail client that supports html is useful for more than
that.
Untrusted sources can be also blocked as Icedove does. In fact, Kmail
also does the same way, allowing the user whether load or don't load
images coming from external sites or even displaying (by default) html
formatted messages as plain text.
That is not a valid argument for Kmail cannot forward or reply to html
formatted e-mails while preserving the whole sctructure of the message.
> When using the web, you are using a pull / request model. In this case,
> server dictates the terms. The UA must accept and process whatever the
> server deigns to deliver as part of the request, and the user must seek
> out a UA with the right features in order to satisfy their needs.
>
> In this model, "evolution" moves quickly, since new features are adopted
> by a users in order to handle response from more servers.
You will still facing "client side" programming issues. Not all browsers
renders the same the different versions of javascript/DOM/CSS3 (Ajax) so
you still heavily depend on the client and its capabilities.
> When using email, you are using a push / send model. In this case, the
> recipient dictates the terms. The MUA must only create and send data
> that the recipient is willing to accept or the effort is wasted, and the
> user must seek out a MUA that can reach the most recipients. (In a
> support context, more recipients = more replies = more useful replies =
> better support. In a marketing / community context, more recipients =
> more eyes = more inquiries = more sales / members.)
>
> In this model, "evolution" moves slowly, since new features are avoided
> by users in order to reach the most recipients.
>
> I have descent bandwidth, to doing a reasonable multipart/alternative
> message will reach me. You send in text/html and your message just goes
> in the round file. Others don't have the bandwidth to waste / spend;
> multipart/alternative messages reach their round file. Still others
> will accept all 3 forms. If you want the most people to see your
> message, you'll use text/plain.
Again, that reasoning has nothing to do with html messages nor
technicalities, you are talking about what are your own preferences. I
receive text messages bigger in size than html formatted e-mails. It all
depends on the ability of the sender in making well designed e-mails (of
course, it also depends on having a good the e-mail client html editor).
In fact, there is RFC 1896 that addressed (on the earlier Internet days)
the concerns of formatted text in e-mails.
>>> Paradox of choice. Fewer options is easier to understand. If the new
>>> feature is not the default, how will we show it off; if the new
>>> feature is the default, the existing user base will complain.
>>
>>But I'm not talking about "defaulting" KMail to html e-mails. Plain text
>>e-mails can be defauult choice, I have no objections to that. People is
>>smart enough to switch over text/html if properly indicated inside Kmail
>>UI (an actually I know it is) and even if the user cannot find it,
>>he/she can always ask in mailing lists or forums on how to change it.
>
> That was 3 reasons, not 1. You still haven't addressed "Paradox of
> choice" (a practical, documented usability problem) or "Fewer options is
> easier to understand".
If you are concerned about that "usability problem" then ask the users
what would they prefer and what would be more confortable for them. Do
not make the error of just think for them.
Again, Kmail does currently have support for basic html editing and e-
mail creation, so I still fail to see the problem of just "improving" a
feature that is currently available.
> I must have snipped too much, but you mentioned UTF-8 vs. US-ASCII.
> UTF-8 doesn't replace US-ASCII, the replaces dozens of different ways to
> handle bytes that are not in US-ASCII. Using UTF-8 rarely reduces the
> number of people your message is seen by. If it is all US-ASCII
> character, then the UTF-8 encoding is a no-op and everyone that could
> read it before can still read it. If it is not all US-ASCII, then
> you've traded users of specific other encodings for users that can read
> UTF-8. In certain forums, it *still* might be best to use an encoding
> other that UTF-8, but not on a Debian forum. (Since UTF-8 is so well
> supporting in Debian oldstable and above.)
You are not losing audience by using html e-mails. Even Mutt have the
proper tools to handle that (meaning that text based MUAs can just launch
an external program to properly render the e-mail).
Moreover, Icedove has an option to send html formatted e-mails along with
plain text, just plain text or just html. The sender can choose the
appropiate format based on his/her user target.
Ron Johnson
[snip]
>
> Come on, we cannot be so hypocrite. In no way html is a bad thing "per
> se", it is an standard, it has it uses and people need that feature. 2400
> people need that feature.
In business, people *constantly* use html mail in Outlook/Exchange
and it's *stupendously useful* for numbering/bulleting,
highlighting, pasting images, etc, etc.
--
Seek truth from facts.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ron Johnson
[snip]
>
> I have finally understood that the rest of you want HTML functionality. I
> have always thought that KMail's lack of friendliness to HTML is one of its
> strengths.
>
Options, Lisi, *options*.
You can configure Thunderbird to (as I do) ignore html and you can
configure it to (as my wife wants) embrace html.
--
Seek truth from facts.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Boyd Stephen Smith Jr.
>On Sun, 31 Oct 2010 15:40:49 -0500, Boyd Stephen Smith Jr. wrote:
>> When using the web, you are using a pull / request model. In this case,
>> server dictates the terms. The UA must accept and process whatever the
>> server deigns to deliver as part of the request, and the user must seek
>> out a UA with the right features in order to satisfy their needs.
>>
>> In this model, "evolution" moves quickly, since new features are adopted
>> by a users in order to handle response from more servers.
>
>You will still facing "client side" programming issues. Not all browsers
>renders the same the different versions of javascript/DOM/CSS3 (Ajax) so
>you still heavily depend on the client and its capabilities.
Yes, but the user wants something from your service, so you dictate the terms
of communication. If the user has multiple choices for satisfying that want,
you can compete on (lack of) features, but it is ultimately the servers that
make the decision on what the user has to put up with.
>> When using email, you are using a push / send model. In this case, the
>> recipient dictates the terms. The MUA must only create and send data
>> that the recipient is willing to accept or the effort is wasted, and the
>> user must seek out a MUA that can reach the most recipients. (In a
>> support context, more recipients = more replies = more useful replies =
>> better support. In a marketing / community context, more recipients =
>> more eyes = more inquiries = more sales / members.)
>>
>> In this model, "evolution" moves slowly, since new features are avoided
>> by users in order to reach the most recipients.
>>
>> I have descent bandwidth, to doing a reasonable multipart/alternative
>> message will reach me. You send in text/html and your message just goes
>> in the round file. Others don't have the bandwidth to waste / spend;
>> multipart/alternative messages reach their round file. Still others
>> will accept all 3 forms. If you want the most people to see your
>> message, you'll use text/plain.
>
>Again, that reasoning has nothing to do with html messages nor
>technicalities, you are talking about what are your own preferences.
I am talking about which side dictates the terms of the exchange. When
sending a email you (usual) goal is to get as many readers as possible. Using
features their UAs don't understand or that the recipients themselves find
distasteful reduces you readership.
>> You still haven't addressed "Paradox of
>> choice" (a practical, documented usability problem) or "Fewer options is
>> easier to understand".
>
>If you are concerned about that "usability problem" then ask the users
>what would they prefer and what would be more confortable for them. Do
>not make the error of just think for them.
Studies and experience have shown time and time again that users *don't know*
what they want. Henry Ford once said: "If I asked my customers what they
wanted, they would have said 'A faster horse.'" It is an unfortunate truth,
but usability problems are not solved by soliciting user input.
>You are not losing audience by using html e-mails.
Yes you are. There is a non-zero number of people on *this* mailing list that
simply discard mails containing an HTML part.
Klistvud
>
> Studies and experience have shown time and time again that users
> *don't know*
> what they want. Henry Ford once said: "If I asked my customers what
> they
> wanted, they would have said 'A faster horse.'" It is an unfortunate
> truth,
> but usability problems are not solved by soliciting user input.
>
My point exactly. In addition, I think that, as a rule, users who
*could* give you an informed feedback, are a tiny minority, which gets
overwhelmed by the feedbacks of the "uninformed masses". So, in theory,
you *could* get tangible help out of user input, but would have to know
how to weed out noise from insightful input. As it is, the less
insightful, the less constructive, the less informed feedback wins --
by virtue of sheer numbers. In my view, that's not a good developing
model, in fact it's *counter*productive. Fortunately, no developers in
their right mind listen "blindly" to anything the user base says;
developers don't just "develop", they also weed out what to implement
from what to just mark as WON'TFIX. And that's a Good Thing, when done
well.
--
Cheerio,
Klistvud
http://bufferoverflow.tiddlyspot.com
Certifiable Loonix User #481801 Please reply to the list, not to
me.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
gettin...@googlemail.com
I want to install many packets at once with apt-get.
So I wrote a file, like
file-list:
htop
vim
apache2
apt-get shall use this file as it's input eg apt-get install < file-list
(notworking)
does anyone knows a solution?
heiko kokemoor
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
kuLa
Hash: SHA1
On 01/11/10 10:13, gettin...@googlemail.com wrote:
> Hi list,
>
> I want to install many packets at once with apt-get.
> So I wrote a file, like
>
> file-list:
>
> htop
> vim
> apache2
>
> apt-get shall use this file as it's input eg apt-get install < file-list
> (notworking)
>
> does anyone knows a solution?
>
> heiko kokemoor
>
>
I think this should help
cat file-list|xargs apt-get -y install
but only if you've got correct packages names in the file if not you
have to fix it.
- --
|_|0|_| |
|_|_|0| "Heghlu'Meh QaQ jajVam" |
|0|0|0| -------- kuLa --------- |
gpg --keyserver pgp.mit.edu --recv-keys 0xC100B4CA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJMzpQIAAoJEOqHloDBALTKY5EH/0gwkNuC0HVr8SXBWJXK5xAc
RAMDddQFhR6l1ZEJdxRmQ78+VHAD7d90D29qoWgGckgZLPmczSRe/KAayBWQ5Xu7
h4csan+XX+xQhEjkdEXLZ4Tv5hwu9rV4eBq7+HZwtAN/TeNtN+k0XYv7I1rr1Bny
oe1eHDrIQyzn1q1TMtt3Hff7/MgPG7pPE3fYnH7oT+ccVZoPd6kj7C1Gizr9TiFg
fOBVrjlsAlC/wNgXhsDOn/sr254Zil6z+G8eCbE8w+ePKAGtAjAE5AAIq9oe0Nyj
SuYRJHPnHNjCCN53c4h4GNNiNzIHqxg7dBLQh3yl5dmvlPZgh2l5avU6A6QUZAg=
=lhdM
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Mark Allums
> Hi list,
>
> I want to install many packets at once with apt-get.
> So I wrote a file, like
>
> file-list:
>
> htop
> vim
> apache2
>
> apt-get shall use this file as it's input eg apt-get install < file-list
> (notworking)
>
> does anyone knows a solution?
>
> heiko kokemoor
>
>
Consider using aptitude, if a (curses) GUI would be appropriate.
apt-get can take multiple package names on the command line:
#apt-get install pkg1 pkg2 pkg3 pkg4 ...
although dependencies and conflicts might get a little tricky. Or you
can write a small bash script.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
kuLa
Hash: SHA1
> I think this should help
> cat file-list|xargs apt-get -y install
>
>> wow this will got very solw, keep search the whole database each luanch.
>> i think
>
>> apt-get install `sed "s/\n/ /" /your/listfile`
>
>> is much better.
- From my experience it's doing lookup only once cause you're passing
package names only once at start.
- --
|_|0|_| |
|_|_|0| "Heghlu'Meh QaQ jajVam" |
|0|0|0| -------- kuLa --------- |
gpg --keyserver pgp.mit.edu --recv-keys 0xC100B4CA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJMzp5aAAoJEOqHloDBALTK2KUIAI65KHGKd96CkgBSIjuhFWxQ
nl/KHp+pMRDbuOA8MaUmICburLP3M9TengTrsO3Jw0XFUZY3QHxHaD5zSrSyqh6U
y9a61nIe62bFAkyWyRxheYH2o2mmU933fJ6Cy4yq2TPDoIZlr8dPDKbaHrxj9Riy
9kVdHEVZsYS7C2V1CAFQ9yYQiXlDYdKAKJDCLSSfgPT65bLwcFdbAnjhOoOHTPVt
8o55YO47AxZ9F0PmF7YYOmYVAHthTvY52mFCgKJO7jyZtk4B0CE/6oTWPxtoPTqE
7u+eF6RYxzWuxcu0bDoIfry/GLcxBudZYbBD8UE77ODDhshkClaDoV1KoIKXQUE=
=Sv1n
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Steve Kemp
> I want to install many packets at once with apt-get.
> So I wrote a file, like
>
> file-list:
>
> htop
> vim
> apache2
apt-get install $(cat file-list)
Steve
--
Let me steal your soul?
http://stolen-souls.com
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20101101102...@steve.org.uk
Camaleón
> In <pan.2010.10...@gmail.com>, Camaleón wrote:
(...)
>>If you are concerned about that "usability problem" then ask the users
>>what would they prefer and what would be more confortable for them. Do
>>not make the error of just think for them.
>
> Studies and experience have shown time and time again that users *don't
> know* what they want. Henry Ford once said: "If I asked my customers
> what they wanted, they would have said 'A faster horse.'" It is an
> unfortunate truth, but usability problems are not solved by soliciting
> user input.
Sorry but I have to disagree.
First, because I know what I want :-)
And second, because automotive market is not the best sample to compare
with computer industry... if computers had followed the same path, we
were still would be using "punch cards".
>>You are not losing audience by using html e-mails.
>
> Yes you are. There is a non-zero number of people on *this* mailing
> list that simply discard mails containing an HTML part.
Again, that is a _personal_ decision, not a technical one. I have nothing
against personal views... just they're personal.
Any e-mail client out there can handle html formatting, so if someone
rejects e-mails formatted in that way is not because their MUA cannot
manage them.
And I'm not talking here about personal decisions, every one has their
own needs and feelings on this matter. This is about the lack of options
we currently have for Kmail when it comes to html e-mails.
You don't want html in your e-mails? Perfect, don't use it. But if you do
not provide such option for people who need it, you'll lose your users.
It's that simple.
Greetings,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Boyd Stephen Smith Jr.
Changing the subject line in not sufficient to create a new thread. You must
use the "New Message" function of your UA not the "Reply" function. When you
use the reply function, your UA inserts headers like this:
References: <4CBDE2D6...@gmail.com>
<201010301541.0...@gmail.com> <pan.2010.10...@gmail.com>
<201010301134...@pcartwright.com> <4CCDDB1B...@cox.net>
In-Reply-To: <4CCDDB1B...@cox.net>
These headers control threaded for modern UAs.
In <4CCE92E1...@googlemail.com>, gettin...@googlemail.com wrote:
>I want to install many packets at once with apt-get.
>So I wrote a file, like
>
>file-list:
>
>htop
>vim
>apache2
>
>apt-get shall use this file as it's input eg apt-get install < file-list
>(notworking)
You clearly misunderstand how the '<' shell redirection operator works. I
suggest you avoid using it so you don't break something, at least until you
know the different between command-line arguments, standard input, and
standard output.
>does anyone knows a solution?
Real, good solutions have already been posted.
Boyd Stephen Smith Jr.
>On Mon, 01 Nov 2010 02:42:37 -0500, Boyd Stephen Smith Jr. wrote:
>> In <pan.2010.10...@gmail.com>, Camaleón wrote:
>(...)
>
>>>If you are concerned about that "usability problem" then ask the users
>>>what would they prefer and what would be more confortable for them. Do
>>>not make the error of just think for them.
>>>
>> Studies and experience have shown time and time again that users *don't
>> know* what they want. Henry Ford once said: "If I asked my customers
>> what they wanted, they would have said 'A faster horse.'" It is an
>> unfortunate truth, but usability problems are not solved by soliciting
>> user input.
>
>Sorry but I have to disagree.
Well, then you are wrong. There a more than a decade of studies showing you
are wrong. I'll let you find them yourself.
Users didn't want UNIX or C when it was invented.
Users didn't want the GUI when it was invented.
>>>You are not losing audience by using html e-mails.
>>>
>> Yes you are. There is a non-zero number of people on *this* mailing
>> list that simply discard mails containing an HTML part.
>
>Again, that is a _personal_ decision, not a technical one. I have nothing
>against personal views... just they're personal.
My point still stands. If you use HTML mail, you will lose readers. This is
a bad thing.
>Any e-mail client out there can handle html formatting, so if someone
>rejects e-mails formatted in that way is not because their MUA cannot
>manage them.
There are a number of client out there that, absent some custom configuration,
render the "raw" HTML code. This is virtually unreadable for most people,
especially considering the poor quality HTML produced by most
Camaleón
> In <pan.2010.11...@gmail.com>, Camaleón wrote:
>>> Studies and experience have shown time and time again that users
>>> *don't know* what they want. Henry Ford once said: "If I asked my
>>> customers what they wanted, they would have said 'A faster horse.'"
>>> It is an unfortunate truth, but usability problems are not solved by
>>> soliciting user input.
>>
>>Sorry but I have to disagree.
>
> Well, then you are wrong. There a more than a decade of studies showing
> you are wrong. I'll let you find them yourself.
Sigh. Then I'll have to live with that along with my need of having to
manage html e-mails in a world that cannot understand me :-)
> Users didn't want UNIX or C when it was invented. Users didn't want the
> GUI when it was invented.
Are you basing your argument in stating that all users in the world are
always wrong? Ouch, I wouldn't like to be in the marketing area nor in
usability studies field, what a waste of time...
>>>>You are not losing audience by using html e-mails.
>>>>
>>> Yes you are. There is a non-zero number of people on *this* mailing
>>> list that simply discard mails containing an HTML part.
>>
>>Again, that is a _personal_ decision, not a technical one. I have
>>nothing against personal views... just they're personal.
>
> My point still stands. If you use HTML mail, you will lose readers.
> This is a bad thing.
And so is mine. Kmail will lose users that need that feature which now is
provided in a very limited state.
>>Any e-mail client out there can handle html formatting, so if someone
>>rejects e-mails formatted in that way is not because their MUA cannot
>>manage them.
>
> There are a number of client out there that, absent some custom
> configuration, render the "raw" HTML code. This is virtually unreadable
> for most people, especially considering the poor quality HTML produced
> by most
Hey, it's html and one of its benefits is precisely that is "plain text"
and so "readable" with just the most primitive text editor. You can even
save the raw e-mail message and then render it within the web browser of
your choice (yep, lynx included).
Boyd Stephen Smith Jr.
> On Mon, 01 Nov 2010 14:14:48 -0500, Boyd Stephen Smith Jr. wrote:
> > Users didn't want UNIX or C when it was invented. Users didn't want the
> > GUI when it was invented.
>
> Are you basing your argument in stating that all users in the world are
> always wrong?
No.
Camaleón
> On Monday 01 November 2010 14:34:10 Camaleón wrote:
>> On Mon, 01 Nov 2010 14:14:48 -0500, Boyd Stephen Smith Jr. wrote:
>> > Users didn't want UNIX or C when it was invented. Users didn't want
>> > the GUI when it was invented.
>>
>> Are you basing your argument in stating that all users in the world are
>> always wrong?
>
> No.
"No" is neither a good argument :-)
Brian Ryans
> > cat file-list|xargs apt-get -y install
> >
> >> is much better.
>
> package names only once at start.
ACK.
> cat file-list|xargs apt-get -y install
apt-get -y install foo
(read db; grab foo; install foo; write new db)
apt-get -y install bar
(read db; grab bar; install bar; write new db)
apt-get -y install baz
(read db; grab baz; install baz; write new db)
> apt-get install `sed "s/\n/ /" /your/listfile
apt-get install foo bar baz
(read db; grab foo, bar, baz; install foo, bar, baz; write new db)
--
_ Brian Ryans 8B2A 54C4 E275 8CFD 8A7D 5D0B 0AD0 B014 C112 13D0 .
( ) ICQ 43190205 | Mail/Jabber/Yahoo/MSN: Brian...@gmail.com ..:
X ASCII Ribbon Campaign Against HTML mail and v-cards: asciiribbon.org
/ \ Modern man has an approximately 140-character attention span. -- blr
Felipe Sateler
> Quoting kuLa on 2010-11-01 06:02:50:
>>> cat file-list|xargs apt-get -y install
>>>> apt-get install `sed "s/\n/ /" /your/listfile`
>>>
>>>> is much better.
>>
>> From my experience it's doing lookup only once cause you're passing
>> package names only once at start.
>
> ACK.
>
>> cat file-list|xargs apt-get -y install
> apt-get -y install foo
> (read db; grab foo; install foo; write new db)
> apt-get -y install bar
> (read db; grab bar; install bar; write new db)
> apt-get -y install baz
> (read db; grab baz; install baz; write new db)
This happens only if you pass the -l flag to xargs. Otherwise it passes
all at the same time.
--
Saludos,
Felipe Sateler
Boyd Stephen Smith Jr.
>On 11/03/2010 03:01 AM, Brian Ryans wrote:
>> Quoting kuLa on 2010-11-01 06:02:50:
>>>>> apt-get install `sed "s/\n/ /" /your/listfile`
>>>>> is much better.
>>>
>>
>> apt-get -y install foo
>> (read db; grab foo; install foo; write new db)
>> apt-get -y install bar
>> (read db; grab bar; install bar; write new db)
>> apt-get -y install baz
>> (read db; grab baz; install baz; write new db)
>
>This happens only if you pass the -l flag to xargs. Otherwise it passes
>all at the same time.
..up to the maximum command-line length allowed on the system xargs was
./configure'd on. When installing 16000 packages, you'll find find xargs
invokes apt-get multiple times. If you use the sed, your shell will just give
you an error.
I recommend xargs. If you are going to use that sed expression (which is not
quite the same as xargs), I recommend using $() instead of `` for subshell
expansion. (It nests better with itself and/or "".)
Celejar
Camaleón <noel...@gmail.com> wrote:
...
> with mbox and searching strings in Icedove is bit slow if mbox files are
> big (measured in GiB :-P).
If you're still doing on-demand searching, have you considered using a
mail indexer, such as Sylph-Searcher, or a generic file indexer, such as
recoll?
Obviously, dedicated mail indexers have the advantage of
understanding the structure of emails, so you can search for mail
with specific field contents.
Celejar
--
foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20101104163531....@gmail.com
Camaleón
> On Sat, 30 Oct 2010 15:48:30 +0000 (UTC) Camaleón wrote:
>
> ...
>
>> with mbox and searching strings in Icedove is bit slow if mbox files
>> are big (measured in GiB :-P).
>
> If you're still doing on-demand searching, have you considered using a
> mail indexer, such as Sylph-Searcher, or a generic file indexer, such as
> recoll?
Yep, I'm using Tracker. But Tracker for Lenny still lacks Icedove
integration so I have to use Icedove embedded search, which is fine but
so basic. And I need to keep Icedove because of its hmtl support. Another
option is Evolution but always found it too much resource consuming and
bloated.
> Obviously, dedicated mail indexers have the advantage of understanding
> the structure of emails, so you can search for mail with specific field
> contents.
I would like to see Icedove supporting both, mbox and maildir :-)
Greetings,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Celejar
Camaleón <noel...@gmail.com> wrote:
> On Thu, 04 Nov 2010 16:35:31 -0400, Celejar wrote:
>
> > On Sat, 30 Oct 2010 15:48:30 +0000 (UTC) Camaleón wrote:
> >
> > ...
> >
> >> with mbox and searching strings in Icedove is bit slow if mbox files
> >> are big (measured in GiB :-P).
> >
> > If you're still doing on-demand searching, have you considered using a
> > mail indexer, such as Sylph-Searcher, or a generic file indexer, such as
> > recoll?
>
> Yep, I'm using Tracker. But Tracker for Lenny still lacks Icedove
> integration so I have to use Icedove embedded search, which is fine but
> so basic. And I need to keep Icedove because of its hmtl support. Another
> option is Evolution but always found it too much resource consuming and
> bloated.
I use recoll, which has no MUA integration. I'm thinking of configuring
Sylph-Searcher, which uses a postgresql backend.
I don't do HTML mail ;)
> > Obviously, dedicated mail indexers have the advantage of understanding
> > the structure of emails, so you can search for mail with specific field
> > contents.
>
> I would like to see Icedove supporting both, mbox and maildir :-)
Sylph uses MH, similar to maildir, but can import and export mbox.
Celejar
--
foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20101105163317....@gmail.com