VI for SpartaDOS ?

[flashjazzcat]

I have compiled a stripped-down version of The Last Word (20KB as opposed to 36KB) which will work in 80 columns with the S_VBXE driver (in much the same way as the MyIDE FDISK utility). It only took an hour so far, so hopefully it isn't distracting me too greatly from my more important duties.

 

I aim to develop this as a diversion over the coming weeks; it ought to fit in conventional RAM, and will work with any DOS. It will probably share the same UI as FDISK (for those familiar with that app). However, I invite suggestions and feature requests.

Edited June 3, 2011 by flashjazzcat

[576XE]

Hello friends.

As far as it's concerned VI-editor, I found this link: http://singularcrew.hu/vi65/

It's alpha version but surprisingly it's works on ATARI in 40/53/64/80 columns modes.

I think VI may be a better choice because of obvious limitations of ATARI Keyboards.

I mean it's lack of arrow keys. VI needs not arrows.

EZ

[drac030]

What a pity that there is no source code available...

[greblus]

My jaw dropped.and a dream came true. But I can't manage to run it under SDX. Gives memory conflict.

[drac030]

It loads at $0800, so its usability is much limited.

[danwinslow]

has anyone asked them for source?

[flashjazzcat]

If an editor is required with this command set and which also supports S_VBXE and RC_GR8.SYS, it can be done fairly fast.

[w1k]

cant load from SIDE II..

[flashjazzcat]

See post #55.

[greblus]

If an editor is required with this command set and which also supports S_VBXE and RC_GR8.SYS, it can be done fairly fast.

 

Adding vim-like uber geek mode to the minimal version of LW would make it the best $EDITOR in the Atari world

[flashjazzcat]

 

Adding vim-like uber geek mode to the minimal version of LW would make it the best $EDITOR in the Atari world

 

Well, I was working on a new text editor for SDX earlier this year, but it uses the text-mode UI library and is rather large. Konrad encouraged me to make something much smaller without the fancy UI. I can easily strip the UI out and add whatever interface is needed to the bare editor. Now, I've only seen VI (or something similar) in action a couple of times. What version of VI/VIM would be the recommended "model" on the PC, from which to take design cues?

 

EDIT: Have downloaded VIM plus the manual. Looks interesting...

Edited December 20, 2013 by flashjazzcat

[greblus]

 

Well, I was working on a new text editor for SDX earlier this year, but it uses the text-mode UI library and is rather large. Konrad encouraged me to make something much smaller without the fancy UI. I can easily strip the UI out and add whatever interface is needed to the bare editor. Now, I've only seen VI (or something similar) in action a couple of times. What version of VI/VIM would be the recommended "model" on the PC, from which to take design cues?

 

EDIT: Have downloaded VIM plus the manual. Looks interesting...

 

vim on Linux or other Unices would be the best "model", but the problem is with finding a minimal subset of cool features to implement. Every user has his own habits, but moving around a file in vim-style, visual mode, commands repetitions, visual blocks, yanking/putting to/from registers and maybe multiple windows would make it something really great.

[flashjazzcat]

 

vim on Linux or other Unices would be the best "model", but the problem is with finding a minimal subset of cool features to implement. Every user has his own habits, but moving around a file in vim-style, visual mode, commands repetitions, visual blocks, yanking/putting to/from registers and maybe multiple windows would make it something really great.

 

Makes sense. I'll check out the Linux version under Mint over the weekend. The documentation describes a stupendous amount of functionality, so the challenge - as you say - will be deciding what to leave out. I think a very small, bare-bones editor is the best place to start, and then we can simply judiciously add stuff over time.

[Frankie]

I'm going to get my 'I use these all the time features' in right away :-)

 

There are the basic movement keys h j k l

Ctrl+d jump down 1/2 a screen

Ctrl+u jump up 1/2 a screen

 

$ end of line

0 beginning of line

 

G bottom of file

 

i go into insert mode till you hit ESC

A go into insert mode, put cursor at the end of the line

 

cw change word till you hit ESC

 

yy yank current line

p put the line you just yanked or deleted with dd

/ search

? search backwards

:wq - I know, I should use ZZ but I can't seem to give up :wq

:q exit without saving

:q! ignore any changes, exit without saving

:w write changes

r replace character under cursor with next character typed

R keep replacing characters until ESC is hit

x delete character under cursor

dd delete line under cursor

. repeat last command

u undo last command

J join current line with the next line

dG delete from this line all the way to the end of the file

Edited December 21, 2013 by Frankie

[greblus]

Good practical example showing that vim is not only an object of some strange cult is vimperator. It turns my quite useless Eee pc into an ultimate, full screen, mouseless web browsing expirience

[flashjazzcat]

What kind of file selector do we want? Something pop-up, or a separate document window like VIM, or purely command-line (i.e. similar to ProText?).

[+bf2k+]

CLI!

[flashjazzcat]

Cool!

[Frankie]

There are no popups in VI ! CLI

 

There is also the :r filename command to read a file into the current document

Edited December 21, 2013 by Frankie

[Sub(Function(:))]

 

Makes sense. I'll check out the Linux version under Mint over the weekend. The documentation describes a stupendous amount of functionality, so the challenge - as you say - will be deciding what to leave out. I think a very small, bare-bones editor is the best place to start, and then we can simply judiciously add stuff over time.

Please remember if you look at a current linux distro, these have VIM installed (vi improved) this has a lot more functionality than vi.

 

To start I would suggest only look at vi functionality.

[flashjazzcat]

Ok - thanks. Should be a nice little side project when APT is done.

[twh/f2]

Cool project. Would be nice to have a SDX compatible version as default $EDITOR on the cart.

[Creature XL]

Ok - thanks. Should be a nice little side project when APT is done.

 

"little"... you maybe should use VI for a while before saying that

Although I am only using VIM. So I'd say go for it

[576XE]

Sorry, but I have another suggestion about file selector.

I mean some not windowed but full screen vertically splited panel.

 

Top part must contain some kind of breadcrumbs for speed directories navigation. They must be stacked vertically with scrolling and down part must be filenames themselve. Esc,Tab, Arrows as controls. Return for editing.

 

It's like IBM AIX SMIT utility.

Really I love JWB ED, of course. But it can't work with 80 cols. So pity.

 

[drac030]

Well, I was promised an ED replacement years ago by two individuals separately, and ED is still around.

 

ED has just one drawback, it cannot work in anything else than GR.0 and cannot be easily accommodated to work with another display mode. It has one advantage too, and it is remaining unbeaten in that respect: it is only 2,8 KB in size (and the actual program has 2,3k). Any replacement editor, due to the known constraints of CAR: device, and due to its general capacity on a 128k cartridge, certainly cannot occupy like 20k. Therefore it would be better to avoid menus, complex file selectors etc., especially in a program which mostly allows to edit CONFIG.SYS or a BAT file and virtually nothing else (because for everything else there is LW).

 

Back to vi, I am not a fan of it, but it certainly would be nice to have something like this at least on the Toolkit. Apart from writing one from scratch, another approach would be to request the source code from the original author (I did it already), or in case he does not answer in reasonable time, to assume that the project is dead (note that last update was in Jan 2011 or something) and reverse engineer the source from the binary.