You're insane. Comments follow:
On Fri, May 14, 2010 at 6:01 PM, mobi phil <mobi_AT_mobiphil.com> wrote:
> 1. good tools should have a way to define easily keyboard shortcuts.
Good tools should have good keyboard shortcuts, change them in the
source if you have to.
> 1.1. Preferably good tools should have at least one predefined set of
> shortcuts that is compatible with vim
Why not compatible with any other editor that anyone else use?
> 1.2. would make sense to define a "keyboard mapping library" that
> would define a syntax and rules for writing shortcuts.
No.
> 1.3. vimperator is a firefox plug-in that is very close to this requirements
A plugin for firefox can never be suckless.
> 2. C like scripts could replace in several places slow shell or other scripts.
Why? Do you believe this would make things faster?
> * 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)
Latest ubuntu boots very fast without rewriting everything in C,
because they likely did relevant benchmarking and profiling to find
out where the bottlenecks were, instead of just assuming they were
CPU-cycle-bond.
> 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... )
If you need this, you are doing something wrong, and shouldn't bloat
down irrelevant applications.
> * Should be able to open a full source tree in one "aggregated"
> buffer. This would allow a linear browsing of the code.
Why do you think that a tool made to edit text should also be hacked
to browse source?
> * 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.
In a text EDITOR?
> * 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.
blah blah, obviously no idea about the do-one-thing-and-do-it-well
expression. Sometimes I need to edit graphics for a piece of code so I
think your editor should also implement a sprite-editor!
> * 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.
Insane. What if you need to edit your logfile in gimp? Or in a music
editor? I think gimp could use a log-file analysis tool, since gimp is
really good at colourising stuff. You could also blur out lines that
are not very important, for example.
You don't use a TEXT EDITOR to analyze and filter log files. You use a
combination of tools that are already made for the purpose of
filtering large amounts of computer generated data.
Received on Fri May 14 2010 - 16:40:13 UTC
This archive was generated by hypermail 2.2.0 : Fri May 14 2010 - 16:48:02 UTC