Re: [dev] ved

markus schnalke wrote:
> [2009-10-06 10:43] pancake <pancake_AT_youterm.com>
> or better
> [2009-10-05 03:04] pancake <pancake_AT_youterm.com>
>
>> Vi is the visual ed, but I have never seen any implementation using
>> ed. They just embed it inside the 'GUI' .
>>
>> I think that having all the editing engine implemented in ed is
>> simple to wrap it into a GUI based on X11 or ncurses.
>>
>
> Okay. Now I see a difference. But also difficulties.
>
> What about unlimited undo for example? Ed does not provide this. Thus,
> if you want it (We *do* want it.), you have to put it in the UI. But
> that's the wrong place.
>
> We also should do performance experiments first, because it's important
> that the editor responds directly. Splitting it into two processes might
> cause bad performance.
>
> What I like, however, is the idea of having one UI and several eds
> behind -- one for each file you edit.
>
>
Yep, I know that this approach enables so many issues in fronts
like performance or features that are mixed between UI and ED.

The idea is that ED is used to edit lines, so the communication between
gui and backend must be only done after editing a line. The GUI must
understand at least a block of information from the backend. it needs
a context.
>
>> Vim supports launching apps to filter text, but it is not the main
>> way to work. Because is more optimal and easy to port to other os
>> like dos or w32.
>>
>> Syntax highlighting is something that can be implemented in a
>> filter program.
>>
>
> Syntax highlighting is bad on terminals. Seems there is no sane way to
> have it. Don't know about X applications.
>
>
>
Yeah, I have always seen syntax highlighting a pretty slow and buggy
thing. emacs and vim have problem with syntaxes so many times
because the performance or because they lack of enought context
to colorize a big comment block or so.

In files mixing more than one syntax it makes the problem much bigger
(like html+css+js or gtkaml+vala,. ..)

I dont really see a clean and optimal solution for syntax highlight.
But I cant live without it :)

At least by having a set of regexpes colorizing list of keywords and
text between quotes should be enought for most of situations. The
problem appears when a line changes the syntax rules of the following
ones.
>> The same for indent, line numbering, text
>> alignment, etc..
>>
>
> The question is: Do you really want this stuff to be outside the
> editor? You'd need constantly a whole lot of forks.
>
>
>
I never use real-time indentation or text align, and line numbering
can be provided by ed. The only times I use text indent is when
in vim I choose a block of code and press = or gg=G to indent the
whole file.
>> I love vim, but I feel that most of the capabilities it supports
>> are embedded in the editor instead of using a unixlike design based
>> on pipes and filters.
>>
>> Autocompletion, ctags, searchs,,.. Can be implemented outside the
>> GUI without much pain.
>>
>
> I think search (read: RegExp) is crutial to be a core part of the
> editor. Ed already offers it.
>
> For the other stuff, I agree. If one needs them (at all) then through
> external programs.
>
>
>
yep, and also search+replace with regexpes.
>> We just need a GUI that supports X11, ncurses, sdl or OpenGL that
>> allows to bind some keybindings to run commands at Ed level or
>> change the filters for example.
>>
>
> We probably don't want sdl and OpenGL.
>
>
>
yeah I was joking at this point.
>> The main problem in this application is to find the good
>> simplification of the design to allow good flexibility, performance.
>>
>
>
>> Any proposal?
>>
>
> Have a look at sam. That's what the former users of ed use today.
> You'll probably find interesting approaches there.
>
>
For sure, sam have good ideas, but it lacks a keyboard interaction.

I think that if we want to manage different files on a single implementation
we have to think on a more global approach using the WM to manage
multiple instances of the same file allowing interactive editing with more
than one user, or supporting the edition from local and remote of the
box (screen is just an ugly hack). Applications must be independent
from the backend and the data they work on. This is the only way
we can move or manage it without depending on a terminal or Xwindows.
(what if your Xwindows get locked, or you want to continue editing a file
from a remote box via ssh?). lock files should be only useful as timestamps
and watermarks to define who and when has changed the contents of the
file. This is probably one of the most anoying things of vim.
> First try to get a prototype ready, which excludes the extreme parts.
> You'll may notice that some of the ideas simply don't work. But if the
> design holds, go on in a second iteration.
>

I think we probably need more discussion on this topic to get the right
design for 'ved' or 'sved' (i think ved already exists), I will think more
on the way to solve the missing parts of this design. Ideas are welcome :)
> In other words: Don't try to get a micro kernel right on the first try
> ... i've heard of some guys who still work on it. :-)
>
>
Hehe, microkernel discussions are endless ones, I'm just trying to
push some light about the problems we face when editing text and
the tools we already have and the ones we miss to get a simpler
implementation.
> I'm looking forward for the project
>
I'm probably more interested on working for the email project than
the editor one, but i'll be happy to discuss things if any of you is
interested on writing a POC of the above ideas.

At least (nowadays) I'm spending more time thinking on how to make
a good design before coding any line (yeah, im getting old ;)

If I get a bright idea about how to get this splitted reinvented wheel
working i'll push some sources for review. But feel free to do it by
yourself if you want, writing a text editor is not in my short TODO
plans actually :)

--pancake
Received on Tue Oct 06 2009 - 16:42:42 UTC