Re: vi horizontal split screen

Tim Harig wrote:
On 2009-05-15, DMcCunney <plugh@xxxxxxxxx> wrote:
Tim Harig wrote:
On 2009-05-14, DMcCunney <plugh@xxxxxxxxx> wrote:

I'm an old ksh hacker, but bash will do fine.

I have always heard great things about Ksh; but, I have not used it as it
was never readily available when I was learning. I avoided Csh because of
the bad press. Zsh has some nice features for interactive use; but, most
of them can be added to Bash with a little bit of scripting and I hate to
use one shell for interactive use and another for script use. I often
small scripts on the fly directly from the command prompt.

I started on the SysV R2 Bourne shell, and used csh for a better interactive interface. But when ksh became available, I grabbed it with both hands. Command line recall and edit, which I had on DOS, was worth the price of admission by itself. Other features, like built-in integer arithmetic and the "print" command were icing on a tasty cake. For years, I ran the MKS Toolkit under DOS, because it had a very complete implementation of the Korn shell (lacking only things single-tasking DOS could not do, like aysnchronous sub-processes.)

Csh got bad press because of parser bugs that made serious scripting in it a questionable idea. The script language was designed to look like C for the benefit of C programmers working on *nix, but you still needed to know Bourne syntax, because all the scripts that controlled Unix itself were in the Bourne shell language. I've spent time on various systems rewriting csh scripts in Bourne syntax for maintainability.

Ksh got mature enough to be installed as sh back around '85, I believe, and I did so in a few cases.

Zsh is largely ksh compatible, and I have a win32 port I use under XP on occasion.

Bash, meanwhile, was trying to marry the Bourne/C shell flavors and include the best aspects of both. I suppose it did, but the result is big enough that some things call ash to process scripts to avoid the overhead.

Taken together, all of these tools form their own kind of application
environment while all being independant of another. Most of them could
easily be switched for another application if I found one that I thought
to work better. I consider that to be the Unix philosophy.
Which it largely is, though that philosphy is likely undergoing changes.

That is true of some groups -- particually within the Linux community. A
large part of that is many Linux users started with Windows and then moved
to Linux. They took a lot of their working habits with them. I have the
opposite issue. I take most of my Unix workhabits with me when I work on
Windows.

I think it's occurring because of changes in what *can* be done. For instance

I dislike when people try too hard turn Unix into Windows. There are a
great many things that I like from the Windows platform COM, .net,
powershell/monad, WSH, WSUS, GPOs, etc. that I think would would be useful

you mention Powershell. You can create scripts with pipelines in Powershell, but what gets passed around in the pipelines are fully qualified .NET objects, rather than ASCII strings. I suspect the surface of that capability has just been scratched.

when translated the Unix environment; however, Unix is a separate
environment with its own strengths. It has been around a long time
directly because of those strenghts and those strengths stem from its
central philosophies. They should not be forgotten or we will end up with
a poorly implemented version of Windows.

I don't think we need to worry about that very hard.

There is certainly something to be said for a more unified environment.
The nice thing about a unified environment is uniformity of usage. This is an area where the Gnu tools have polished a few rough edges off of Unix. The Unix utilities were largely written by different programmers scratching different itches, so uniformity of syntax wasn't a consideration. Gnu tools can all be counted upon to have at least some options in common, like --help.

Very true, they also remove many arbitrary limits. They make more use of
system memory to remove disk usage which is normally good for modern
systems. I like them and use them on many systems for these reasons.
I agree that conformity is good when possible; but, is no silver bullet
and I feel it should be trumped when in conflict with other things like
utility and usability.

I don't consider them a magic bullet - merely something it would have been nicer to have from the beginning. And I fail to see where regularity of syntax will conflict with utility and usability.

I use X so that I can have three screens and so that I can run them at
higher resolutions. I run graphical applications when dealing with
graphical things; but, I still spend most of my time in X terminal windows.
This mainly because I find them so much more efficient to use. I almost
never take my fingers off of the keyboard -- even when working inside of
GUI applications where I make extensive use of "hot keys."

I learned Unix back before X and GUIs were common, and got accustomed to the command line as well, so I pretty much always have an X-term open. I wish I had the room for multiple screens here, but my computer desk at home hasn't space for two 19" monitors.

It also seems to me that many text based applications tend to be more
solidly written and more accessable in terms of scriptability. As long as
an application has text inputs and outputs it can be automated and linked
to other applications -- even it it didn't provide any explicit hooks for
the task. Graphical applications can often be accessed and automated
through the use of COM objects; but, the applications must be explicitly
designed to export those objects (and possible provide enough documentation
to know how to use them).

The "one tool for one job" philosophy is easiest to apply when all the tools work on the same underlying data format. I'd call the philosophy an outgrowth of history. Unix was developed by programmers wanting a better environment for the task of doing software development than the one provided by the system they were using. They needed to be able to create, manipulate, and transform source code, and that was stored as ASCII text. So if your data is ASCII text, Unix offers all manner of handy tools to massage it. If not, things get a bit more complicated.

Working with text based applications also has the benefit that they are
easy to work with remotely. I make extensive use of ssh. VNC and RDP are
good tools as well; but, I can get an SSH link working in environments
where VNC and RDP will not.

I've used all of the above, and agree. Unfortunately, not everything you might want to use *is* text based.

I prefer "best of breed" myself, but I understand the attraction of performing edits, reading and replying to email and newsgroups, interacting with the shell, and compiling and debugging from within a single environment, with no need to switch programs or command sets to do it.

I do understand why people prefer unified environments and I suppose that I
would learn to like it if I ever found one good enough. Emacs is not it.

Depending upon what you do, there may not be one.

The most popular integrated environment I know of these days is IBM's Eclipse programmers IDE. There are lots of IDEs about, but it's hard to justify paying for one when Eclipse is free, open source, and cross platform.

But the power is a two-edged sword. I saw commentary by one developer who deliberately reverted to a standard text editor to really learn Java, because things in Eclipse like auto-complete were relieving him of the need to really understand how to construct things like templates. Once he felt he had learned Java properly, he was willing to use Eclipse again because the features were time-savers, but he understood what was being done for him.

The default Emacs editing modes are a product of this. I don't know
many people who use Emacs because they think the keystroke are great.
I find them to be mediocre and clumsy. Even the old wordstar based
keystrokes that most windows text editors follow is superior. The fac
The default Emacs keystrokes have the same basic characteristic as the default vi keystrokes and the default WordStar command set: they are keyboard independent. If you have a Control-key and a QWERTY keyboard, you can use them. They don't require things like arrow keys of F-keys.

Emacs also makes heavy use of the Meta key. Even today with a standard 101
key PC style keyboard it may or may not corespond to the ALT key based on
terminal settings. In some environments, it is still accessed using the
ESC key.

The Meta key is another keyboard independent function. Esc always exists - you can do it as ^[ if your keyboard doesn't happen to have an Esc key. Or you can bind it to a key your keyboard *does* have. I believe devices like the TI Lisp Machine had keyboards with several different Meta keys which could be mapped to different uses. In some respects, the 101 key IBM PC keyboard is a simplification of what Emacs can do.

I learned WordStar back in the days when you learned it as your second
editor, because the one you preferred might not be available, but
WordStar was. I had Emacs customized to use WordStar commands to avoid

That is largly true of basic vi commands on Unix systems.

Entirely true, really, for reasons I mentioned earlier. Some of the things used as terminals on early Unix systems didn't *have* arrow keys or F-keys. (Reading the comments in old termcap files can be amusing. the folks creating the termcap entries expressed their feelings about the devices they were trying to support. "Magic Cookie Glitch", anyone?)

But meanwhile, it sounds like you are claiming Emacs is a poor editor not because it lacks the editing abilities, but because you dislike the command set it uses to apply those capabilities. Fair enough, but like everything else about Emacs, that's customizable, and you can remap the command set however you like.

That partially true. It is also largely true of vi. I have seen some very
interesting uses of remapping the entire keyboard.

Well, true of vim. Less true of vi, I think, though the :map directive permits interesting things. I have an ancient set of vi macros around to make the arrow keys work in Input mode. Whether or not they could be used depended on what sort of macro storage space your vi had been compiled with (and the author of the macros implicitly assumed you *had* source, and *could* rebuild vi with more macro storage to be able to use his macros.)

My main complaint about Emacs is that you largely *have* to customize it to make it truly useful, and learning enough to be *able* to customize it is a non-trivial task.

Very true. That is why I consider it a shell and application environment
rather then an editor. You can do virtually anything with it including
recreating what I like about vi. It is partially an apples and oranges
comparison when trying to compare it against any text editor. Therefore,
the only way I can compare Emacs as an editor is to compare its default
editing mode.

Okay. I understand the feeling, but I'm not sure I agree. If you compare editors based only on the defaults they come with, and ignore the ability to customize them using whatever facilities they provide, you essentially ignore most of what makes a particular editor desirable to those who use it,

just wants to edit text using a vi keymapping, then why would one use
Viper instead of just using a ligher vi clone?
Possibly because one wants the various *other* things Emacs can do, but prefers the vi command set?

But what else is Emacs any better then other applications at doing?

Not "better". Say rather "As good as" or "good enough". A best-of-breed application may have an assortment of features not present in competitors, but if you never have occasion to *use* those features, you may not *care* that Emacs (or whatever else you use) lacks them.

For instance, Vim has an enormous number of features. But for the uses I put it to, I seldom if ever use them. For what I need to do, plain vi is quite adequate, and the way I use Vim, it might as well *be* vi.

I like using the best tool for the job, but that doesn't equate to the most powerful. My philosophy is the tool to *fit* the job. So I won't resort to perl, for instance, if tr or sed can do it. And on the same lines, I have a number of different editors, and some are minimal indeed, but the best fit I've found for the contexts in which they are used.
______
Dennis
.

Relevant Pages

  • Re: (OT) Learning C (in order to patch nethack, so not entirely OT after all)
    ... under Unix). ... moving my hands from the basic position on the keyboard. ... My first experience with emacs was under DOS. ... But on both, I install the necessary ...
    (rec.games.roguelike.nethack)
  • Re: Great SWT Program
    ... attacking, and which I never made, is "emacs is psychic and can know ... Of course it is - there is no way to use it except of as unix. ... Unix isn't "the command shell and emacs". ...
    (comp.lang.java.programmer)
  • Re: Great SWT Program
    ... Is seems somewhat common for emacs users to use C-w C-_ to copy the ... Unix: Invisible selections commonplace. ... When you need to specify a file, you get a prompt saying "Enter ... Eh -- there's a command when editing a text file to interpret the line ...
    (comp.lang.java.programmer)
  • Re: Text Editor for HTML, XML, etc
    ... Which is why I'd recommend emacs instead. ... becomes a course on Terminal, the command line, unix, and emacs. ... I only ever started emacs twice in my life, each time it took me 20 mins ...
    (comp.sys.mac.apps)
  • Re: book recommendation: Mac as Unix
    ... I'm a total newbie to the Mac. ... I've been using Unix and Linux ... I wanted to invoke Carbon Emacs from the command line, ...
    (comp.sys.mac.system)