Thursday, January 13, 2000, 1:26:27 AM, Oleg wrote:
> Because it's an argument for a single tool: TheBat! for all tasks
> regarding mail management.
^^^^^^^^^^
Spell checking and editing don't fall under management.
> It has nothing to do with the problem we are discussing. For any developer
> of any soft there always will be wishes. Very few of them will be original.
> Most of them will be in the form "wouldn't it be nice if x software did this
> like y software".
It has everything to do with it. By keeping to the core product when a
user says, "Hey, can this have that function" the answer is simple. Yes,
exchange that portion for something that works for you.
> And that is not implementation we are discussing. The thread began with that
> you said that you don't want to have another interface switching to another
> editor.
As threads are wont to do.
SL>> I have used paragraph reformat in my perl coding. ;)
> Maybe it is not editor that you need? Maybe you need some lego to let you
> make your editor?
Why wouldn't it be the editor I need? In that case it was the editor I
needed because I needed to reflow a paragraph in the middle of code. If I had
been following your example I wouldn't have had that function. I never
expected to need that function while editing code, but it was there because I
had a general editor tuned to the specific task at hand.
> I think that scripting is not a panacea because as any interpreter it is not
> much of efficiency by the definition. I prefer pre-compiled code.
I prefer being able to develop at the application level rather than the
system level. Each has their benefits, let's not get into that here.
SL>> No, word processing isn't just ASCII text.
> How about HTML messages?
HTML isn't word processing. It is similar and as a result I advocate the
use of appropriate tools. I use both vim and macromedia's dreamweaver to do
the work. Of course, the latter, like the former, doesn't mangle my code like
every other editor out there which is why I advocate it.
>>> Don't vim use standard windows edittext object? I'm sure TB! does.
SL>> No, it doesn't. TB! does.
> Than it is vim bloating system by reimplementing the same basic editor,
> while TB! doesn't.
No. Because TB! is enhancing the basic editing model in a completely
different way than the way Eudora enhances the same model, which is completely
different than the way PMMail enhances the same model, which is completely
different than the way Netscape enhances the same model, which is completely
different than the way than XNews enhances the same mode, which is a
completely different way every other program enhances the same basic model.
By calling a single applications you have exactly one copy. By taking
that one model and "fixing" the problems on it in your own way you have as
many copies as there are programs.
> Didn't noted that. I thought you advocate vim. Than all you need is user
> definable keys in TB!'s editor?
No, I advocate User Choice. No, user definable keys will not work in
TB!'s editor. Hey, I want to pipe this text through a filter. Can't do it.
Damn, hard to bind a key for something I can't do in the first place. Forcing
the user to use the editor supplied is not user choice. Giving the user a
hook to use whatever editor he wants to use *IS* user choice. User definable
keys is configurability, not choice, since I am still using the same force-fed
editor.
> Mistype. I meant %OATTACHMENTS. How to implement QT containing
> %OATTACHMENTS with external editor?
Again, what is that?
>>> I don't know 20 different keystrokes just to del line. I use Shift-Dn,
>>> Del. Works on all comprehensive editors I know (I don't use UNIX).
SL>> That is the CUA standard.
> Exactly.
Which covers only the most basic of editing functions, nothing more.
There is no CUA standard for "reflow paragraph."
> Yes, because there is no need in it any more. Because delete line is a
> relict of FORTRAN, ASM and EDLIN epoch when there were no blocks
> and shift-arrow marking.
Funny, I find a need all the time for deleting lines as opposed to blocks.
I find the CUA mode clumsy at times because I can't just delete an arbitrary
set of lines. Furthermore, the way it marks blocks leaves a lot to be
desired.
> You are saying that to TB! developers it is better to concentrate on mailer
> and leave editing to external editor. Will that mean that internal editor
> will be removed?
In my view, yes.
> Than it will mean that I will be forced to learn another editor.
No, you will be forced to learn one *LESS* editor. You were forced to
learn one more editor because TB! included an editor and forced you to use it.
When you're outside TB! are you using TB!'s editor? No.
Let me give you a simplistic view. On Windows I use TB! for mail, XNews
for news. As a result I am forced to learn two editors. TB!'s internal editor
and XNews internal editor.
On Linux I use mutt for mail and slrn for news. I use vim for mail and
for news.
Windows total editors: 2
Unix total editors: 1
On Windows I decide to change from TB! to Eudora & from XNews to Gravity.
I am now forced to learn Eudora's editor and Gravity's editor.
On Unix I decide to change from mutt to pine & from slrn to nn. I use vim
for mail and news.
Windows total editors: 4
Unix total editors: 1
I decide that Eudora isn't for me, I really want Pegasus. And Gravity
sucks, give me Agent. As a result I am now forced to learn Pegasus' editor
and Agent's editor.
Meanwhile, on Unix I decide nn sucks, give me trn and pine isn't to my
liking, give me elm. I configure both to use vim.
Windows total editors: 6
Unix total editors: 1
No, wait, forget Pegasus and Agent. I want Calypso and, erm, Outlook.
Once again I am forced to learn new editors.
trn gives me gas and elm is to wooden for my tastes. Give me tin and, oh,
hmmmm, sms (my theoretical mail system). I configure vim as the editor of
those.
Windows total editors: 8
Unix total editors: 1
Let's cut to the chase, shall we? On Winfiles I counted a good ~70 email
clients of various capacities and ~50 programs dealing with news. Let's
figure 20 of those email programs aren't really clients and a good 30 of the
news programs are nothing more than binary extractors (I think that is about
right). That leaves a 50 email clients, 20 news clients all implementing
their own editor in their own way. That means to go through them all I have
to learn and evaluate 70 different editors. Not only is that a lot of
duplication in terms of binaries, it is also in code and programming time.
If they just implemented an external editor and was done with it. I would
learn exactly *1* editor.
70. 1. 70. 1. What was this again about you being forced to learn
"another" editor when you can chose that editor and no matter what happens
with the other portions of your system that one thing remains constant? No,
sir, you are being forced to learn different editors and don't even know it.
> If not than TB! authors will still have to improve editor as well, but they
> will have to add another feature which will not mean more concentration on
> mailer functions.
Exactly. TB! is an email client, not an editor. They should be
concentrating on the email client and its interface, not on an editor.
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
ICQ: 5107343 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------
--
--------------------------------------------------------------
View the TBUDL archive at http://tbudl.thebat.dutaint.com
To send a message to the list moderation team double click here:
<mailto:[EMAIL PROTECTED]>
To Unsubscribe from TBUDL, double click here and send the message:
<mailto:[EMAIL PROTECTED]>
--------------------------------------------------------------
