> Hello,
hi
> 3. I am looking for people who would be interested in writing a vim
> clone. I already called it viq (vi quick)
I'm interested, but some of the ideas you have seem a little too unsuckless
(i'll cover what i think in a mo)
Keep in mind, I'm not trying to be Uriel, this is constructive criticism.
> * Should be able to open a full source tree in one "aggregated"
> buffer. This would allow a linear browsing of the code.
> * Should be able to aggregate files in different ways during editing.
> For example given a source code file f1.c, you would have a
> f1.mycomments, that would contain refferences like
> f:function correct the parameter list
> l:123 remove comments when done
>
> the lines from f1.mycomments would not be part of the source code,
> however they would be displayed inside the editer. To distinguish the
> two, different background could be used etc. etc.
An editor isn't supposed to do any of this, these should really be in
a different programs.
If we could embed things (like XEmbed), in curses, it'd be great.
That's what multiple
terminals are for.
> * Should be able to present different views of the sourcecode.
> for example you are in a new project like the linux kernel, and you
> would want to get familiarised. Simple tools like static callgraphs
> would be very powerful helpers. Once all the files in memory and with
> efficient algorithms such "views" could be generated under one second.
Again, not strictly an editor feature. Static call graphs can be generated
by an external program and from that images or documents can be viewed
with the editor.
> * It would have a fast internal ctags like browser.
Unless your code is all bunched in one huge file, you know what you're
looking for.
Just use a search function? Or call ctags and filter the output to a terminal,
say if you wanted a function list.
> * It would be able to do jobs like source code parsing for tag in the
> background in a sort of "fiber" model. User interaction would
> interrupt the task if any is running in the background. No threads, as
> threads make buffer modelling difficult.
Call a separate program to do this (ctags), rather than reinvent.
> * Should have a vim compatibility engine, that would allow reuse of
> hundreds of scripts and syntax files.
A scripting feature, maybe, but why follow vim? What about something like
Lua, or even shell scripts (and thus any scripting language)?
> * Would allow use of simple markups that would speed up writing
> documentation etc.
External program to generate markup, so you could write javadoc-esque
comments, and get this external program to create your man pages
or whatever. Not an editor feature.
> * the buffer modelling is the most important thing. Let's suppose that
> for the moment I have a huge 400 MB file (yes to edit!! :) ). If you
> do not want to open for editing you might have a giant log file for
> analysis. Vim opens it slowly as it breaks into pieces delimited by
> newline. When opening a file it is not necessary to break the buffer
> into pieces. It is however important to memorise the newlines, this is
> important for display and jump to linen-number. Once the text is
> displayed, the editor can start in the background syntax analysis for
> colorising or other heavy tasks, that are not so important for the
> first few seconds of viewing/editing, but at least does not give the
> impression that "you are again faster than your computer" :)
I'd be interested in how to implement this, perhaps using mmap to read
huge files? Or is this what's done already?
The main feature I'd look for would be to filter text through an
external program
and replace the filtered text with the external program's output.
I believe vim has this with
:range!program
Possibly a visual mode, like vim's would be nice, specifically column-based.
I am a fan of vi key bindings, but just because we are doesn't mean we
stick to it.
We could use /etc/inputrc and whatever else to use the user's
preferred bindings,
and perhaps even have mouse support, similar to what sam/acme use, to keep the
plan9 fanboys happy.
Cheers, Rob.
Received on Fri May 14 2010 - 16:38:52 UTC
This archive was generated by hypermail 2.2.0 : Fri May 14 2010 - 16:48:01 UTC