Hello,
as I am already here, and time is short in life, I would like to share
with the community a few suckless.org compatible ideas:
1. good tools should have a way to define easily keyboard shortcuts.
1.1. Preferably good tools should have at least one predefined set of
shortcuts that is compatible with vim
1.2. would make sense to define a "keyboard mapping library" that
would define a syntax and rules for writing shortcuts.
1.3. vimperator is a firefox plug-in that is very close to this requirements
2. C like scripts could replace in several places slow shell or other scripts.
* tcc is a tool that should one day become part of suckless.org
* stali could experiment with an init replacement that would have
scripts written in C and "run" by tcc, and compiled when changed. It
should implement simple makefile like rules, thus running them in
parallel would speed-up boot times. (I know that latest ubuntu now
boots really fast)
3. I am looking for people who would be interested in writing a vim
clone. I already called it viq (vi quick)
Pankace told me that there would be already one experiment here on
suckless.org, but I did not find it. Viq should:
* Open huge files (4gb) on the fly (yes I need that often, and I can
tell you some hints, and you would start to use that as well... )
* 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.
* 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.
* It would have a fast internal ctags like browser.
* 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.
* Should have a vim compatibility engine, that would allow reuse of
hundreds of scripts and syntax files.
* Would allow use of simple markups that would speed up writing
documentation etc.
* 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" :)
rgrds,
mobi phil
being mobile, but including technology
http://mobiphil.com
Received on Fri May 14 2010 - 16:01:54 UTC
This archive was generated by hypermail 2.2.0 : Fri May 14 2010 - 16:12:02 UTC