Main Area and Open Discussion > General Software Discussion
TheBat email client v4 (early alpha) - some observations
CodeTRUCKER:
how could program detect wrapped link in plaintext? surprise me :-)
-marek_mikus (January 24, 2008, 03:56 PM)
--- End quote ---
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?
allen:
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:
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!)
-allen (January 24, 2008, 10:57 PM)
--- End quote ---
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:
how could program detect wrapped link in plaintext? surprise me :-)
-marek_mikus (January 24, 2008, 03:56 PM)
--- End quote ---
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.
-CodeTRUCKER (January 24, 2008, 10:56 PM)
--- End quote ---
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:
old Microed used until 3.99 is not paragraph based, as I know, new one should be, must check this, it is implemented early.
-marek_mikus (January 24, 2008, 03:56 PM)
--- End quote ---
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?
-superboyac (January 24, 2008, 07:55 PM)
--- End quote ---
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 :-)
-marek_mikus (January 24, 2008, 03:56 PM)
--- End quote ---
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.
-superboyac (January 24, 2008, 07:55 PM)
--- End quote ---
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
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version