The very first text editor 3655
The very first text editor 3657
well IBM 026 and 029, Spring 1968 plus 1. Coursewriter III on a 360-50 at the University of Texas, Fall 1968 plus 1...
*Someone making changes marked up by someone else*. Okay. So, not someone who is thinking, during the editing process, about what changes to make? only about how to make them? and no, I don't mean by this that the editing person is a mindless robot, only that he-she is focusing on something different from what one would focus on if one is composing text as one types.
The very first text editor 3662
snip Ah. Again, "95% chance of working" isn't my experience, but whatever. There *are* some quirks in the traditional Unix toolkit -- I'd mention inconsistencies in the one...
Yes, yes, wrestling with one's tools slows things down.
But writing code is more than data entry, as you must surely know. Many coders are not very fast typists, but I'm fairly certain that improving their typing speed would have very little effect on their overall productivity.
The very first text editor 3660
Umm. Check the TLD in my signature. :-( Striking against the government can work... sometimes... but it sure better be over something with many orders of magnitude more public support than...
A lot of what coders do with a text editor, as you must surely also know, is make small changes to existing code. Speed of data entry doesn't matter much there; being able to quickly find the code one wants to change matters more. ("It's somewhere in function foo. Now, where is foo ...." Easy in any "good" editor, of course.)
With all due respect, I don't find this to be true. I have very little experience with using any text editor to make changes marked up by someone else, but I use vim to compose pretty much everything -- source code, e-mail, news postings, input to LaTeX for "pretty" documents, etc., etc. -- and many of these "bells and whistles" are central to my idea of what makes a "real" text editor (as opposed to -- Notepad maybe?)
The features for automatic indentation, for example. For all of the programming languages I can think of, consistent indentation of block constructs (loops, if-then-else, subprograms) makes a big difference in whether the code can be read and understood by humans, *which matters*. It's a significant slowdown if I have to be thinking myself about how many tabs or spaces to put at the start of each line in order to get things to line up in the preferred fashion.
Or here's what might be a better example. I took a course in COBOL ages and ages ago, back when programs were punched into cards and turned over to the keeper of the mainframe to be compiled and executed. COBOL, if I remember right, has some fairly strict indentation requirements (e.g., statements must start in column 8). It wasn't until *AFTER* the course that I found out that I could make a "drum card" for the keypunch that would let me skip over to column 8 with one keystroke rather than hitting the space bar seven times. How much faster, if I'd known .... Similar, if I'd been using a text editor to compose these programs, it would have been a lot faster to be able to skip (inserting spaces) to column 8 with one keystroke rather than typing seven spaces. Even faster might have been one that automatically started each line in column 8, with some provision for starting the line in a different place in the few (?) situations in which that was appropriate.
You know, some of this stuff probably applies to data entry as well, given your point (later) that that's not necessarily always just entering straight ASCII text.
That's what I'm trying to do here.
"Sigh!" ? Why would you make this buttumption about what I think? well, never mind ....
What I am buttuming here is that we're talking about people who are not thinking about what changes to make or what data to enter, but only about how to get the data into the computer as quickly and accurately as possible. Depending on the interests and abilities of the person doing this, that might be mindless or might involve quite a lot of thinking. I'm not going to speculate on which end of that spectrum predominates; I don't have sufficient information.
(Interesting -- I read some of those books but don't remember a Miss Corsica. But I don't remember any of the other characters
Well, admittedly tinkering with one's tools can be a guilty pleasure, seducing one away from Real Work.
But I'm not talking about spending hours thinking up clever new emacs macros, just to save two minutes' typing, or for the sheer fun of it. I'm talking about spending 30 seconds thinking about how to do something using a text editor's "bells and whistles", and then doing it that way, rather than spending five minutes doing it the no-thought way. If you want examples I'm sure with some thought and typing I can come up with them, but this is long enough already ....
That's interesting but doesn't seem to answer my question -- did the data-entry people and the bit gods use TECO in the same way, and find the same features useful?
That speaks well for the tool.
I would claim that this is equally true of emacs and vim, and when you hear people swearing at one of these editors, it's because they have put zero effort into learning how to use it, or because they're irritated by the fact that it's not like whatever they're used to. If you say "but all it takes to learn TECO is ...." -- I would claim that the effort is very similar for similar functionality in emacs and vim.
You wouldn't know that from the way most people seem to work these days .... :-)?
But back to the point.
Many people do use these all-in-one tools to write and modify code, where I would be inclined to use my preferred text editor, together with an buttortment of other tools (compiler, debugger, etc.). My question is which approach is actually overall more efficient.
For example, a lot of the all-in-one tools will, when you type in the name of a library function, pop up a little box with the names and types of the function's arguments. That's annoying when you know all of that, but if the function is one you don't use often, without the little reminder you'd be bringing up documentation in another window, or getting out a book .... So the all-in-one tool provides something *that will help in entering code* and that would probably not be available with a plain text editor. (I imagine some emacs fan will tell me that emacs can do this -- it can do pretty much anything as far as I can tell -- but that's not really my point here.)
-- B. L. Mbuttingill ObDisclaimer: I don't speak for my employers; they return the favor.
The very first text editor 3656
from long ago and far away ... Lynn, After seeing some of the RED-XEDIT dialogue between you and lovelove, I thought I would express my point of view...