kill the timestamps

diff --git a/DESIGN/plugins_vs_scripting.txt b/DESIGN/plugins_vs_scripting.txt
index 91964d55bc8ab6b6bcd41f09e8866feb3b971457..a569240ae03b8ca851e07f6db0b4f7ecde5bf2b0 100644 (file)
--- 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