>> 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.
no problem... however keep in mind that what fits for me, does not
necessarily fits for you. I tried to convince quite smart people to
use tiling window managers... I failed. And the reason was different
for different people. What is good for me is not necessarily good for
you... It would be completely unsuckless if everybody would have the
same taste.
>> * 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.
it is not supposed to do any of this, because you were always told so,
or you might be shocked, that it can be done differently... When you
are looking some functions or some patters you use grep, isn't it?
Each time you do grep, the file is loaded into memory, you do the next
grep again, etc. Having the files aggregated in a buffer is like you
would have a filesystem in the memory. You have all the stuff in
memory and that is good, as you are supposed to work on huge part of
it... The secret is that you would not really have it aggregated in
one continuous buffer, but you would have a sort of tree of buffers,
but you would have different views of the buffers, and one view is a
linear view.
> If we could embed things (like XEmbed), in curses, it'd be great.
> That's what multiple
> terminals are for.
yes and no. There are things that make sense to embedd, but in case of
an editor you need to have stuff inside the same process. Any data
exchange between processes would slow down operations...
>
>> * 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.
I called it editor. But as 90% of the editors it would do more than
it. We can probably create an endless discussion what an editor
means... Are text objects in vim part of an editor? Yes? then why
other editors do not have thenm. No? then it means that vim is more
than an editor.
So just think it as an editor with some "new" features. Did you ever
have to deal with gigs of logfiles? You can write tools to create for
you some analysis, but like "radare" you need some primitives and you
need to have stuff loaded, to apply those primitives... If you had to
deal only with 10*100 lines of codes then for sure such features are
not for you...
Static graphs... What you want is to make continuous changes, and you
want instantly to see the changes in other views. Once the stuff is in
memory, why would you want that other processes would load the same
raw information to generate some derived information? Most of the
tools spend time by reading data from disk into memory..
>> * 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.
you would call each time ctags when you made changes? Why don't you
want to have stuff up to date? I am vim user, but often miss derived
views that eclipse like tool present..
>> * 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.
why would you stick on "rather than invent" instead of seeing when it
is appropiate. As described above, ctags cannot do it's job
incrementally. Besides that they are badly integrated into the editor
itself.
Let me put it like that: Why all these tools on "suckless" should be
maintained if there are already existing ones?
>> * 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)?
Did I say I want to follow vim? No. Did I say that sthg. like Lua
should be excluded? No. Having a compatibility engine, would make a
"transition period" smoother, would attract existing vim users, etc.
etc. If the design is good, you could easilly inject any kind of
scripting language to command the core.
>> * 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.
yes and no. Converting the docs into any other format would make
indeed less sense to have it part of the tools. What would be great is
to have a "what you see is what you... blahblah" viewer, inside the
same tool, that would give you an idea, how the result would look
like.
>> * 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?
No, mmap is probably not the best choice.
> 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
That could be part of the game, but that is appropriate for certain
jobs but not for all of them. Linux pipes and family are great... but
they are not solution for all the problems.
Imagine if you would break a compiler into pieces, one that would read
the buffer, the other would tokenize, the 3rd would do syntactical
analisys etc.. and you would pipe them.. The job would take probably
double time...
> 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.
I like visual mode as well. I would not sacrifice any of the positive
features. The idea is to create some core lego like componenents, and
then you could build it based on taste, etc.
rgrds,
mobi phil
being mobile, but including technology
http://mobiphil.com
Received on Fri May 14 2010 - 17:21:18 UTC
This archive was generated by hypermail 2.2.0 : Fri May 14 2010 - 17:24:02 UTC