FrozenVoid's (lack of) IDE

http://dis.4chan.org/read/prog/1321439259/23

Reducing typing is a noble goal, but any programmer worth his salt would write a decent .vimrc instead of abusing the cpp.

* All your nifty macros take up half of the code you produce
* These macros need to be lifted from project to project
* You end up producing code that is hard to understand for people who haven't memorized your macros.
* You can't use the macros while hacking *any* OSS

in short: learn to use a decent IDE and all these cpp abuses become obsolete. have a nice day.

>decent IDE
>haven't memorized your macros.
I don't memorize any macros myself, if i need i just read them from the start of file.
What you need is to develop decent memory skills if you can't read a dozen #define's into your brain.
People which ignore #define treating them as useless constant blocks should not use C at all and instead move to simpler languages such as python.

>>2
And this is why nobody will ever use the code you produce.

>>1
Agreed. Vim is the only way.

>You can't use the macros while hacking *any* OSS
What? i can't include void.h? The is some magic barrier which shields the code from my macros?

>>5
Yes. It's called source control and sane maintainers/developers.

>>6
I'm not going to join any OSS project, i'd rather fork it  and make my own version.
 And void.h and similar macro headers will be included in all files at start.
In fact, if i wrote my own OS, void.h will be included at compiler level, and headers like stdio.h will be built around the basic abstractions(typedefs/asm funcs/kernel hooks) from void.h(stdio.h will be not an interface, but real code like void.h, which will be included as desired(in parts of copy-pasted code or as whole #include))

>>7
I won't touch anything that uses kernel hooks exposed in stdio.h

>>8
Suppose you wrote a faster printf(typically some fast decoding of string via a new algo)
but all code uses old printf. You don't change printf as it fairly solid,stable function.
you just hijack its function pointer, hook a custom printf and load the rest of code.
You can test algorithms, modify kernel parts or switch function called to your own.
Its like a OS built from blocks: you can use standard blocks, or replace them with your own.

including your own macros just to work on a project is madness. no one is ever going to accept your patches back into their project if you keep adding void.h... or you want to do maintenance of that code forever? clearly a well configured IDE is the only way.

face it: NOBODY uses your strategy. because your strategy SUCKS. you need to CHANGE your strategy. you need to REFACTOR your cpp macros into vim macros.

but i see the problem here frozenvoid: you have commited to one way and your ego stubbornly won't allow you to change your ways. you're an old hound stuck in your suboptimal ways. it's a sad day when pride overvomes intellect, but i always told you namefaggotry would come back to bite you in the ass...and now look! [i]Terrible![/b]

>>10
[i]Terrible![/b]
This wouldn't have happened if you had included void.h.  Now hang yourself in shame and hope you're reborn as FrozenSon.

vim is shit, Emacs is king

>>11
negative, the reason is that i didn't compose my post in vim.

>>13
Yes, you should make a Vim script that will automatically include void.h in all C files you open.

the solutions would be to write a c preprocessor that would only expand frozen void's macros, as well as properly indent the code. Then the expanded version could be submitted. If frozenvoid was to work on other people's code, or review changes people have made to his expanded code, then he could first unmacroexpand the source code with a c reprocessor that would factor normal code into frozen void's macros.

Jist listen to this ELP masterpiece!
http://www.youtube.com/watch?v=OoJEwKFaOD4

It is about jewish-khazarian God and shabbos goyim demons.

>could first unmacroexpand the source code
I wouldn't need that, but i'll change to my macros anytime there is code change.
The argument is that i'm using a compiler-based solution to a thing you write macros for.
My macros are more versatile, you can't just make a vim macro that computes a dozen defines and writes a final string.
vim macros are inferior to C preprocessor power.

>>17
Do you actually know anything?

>>18
Also to port my code with void.h: copy void.h+main.c which is filled with compact, abstract representations of code
To port my code with vim macros:bloated main.c filled with expanded macros+ make everyone use vim and specific vimrc

>>19
Other people use your code?

>>20
If they didn't they wouldn't complain and create threads about it

>>15
That is an excellent solution, I suggest FV gets to it right away.

>>19
you can't just make a vim macro that computes a dozen defines and writes a final string.
>make everyone use vim and specific vimrc
>vim macros are inferior to C preprocessor power.

meanwhile, i got a macro to "close" the current line:
type fun('der, hit ^RET: automatically inserts ');. *BAM*. also closes [], "", and {}. and it's compatible with my html tag closer.

>>22

but..but..but I wanted:


  fun('der',
      'la');

oooo I am so frustrated!

>>23
note the subtle difference between RET (enter) and ^RET (ctrl-enter).

>>24

well that's nifty.

I'm going to attempt getting something similar in vim with key mapping and regular expression substitutions...I don't think I will be successful.

>meanwhile, i got a macro to "close" the current line:

#define func(x) ;code; <--Closes the current line everytime its used.

>>26
Have fun defining every single function and statement you'll ever use.

>>27
Which i'm already doing in new headers.
there is Inline_Form_Func(x) (which does not close with semicolon) and #define Func(x) ;; (which includes a final semicolon)

not anime