http://blog.gmane.org/gmane.emacs.cc-mode.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.emacs.cc-mode.general/6123 <pre>Thank you for your explaination. It is not a big problem, and I can stay with it. ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev </pre> Jun 2013-06-13T09:16:02 http://permalink.gmane.org/gmane.emacs.cc-mode.general/6122 <pre>I often want to define default initializers for my structs but c-mode's macro heuristic misidentifies and incorrectly indents the designated initializer list. Here's what it produces, with the .b line not aligned to the .a: #define BAD_INDENT { \ .a = 1, \ .b = 2, \ } \ Here's what I expect: #define IDEAL_INDENT { \ .a = 1, \ .b = 2, \ } \ c-show-syntactic information shows that .a is being identified as defun-block-intro, while the same spot in the corresponding non-macro designated initializer is identified as brace-list-intro. There's no option but to use macros for this purpose because it's sometimes necessary to use them to initialize static variables. GCC allows compound literals to be used for this, as an extension, but doesn't allow the use of alternatives like const struct variables or a const functions. ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev </pre> Alex Podolsky 2013-06-11T17:49:34 http://permalink.gmane.org/gmane.emacs.cc-mode.general/6121 <pre>Hello, Jun. On Fri, Jun 07, 2013 at 01:44:05PM +0000, Jun wrote: This is indeed the case. ------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j </pre> Alan Mackenzie 2013-06-08T19:08:22 http://permalink.gmane.org/gmane.emacs.cc-mode.general/6120 <pre>Hello, Jun. On Fri, Jun 07, 2013 at 01:44:05PM +0000, Jun wrote: This is indeed the case. That file catches on several heueristics in CC Mode which work well most of the time: Parsing line 2 causes "HI_VOID" to be added to `c-found-types' and thereafter will be treated as a type wherever it is found. However, on line 1, the "*" in "HI_VOID*" disables this recognition. Since L1 is parsed first, it doesn't get recognized as a declaration on the first fontification. Normally, a workaround would be to make a change to L1, which would enable it to pick up `c-found-types' and thus recognize "HI_VOID" as a type. However, when the parsing starts at the beginning of the buffer, as here, `c-found-types' gets erased. This is to help stop `c-found-types' filling up with rubbish. Usually this isn't a problem, since most C files start with comments anyway. Although this is really a bug, it occurs rarely enough in practice to be not really worth trying to fix (which would be difficult). As a workaround, you can reverse the order of the two lines. Sorry I can't be more helpful, here. </pre> Alan Mackenzie 2013-06-08T19:32:07 http://permalink.gmane.org/gmane.emacs.cc-mode.general/6119 <pre>The first line can't be fontified. I'm using emacs 24.3. ----------xxx-------- HI_VOID* SampleStartSnapByMode1(HI_VOID *p); HI_VOID SampleStartSnapByMode1(HI_VOID *p); ----------xxx-------- emacs -Q, open a blank c file, and then paste the above c code. ------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j </pre> Jun 2013-06-07T13:44:05 http://permalink.gmane.org/gmane.emacs.cc-mode.general/6118 <pre>Tags: patch Resubmitting my patch (with correct "Tags: patch" this time) in hope it finally gets merged. --- === modified file 'lisp/ChangeLog' --- lisp/ChangeLog 2012-07-06 07:08:10 +0000 +++ lisp/ChangeLog 2012-07-06 13:48:51 +0000 &lt; at &gt;&lt; at &gt; -1,3 +1,11 &lt; at &gt;&lt; at &gt; +2012-07-06 Toon Claes &lt;toon&lt; at &gt;tonotdo.com&gt; + +* progmodes/cc-fonts.el (gtkdoc-font-lock-keywords): Better gtkdoc +parsing. + +* progmodes/cc-vars.el (c-doc-comment-style): Use gtkdoc as default +for C++. + 2012-07-06 Glenn Morris &lt;rgm&lt; at &gt;gnu.org&gt; * Makefile.in (compile-one-process): Rename from "recompile". === modified file 'lisp/progmodes/cc-fonts.el' --- lisp/progmodes/cc-fonts.el 2012-01-19 07:21:25 +0000 +++ lisp/progmodes/cc-fonts.el 2012-07-06 13:49:00 +0000 &lt; at &gt;&lt; at &gt; -2572,7 +2572,7 &lt; at &gt;&lt; at &gt; (defconst gtkdoc-font-lock-keywords `((,(lambda (limit) - (c-font-lock-doc-comments "/**$" limit + (c-font-lock-doc-comments "/**([^*/].*)?$" limit gtkdoc-font-lock-doc-comments) (c-font-lock-doc-comments "/*&lt; " limit gtkdoc-font-lock-doc-protection) === modified file 'lisp/progmodes/cc-vars.el' --- lisp/progmodes/cc-vars.el 2012-02-11 22:13:29 +0000 +++ lisp/progmodes/cc-vars.el 2012-07-06 13:48:46 +0000 &lt; at &gt;&lt; at &gt; -552,7 +552,8 &lt; at &gt;&lt; at &gt; (defcustom-c-stylevar c-doc-comment-style '((java-mode . javadoc) (pike-mode . autodoc) - (c-mode . gtkdoc)) + (c-mode . gtkdoc) + (c++-mode . gtkdoc)) "*Specifies documentation comment style(s) to recognize. This is primarily used to fontify doc comments and the markup within them, e.g. Javadoc comments. &lt; at &gt;&lt; at &gt; -562,7 +563,7 &lt; at &gt;&lt; at &gt; javadoc -- Javadoc style for "/** ... */" comments (default in Java mode). autodoc -- Pike autodoc style for "//! ..." comments (default in Pike mode). - gtkdoc -- GtkDoc style for "/** ... **/" comments (default in C mode). + gtkdoc -- GtkDoc style for "/** ... **/" comments (default in C/C++ mode). The value may also be a list of doc comment styles, in which case all of them are recognized simultaneously (presumably with markup cues ------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j </pre> Toon Claes 2013-06-05T08:24:56 http://permalink.gmane.org/gmane.emacs.cc-mode.general/6117 <pre>Bug fixed. </pre> Alan Mackenzie 2013-06-04T16:34:15 http://permalink.gmane.org/gmane.emacs.cc-mode.general/6116 <pre> Seems to work for me. Thanks! </pre> Michael Welsh Duggan 2013-06-02T02:51:53 http://permalink.gmane.org/gmane.emacs.cc-mode.general/6115 <pre> Seems to work for me. Thanks! </pre> Michael Welsh Duggan 2013-06-02T02:51:53 http://permalink.gmane.org/gmane.emacs.cc-mode.general/6114 <pre>Hi, Michael! On Thu, May 30, 2013 at 10:46:20PM -0400, Michael Welsh Duggan wrote: Sorry, I missed this one last year. Yes, sort of. I think the c-in-sws properties are right. What I think is throwing it off is the calculation of a search limit (effectively a buffer narrowing) in `c-guess-basic-syntax'. That limit was erroneously at a random position, but it actually needs to be at a "syntactically neutral" position. I put that limit calculation in as part of a large optimisation for a ~3,500 line macro which was causing scrolling to go very slowly. Taking it out again doesn't seem to slow it down all that badly. So, out it comes! Yes. Thanks for the bug report. Could you try out this patch please. I think it fixes the bug: diff -r ce17d1595c2f cc-engine.el --- a/cc-engine.elTue May 28 15:00:49 2013 +0000 +++ b/cc-engine.elSat Jun 01 13:52:38 2013 +0000 &lt; at &gt;&lt; at &gt; -9396,10 +9396,6 &lt; at &gt;&lt; at &gt; containing-sexp nil))) (setq lim (1+ containing-sexp)))) (setq lim (point-min))) - (when (c-beginning-of-macro) -(goto-char indent-point) -(let ((lim1 (c-determine-limit 2000))) - (setq lim (max lim lim1)))) ;; If we're in a parenthesis list then ',' delimits the ;; "statements" rather than being an operator (with the </pre> Alan Mackenzie 2013-06-01T13:56:09 http://permalink.gmane.org/gmane.emacs.cc-mode.general/6113 <pre> Correction, 22.1. Anyway, "since a long time ago". ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with &lt;2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 </pre> Glenn Morris 2013-05-31T17:46:52 http://permalink.gmane.org/gmane.emacs.cc-mode.general/6112 <pre> PPS, In Emacs, cc-bytecomp-defun seems unecessary since Emacs 21.1. It mainly seems to be used for things like: ;; Silence the compiler. (cc-bytecomp-defun set-keymap-parents) ; XEmacs (if (cc-bytecomp-fboundp 'set-keymap-parents) (set-keymap-parents map c-mode-base-map)) to silence a compilation warning about set-keymap-parents not being known. Since 21.1, the Emacs byte-compiler is smart enough to do that anyway for function calls behind fboundp tests. ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with &lt;2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 </pre> Glenn Morris 2013-05-31T17:39:17 http://permalink.gmane.org/gmane.emacs.cc-mode.general/6111 <pre>I'd like to bump this issue. I looked into it a little, and it looks like several of the macros before the point in question are being marked as c-in-sws, which doesn't seem right to me. The code ends up evaluating `c-beginning-of-macro' in a buffer that is narrowed such that the beginning of the macro that it is trying to find the beginning of is cut off. The resulting indentation problem isn't horrible, but the bug that leads to this problem is subtle enough that it could be causing other problems in similar situations. </pre> Michael Welsh Duggan 2013-05-31T02:46:20 http://permalink.gmane.org/gmane.emacs.cc-mode.general/6110 <pre> I use the appended code for cc-bytecomp.el (plus the standard boilerplate at beginning/end, of course ;-). Note that with that code, I get some extra warnings. The reason is that cc-mode (especially via cc-lang) is initialized in a tortured way, which calls the byte-compiler explicitly. IIRC some of the problem is that if you compile a code like (defvar foo) (eval-when-compile (byte-compile '(lambda (x) (+ x foo)))) the compiler will warn you about an unknown `foo': the defvar does add `foo' to byte-compile-bound-variables, but byte-compile begins by re-binding byte-compile-bound-variables to nil. IIUC cc-bytecomp-defvar tries to address this problem with a major-ugly-hack. I think a lot of the rest is trying to solve similar things. A better solution would be to rethink the way cc-lang works so that cc-mode doesn't need to call byte-compile explicitly. Stefan (defmacro cc-require (cc-part) `(require ,cc-part)) (defmacro cc-provide (feature) `(provide ,feature)) (defmacro cc-load (cc-part) `(load ,cc-part nil t nil)) (defmacro cc-require-when-compile (cc-part) `(require ,cc-part)) (defmacro cc-external-require (feature) `(require ,feature)) (defmacro cc-bytecomp-defvar (var) `(defvar ,var)) (defmacro cc-bytecomp-defun (fun) `(declare-function ,fun unspecified)) (defmacro cc-bytecomp-obsolete-var (symbol) ()) (defmacro cc-bytecomp-obsolete-fun (symbol) ()) (defmacro cc-bytecomp-boundp (symbol) `(boundp ,symbol)) (defmacro cc-bytecomp-fboundp (symbol) `(fboundp ,symbol)) ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with &lt;2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 </pre> Stefan Monnier 2013-05-29T13:14:27 http://permalink.gmane.org/gmane.emacs.cc-mode.general/6109 <pre> PS I'd be happy to make those changes if they are acceptable. ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with &lt;2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 </pre> Glenn Morris 2013-05-29T06:29:13 http://permalink.gmane.org/gmane.emacs.cc-mode.general/6108 <pre>Package: emacs,cc-mode Version: 24.1 cc-bytecomp-obsolete-fun hasn't worked for 2+ years (Emacs 24.1 onwards), since it calls cc-bytecomp-ignore-obsolete, which uses byte-compile-obsolete, which was removed 2011-04-01. Since no-one has complained (and a web-search shows zero apparent users of cc-bytecomp-obsolete-fun), please can it just be removed. IMO most of the rest of cc-bytecomp should also be removed. cc-bytecomp-defun is replaced by the standard `declare-function', which works since Emacs 23.1 (and is defined in 22.2 onwards as a compat stub). cc-bytecomp-defvar is replaced by `(defvar foo)' with no init value. ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with &lt;2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 </pre> Glenn Morris 2013-05-29T01:56:18 http://permalink.gmane.org/gmane.emacs.cc-mode.general/6107 <pre>Hello Alan, I've applied the patch here and can confirm that it indeed fixes the problem! Thank you so much for the amazing support! ------------------------------------------------------------------------------ Try New Relic Now &amp; We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, &amp; servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may</pre> Sezaru 2013-05-26T20:10:34 http://permalink.gmane.org/gmane.emacs.cc-mode.general/6106 <pre>Hi, Sezaru. On Sun, May 12, 2013 at 06:49:32AM +0000, Sezaru wrote: Yes. This problem has existed ever since "#if" was invented, and it's a surprisingly difficult one to fix. CC Mode handles it by simply ignoring the "#if" lines, etc., and thus sees the "test2" line as the coninuation of the "test" line. A proper fix would need selectively to ignore whichever one of the function definitions wasn't currently "in scope" (for some value of "in scope"). I'm afraid I can't envisage this being fixed soon. Sorry. </pre> Alan Mackenzie 2013-05-26T14:12:45 http://permalink.gmane.org/gmane.emacs.cc-mode.general/6105 <pre>Hi, Sezaru. On Wed, May 22, 2013 at 09:08:37PM +0000, Sezaru wrote: Thanks for taking the trouble to report this, and thanks even more for such an accurate description. I think I've tracked this down, it's an ugly (mis)feature in the innards of Emacs's `yank' which messes around with text properties. Would you please try out the following patch, and let me know whether or not it fixes the problem fully. diff -r 10c9ed75910b cc-mode.el --- a/cc-mode.elThu May 02 11:03:15 2013 +0000 +++ b/cc-mode.elSun May 26 13:47:14 2013 +0000 &lt; at &gt;&lt; at &gt; -1100,13 +1100,14 &lt; at &gt;&lt; at &gt; (setq beg end))) ;; C-y is capable of spuriously converting category properties -;; c-&lt;/&gt;-as-paren-syntax into hard syntax-table properties. Remove -;; these when it happens. +;; c-&lt;/&gt;-as-paren-syntax and c-cpp-delimiter into hard syntax-table +;; properties. Remove these when it happens. (when (memq 'category-properties c-emacs-features) (c-clear-char-property-with-value beg end 'syntax-table c-&lt;-as-paren-syntax) (c-clear-char-property-with-value beg end 'syntax-table - c-&gt;-as-paren-syntax)) + c-&gt;-as-paren-syntax) + (c-clear-char-property-with-value beg end 'syntax-table nil)) (c-trim-found-types beg end old-len) ; maybe we don't need all of these. (c-invalidate-sws-region-after beg end) </pre> Alan Mackenzie 2013-05-26T14:00:24 http://permalink.gmane.org/gmane.emacs.cc-mode.general/6104 <pre>This just happened to me in a nightly build: GNU Emacs 24.3.50.1 (x86_64-apple-darwin, NS apple-appkit-1038.36) of 2013-03-20 on bob.porkrind.org I get this error once in a while when editing C or C++ code. This time it happened while reading SICP chapter 5 and scribbling, source attached. Unsure how to debug it. Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p (2193 . 2446)) c-looking-at-inexpr-block((2193 . 2446) (2193 . 2446)) c-inside-bracelist-p(2466 ((2193 . 2446) 2466 (1759 . 1803) (2193 . 2446) 2466 (1759 . 1803) (2193 . 2446) 2466 (1759 . 1803) (2193 . 2446) 2466 (1759 . 1803) (2193 . 2446) 2466 (1759 . 1803) (2193 . 2446) 2466 (1759 . 1803) (2193 . 2446) 2466 (1759 . 1803) (2193 . 2446) 2466 (1759 . 1803) (2193 . 2446) 2466 (1759 . 1803) (2193 . 2446) 2466 (1759 . 1803) (2193 . 2446) 2466 (1759 . 1803) (2193 . 2446) 2466 (1759 . 1803) (2193 . 2446) 2466 (1759 . 1803) (2193 . 2446))) c-guess-basic-syntax() #[(&amp;optional syntax quiet ignore-point-pos) "\212\306\210`Sf)\307=\306\211\f\204C------------------------------------------------------------------------------ Try New Relic Now &amp; We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, &amp; servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may</pre> Kristoffer Grönlund 2013-05-23T04:34:53 http://permalink.gmane.org/gmane.emacs.cc-mode.general/6103 <pre>cc-mode sometimes loose the indentation when working with c++ header files, there is another thread with some similar problem here but the workaround shown there does not work and it was said that in emacs-24.3 it was fixed, which is the version I'm using and it still have the problem, so I decided to create a new thread as it look like a diferent issue is causing the problem. I've tested this problem in my gentoo emacs 24.3 build and in a vanilla one download from the official website. The bug persists in both even when using the built-in cc-mode or the lastest direct from the repositories. It also persistis when using -q option, so it is not another mode conflicting with cc-mode. I've made a little example to reproduce the problem: #ifndef TEST_H_ #define TEST_H_ class Test { public: Test(void); Foo(void); Bar(void); }; #endif // TEST_H_ Save this code as test.hpp, now open it, and there will be 3 empty lines between #define TEST_H and class Test, in the second empty line paste this: #include &lt;iostream&gt; Now the indentation will fail and every line you try to indentate will not. Beware that you need to paste the #include &lt;iostream&gt; in the code and not simply write it, if you write character by character the indentation will still works as it should, it only breaks when you paste it (or at least it was the only way I've found to reproduce it) Thanks! ------------------------------------------------------------------------------ Try New Relic Now &amp; We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, &amp; servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may</pre> Sezaru 2013-05-22T21:08:37 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.emacs.cc-mode.general