From fbdd37647b66cb1745ef448e9808a358cc4873f5 Mon Sep 17 00:00:00 2001 From: Dana Jansens Date: Mon, 17 Mar 2003 08:10:26 +0000 Subject: [PATCH] kill the timestamps --- DESIGN/plugins_vs_scripting.txt | 106 ++++++++++++++++---------------- 1 file changed, 53 insertions(+), 53 deletions(-) diff --git a/DESIGN/plugins_vs_scripting.txt b/DESIGN/plugins_vs_scripting.txt index 91964d55..a569240a 100644 --- a/DESIGN/plugins_vs_scripting.txt +++ b/DESIGN/plugins_vs_scripting.txt @@ -1,56 +1,56 @@ So I had a bit of a rant and thought I'd save it... -01:15 * xOr figures python wont last for ob4, but we'll see -01:15 (xOr) since theres only so much you can do -01:15 (xOr) and some added config files/c code can do it all -01:16 (xOr) i mean, realisticly, how many people are going to make .py's -01:16 (xOr) theyre going to ask me for a new feature -01:16 (xOr) they wont write a py -01:16 (xOr) so a clean and smart c kernel with sub modules of C code would - probly be more optimal eventually -01:17 (xOr) scripting was cool for gnus, but i wished i could just set it (mutt) -01:17 (shrimpx) .so's would be cool in the absence of scripting, prolly -01:17 (xOr) yea thats what im meaning -01:17 (xOr) like engines, but for functions -01:18 (xOr) so youd replace bbappconf witha .so that can interact properly -01:18 (xOr) and you dont have to write all this crazy Python/c at all and you - end up with something easier to configure -01:18 (xOr) with less effort -01:20 (@xOr) also less room for pregnancy [strong typing is good] with all C -01:21 (@xOr) and less 'my python script wont load, tteach me python xor' -01:44 (@xOr) what i figure would happen over slow evolution course is.. -01:44 (@xOr) python modules would be converted to python/c inline shit -01:44 (shrimpx) xOr: you know that some wacko is going to embed python in an .so -1:45 (@xOr) shrimpx: and itd probly be better -01:45 (@xOr) shrimpx: cuz it would do less stuff -01:45 (shrimpx) less stuff == less defensive programming against moron - extension programmers -01:45 (@xOr) yea -01:45 (@xOr) and less to try learn to use it -01:46 (@xOr) and less to screw up -01:56 (@xOr) and for instance, if we were to look at emacs, which is the - probably most popular scripted application -01:56 (@xOr) my .emacs is not crazy code -01:56 (@xOr) its some keybindings -01:56 (@xOr) and setting variables -01:57 (shrimpx) yah but 99% of emacs functionality is in lisp -01:57 (@xOr) ya -01:57 (@xOr) but thats not a reason to use it -01:57 (@xOr) or a reason why its good -01:58 (@xOr) thats just the language of implementation -01:58 (shrimpx) even tho it's not .rc -01:58 (@xOr) its good because entensions are written in the same language as - its implementation -01:58 (@xOr) do vim plugins have access to the same amount of internals as - emacs entensions? -01:59 (shrimpx) no -01:59 (@xOr) right -01:59 (@xOr) this i think is why emacs is better than vim -01:59 (@xOr) youcan write a crazy dope cvs.el -01:59 (@xOr) you can write shell.el -01:59 (@xOr) you cant do these with vim -01:59 (@xOr) you can make hackish addons with keybindings -02:00 (@xOr) so if openbox has .so plugins, its equally as good for exteding as - with python extensions -02:00 (@xOr) possibly better because you can access more +* xOr figures python wont last for ob4, but we'll see +(xOr) since theres only so much you can do +(xOr) and some added config files/c code can do it all +(xOr) i mean, realisticly, how many people are going to make .py's +(xOr) theyre going to ask me for a new feature +(xOr) they wont write a py +(xOr) so a clean and smart c kernel with sub modules of C code would + probly be more optimal eventually +(xOr) scripting was cool for gnus, but i wished i could just set it (mutt) +(shrimpx) .so's would be cool in the absence of scripting, prolly +(xOr) yea thats what im meaning +(xOr) like engines, but for functions +(xOr) so youd replace bbappconf witha .so that can interact properly +(xOr) and you dont have to write all this crazy Python/c at all and you + end up with something easier to configure +(xOr) with less effort +(@xOr) also less room for pregnancy [strong typing is good] with all C +(@xOr) and less 'my python script wont load, tteach me python xor' +(@xOr) what i figure would happen over slow evolution course is.. +(@xOr) python modules would be converted to python/c inline shit +(shrimpx) xOr: you know that some wacko is going to embed python in an .so +(@xOr) shrimpx: and itd probly be better +(@xOr) shrimpx: cuz it would do less stuff +(shrimpx) less stuff == less defensive programming against moron + extension programmers +(@xOr) yea +(@xOr) and less to try learn to use it +(@xOr) and less to screw up +(@xOr) and for instance, if we were to look at emacs, which is the + probably most popular scripted application +(@xOr) my .emacs is not crazy code +(@xOr) its some keybindings +(@xOr) and setting variables +(shrimpx) yah but 99% of emacs functionality is in lisp +(@xOr) ya +(@xOr) but thats not a reason to use it +(@xOr) or a reason why its good +(@xOr) thats just the language of implementation +(shrimpx) even tho it's not .rc +(@xOr) its good because entensions are written in the same language as + its implementation +(@xOr) do vim plugins have access to the same amount of internals as + emacs entensions? +(shrimpx) no +(@xOr) right +(@xOr) this i think is why emacs is better than vim +(@xOr) youcan write a crazy dope cvs.el +(@xOr) you can write shell.el +(@xOr) you cant do these with vim +(@xOr) you can make hackish addons with keybindings +(@xOr) so if openbox has .so plugins, its equally as good for exteding as + with python extensions +(@xOr) possibly better because you can access more -- 2.39.2