On 5/14/10, mobi phil <mobi_AT_mobiphil.com> wrote:
>> 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...
Yes, you mention a real problem.
>>> 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...
I thought that you proposed that we create a C library that programs could
link to that would implement a vim-like interface. Thus all apps would get
an uniform interface. That would be a half-assed Apple-like solution modulo
Apple-type "user-friendliness". That would force all apps to use modes --
some apps such as web browsers or image renderers don't necessarily
gain anything from modes. Ok, I shouldn't say this as I'm typing this from
the insert mode of Uzbl (and I don't even have an excuse from using it
for mail).
But that's a hack to use the text editor built into Webkit. But some users
don't like modes, some users don't like the default keybindings so that
all has to be easily configurable by the user. And some apps will only
want to use some of the keybindings. And some keybindings should bubble
while other shouldn't. I think this is best achieved with simple rethrowing.
Modes are less needed where keybindings change depending on focus,
one can though change modes by changing where root looks for keybindings.
If application specific modes are needed, the container application can act
as a rethrower (as all keypresses bubble through it).
> 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.
This is achievable by focusing the root window / window manager and passing
your keystrokes straight to him. My personal preference would be focusing
the root window when I press <Super>, so I can spawn new windows
which then get my focus. You don't need modes as much when you've got
windows and focus.
>>> 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.
If you show me one second, I'll be Really Impressed.
But that depends heavily on SSD, no network, etc. Define "boot" first.
I don't have much knowledge on this subject though.
>>> 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"
You forgot mostly irrelevant.
>> 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?
Sorry, maybe I was dreaming, but I thought I saw some mention of features
integrated into a text editor. That's more than a text editor so I thought the
word IDE was more appropriate. Wrong semantics on my half I guess.
>> 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?
No idea, haven't tested it yet.
Received on Fri May 14 2010 - 22:19:19 UTC
This archive was generated by hypermail 2.2.0 : Fri May 14 2010 - 22:24:03 UTC