OSDev.org

Hey..

I am thinking of implementing an editor as a part of my os. This editor would basically be a replacement for the console. All messages that will be sent to the console by the drivers and the system itself would be shown in the editor. The os would simply start of with the editor itself and the messages would simply appear. The cursor can be moved around anywhere, but you cannot edit the read-only stuff like the driver messages.

What you can edit, is the active entities. These entities would be created by programs like 'ls' etc..
Heres an example...

------------------------
Initiating drivers...
Starting vm...
ls
sched.txt
readme.txt
mfile.m
pfile.p
-------------------------

There is no prompt. The cursor simply appears on the next line after the 'starting vm...' message. Now the user types ls in a special way (maybe holding 'ctrl', telling that it is a command) and the command executes.

Now the user can get his cursor to any of the listed files, and simply edit their names, and when he does so, the filenames would actually be edited in the filesystem.

The user may open text files by the command open and then he would type close or save to mark the end of the file he edited. Whenever he wishes to edit it again, he does not need to type open, but simply scroll to where he opened it last time. As he enters the 'open'-'close' range, the editing becomes connected to the actual file instead of the console...

Comments?

Sounds confusing like hell... and in your listing, if I edited the name of readme.txt and the rename results in an error (file already exists, for example) - where would you print that? Below the listing, or in between?

What...?

Interesting idea, but the manual would have to be the size of the DOS 5 manual. And that thing's over 700 pages long!

can your editor view text that lenght more than screen width

i suppose the screen width is 80 char.
when the line length more 80 char.

what happen :
1. ignore the rest
2. make scroll
3.

cheers,
Ahmad T. Dajani

I like your idea. I think you have to make it well documented, maybe with some tutorials or screencasts. And you have to make it easy to enter commands. Pressing Ctrl while entering commands doesn't cut it if you want to enter many commands. Maybe "double-click" on Ctrl to make it in command-mode and it automatically drops out of that mode, when you move the cursor to some text file. It would also be nice with some visual guidance, e.g. commands are in a specific color and text editing in another. Or just some kind of visual change, when you're about to enter a command. Maybe the cursor will change color, so you know if you enter "close" now it actually does that and it is not text being entered in a file.

I'm playing around with a slightly different idea, but still, here it goes:

You have a shell with a prompt and you're able to move your cursor everywhere. Commands like 'ls' create widgets as output. You cannot see the difference, because widgets are formatted like normal text output (from 'ls' or what else commands output would normally look like). The smart thing is that widgets are active/alive after the command finished. So you can go up and edit filenames, or sort files by time instead of name by pressing Enter on the column header. You are able to resize the height of a widget, it will then have a scroll bar. You would in fact be able to create a text editor, when called just showed a text-editor-widget, which you can edit your file in. I didn't think about that possibility until now.

It sounds like you've reinvented emacs

If it's implemented well, this seems like an efficient way of using a text-mode machine. Maybe have a status bar at the bottom of the screen and have a title bar at the top.
Then have a different colour background for command outputs like LS growing from the right, staying there until it loses focus. (Keypress when cursor is out of the box).

I agree that if implemented well, it could be nice.
Hopefully it's not reinventing emacs -- that thing is way too bloated.
Yes, the typical CLI needs to be smarter. The concept of a "command line history" with a very simplistic search/replace function is really pathetic in typical shells. Incorporating a full editor into the shell, with access to previous command lines, previous command outputs, and previous filenames, seems like a potential way to make a significantly more powerful CLI shell -- if that's what you want to work on.

It's a nice idea but you guys do realise that you're getting close to a GUI, right? I mean, with a bit more amount of work (I'm not talking about much here), you could implement something like Turbo Vision (if you remember it ) as a user interface. And that DOESN'T need a manual at all ...

This may be a little OT, but as far as modern, user-friendly shells go, I would recommend fish. I currently have it set as my default shell mainly for the tab-completion and color-coding but it also has other nice things like being able to 'cd' without typing 'cd'. For instance, the easiest way to go to your home directory is to simply type '~' (and hit enter of course). If I type some text (it can contain anything including whitespace) and then hit the up key (to look through the history) it will only display history items that contain that text.

So that sounded like an advertisement... but I think it goes way above an beyond shells like bash, though it does not integrate an editor into the shell (but it does have multi-line editing).

@Solar:
If the filename editing generated an error, then you would get that error at the end of the console after all messages, and as the listing is an active entity it would simply restore the original filename, thus passively showing you that something got screwed up. That way you don't even have to bother about the error (Most of the times, you know why you screwed up; you don't need to read the error).

@Ahmad T. Dajani:
Yes it can, it is just like a normal editor, with a buffer size that can increase without any bounds. In case you made the file too big, you can simply switch to another virtual 'editor' and do your stuff or say 'new (active) file'.

And yes, the main hurdle i am facing here, is of writing an editor for this. Once I am done with the editor, IMHO, making the active entities wouldn't bee too difficult. But the implementation of the basic concepts of the editor: cursor movement, buffer arrangement over screen framebuffer, cut-copy-paste etc.. are bugging me like hell. The time I think I will require to code this stuff seems eternity.

I found this editor in SanOS which I could port easily to my OS but, in order to improve it and add features, i need to understand the concept of editing that it works on. Unfortunately I couldn't find any documentation for that editor.

If I think of going for open source editors, like Joe, then it seems difficult to compile them, as they would need a shell to configure stuff etc.. In addition to that, again I may not be able to modify them easily.

Hey...

I am done with the basics of my editor.. with cursor movement, page up, page down, home, end, inserting keys etc.. I am glad I found a way to do it in an easy but not so memory efficient way..

As soon as I am done with the 'active' concept of this editor I will announce it so that you'll can test it...