Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone

> As others have pointed out, some of your ideas are not so suckless,
> but I'll respond to the ones I find the most interesting.
nice to hear that..

>> 1. good tools should have a way to define easily keyboard shortcuts.
> True. It's quite irritating that some tools use the arrow keys for scrolling,
> others use hjkl (which doesn't make sense on all keyboards) and one
> has to configure each seperately to use the keybindings you like.
well, you seem to see my point...

>> 1.1. Preferably good tools should have at least one predefined set of
>> shortcuts that is compatible with vimi

> I don't think imitiating vim is a good idea. When in a windowing system
> at least it would be nice if apps grabbed all keys they wanted
> (e.g. text boxes could grab all printing characters) but all other keys would
> bubble up (as I think they already do in X) but if they reach the root window
> they could be rethrown in the original window, but as some other user-defined
> keys. For example if one presses <j> when focused on an image
> inside web page, it would bubble through e.g. xloadimage, surf, tabbed, root
> and then root would look it up and see that <j> should be rethrown as
> <down> which would bubble through xloadimage to surf which would scroll
> down. But I doubt it's possible in X (or does XEmbed allow for this?).

I do not say that imitating vi/vim (or family), is the best. It is
question of taste. I use vim, and I know why it increases
productivity. The most important thing is to keep a constant mindset
when you want to achieve something by pressing keys. I find modes very
important. Lot of tools would benefit from modes. Some of them have
their own very intuitive mappings, but they conflict with what I
learned with vi. I use time to time blender. (Of course this community
would never include sthg. like blender, as it is bloated compared to a
400 bytes of "true" cammand :) ). You can perfectly draw complex
objcets with blender without mouse...

Well, you should be able to switch modes of the entire desktop. Insert
mode of the desktop would be when a certain window has control, etc,
and normal mode of the desktop would be when you create new window,
start application, etc. etc.

>> 1.2. would make sense to define a "keyboard mapping library" that
>> would define a syntax and rules for writing shortcuts.\
> I like my approach better :)
well... you practically say, no approach. What kind of approach can
you have for a tool that does not allow you keymappings? If you can
avoid such application, then lucky you..

>> 1.3. vimperator is a firefox plug-in that is very close to this requirements
> I dislike plug-ins. Stay away from them. Vimperator works in Firefox /only/.
> Going from language-specific libraries to program-specific ones isn't
> an improvement.
I dislike them as well... That is why I am thinking about some sort of
"library" or component, that could make the programmers life easier,
and the same time enforce a sort of "uniform" approach. If vimperator
would be a library, that would have some interfaces that each "client"
app would have to define, I would have used it on other applications
already. Ugy not ugly, vimperator makes my browsing experiment easier,
and I do not have to touch mouse...

>> 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)

> I agree that using sh for programming tasks isn't a good idea, but
> mainly because of sh's handling of whitespace and variables, but I
> agree that compiling stuff running at boot time is probably a good
> idea, unix shells are capable of much parallelism with little effort.
> But how much this speeds things up is unknown. But if reordering files
> on disk improves the boot time of maemo considerably, why not this.
Honestly this is one of the issues I am less "interested". It is an
idea I wanted to discuss with "people with similar interests".
But I am happy to comment your comments. What is happening with such
scripts. It is known that starting new processes is not cheap. (By the
way don't suckless oriented people find elf format a bloat? You write
few asm instructions equivalent of C code and 10KB of elf overhead is
generated????). Therefore you either do not care about how many
processes your script will start, and the resulting script will be
very slow, or you care and you spend lot of time with the care. Once
inside one process, you might achieve the same effect with lib/kernel
calls, but you could do more etc. etc. I know, by reordering files on
disk etc. you can fix 80 percent. You reduce booting time from 1
minute to 10 seconds. But you could have a console in 1 second, ready
to accept your commands... etc.

>> 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.

I am sorry but this is a really cheap and out of fashion sarcasm: "If
you want an O/S, go download Emacs"

> The point of suckless is to use editors instead of IDE (or anything
> with the word "integrated" in it in general) with unnecessuary
> "features".
Why do you want to put lies into my mouth? Did I mention IDE?

> As a rule of thumb, one should be able to rewrite any
> feature in another language. And :range!filter is a basic but powerful
> feature that a editor must have and shall not be underestimated. How
> would you do :0,!cat /dev/tty otherwise? If you need to optimize that,
> shared memory might be the right tool. Doesn't Sam of Plan 9 have a
> command language based on structured-expressions? Seems like a
> powerful and suckless editor. But I can't get it to compile on my
> machine because of conflicting types :(

Can it open 400MB of source code in under 1 second?

-- 
rgrds,
mobi phil
being mobile, but including technology
http://mobiphil.com