Alan W. Irwin writes: > I have changed to the "style" subject line for this since it touches on > three separate recent threads with varying subject lines involving style. > > On 2009-06-30 15:20-0500 Geoffrey Furnish wrote: > > > Oh, one more really last thing. I haven't gotten around to trying out > > Alan's proposal for plplot-mode. > > It seems to me consensus on style has largely been reached, but I remain > deeply concerned that all the thought and time that has gone into this > discussion will be completely wasted unless somebody can come up with at > least one method to make it easy to conform to our agreed-upon style > consensus. > > Changing plplot-mode.el to reflect our style consensus is just one > possibility for that, but my newbie emacs questions on how to use emacs to > control more than just indentation (for example, to place whitespace > around parentheses, break or attach brackets, etc.) have gone unanswered. > It appears to me from describe-mode that parentheses and braces are > specially defined so the answer may be that with the appropriate > modifications to plplot-mode.el, that all new code will automatically > conform to our parentheses and bracket style. I just checked with a bit > of new C code, and it appears those modifications still need to be made. > But I hope this much at least is possible with emacs.
I am overbooked with professional obligations for the next few work days. I expect I'll be able to address some of this in the time frame of end of next week. In very short, and probably inadequate response, my experience with using cc-mode for over a decade, is that I do my own spacing within a line, use C-j for newline, and the indentation happens correctly, and I am happy. The :-character also does some auto redenting. Electric braces just show me where the matching brace is, but I don't have any sort of auto-replacement of braces active in my own cc-mode style. The style you proposed is very very long compared to the one tht Maurice and I have used for years. I took a look through it, and didn't recognize many of the settings. The default cc-mode style, with adjusted c-basic-offset, is very close to how Maurice and I have used to author C and C++ for years. I plan to try to cull that out and exhibit it for consideration as well. But I have to get through an all-consuming activity at work in the next few days first. > However, because of the strong possibility that emacs may not be suitable > for changing the style of our old code, I started looking for other > coding-style tool alternatives, and the first one I found (called astyle) > looks interesting. Please take a look at > http://astyle.sourceforge.net/astyle.html for all the possibilities for > dealing with whitespace, parentheses, and brackets in programme source for > C, C++, and Java. It's a command-line tool with the possibility of using > a style file to control transforming our code base to our style consensus. > Thus, at first look it seems ideal for our needs, and I would appreciate > others here to look at it in more detail to make sure that really is the > case. My only real concern with this, is that no reformatting tool I've ever used has had the result of producing the same thing as what flows naturally from the use of cc-mode. If you use a reformatter (say as part of git commit <wink>), and then find that the tab key (reindent line in [X]Emacs) moves stuff around, it sort of defeats the whole purpose of an editor-based style. So, I'm interested, but I'd like to see that we find a way to converge the in-editor-style with the reformatter-tool-style. I hope that's possible. And, I hope we can get the same or nearly the same assistive style programmed up for vim. I don't know vim myself, but I've been told it has programmable styles too, so I'm optimistic. But the more special casing we put into the style, the harder it will be to duplicate it on a range of tools (vim + [X]Emacs + reformatter(s)). So I think we should continue to do some experimenting and see how close we can come to something that works automatically and consistently. > > Does anyone know why "describe-mode" doesn't seem to have much to say > > about cmake-mode? Skimming the file, you'd think there would be a > > number of functions bound to keys, but apparently not. Seems strange. > > Am I missing something that anyone else has found? > > cmake-mode.el is a work in progress by the CMake team of developers. The > (almost) latest version can be found at cmake-2.6.4/Docs/cmake-mode.el. I > just checked, and that is very different from the equivalent file for > cmake-2.6.0. So if you are trying out an earlier version you should > probably switch to the 2.6.4 version. That said, I just switched from the > 2.6.0 version to 2.6.4, and the describe-mode results appear to be > unchanged. > > I say "almost" above, because my understanding from the CMake mailing list > is there has been a recent burst of activity extending cmake-mode.el in the > form of a patch from an outside person adding some substantial > functionality. The CMake developers apparently like the patch and have > promised to put it into their cvs version and eventually their next release. > > Anyhow, Geoff, if you wanted to grab the 2.6.4 (or cvs) version of > cmake-mode.el and commit it with an adaptation for our indentation needs, > please do so. Okay, I'll check and see which one I got. I did pull it from a cmake release, but I don't remember which one. Again, expect minimal visible activity from me for the next 7 to 10 days. -- Geoff ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
