topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Friday March 29, 2024, 5:34 am
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Last post Author Topic: TheBat email client v4 (early alpha) - some observations  (Read 46447 times)

CodeTRUCKER

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 1,085
    • View Profile
    • Donate to Member
Re: TheBat email client v4 (early alpha) - some observations
« Reply #25 on: January 24, 2008, 04:43 PM »
regarding nohtml inline, could you be a little more specific? 

Sorry about that. :-[  Corrected original wording in my post; however, my questions have been addressed by Marek, except for the one about SmartBat.  Well, maybe he already answered it. ;)

for 4.0, no changes are prepared for SmartBat/Scheduller except GUI changes, as I heard, scheduller improvements are planned for 4th generation, but do not when

Thanks for the feedback!  I can wait for the new implementation, but please don't fall into the trap of trying to be the "SUPER PROGRAM" that tries to be everything to everyone.  Some developers have fallen into this trap and have made great apps not-so-great by doing so.  TheBAT! is a great e-mail client (and getting better) and I hope it stays that way, personally.  I just think the SmartBAT is sparse and a little dated, IMO, but I'll be waiting to see what Ritlabs does with it. :)

J-Mac

  • Supporting Member
  • Joined in 2007
  • **
  • Posts: 2,918
    • View Profile
    • Donate to Member
Re: TheBat email client v4 (early alpha) - some observations
« Reply #26 on: January 24, 2008, 04:43 PM »
...1. Problems with HTML in Pocomail/Barca on forwards or replies are not intentional, ie. it's not to "increase security", it's due to a limited viewer/editor control used. Btw. AFAIK it is getting replaced.

Not according to Slaven, their programmer from the beginning.  He & I have discussed this countless times - he says it is for security alone.  (And I disagree with him, of course!)

2. I have seen antivirus programs fail recognizing security threats in html. No protection is 100%.

I cannot say that's not true for you, but no one has ever been able to show me a real live example of it in the past five years.

Not sure, my guess is that it's way more complex to implement, and way less people use it than the POP protocol.

I don't know how true that is today, since Gmail now offers IMAP.  Still, is that a valid reason? Majority rules?

Whether it's a valid or non-valid concern, depends on point of view. It certainly increases the security.

I don't really believe that. No one has offered an explanation.

Of course you can say that people shall patch their OS, always use latest up-to-date firewalls and antiviruses and antispywares and whatever, and you know what I do it, you do it, and few other people too, particularly those on this board and similar geek types. But try to see a majority user of those apps.

So IMHO it increases security (how much is another question, maybe it's just a very small increase in overall security, I don't know), but cutting down on functionality. Whether that's valid, depends on the user. You and I might hate it as we can secure our computers without having to sacrifice on functionality, but there might be others who sleep better thanks to it. (I have found several MAPI viruses discovered in 2004 and 2005 after some short search, though frankly I'm not an expert on that so I have no clue whether those threats would apply on what we are discussing.)

I don't really care if others are lax in patching their OS. Are you saying that it is the email client developers' job to protect the users who do not practice any security at the expense of other users?  Oh, please! Those fools aren't using Pocomail or The Bat! anyway, right?

We are also speaking about future security. If IMAP has long history of past threats, would you now jump on it as a developer knowing that it was ok for last year or two, but not for the years before?

Anyway, I'd like to stress that I'm not supporting the "no IMAP" stance. I'm the "give me full powers, I decide" advocate.

I think you are mixing up IMAP and MAPI, true?

Jim

tamasd

  • Supporting Member
  • Joined in 2008
  • **
  • default avatar
  • Posts: 64
    • View Profile
    • Donate to Member
Re: TheBat email client v4 (early alpha) - some observations
« Reply #27 on: January 24, 2008, 07:01 PM »
Still, is that a valid reason? Majority rules?
It's a business decision.
If you will spend a year on IMAP support, how much will it increase your sales?
Or have your client support POP, with some basic IMAP, risking some sales lost.

Note I'm not supporting their decision...you asked why those programs don't have IMAP, I offered my best guesses.

I don't really care if others are lax in patching their OS. Are you saying that it is the email client developers' job to protect the users who do not practice any security at the expense of other users?  Oh, please! Those fools aren't using Pocomail or The Bat! anyway, right?
Not sure about The Bat! as it has different average user profile than Pocomail.
Generally email developers job is to decide whom to target and how to differentiate their application. Those whom Pocomail targets ("I heard somewhere that Outlook is evil" or "Outlook doesn't work for me") are more of a mainstream users that The Bat! target group. You say fools, I say majority of users.

I'm not defending them actually. Any email application shall  IMHO target full email functionality. That they are a bit slow at getting there, might simply be because there is no or little money in it.

Email applications are tough business, many good clients ceased to be developed in last few years, so good decisions in terms of where to spend the development time are crucial. And it's more on the business decision (can we afford to spend the coding time on this) than the technological decision (oh we have poor support for an important part of emailing functionality like IMAP is)

I think you are mixing up IMAP and MAPI, true?
I'm sorry for the typo, of course "MAPI has a history of security threats" and it shall read that I'm not supporting their "no MAPI" stance. (Which has actually changed recently...).
They are not/were not against IMAP as far as I can tell, again I'm sorry for that typo.
Just taking too long to implement it (IMAP) fully as far as I can tell.

tamasd

  • Supporting Member
  • Joined in 2008
  • **
  • default avatar
  • Posts: 64
    • View Profile
    • Donate to Member
Re: TheBat email client v4 (early alpha) - some observations
« Reply #28 on: January 24, 2008, 07:04 PM »
My needs are not so critical, but it is improtant for me to be able to locate specific strings in past e-mails (up to 25,000+ so far) quickly.
I'm using Archivarius. It can search both Pocomail and The Bat!, and many other way weirder formats (Zoot !). It takes a second... and that's an exageration.

superboyac

  • Charter Member
  • Joined in 2005
  • ***
  • Posts: 6,347
    • View Profile
    • Donate to Member
Re: TheBat email client v4 (early alpha) - some observations
« Reply #29 on: January 24, 2008, 07:55 PM »
old Microed used until 3.99 is not paragraph based, as I know, new one should be, must check this, it is implemented early.
OK, I'll look forward to it.  Right now, I'm using the regular windows editor.  This is another topic, and I already started a thread about it a while back, but what's the big deal/advantage of MicroEd?

how could program detect wrapped link in plaintext? surprise me :-)
Well, I'm not a programmer, so I'm not sure.  But I'll give it a shot.  If the link was detected as being one line, but wrapped, since the link doesn't have spaces in it, it should easily be able to tell that everything from "http" to the first space after that is part of a link.  Now, maybe it's not possible for it to detect wrapped lines, so it would consider it two separate lines.  But I don't see why it can't detect the difference between two lines and a wrapped line.  Is information like that inherently lost when you send email?  I know that in text editors, it's very easy to tell and preserve multiple lines vs wrapped lines.
But, let's assume the program will never be able to detect a wrapped line.  Then there should be a workaround.  If I highlight the whole multi-line link, there should be a context-menu item like "open selected text as hyperlink with merging".  That way I can force the program to merge the multi-line content into one line even though it can't tell automatically.

Right now, it's frustrating because when that happens you have to copy the lines, paste them into a text editor, manually delete the "return" so it becomes one line, then repaste it into the web browser.  This has been an issue for years with email, let's solve it already.

CodeTRUCKER

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 1,085
    • View Profile
    • Donate to Member
Re: TheBat email client v4 (early alpha) - some observations
« Reply #30 on: January 24, 2008, 10:56 PM »
how could program detect wrapped link in plaintext? surprise me :-)

Why not use the existing spellchecker?  Here's how, I'll use the link to this thread as an example as it is fairly representative of many URLs...

http:://www.donationcoder.com/forum/index.php?topic=11985.0#quickreply 

(FYI - I put in two colons so the SMF engine wouldn't compact the URL)

-=o=-  First, like Superboyac saiid, it is a long string without spaces...

-=o=- Next, if you split this at just about any point it is basically unintelligible jibberish as far as a spell check is concerned.  Yes, I do see that a split between "quick" and "reply" might get past this, but this is far and away the exception and not the rule; in fact, the chances of the split actually occurring at a chance intelligible break like that would be astornomical.  Also given it was jibberish to start with, it seems an "intellegent" parser would be able to identify the string as a URL (the "http;//" at the beginnig of the string would be a big hint) and could be "marked" in the editor to treat it as "Do not break" when lines are wrapped.

-=o=-  Now we have two split lines.  For the sake of argument we'll say both are unintelligible strings that could/will be flagged by the spellcheck.
Obviously, any string that starts with "http://...", "https://..." or "ftp://..." is easily identified as an URL or FTP address.  What about the backend?

-=o=-  The back end will more than likely be unintelligible jibberish, as I said, but here is the key...  the positively identified front end will always be at the end of the line as the last "word" on the line and the back end will always be the very first "word" of the next line.  An exception could be a URL/FTP address that is verrrrry lonnnnng.  In that case the first part is the positively identified address which is the last "word" on a line.  The next line would be complete jibberish with no spaces and the next and the next, etc. The last part of the string would still be the first "word" of the next line.  I realize that even the "http//" part could be split anywhere in the string, but think about it... no where could it be split and be the beginning or end of any English word that I know of.   

-=o=-  So with what we have established above, it would seem a simple matter to parse using the exisiting spellcheck engine (if it can be used during the wrapping process) to identify and keep together a URL/FTP address.  There would needs be more code to make this all happen, but that shouldn't be any kind of hurdle.  Probably, a few lines of code.  At least, the logic picture is pretty straightforward.  Franly, I think "marking" the string as a special entity would be the simplest approach, but the parsing method should work as well and it wouldn't take too much more effort to even repair broken URL strings from an original e-mail.

Is this doable in TheBAT! 

I'm with Superboyac... this has plagued e-mail clients (and other editors) since the beginnig.  Let's get it out of the way!  :Thmbsup:



<edit> customary spell corrections and clarifications </edit>  Mouser, can we have a button installed to frame our edit remarks?
« Last Edit: January 24, 2008, 11:05 PM by CodeTRUCKER »

allen

  • Charter Member
  • Joined in 2006
  • ***
  • Posts: 1,206
    • View Profile
    • Donate to Member
Re: TheBat email client v4 (early alpha) - some observations
« Reply #31 on: January 24, 2008, 10:57 PM »
I've been a paying fan of TB! for a solid decade now, so I'm not trolling by any means. . . and will upgrade to 4.1, but... honestly, has anyone ever heard of major version free, while the next decimal update to that major version is a paid upgrade?

I can remember when TB 2.0 was more mythological than anything--having been mentioned for years; RIT is known for major version changes that are not so much update based as version number (call it time, if you'd like) based, version 2.0 not being that different from late 1.x, same for 2 to 3, etc. -- so it's not a suprise that 4.0 is just a subtle update to 3.9x. But the pay for 4.1 as opposed to 4.0 just really blows my mind.  I'd wager it's a problem of arbitrary version numbering--and as tb is at 3.99, you have nowhere to go but 4.0.  But as a fan of sensible numbers, I'd rather pay for a trivial upgrade to 4.0 than pay to go from 4.0 to 4.1, understanding when paying for 4.0 that 4.1 will be a bigger update than 3.9 to 4.0 was.

It doesn't bother me in a way that would make me less likely to use the software, but this scores high, for me, on the WTF?! scale -- admittedly a scale RIT has been a frequent presence on.

(Unrelated, but nice to see you here Marek; having been subscribed to TBUDL for ... well, ages, your name is by no means unfamiliar!)

marek_mikus

  • Participant
  • Joined in 2008
  • *
  • default avatar
  • Posts: 14
    • View Profile
    • Donate to Member
Re: TheBat email client v4 (early alpha) - some observations
« Reply #32 on: January 25, 2008, 02:16 AM »
I've been a paying fan of TB! for a solid decade now, so I'm not trolling by any means. . . and will upgrade to 4.1, but... honestly, has anyone ever heard of major version free, while the next decimal update to that major version is a paid upgrade?

I can remember when TB 2.0 was more mythological than anything--having been mentioned for years; RIT is known for major version changes that are not so much update based as version number (call it time, if you'd like) based, version 2.0 not being that different from late 1.x, same for 2 to 3, etc. -- so it's not a suprise that 4.0 is just a subtle update to 3.9x. But the pay for 4.1 as opposed to 4.0 just really blows my mind.  I'd wager it's a problem of arbitrary version numbering--and as tb is at 3.99, you have nowhere to go but 4.0.  But as a fan of sensible numbers, I'd rather pay for a trivial upgrade to 4.0 than pay to go from 4.0 to 4.1, understanding when paying for 4.0 that 4.1 will be a bigger update than 3.9 to 4.0 was.

It doesn't bother me in a way that would make me less likely to use the software, but this scores high, for me, on the WTF?! scale -- admittedly a scale RIT has been a frequent presence on.

(Unrelated, but nice to see you here Marek; having been subscribed to TBUDL for ... well, ages, your name is by no means unfamiliar!)

as I think, they thought, users will not pay for upgrade, if there will be upgrade from 3.99 to 4.0.0, so planned updated GUI and some new features, this is why upgrade was announced as free for v3 user until major rework in 4.1 will be introduced.

But this was changed, because 4.0 was announce for years as big milestone, so there are smaller GUI changes (rewritten tabs, rewritten statusbars, updated message header pane etc.) AND there are major changes implemented, which were planned for 4.1 like new unicode Microed with new spellcheck system (long time developed), downloading remote images, new image viewer, new Address History feature, new unicode viewer with new search pane etc.

So after more than 3 years, users of v3 will get free upgrade for a major milestone 4.0.0-4.0.x. And for 4.1 and others 4.x, additional major changes are prepared too :-)

marek_mikus

  • Participant
  • Joined in 2008
  • *
  • default avatar
  • Posts: 14
    • View Profile
    • Donate to Member
Re: TheBat email client v4 (early alpha) - some observations
« Reply #33 on: January 25, 2008, 03:17 AM »
how could program detect wrapped link in plaintext? surprise me :-)

Why not use the existing spellchecker?  Here's how, I'll use the link to this thread as an example as it is fairly representative of many URLs...

http:://www.donationcoder.com/forum/index.php?topic=11985.0#quickreply 

(FYI - I put in two colons so the SMF engine wouldn't compact the URL)

-=o=-  First, like Superboyac saiid, it is a long string without spaces...

-=o=- Next, if you split this at just about any point it is basically unintelligible jibberish as far as a spell check is concerned.  Yes, I do see that a split between "quick" and "reply" might get past this, but this is far and away the exception and not the rule; in fact, the chances of the split actually occurring at a chance intelligible break like that would be astornomical.  Also given it was jibberish to start with, it seems an "intellegent" parser would be able to identify the string as a URL (the "http;//" at the beginnig of the string would be a big hint) and could be "marked" in the editor to treat it as "Do not break" when lines are wrapped.

but as I understand You, You are talking about lines wrapped by rescipients viewer, but problem is in URLs wrapped by sender's MUA or sender's MTA, so rescipients plaintext viewer have no chance to know, link is wrapped to more lines

marek_mikus

  • Participant
  • Joined in 2008
  • *
  • default avatar
  • Posts: 14
    • View Profile
    • Donate to Member
Re: TheBat email client v4 (early alpha) - some observations
« Reply #34 on: January 25, 2008, 06:06 AM »
old Microed used until 3.99 is not paragraph based, as I know, new one should be, must check this, it is implemented early.
OK, I'll look forward to it.  Right now, I'm using the regular windows editor.  This is another topic, and I already started a thread about it a while back, but what's the big deal/advantage of MicroEd?

AFAIK Windows editor is based on same library like Notepad, so it has limited feature set. New Microed was developed from scratch but with preservation of all useful features like column block, free caret position, formatting text etc. It is planned to remove Windows editor, because new Microed is based on Unicode and supports proportional fonts, there will be no need to have both.

how could program detect wrapped link in plaintext? surprise me :-)
Well, I'm not a programmer, so I'm not sure.  But I'll give it a shot.  If the link was detected as being one line, but wrapped, since the link doesn't have spaces in it, it should easily be able to tell that everything from "http" to the first space after that is part of a link.  Now, maybe it's not possible for it to detect wrapped lines, so it would consider it two separate lines.  But I don't see why it can't detect the difference between two lines and a wrapped line.  Is information like that inherently lost when you send email?  I know that in text editors, it's very easy to tell and preserve multiple lines vs wrapped lines.
But, let's assume the program will never be able to detect a wrapped line.  Then there should be a workaround.  If I highlight the whole multi-line link, there should be a context-menu item like "open selected text as hyperlink with merging".  That way I can force the program to merge the multi-line content into one line even though it can't tell automatically.

Right now, it's frustrating because when that happens you have to copy the lines, paste them into a text editor, manually delete the "return" so it becomes one line, then repaste it into the web browser.  This has been an issue for years with email, let's solve it already.

as I wrote in previous message, there is a difference between wrapping long URLs in rescipients viewer and URLs wrapped by sender's MUA or sender's MTA

f0dder

  • Charter Honorary Member
  • Joined in 2005
  • ***
  • Posts: 9,153
  • [Well, THAT escalated quickly!]
    • View Profile
    • f0dder's place
    • Read more about this member.
    • Donate to Member
Re: TheBat email client v4 (early alpha) - some observations
« Reply #35 on: January 25, 2008, 06:13 AM »
Humm,

I'll upgrade to 4.0 when it's final & stable, but I dunno if I will pay for 4.1. Instead, I'll probably migrate my entire existing email base (including the couple of years from PMMail2000 that I have in .rar files) to some mail archive/indexing system, and change client to Thunderbird with IMAP. IMAP is friggin' great.

I've found that I don't really use m/any of the more advanced TheBat features, the menus are too crowded, and I sometimes find it a bit difficult to find whatever setting I'm looking for. I also don't like how difficult it is to get mails exported to a standard format (you have to go folder-by-folder, Ctrl+A, export to mbox... no automated way of doing it).

On the other hand we have Thunderbird, with a very nice & clean interface, probably all the features I need, with an extension system that seems pretty well-thought?, and using mbox files by standard. No, mbox files aren't the best solution once your number of mails grow, which is why I'll be moving off messages to an archive/indexing system on a monthly or quarterly or whatever basis. But mbox does have the advantage of being a very++ standard format.
- carpe noctem

marek_mikus

  • Participant
  • Joined in 2008
  • *
  • default avatar
  • Posts: 14
    • View Profile
    • Donate to Member
Re: TheBat email client v4 (early alpha) - some observations
« Reply #36 on: January 25, 2008, 06:39 AM »
Humm,

I'll upgrade to 4.0 when it's final & stable, but I dunno if I will pay for 4.1. Instead, I'll probably migrate my entire existing email base (including the couple of years from PMMail2000 that I have in .rar files) to some mail archive/indexing system, and change client to Thunderbird with IMAP. IMAP is friggin' great.

I've found that I don't really use m/any of the more advanced TheBat features, the menus are too crowded, and I sometimes find it a bit difficult to find whatever setting I'm looking for. I also don't like how difficult it is to get mails exported to a standard format (you have to go folder-by-folder, Ctrl+A, export to mbox... no automated way of doing it).

On the other hand we have Thunderbird, with a very nice & clean interface, probably all the features I need, with an extension system that seems pretty well-thought?, and using mbox files by standard. No, mbox files aren't the best solution once your number of mails grow, which is why I'll be moving off messages to an archive/indexing system on a monthly or quarterly or whatever basis. But mbox does have the advantage of being a very++ standard format.

I understand You, if You do not take advantage of The Bat! features, but upgrade fee after almost 4 years is not something, I could blame a developer of such app. many apps I have requires 1year or 2years subsription and I do not use them as often as The bat!

I have tested many clients and there is no chance for me to migrate, if I would a reason to do it.

There is no client with such template system and macros set, with such security features including S/MIME & PGP & GnuPG, with virtual folders and filtering system, with system shortcuts and menu/toolbars customiser.

And big problem for me is eastern europe charsets support and localisation, this is drawback of apps like Eudora or Pocomail, which have major problems with this.

f0dder

  • Charter Honorary Member
  • Joined in 2005
  • ***
  • Posts: 9,153
  • [Well, THAT escalated quickly!]
    • View Profile
    • f0dder's place
    • Read more about this member.
    • Donate to Member
Re: TheBat email client v4 (early alpha) - some observations
« Reply #37 on: January 25, 2008, 06:44 AM »
S/MIME never worked for me in TheBat!, tells me that the messages are invalid or something...

Virtual folders are a cute enough idea, but if the search is powerful & intuitive enough, I don't need them.
- carpe noctem

marek_mikus

  • Participant
  • Joined in 2008
  • *
  • default avatar
  • Posts: 14
    • View Profile
    • Donate to Member
Re: TheBat email client v4 (early alpha) - some observations
« Reply #38 on: January 25, 2008, 06:54 AM »
S/MIME never worked for me in TheBat!, tells me that the messages are invalid or something...

this is strange, we must use it in communicatiion with government institutions and it works for years... They have OE, so in The Bat! it is needed to select MS Crypto API and The Bat! will use certificate store of Windows

Virtual folders are a cute enough idea, but if the search is powerful & intuitive enough, I don't need them.

why search if You have virtual folders created for the most used searches? :-) I have many accounts, so I have virtual folder for all Inboxes in all accounts and only todays messages are displayed. Second virtual folder is for company employees, third for all flagged messages, fourth for my projects etc.

f0dder

  • Charter Honorary Member
  • Joined in 2005
  • ***
  • Posts: 9,153
  • [Well, THAT escalated quickly!]
    • View Profile
    • f0dder's place
    • Read more about this member.
    • Donate to Member
Re: TheBat email client v4 (early alpha) - some observations
« Reply #39 on: January 25, 2008, 07:00 AM »
S/MIME never worked for me in TheBat!, tells me that the messages are invalid or something...

this is strange, we must use it in communicatiion with government institutions and it works for years... They have OE, so in The Bat! it is needed to select MS Crypto API and The Bat! will use certificate store of Windows

Yeah, we have something similar, although S/MIME is not enforced. When I cilck on the little padlock icon on an S/MIME message, I get to enter my passphrase. Then the list of file attachments for that mail include a couple of new files. If I try to click any of those, I get an error box saying "Can't decrypt this message. Failed to parse PKCS#7 data object.".

Virtual folders are a cute enough idea, but if the search is powerful & intuitive enough, I don't need them.

why search if You have virtual folders created for the most used searches? :-) I have many accounts, so I have virtual folder for all Inboxes in all accounts and only todays messages are displayed. Second virtual folder is for company employees, third for all flagged messages, fourth for my projects etc.

Yeah okay, that's pretty useful. For my needs, simply filtering incoming messages and dropping to another mailbox folder is good enough.
- carpe noctem

superboyac

  • Charter Member
  • Joined in 2005
  • ***
  • Posts: 6,347
    • View Profile
    • Donate to Member
Re: TheBat email client v4 (early alpha) - some observations
« Reply #40 on: January 25, 2008, 11:15 AM »
as I wrote in previous message, there is a difference between wrapping long URLs in rescipients viewer and URLs wrapped by sender's MUA or sender's MTA
Right, ok.  I understand that.  Since the bat has no control over that, then I guess there's nothing it can do.  However, I still think my work around is a good idea, where the user can highlight text that spans multiple lines, and a right-click context menu item can open up those multiple lines of text as a hyperlink and merge it.  Again, this is a very common issue in email and I don't think it would be that difficult to implement.

marek_mikus

  • Participant
  • Joined in 2008
  • *
  • default avatar
  • Posts: 14
    • View Profile
    • Donate to Member
Re: TheBat email client v4 (early alpha) - some observations
« Reply #41 on: January 25, 2008, 11:23 AM »
as I wrote in previous message, there is a difference between wrapping long URLs in rescipients viewer and URLs wrapped by sender's MUA or sender's MTA
Right, ok.  I understand that.  Since the bat has no control over that, then I guess there's nothing it can do.  However, I still think my work around is a good idea, where the user can highlight text that spans multiple lines, and a right-click context menu item can open up those multiple lines of text as a hyperlink and merge it.  Again, this is a very common issue in email and I don't think it would be that difficult to implement.

do not know if it can be included in 4.0 yet, but I have asked developers about it

marek_mikus

  • Participant
  • Joined in 2008
  • *
  • default avatar
  • Posts: 14
    • View Profile
    • Donate to Member
Re: TheBat email client v4 (early alpha) - some observations
« Reply #42 on: January 25, 2008, 07:07 PM »
as I wrote in previous message, there is a difference between wrapping long URLs in rescipients viewer and URLs wrapped by sender's MUA or sender's MTA
Right, ok.  I understand that.  Since the bat has no control over that, then I guess there's nothing it can do.  However, I still think my work around is a good idea, where the user can highlight text that spans multiple lines, and a right-click context menu item can open up those multiple lines of text as a hyperlink and merge it.  Again, this is a very common issue in email and I don't think it would be that difficult to implement.

superboyac, I have asked developers yesterday about this and received answer, it was done now. So, stay tuned :-)

CodeTRUCKER

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 1,085
    • View Profile
    • Donate to Member
Re: TheBat email client v4 (early alpha) - some observations
« Reply #43 on: January 25, 2008, 09:39 PM »
how could program detect wrapped link in plaintext? surprise me :-)

Why not use the existing spellchecker?  Here's how, I'll use the link to this thread as an example as it is fairly representative of many URLs...

http:://www.donationcoder.com/forum/index.php?topic=11985.0#quickreply 

(FYI - I put in two colons so the SMF engine wouldn't compact the URL)

-=o=-  First, like Superboyac saiid, it is a long string without spaces...

-=o=- Next, if you split this at just about any point it is basically unintelligible jibberish as far as a spell check is concerned.  Yes, I do see that a split between "quick" and "reply" might get past this, but this is far and away the exception and not the rule; in fact, the chances of the split actually occurring at a chance intelligible break like that would be astornomical.  Also given it was jibberish to start with, it seems an "intellegent" parser would be able to identify the string as a URL (the "http;//" at the beginnig of the string would be a big hint) and could be "marked" in the editor to treat it as "Do not break" when lines are wrapped.

but as I understand You, You are talking about lines wrapped by rescipients viewer, but problem is in URLs wrapped by sender's MUA or sender's MTA, so rescipients plaintext viewer have no chance to know, link is wrapped to more lines

Maybe I'm dull or dingy, :huh: but to me it doesn't matter if the break was on inbound e-mail or the original editor. ;)   It all comes down to parsing text and applying rules.  If it it finds "A" do "This" if "B" is found, do "That". 

I'm sorry Marek, but I still don't see this as a major hurtle and if TheBAT! had the capability, it would be the first client in history where you wouldn't have to worry about broken URLs, AFAIK There are a whole lot more people than Superboyac and CodeTRUCKER that would applaud such a paradigm shift. 

I am not saying that there would never be abroken URL, but I think mathematics professionals would be on my side of the probability argument, but I could be wrong?

Like I said, maybe I'm just dense.  If someone sees why my logic wouldn't work or couldn't be coded, I would appreciate the clue. :) Since T-Bird has an extension capability, maybe I might see if my logic holds any water by making an extension to do this?

Man, my to-do list is turning into FrakenDo!

CodeTRUCKER

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 1,085
    • View Profile
    • Donate to Member
Re: TheBat email client v4 (early alpha) - some observations
« Reply #44 on: January 25, 2008, 09:59 PM »
as I wrote in previous message, there is a difference between wrapping long URLs in rescipients viewer and URLs wrapped by sender's MUA or sender's MTA
Right, ok.  I understand that.  Since the bat has no control over that, then I guess there's nothing it can do.  However, I still think my work around is a good idea, where the user can highlight text that spans multiple lines, and a right-click context menu item can open up those multiple lines of text as a hyperlink and merge it.  Again, this is a very common issue in email and I don't think it would be that difficult to implement.

superboyac, I have asked developers yesterday about this and received answer, it was done now. So, stay tuned :-)

Marek, I am glad that this feature will be implemented to Superboyac's specs :Thmbsup:, but maybe I'm not communicating so I have a final thought I would like you to address...

I am not a great coder, but I have coded some working apps and I know this can be done, although I would have to work to make it happen.  

Given that the developers of TheBAT! have produced an exceptional product in many respects they must be excellent coders.. :graduate: 
Please help me to understand why this is so difficult?

If this can be done to let the user do it via the mouse, why can't it be automated via parsing the text, regardless of where the wrapping occured?