[dev] Re: you mentioned a widget library
Hello all,
I am really happy to find this community, pancake suggested me to have
a visit, and it is really worth...
As I was looking for a simple widget implementation, accidentally it
happened the pancake was working on sthg. like that..
Please allow me a few commenst about swk:
I find the markup for widgets cool, should go from test into the library...
about the markup:
1. grouping of widgets should be possible, I think the '{' would be
much more useful for that than for the title of the window (we have
limited characters, isn't it?)
2. newline inside text of widgets would be not a bad idea...
3. inside ui.c would rename mode with state... reading the markup is a
sort of statemachine... mode is a bit confusing
4. if newline outside a control is used for SWK_BOX_NEWLINE, I would
keep '=' for something else
rgrds,
mobi phil
being mobile, but including technology
http://mobiphil.com
Re: [dev] SDL fullscreen problems in dwm
Its because SDL is resolution dependent(non resizeable). I wrote the Quad-Ren graphics engine, a resolution independent graphics engine to solve this problem. It was designed specifically to work with tiling WM's.
Re: [dev] SDL fullscreen problems in dwm
On 5/14/10, hessi...@hessiess.com wrote: > Its because SDL is resolution dependent(non resizeable). what do you mean by non resizeable?
Re: [dev] SDL fullscreen problems in dwm
> On 5/14/10, hessi...@hessiess.com wrote: >> Its because SDL is resolution dependent(non resizeable). > > what do you mean by non resizeable? > Literally non resizeable, the window cannot be resized.
Re: [dev] SDL fullscreen problems in dwm
On Fri, May 14, 2010 at 04:40:59PM -, hessi...@hessiess.com wrote: > Literally non resizeable, the window cannot be resized. hm, I can open SDL windows that are resizable easily enough, with... "SDL_RESIZABLE" Mate
Re: [dev] SDL fullscreen problems in dwm
> On Fri, May 14, 2010 at 04:40:59PM -, hessi...@hessiess.com wrote: >> Literally non resizeable, the window cannot be resized. > hm, I can open SDL windows that are resizable easily enough, > with... "SDL_RESIZABLE" > > Mate > Sure, but *NO ONE* uses that flag. Go download almost any game made with SDL, its not resizeable.
[dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
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
Re: [dev] SDL fullscreen problems in dwm
>>> Literally non resizeable, the window cannot be resized. >> hm, I can open SDL windows that are resizable easily enough, >> with... "SDL_RESIZABLE" > > Sure, but *NO ONE* uses that flag. Go download almost any game made with > SDL, its not resizeable. > Doesn't that mean that the games are very badly designed? Or do all those games have specially tailored graphics for each single physical display size?
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
> Hello, hi > 3. I am looking for people who would be interested in writing a vim > clone. I already called it viq (vi quick) I'm interested, but some of the ideas you have seem a little too unsuckless (i'll cover what i think in a mo) Keep in mind, I'm not trying to be Uriel, this is constructive criticism. > * 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. An editor isn't supposed to do any of this, these should really be in a different programs. If we could embed things (like XEmbed), in curses, it'd be great. That's what multiple terminals are for. > * 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. Again, not strictly an editor feature. Static call graphs can be generated by an external program and from that images or documents can be viewed with the editor. > * It would have a fast internal ctags like browser. Unless your code is all bunched in one huge file, you know what you're looking for. Just use a search function? Or call ctags and filter the output to a terminal, say if you wanted a function list. > * 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. Call a separate program to do this (ctags), rather than reinvent. > * Should have a vim compatibility engine, that would allow reuse of > hundreds of scripts and syntax files. A scripting feature, maybe, but why follow vim? What about something like Lua, or even shell scripts (and thus any scripting language)? > * Would allow use of simple markups that would speed up writing > documentation etc. External program to generate markup, so you could write javadoc-esque comments, and get this external program to create your man pages or whatever. Not an editor feature. > * 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" :) I'd be interested in how to implement this, perhaps using mmap to read huge files? Or is this what's done already? The main feature I'd look for would be to filter text through an external program and replace the filtered text with the external program's output. I believe vim has this with :range!program Possibly a visual mode, like vim's would be nice, specifically column-based. I am a fan of vi key bindings, but just because we are doesn't mean we stick to it. We could use /etc/inputrc and whatever else to use the user's preferred bindings, and perhaps even have mouse support, similar to what sam/acme use, to keep the plan9 fanboys happy. Cheers, Rob.
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
You're insane. Comments follow: On Fri, May 14, 2010 at 6:01 PM, mobi phil 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.
Re: [dev] SDL fullscreen problems in dwm
On Fri, 14 May 2010 16:50:53 -
hessi...@hessiess.com wrote:
> > On Fri, May 14, 2010 at 04:40:59PM -, hessi...@hessiess.com wrote:
> >> Literally non resizeable, the window cannot be resized.
> > hm, I can open SDL windows that are resizable easily enough,
> > with... "SDL_RESIZABLE"
> >
> > Mate
> >
>
> Sure, but *NO ONE* uses that flag. Go download almost any game made with
> SDL, its not resizeable.
>
>
[panc...@dazo tmp]$ cat sdldwm.c
/*
* Copyright (C) 2010
* pancake
*
* $ gcc sdldwm.c -shared -ldl -fPIC -o sdldwm.so
* $ LD_PRELOAD=./sdldwm.so programname
*/
#define _GNU_SOURCE
#include
static void *(*svm)(int w, int h, int b, unsigned int f);
static void __() __attribute__ ((constructor));
static void __() { svm = dlsym(RTLD_NEXT, "SDL_SetVideoMode"); }
void *SDL_SetVideoMode(int w, int h, int b, unsigned int f) {
return svm(w,h,b,f|0x10);
}
what about this hack?
Re: [dev] SDL fullscreen problems in dwm
Many of them are using fixed resolution pixmaps, not vectors, so, to avoid scaling or incorrect display they prefer to drop this possibility (ugly btw) On May 14, 2010, at 6:25 PM, Anders Andersson wrote: Literally non resizeable, the window cannot be resized. hm, I can open SDL windows that are resizable easily enough, with... "SDL_RESIZABLE" Sure, but *NO ONE* uses that flag. Go download almost any game made with SDL, its not resizeable. Doesn't that mean that the games are very badly designed? Or do all those games have specially tailored graphics for each single physical display size?
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
On Fri, May 14, 2010 at 06:01:54PM +0200, mobi phil wrote: > 3. I am looking for people who would be interested in writing a vim > clone. I already called it viq (vi quick) So traditional-vi, nvi, vim, elvis, vile, and busybox's vi aren't enough? :) > * 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 Allways comment your code where you need to. No one's gonna stop doing that just for one editor. And code should be readable, which means you wouldn't need a file full of comments. Read chapter 8 of the Kernel Coding Style if you wish. -- Marvin Vek - dprintk(5, KERN_DEBUG "Jotti is een held! "); linux-2.6.6/drivers/media/video/zoran_card.c
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
>> 3. I am looking for people who would be interested in writing a vim >> clone. I already called it viq (vi quick) > I'm interested, but some of the ideas you have seem a little too unsuckless > (i'll cover what i think in a mo) > Keep in mind, I'm not trying to be Uriel, this is constructive criticism. no problem... however keep in mind that what fits for me, does not necessarily fits for you. I tried to convince quite smart people to use tiling window managers... I failed. And the reason was different for different people. What is good for me is not necessarily good for you... It would be completely unsuckless if everybody would have the same taste. >> * 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. > An editor isn't supposed to do any of this, these should really be in > a different programs. it is not supposed to do any of this, because you were always told so, or you might be shocked, that it can be done differently... When you are looking some functions or some patters you use grep, isn't it? Each time you do grep, the file is loaded into memory, you do the next grep again, etc. Having the files aggregated in a buffer is like you would have a filesystem in the memory. You have all the stuff in memory and that is good, as you are supposed to work on huge part of it... The secret is that you would not really have it aggregated in one continuous buffer, but you would have a sort of tree of buffers, but you would have different views of the buffers, and one view is a linear view. > If we could embed things (like XEmbed), in curses, it'd be great. > That's what multiple > terminals are for. yes and no. There are things that make sense to embedd, but in case of an editor you need to have stuff inside the same process. Any data exchange between processes would slow down operations... > >> * 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. > Again, not strictly an editor feature. Static call graphs can be generated > by an external program and from that images or documents can be viewed > with the editor. I called it editor. But as 90% of the editors it would do more than it. We can probably create an endless discussion what an editor means... Are text objects in vim part of an editor? Yes? then why other editors do not have thenm. No? then it means that vim is more than an editor. So just think it as an editor with some "new" features. Did you ever have to deal with gigs of logfiles? You can write tools to create for you some analysis, but like "radare" you need some primitives and you need to have stuff loaded, to apply those primitives... If you had to deal only with 10*100 lines of codes then for sure such features are not for you... Static graphs... What you want is to make continuous changes, and you want instantly to see the changes in other views. Once the stuff is in memory, why would you want that other processes would load the same raw information to generate some derived information? Most of the tools spend time by reading data from disk into memory.. >> * It would have a fast internal ctags like browser. > > Unless your code is all bunched in one huge file, you know what you're > looking for. > Just use a search function? Or call ctags and filter the output to a terminal, > say if you wanted a function list. you would call each time ctags when you made changes? Why don't you want to have stuff up to date? I am vim user, but often miss derived views that eclipse like tool present.. >> * 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. > Call a separate program to do this (ctags), rather than reinvent. why would you stick on "rather than invent" instead of seeing when it is appropiate. As described above, ctags cannot do it's job incrementally. Besides that they are badly integrated into the editor itself. Let me put it like that: Why all these tools on "suckless" should be maintained if there are already existing ones? >> * Should have a vim compatibility
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
> So traditional-vi, nvi, vim, elvis, vile, and busybox's vi aren't > enough? :) you mentioned 5 of them. All do the same, nothing more. None could open a huge logfile for analysis, or none has created me clear control or monitoring points for the buffer. >> * 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 > Allways comment your code where you need to. No one's gonna stop doing > that just for one editor. And code should be readable, which means you > wouldn't need a file full of comments. Read chapter 8 of the Kernel > Coding Style if you wish. Did not mentioned a detail on purpose. You share work with several people, there are comments that you want to share, there are comments that you do not. Can happen that it is not the case with you... > -- > Marvin Vek > - > dprintk(5, KERN_DEBUG "Jotti is een held! > "); > linux-2.6.6/drivers/media/video/zoran_card.c > > -- rgrds, mobi phil being mobile, but including technology http://mobiphil.com
Re: [dev] SDL fullscreen problems in dwm
On Fri, May 14, 2010 at 7:15 PM, pancake wrote: > Many of them are using fixed resolution pixmaps, not vectors, so, to avoid > scaling or incorrect display they prefer to drop this possibility (ugly btw) Yeah, but they could still implement a scrolling view or similar. Making a game for a fixed resolution was ok on the Amiga, possibly as far as VGA. Off-topic anyway.
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
well, > You're insane. Comments follow: thanks for the welcome, I hope you did not mean it.. > On Fri, May 14, 2010 at 6:01 PM, mobi phil 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. I would change it if I would not have to change half of the source for that... But disappointed that you do not agree... >> 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? I said at "least one"... I invite other armies to declare their expectations... >> 1.2. would make sense to define a "keyboard mapping library" that >> would define a syntax and rules for writing shortcuts. > No. Well, that means you love to do exercise mouse keyboard mouse keyboard. >> 1.3. vimperator is a firefox plug-in that is very close to this requirements > A plugin for firefox can never be suckless. Hm... well... >> 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. I am not doing anything wrong. You might be wrong by not asking questions about details ... but replied about the topic in a prev email. >> * 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? Because you can save time by waiting for each tool to load the same stuff into memory etc. etc. I think you would have difficulties to imagine the added value of tiling window manager, before ever having have used it. The same with this... Please do not be so rigid.. >> * 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! I think you should stick to your notepad on windows, even better, buy ZX spectrum, and install your Spartan like tools on it. I think you make me a clear image about suckles, and you have a well formed welcoming style. I think you dropped too many decorations... -- rgrds, mobi phil being mobile, but including technology http://mobiphil.com
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
On Fri, May 14, 2010 at 07:47:32PM +0200, mobi phil wrote:
> I think you should stick to your notepad on windows, even better, buy
> ZX spectrum, and install your Spartan like tools on it. I think you
> make me a clear image about suckles, and you have a well formed
> welcoming style. I think you dropped too many decorations...
Mobi - Go
That ZX Spectrum would actually be awesome.
--
Marvin Vek
-
printk("; corrupted filesystem mounted read/write - your computer
will explode within 20 seconds ... but you wanted it so!
");
linux-2.4.3/fs/hpfs/super.c
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
> That ZX Spectrum would actually be awesome. > > -- > Marvin Vek My C64 beats the crap out of any lame Spectrum any day.
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
>> That ZX Spectrum would actually be awesome. >> >> -- >> Marvin Vek > > My C64 beats the crap out of any lame Spectrum any day. Did you install ms notepad on it? -- rgrds, mobi phil being mobile, but including technology http://mobiphil.com
Re: [dev] SDL fullscreen problems in dwm
On 14/05/10 18:02, pancake wrote:
>
> [panc...@dazo tmp]$ cat sdldwm.c
> /*
> * Copyright (C) 2010
> * pancake
> *
> * $ gcc sdldwm.c -shared -ldl -fPIC -o sdldwm.so
> * $ LD_PRELOAD=./sdldwm.so programname
> */
> #define _GNU_SOURCE
> #include
>
> static void *(*svm)(int w, int h, int b, unsigned int f);
> static void __() __attribute__ ((constructor));
> static void __() { svm = dlsym(RTLD_NEXT, "SDL_SetVideoMode"); }
>
> void *SDL_SetVideoMode(int w, int h, int b, unsigned int f) {
> return svm(w,h,b,f|0x10);
> }
>
> what about this hack?
>
I think you will find that this would just stop the app working; when
the SDL_RESIZABLE flag is set the app has to react to SDL_VIDEORESIZE
events from SDL by re-calling SDL_SetVideoMode with the size in the
SDL_VIDEORESIZE event. If the app isn't set up to do this then things
will go wrong...
--
Thomas Spurden
Re: [dev] SDL fullscreen problems in dwm
Well .. It is possible to hackaround the event handler to manage this
event. But surely will depend on app.. So.. Crappy
On May 14, 2010, at 8:10 PM, Thomas Spurden
wrote:
On 14/05/10 18:02, pancake wrote:
[panc...@dazo tmp]$ cat sdldwm.c
/*
* Copyright (C) 2010
* pancake
*
* $ gcc sdldwm.c -shared -ldl -fPIC -o sdldwm.so
* $ LD_PRELOAD=./sdldwm.so programname
*/
#define _GNU_SOURCE
#include
static void *(*svm)(int w, int h, int b, unsigned int f);
static void __() __attribute__ ((constructor));
static void __() { svm = dlsym(RTLD_NEXT, "SDL_SetVideoMode"); }
void *SDL_SetVideoMode(int w, int h, int b, unsigned int f) {
return svm(w,h,b,f|0x10);
}
what about this hack?
I think you will find that this would just stop the app working; when
the SDL_RESIZABLE flag is set the app has to react to SDL_VIDEORESIZE
events from SDL by re-calling SDL_SetVideoMode with the size in the
SDL_VIDEORESIZE event. If the app isn't set up to do this then things
will go wrong...
--
Thomas Spurden
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
every programmer should write their own editor. whether they share it with the world or not is unimportant. i don't understand why this isn't some unspoken rule of programmer culture, like a right of passage. (every programmer should create their own programming language too, but i digress) my editor's name is max. you can probably guess the etymology.
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
Yes another sucking bloated program. On Fri, May 14, 2010 at 07:21:18PM +0200, mobi phil wrote: > When you are looking some functions or some patters you use grep, > isn't it? Each time you do grep, the file is loaded into memory, you > do the next grep again, etc. No. It's piped into grep. Pipes are cheap. > There are things that make sense to embedd, but in case of an editor > you need to have stuff inside the same process. Any data exchange > between processes would slow down operations... Do you really feel that latency? Don't you feel accretive complexity? > >> * It would have a fast internal ctags like browser. > > > > Unless your code is all bunched in one huge file, you know what you're > > looking for. > > Just use a search function? Or call ctags and filter the output to a > > terminal, > > say if you wanted a function list. > > you would call each time ctags when you made changes? Why don't you > want to have stuff up to date? Because my working environment remains simple and controllable. Bind a keystroke to update tags. Don't you complain that your web browser does not reload a page automatically every 5 seconds so you have to do it manually? > I am vim user, but often miss derived > views that eclipse like tool present.. I piss on all those "modern IDEs" that consider themselves to be smarter than me. > If the design is good, you could easilly inject any kind of > scripting language to command the core. Yeah, it's easy. Keeping simple is hard. > Imagine if you would break a compiler into pieces, one that would read > the buffer, the other would tokenize, the 3rd would do syntactical > analisys etc.. and you would pipe them.. The first one is cat? )))
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
On 5/14/10, mobi phil wrote: > Hello, Hi > 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: 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. > 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. > 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 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 should be rethrown as 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?). > 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 :) > 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. > 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. > 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. 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". 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 :( -- kv, - Bjartur
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
> Yes another sucking bloated program. I hope you did not suck your vodka already.. I think you are so fixed on this suck, that you fail to see the forest from the trees. > On Fri, May 14, 2010 at 07:21:18PM +0200, mobi phil wrote: >> When you are looking some functions or some patters you use grep, >> isn't it? Each time you do grep, the file is loaded into memory, you >> do the next grep again, etc. > > No. It's piped into grep. Pipes are cheap. and why would you be obsessed so much about pipes. Do the form of pipes create you some special mental state? Why would you call it bloat calling a function from grep and you do not call bloat when you do pipe? You do pipe or you call a function it is part of the same computer, it uses the same memory, the same processor. Pipe suck more than calling a function! You are trying to defend those badly written blackboxes, that had zero reusability in mind? Why did you never try to call a function in grep? Because everybody was obsessed about pipes. Nobody could see the forest from the tree! >> There are things that make sense to embedd, but in case of an editor >> you need to have stuff inside the same process. Any data exchange >> between processes would slow down operations... > Do you really feel that latency? Don't you feel accretive complexity? If you > have to pipe 100 bytes for sure not. But processing 400MB of data through > pipes: YES try it. >> >> * It would have a fast internal ctags like browser. >> > >> > Unless your code is all bunched in one huge file, you know what you're >> > looking for. >> > Just use a search function? Or call ctags and filter the output to a >> > terminal, >> > say if you wanted a function list. >> you would call each time ctags when you made changes? Why don't you >> want to have stuff up to date? yes! what is your problem with that? maybe your imagination is limited? Or you like to keep yourself busy with useless details? Did not say to run ctags on the full raw data, but on parts that have changed! > Because my working environment remains simple and controllable. Bind a > keystroke to update tags. Don't you complain that your web browser does > not reload a page automatically every 5 seconds so you have to do it > manually? I would complain if it would be the case. Websites that need to do that they do. I hate google, but gmail is a web application, and does reload of WHAT IS NECESSARY. So I do not have to do reload. If I would have to do reload in gmail, I would move to the next... The simplest way to keep your working environment simple is not to start your computer. I hate bloat probably more than you, but this does not mean that I am open for NEW. >> I am vim user, but often miss derived >> views that eclipse like tool present.. > I piss on all those "modern IDEs" that consider themselves to be smarter > than me. you see... instead of thinking, you express your frustration or your bad experience with any employer who wanted to force you to use modern IDEs. If I would love those IDE's, I would move there and basta. But I want to use the minimal what they offer... as idea... >> If the design is good, you could easilly inject any kind of >> scripting language to command the core. > Yeah, it's easy. Keeping simple is hard. Well, how many time do you preach this sentence one day? Why do you think that other people would be so idiot, that would not know such an obvious think? >> Imagine if you would break a compiler into pieces, one that would read >> the buffer, the other would tokenize, the 3rd would do syntactical >> analisys etc.. and you would pipe them.. > The first one is cat? ))) Did you ever compile a project with more than 10 lines of code? rgrds, mobi phil being mobile, but including technology http://mobiphil.com
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 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 should be rethrown as > 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 s
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
2010/5/14 mobi phil : > Can it open 400MB of source code in under 1 second? Óðinn above, you are doing something very wrong if you have source files that are 400MB. Chop up your files into smaller pieces; you mentioned log files earlier, you can have: pizza.log.1, pizza.log.2, pizza.log.3 … And why do you need to edit these aforementioned 4GB log files anyways? Can't you use grep to find the appropriate lines, and if you need to go back and tweak, just use something simple like ed or sed? Why do you require a whole new bloated text editor? -- Samuel Baldwin - logik.li
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
> Óðinn above, you are doing something very wrong if you have source > files that are 400MB. Chop up your files into smaller pieces; you > mentioned log files earlier, you can have: pizza.log.1, pizza.log.2, > pizza.log.3 … And why do you need to edit these aforementioned 4GB log > files anyways? Can't you use grep to find the appropriate lines, and > if you need to go back and tweak, just use something simple like ed or > sed? Why do you require a whole new bloated text editor? well, do it like that... by time you will understand that there are faster ways to do things... keep yourself busy with simple tools. When you go shoping you split up your shopings into 10 bags, you bring bag 1 home, then back to the shop etc. etc.? If I have to do 100 operations on a 4GB file, why would I keep myself busy to split it up into pieces you mention, load each time piece1 realise that it is in piece 2 etc. etc. You are suggesting me to do so, because you might have done it like this. You did your job... But this does not mean that there are better ways to do it... But the same ... -- rgrds, mobi phil being mobile, but including technology http://mobiphil.com
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
too much text, not enough time :P
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
Btw, for me notepad is one of the greatest windows apps ever built. This is a really stupid thread! But good to know that I'm not the only one wasting my time today. On 5/14/10, hiro <23h...@googlemail.com> wrote: > too much text, not enough time :P >
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
> Btw, for me notepad is one of the greatest windows apps ever built. > This is a really stupid thread! > But good to know that I'm not the only one wasting my time today. why don't you port it to linux? :) -- rgrds, mobi phil being mobile, but including technology http://mobiphil.com
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
Why don't you port cat to windows? On 5/14/10, mobi phil wrote: >> Btw, for me notepad is one of the greatest windows apps ever built. >> This is a really stupid thread! >> But good to know that I'm not the only one wasting my time today. > > why don't you port it to linux? :) > > > > > -- > rgrds, > mobi phil > > being mobile, but including technology > http://mobiphil.com > >
[dev] dev+unsubscribe, I think it is better to avoid the bloat
Well, I had a funny day here, but I think I knocked at the wrong door... By the way. Ion3 is less bloated than any of the wi, wii, wi, wii or drm... Isn't it a bloat or "not suckles" to have the same 3 times? Anders Andersson said "You're insane". Two of them in the same place is too dangerous. I will respect Marvin Vek suggestion "Mobi - Go" good luck, and please be suckless! rgrds, mobi phil being mobile, but including technology http://mobiphil.com
Re: [dev] dev+unsubscribe, I think it is better to avoid the bloat
On Fri, May 14, 2010 at 5:55 PM, mobi phil wrote: > By the way. Ion3 is less bloated than any of the wi, wii, wi, > wii or drm... Isn't it a bloat or "not suckles" to have the same 3 > times? Has anyone really been far even as decided to use even go want to do look more like? -- # Kurt H Maier
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
On Fri, May 14, 2010 at 11:49:41PM +0200, hiro wrote:
> Why don't you port cat to windows?
>
> On 5/14/10, mobi phil wrote:
> >> Btw, for me notepad is one of the greatest windows apps ever built.
> >> This is a really stupid thread!
> >> But good to know that I'm not the only one wasting my time today.
> >
> > why don't you port it to linux? :)
Mobi: http://winehq.org
Hiro: http://gnuwin32.sourceforge.net
--
Marvin Vek
-
printk("IOP: oh my god, they killed the ISM IOP!
");
linux-2.6.19/arch/m68k/mac/iop.c
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
Yeah, I know wine, counterstrike is working perfectly. I just don't
like the *look* of notepad on that thing.
But about gnuwin, thanks for that, these people are working
painstakingly. A market gap I have not thought of yet!
On 5/15/10, Marvin Vek wrote:
> On Fri, May 14, 2010 at 11:49:41PM +0200, hiro wrote:
>> Why don't you port cat to windows?
>>
>> On 5/14/10, mobi phil wrote:
>> >> Btw, for me notepad is one of the greatest windows apps ever built.
>> >> This is a really stupid thread!
>> >> But good to know that I'm not the only one wasting my time today.
>> >
>> > why don't you port it to linux? :)
>
> Mobi: http://winehq.org
> Hiro: http://gnuwin32.sourceforge.net
>
> --
> Marvin Vek
> -
> printk("IOP: oh my god, they killed the ISM IOP!
> ");
> linux-2.6.19/arch/m68k/mac/iop.c
>
>
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
On 5/14/10, mobi phil 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 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 should be rethrown as >> 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 , 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
Re: [dev] dev+unsubscribe, I think it is better to avoid the bloat
«Dawning horror tinged with self-loathing crept slowly over the face of mobi phil as he described his "text editor" and by extension his vision of "suckless" to others during a seemingly innocuous email exchange.» Uriel was *not even* involved. A weird (and incredible) day, indeed.
Re: [dev] dev+unsubscribe, I think it is better to avoid the bloat
That's why I always said "suckless" is stupid. People have too high expectations when they read it!
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
On Fri, May 14, 2010 at 10:53:05PM +0200, mobi phil wrote: > > Yeah, it's easy. Keeping simple is hard. > Well, how many time do you preach this sentence one day? Why do you > think that other people would be so idiot, that would not know such an > obvious think? Sorry but you look like an idiot.
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
>> > Yeah, it's easy. Keeping simple is hard. >> Well, how many time do you preach this sentence one day? Why do you >> think that other people would be so idiot, that would not know such an >> obvious think? > > Sorry but you look like an idiot. You're too late, he ragequit.
Re: [dev] dev+unsubscribe, I think it is better to avoid the bloat
On Sat, May 15, 2010 at 12:35:41AM +0200, hiro wrote: > That's why I always said "suckless" is stupid. People have too high > expectations when they read it! It's not plan9 enough!! -- Marvin Vek - /* * We used to try various strange things. Let's not. */ linux-2.2.16/fs/buffer.c
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
On Sat, 15 May 2010 00:04:09 +0100 Rob wrote: > You're too late, he ragequit. He wrote a blog post about how suckless.org scares him, at http://mobiphil.com you could leave the comment there for him. According to the post we made him hate unix.
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
2010/5/14 mobi phil : > well, do it like that... by time you will understand that there are [ … snip … ] > that there are better ways to do it... But the same ... Just run whatever you're doing in a loop? Simple tools are the best, especially when you can chain them together into something necessarily complex. -- Samuel Baldwin - logik.li
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
2010/5/14 Paul Thompson : > He wrote a blog post about how suckless.org scares him, > at http://mobiphil.com you could leave the comment > there for him. According to the post we made him hate unix. That post is truly hilarious. Apparently pointing out flaws in his arguments amounts to dogmatism. I wonder what he calls actual dogmatism? -- Samuel Baldwin - logik.li
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
On Fri, May 14, 2010 at 8:55 PM, Samuel Baldwin wrote: > I wonder what he calls actual dogmatism? I don't think he cares about it until he can serve google adsense with it. -- # Kurt H Maier
Re: [dev] my suckless.org compatible ideas: vim like mapping for any tools, C scripts, vi clone
2010/5/14 Kurt H Maier : > I don't think he cares about it until he can serve google adsense with it. Every day when I wake up I thank Freyja for my ability to block such things in my browser, didn't even notice. Anyways the one idea of his I did like was promoting a suckless interest in tcc or something similar. I definitely think gcc needs to go, although I'm not sure how practical it would be to switch off. I know the OpenBSD people are working on migrating to pcc, and I know the good folks at Plan 9 have their own C compilers, but is there something more suckless than tcc to be used? If it's not readily apparent I don't know too much about C compilers, so feel free to flame. -- Samuel Baldwin - logik.li
