Jump to content
IGNORED

VI for SpartaDOS ?


Frankie

Recommended Posts

 

"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 :)

 

Absolutely agree, but as I say - the VI implementation would be an ongoing sideline. A simple editor can be put together relatively quickly, and added to incrementally.

 

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.

 

 

This is what I was working on earlier in the year:

 

post-21964-0-50291300-1387713241_thumb.png

 

But yeah: it depends on a UI library some 3-4K long (although dialogue box definitions themselves are rather small and economical). Thing about text editors is they need to have lots of RAM devoted to the buffer. It's easy to make something similar to that shown in your screenshot without the UI library, but it just means re-implementing yet another interface design. :)

 

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

 

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.

 

Yep - I hear that loud and clear. I had no time in the summer, and already the text editor I was working on was burdened with menus, windows, etc. Since then I've been labouring to get hard disk tools finished. You know as well as I how long it takes to get things done. ;) Anyway, I'll still finish that larger editor, but I've become enlightened with regard to something small, simple and minimal. The bare bones are already there for something which opens and saves files and lets one edit them using S_VBXE and RC_GR8.SYS, so it's a wonder something suitable isn't done by now. Let's see what I can do in the next couple of weeks, in between Christmas and New Year parties. ;)

Link to comment
Share on other sites

 

Absolutely agree, but as I say - the VI implementation would be an ongoing sideline. A simple editor can be put together relatively quickly, and added to incrementally.

 

 

Please, do not get me wrong. If anyone can develop a text editor it is you, at least you have proofed to be very well capable of doing this. However, if Vi would be a "simple editor", it wouldn't be so popular since maybe 30 years. It has a lot of nice features which make it what it is. Command repetition, split screen, block selection and more stuff like this. Again, no idea what's Vi and what's VIM. So maybe VI is just a simple editor :)

I am using VIM since 6 or so years and still find useful hints all the time. This VIM-wiki states that it has over 1600 tips :)

 

http://vim.wikia.com/wiki/Vim_Tips_Wiki

 

But please do not let that stop you. I only want to give you a heads up that it might be more work then you'd expected :)

Link to comment
Share on other sites

 

However, if Vi would be a "simple editor", it wouldn't be so popular since maybe 30 years.

 

You misunderstand... perhaps I'm not too fluent yet today. ;) I'm not saying VI or VIM are simple editors. I've already been impressed with the documentation which describes the huge amount of functionality in these editors. My intention was to get a "simple editor" up and running which fits Drac030's criteria, and then add to it to perhaps make something which approximates some of VI's feature set. I have no illusions that such a thing can be done overnight, but one has to start somewhere, and a no-frills editor based on the existing core would probably be a good place to begin. :)

Edited by flashjazzcat
  • Like 1
Link to comment
Share on other sites

A little BIG! question.

 

Is it possible to make somethink like ED but compartible with ACE-80 or another modern 80col handler?

 

It's much more demanded then VI revival.

 

The reason is that VI was born earlier than 101-keys keyboards and even so it offered full functionalities.

I could be wrong of course but there is NO ideology above VI.

 

Emacs instead was the attempt to make terminal-based (the first step to voice based) really SMART interface to computer.

NOT to Editor itself!

I remember that they said that LISP is low-level programming language!

It's IDEA of course, BUT you can see now how they advanced.

 

I know only one thing, that Human-ATARI interface must be very simple. Text based of course.

I don't know which of them ...

 

I think that VI is Very Impressive work of very talented peoples for making their's personal environment from simple editor.

 

BUT NO FROM COMPUTER ITSELF!

Link to comment
Share on other sites

 

Is it possible to make somethink like ED but compartible with ACE-80 or another modern 80col handler?

 

 

That's pretty much the whole idea. It'll be compatible with RC_GR8, S_VBXE and any other display driver which uses the same API. Not sure if I'd want to use the standard OS put character routine so that anything which intercepted output via the CIO could work, but I guess it could be done.

Link to comment
Share on other sites

I see all of us are going in the same way.

It's COOL!

 

FJC said that TUI library is too big to ATARI editor.

Konrad said that ED is beautiful.

Ever their word is as honey to me.

 

We are remember menu based editors... FJC trying to dive us even windows based editor,

but there is not ATARI ZEN!

 

VI - too of course.

Link to comment
Share on other sites

Oh GOD!

Dear FJC, I only like to press Ctrl+S for Save and Ctrl+L for Load.

I NEVER used on ATARI of course Search and Replace!!!

Is i'm psychotic?

 

The reason is very simple - After that I must pressed so many keys that I'l better will deletes all of garbage and make a new one.

...

Sorry, I'm a little drinked today.

May be, because of my atari's memory death.

Link to comment
Share on other sites

Not sure if I'd want to use the standard OS put character routine so that anything which intercepted output via the CIO could work, but I guess it could be done.

 

 

E: has its contraints but an editor could of course be done this way: an example is MAE's editor, which works without problems with VBXE text mode provided by CON.SYS, even if the MAE itself is much older than VBXE. The speed may be a problem, but again, there are screen accelerators for GR.0, which fix this issue.

 

 

I get complaints about menu-less editors that the command codes are hard to remember.

 

 

A compromise migh be something like pico: it is rather simple editor, no menus, only CLI parameters and keyboard shortcuts, and it displays the command list all the time in two bottom lines, so it is extremely easy to learn.

post-6049-0-99856900-1387723103_thumb.png

Link to comment
Share on other sites

E: has its contraints but an editor could of course be done this way: an example is MAE's editor, which works without problems with VBXE text mode provided by CON.SYS, even if the MAE itself is much older than VBXE. The speed may be a problem, but again, there are screen accelerators for GR.0, which fix this issue.

Funnily enough, MAE's excellent editor was exactly what I was thinking about while I was typing the post. :)

 

A compromise migh be something like pico: it is rather simple editor, no menus, only CLI parameters and keyboard shortcuts, and it displays the command list all the time in two bottom lines, so it is extremely easy to learn.

Looks good. Thanks!

Link to comment
Share on other sites

Ermm... isn't that one of advantages which VI has?

You hit ESC and go into the normal mode. then every key is avaiable and most (all?) commands have meanigful shortcuts.

Erm... why erm? Not having menus isn't an advantage per se if the incipient user finds it hard to remember shortcut keys. The user will therefore ask "where are the menus?". But certainly meaningful shortcuts are a big help, as you say, and after a while using them, they become second nature. As far as menus go: if the shortcuts are displayed on the menus, pretty soon the user finds it's faster to use the shortcut key, and the assignments seep into the subconscious. I won't dispute any of that. The learning curve for an application without menus is steeper, but the application will be leaner and the seasoned user will appreciate that.

 

Like I say: you can't please everyone. Applications and operating systems not burdened with menus are often dismissed as "complex power-user tools" by those reluctant to read the documentation. There's a school of thought (which has my ear) which advocates hiding all advanced application functionality in an "expert mode", while making basic functionality just about as obvious (and non-destructive) as it can be. My experiences writing applications absolutely bear this out: confronted with a lot of complexity, lots of new users throw their hands up in horror. Similarly, advanced functionality (not accessible via menus) in text editors often ends up completely ignored, since one must read the documentation to utilize it.

 

Anyway: not to get away from the point at hand (and - after all - this thread is about wanting a VI clone)... if a small editor is required, something with phonetic command sequences or minimal menus similar to Pico, makes a lot of sense.

Edited by flashjazzcat
Link to comment
Share on other sites

resist feature creep. Bare bones and small would be what I would appreciate. Basic VI functionality, including the '.' redo last command functionality would be all I was looking for. No menus or popups or file selectors. Being able to run en external dos command with ! would be nice, but not required.

Edited by danwinslow
  • Like 2
Link to comment
Share on other sites

Well, before we get anything, here is a little Christmas gift: the said VI65. It will run under SpartaDOS X. Besides, it only works in GR.0 - just as the original, as I did not really touch the program itself, I have only replaced I/O calls and got rid of the annoying loading address being $0800 (by converting everything into SDX relocatable format). I gave it very little testing, so it is possible that something does not work. But it allows to load a file, do some editing and write it back, so basic functionality should be available.

 

There is one option which does not seem mentioned in the documentation: pressing 'Inverse Video' and 'g' will display how much free space is there inside text buffer. After that you have to press 'Inv. video' again to resume normal operation.

 

I would like to ask VI fans their opinion, if the program is worth anything, especially, if it is worth any more time to spend on improvements (like adding 80-column mode etc.).

 

The attached file is a *.COM, I have renamed it *.ZIP, because the forum did not allow me to attach a *.COM file.

 

Merry Christmas.

vi65.zip

Edited by drac030
  • Like 3
Link to comment
Share on other sites

Well, before we get anything, here is a little Christmas gift: the said VI65. It will run under SpartaDOS X. Besides, it only works in GR.0 - just as the original, as I did not really touch the program itself, I have only replaced I/O calls and got rid of the annoying loading address being $0800 (by converting everything into SDX relocatable format). I gave it very little testing, so it is possible that something does not work. But it allows to load a file, do some editing and write it back, so basic functionality should be available.

 

There is one option which does not seem mentioned in the documentation: pressing 'Inverse Video' and 'g' will display how much free space is there inside text buffer. After that you have to press 'Inv. video' again to resume normal operation.

 

I would like to ask VI fans their opinion, if the program is worth anything, especially, if it is worth any more time to spend on improvements (like adding 80-column mode etc.).

 

The attached file is a *.COM, I have renamed it *.ZIP, because the forum did not allow me to attach a *.COM file.

 

Merry Christmas.

 

This a great find... except it doesn't appear to load the file you specified on the command line and :r filename doesn't work so I don't know how to actually edit an existing file, but a lot of the every day commands I use work great. Fix that file-load whatever it is and this would be perfect for me.

 

Frank

Link to comment
Share on other sites

I would like to ask VI fans their opinion, if the program is worth anything, especially, if it is worth any more time to spend on improvements (like adding 80-column mode etc.).

Thanks! I'll start using it right away. I like it and it's already better than ED (ok, maybe tad unstable ;))

 

Merry Christmas!

 

 

Edited by greblus
Link to comment
Share on other sites

(ok, maybe tad unstable ;))

 

I cannot guarantee fixing anything, but if you observe some consistent behaviour, tell me, we will see what can be done.

 

Here is a version which accepts fname to load in the command line. As before, the file, when downloaded, should be renamed to *.COM (it is not ZIP, I only named it so, because of the forum's restrctions on attached files).

vi65.zip

Edited by drac030
  • Like 2
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...