quote: Original post by tortoise
(assuming bochs will let me, as far as I know no tool exists to write into/out of bochs disk images).

You can use floppies and mount them by clicking on the picture of the floppy in the corner.

I used to be in the same boat... I had no clue why you would want an editor with all those cryptic commands. It doesn''t even have a mouse!

There are two kinds of people... mostly younger people who grew up with the modern day IDEs, they tend to like the visual studio type interface. Then there are the old people who learned on vi, many of which still use it (I know a guy who has been using it for over 20 years).

I decided to take a programing project and learn vi. At first just so I could add it to my hard core computer nerd image, but in the end I found out it was really a great editor.

Spend a few hours on vim.org checking out the tips and scripts people have.

With a little bit of configuration I have gotten my vi to do everything I can in VS.NET and more.

With one keypress I can swtich between .cpp and .h files.
I can search man pages for syntax help without leaving my editor.
I can pull up a Visual studio sytle class browser that lists functions and variables of a class, with simple key presses I can go right to that function.
I can add the code to open up a file for reading/writing to my CPP file with 2 keystrokes.
I can autocomplete words which allows me to have longVariableNamesThatAreVeryDescriptive without having to type them all in. Just typing lon + ctrl+n would auto complete that whole var.
I can autoformat my code in many different styles.
I can even play tetris.

There are TONS of things vi can do to make coding easier, you just have to learn them. Yea the interface is a little archaic, but it''s also a LOT faster once you learn it. Expierenced vi users don''t even need anything other than the qwerty part of the keyboard and the function keys. After a little while reaching the mouse seems like a huge inconvienience.

My best advice is that you don''t have to learn all of vi to be sucessfull with it, just start with the basics and pick up new tricks as you go along. ie during my last coding assignment I learned how to use ~ to automatically change the case of letters, much quicker than deleting it and then pressing shift and the other key.

I know you can probably do all of that stuff in Visual studio, but that''s not the point. The point is you can also do it in vi. It''s very very powerfull, just takes some learning. However, it is well worth it.

Also, to all the emacs users: Emacs is a great OS, it just needs a decent editor

Wow! I didn''t know you could do all those things in vi! I use vim whenever I''m in the console and I''m to lazy to switch to XWindows and open KWrite, or Anjuta, but I only know the basic commands - moving around, changing modes (its pretty hard to use any variation of vi without knowing that), cutting, pasting (or yanking and putting if you prefer that), and basic searching. I really should learn vi better.

quote: Original post by clum
You can use floppies and mount them by clicking on the picture of the floppy in the corner.

Minix doesn''t like them. I formatted the disks with the minix fs (the only fs minix understands, even for floppies). But I always get "Illegal argument" to mount "mount /dev/fd0 /mnt/a", I can mount virtual images just fine.

So I''m currently grabbing a redhat image. I hope I can mount my minix disk as a second disk in the redhat machine, and copy the vim source over, then hopefully vim will compile in minix (!)

Anyway, yeah, that''s how much I''d rather use vim than vi (trying to stay on topic )

Funny. When I''m using a graphical editor, I never use the mouse for normal editing (this includes search&replace, go to line, etc.). The keyboard is simply superiour for this kind of work - and the authors of GUI editors know that.
But when it comes to configuring aspects of the editor, the GUI is much better at presenting and navigating unknown (to the user) options than a CLI can ever be. *That* is why GUI editors are ultimately superiour. And they''re even easier to learn.

cu,
Prefect

GUI editors are superior because they are easier to configure? An interesting way of looking at things.

I personally prefer a text file for configuration options... easy to backup/save/manipulate/etc. But in regards to a GUI to configure you usually need to look up help (well I do anyway) on an option, just as you usually have to look up a command in a non gui config setup... So, as long as that is easy...

quote: Original post by FeralofFireTop
But in regards to a GUI to configure you usually need to look up help (well I do anyway) on an option

Eh, no.

I didn''t say every controll on a gui, but there has definatly been times where either an option didn''t do what I thought it did (so I had to look it up) or I had no fliping idea what an option did (so I had to look it up). (by the by slick edit''s config is what is comming to mind)

one huge advantage of a gui config methodology is it is harder to loose options, and that is a good thing. ... a line I read (I''m certian from teh vim documtation but I''ll be damed if I can find it again) sumed that thought up perfectly, it goes something like, ''A hidden feature is a useless feature''.

A good way not to lose a feature is to keep an engineering journal. It is a smart thing to do for many reasons (which I won''t get into).

I''m not really sure what the capabilities of GUI editors are but one reason that I love ViM is because I can literally write simple scripting extensions to do things that the editor wasn''t initially built to do.

For instance, I use ViM on our systems at work that have a proprietary source code repository for checking files in and out. I wrote some extensions in ViM to automatically search for the file in the correct release and open it up in a split window. All I have to type is ":FindIt MyFile.C" and it will execute the shell commands to find the file and the vim commands to open the file in a split window. Regardless of whether I have a local copy or not it will find the proper file stored on the repository system.

This didn''t take long to configure at all. I have lots of these little things that make my coding life easier. I burn through a lot of code and there is a lot of redundancy that is not nearly intolerable to do with ViM as it used to be with other editors.

Personally I don''t understand how having to navigate through a configuration wizard can be easier than looking at my settings.vim file which prefaces every option I''ve chosen to set with a comment about its functionality. I also like being able to tar up my vim configuration and bring it to every machine I work on.

In the end it is all a matter of education and capabilities. Do you know you editor? Does your editor lack most features (like pico?)

Later,
RandomTask

quote: Original post by RandomTask
I''m not really sure what the capabilities of GUI editors are but one reason that I love ViM is because I can literally write simple scripting extensions to do things that the editor wasn''t initially built to do.

For instance, I use ViM on our systems at work that have a proprietary source code repository for checking files in and out. I wrote some extensions in ViM to automatically search for the file in the correct release and open it up in a split window. All I have to type is ":FindIt MyFile.C" and it will execute the shell commands to find the file and the vim commands to open the file in a split window. Regardless of whether I have a local copy or not it will find the proper file stored on the repository system.

I could do that pretty easily with a VS.NET macro that could be aliased and run from the VS.NET command window.