From: Sam S. <sd...@gn...> - 2003-02-15 01:49:23
|
> * In message <m37kc2a0nj.fsf@localhost.localdomain> > * On the subject of "Re: d-mode.el" > * Sent on 14 Feb 2003 15:43:44 -0800 > * Honorable Peter Seibel <pe...@ja...> writes: > > Sam Steingold <sd...@gn...> writes: > > > > /* a > > b > > c */ > > Do you have a strong preference for this comment style? If it were up > to me, I'd write all multi-line comments in the style you show below > for header comments. It's looks nice and tidy and emacs can fill those > comments nicely. Anyway, I've already got a little perl script to do > that conversion for me. /* * foo */ takes 3 lines, while /* foo */ takes just one. I have a __VERY__ strong preference for making an utmost effort to have as much code as possible on each screen. (taking into account that Emacs wraps lines at col 80, so we should also avoid long lines.) > > 3. declarations (utils/ansidecls.c) M-x d-mode-convert-function RET is > > your friend here. Alternatively, you might want to modify > > ansidecl.c to do what d-mode-convert-function does for you. > > What's the key difference between what ansidecls currently does and > how d-mode-convert-function does things? Is it just the formatting? look at a generated C file. e.g., 'less -pmap_sequence sequence.c' d-mode-convert-function indents the code properly. > > 4. preprocessor statements. Right now they are indented to the code, > > e.g,: > > > > #ifdef FOO > > if (foo) > > bar(foo); > > #endif > > > > the above should be converted to > > > > # if FOO > > if (foo) > > bar(foo); > > # endif > > > > (i.e., the indentation should be between "#" and the preprocessor > > directive) > > Why is that? Is it a style thing or am I missing something about the C > pre-processor? From A12. Preprocessing in K&R 2nd. ed. it seems that > preprocessor directives can have leading white space. the reason I mention it is that indentation in Emacs will move all preprocessor directives to the first column, i.e. the current version is not invariant under TAB. > > 5. indentation. CLISP normally does this: > > > > # UP: explanation [what the heck "UP" stand for?! something in German, > > # I guess!] > > global void do_something (int foo); > > global void do_something () > > var in foo; > > { > > ....; > > } > > > > the above should be converted to the one true style (K&R): > > Do you want to use K&R throughout; As I understand it K&R uses BSD > style for functions (as you illustrate) but moves the open brace up > onto the first line of a block construct for inner blocks. I.e.: > > void do_something (int foo) > { > if (some_bool) { > do_extra_thing(); > } > something(); > } yes, this is what I want. rationale: 1. in Emacs, a #\{ in the first column means start of function (and the current d-mode workarounds are expensive), so we better use BSD for functions. 2. as mentioned above, I do not want to waste a line on a #\{ > BTW, what's up with 'global'. I gather it's just a bit of sugar that > expands into nothing. yes, just like `var' is a marker for a variable. I would also like to see "unless" and "elif" go. Another thing is to replace comments "can trigger GC" with a suger keyword that would also expand to nothing (like `GC_unsafe') > > did I scare you enough already? :-) > Nah. good luck! -- Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html> will write code that writes code that writes code for food |