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