unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#710: qt-special labels not syntactically recognized?
       [not found] <e27db2a60808110405r308ef3c0ic85f9e21e441a431@mail.gmail.com>
@ 2008-08-13 14:31 ` Alan Mackenzie
  2008-08-13 14:35   ` bug#710: Acknowledgement (qt-special labels not syntactically recognized?) Emacs bug Tracking System
  2008-08-13 21:21   ` bug#715: qt-special labels not syntactically recognized? dejfson
  0 siblings, 2 replies; 3+ messages in thread
From: Alan Mackenzie @ 2008-08-13 14:31 UTC (permalink / raw)
  To: dejfson; +Cc: bug-gnu-emacs

Hi, dejfson!

On Mon, Aug 11, 2008 at 01:05:40PM +0200, dejfson wrote:
> Dear All,

> i've been working for some time on elisp and c++-mode and I have
> noticed one thing. When using `c-show-syntactic-information' against
> QT class header files, the label structures as 'protected slots:' and
> 'signals:' are not recognized correctly.

> I know that these are not C++ standards, however is there any way how
> to include them to the indent-parser to be recognized?

CC Mode does handle the QT constructs like "signals:" and "slots:",
though there could well be bugs in that bit of the code.

> The 'signals:' label is correctly recognized, however
> indentation/coloring is not the same of kind as
> 'public/protected/private:' labels in class declaration.  The combined
> form 'protected slots' is not recognized at all. It is identified as
> 'statement', colored as the other statements.

These things are handled OK in one of CC Mode's test files.

Could you send me some sample C++ code, preferably reduced to just a few
lines, which illustrates all these problems, please.  Please describe
exactly what you get, and also say what you expect, and how that differs
from what you actually get.

Also, most importantly, would you supply information on what versions of
(X)Emacs/CC Mode you're using.  The easiest way to do that is with C-c
C-b, which initialises an email buffer.  Please do this and send me all
the configuration information that this generates.  This will help me
track down the problem and fix it.

> thanks

> d.

-- 
Alan Mackenzie (Nuremberg, Germany).







^ permalink raw reply	[flat|nested] 3+ messages in thread

* bug#710: Acknowledgement (qt-special labels not syntactically  recognized?)
  2008-08-13 14:31 ` bug#710: qt-special labels not syntactically recognized? Alan Mackenzie
@ 2008-08-13 14:35   ` Emacs bug Tracking System
  2008-08-13 21:21   ` bug#715: qt-special labels not syntactically recognized? dejfson
  1 sibling, 0 replies; 3+ messages in thread
From: Emacs bug Tracking System @ 2008-08-13 14:35 UTC (permalink / raw)
  To: bug-gnu-emacs


Thank you for filing a new bug report with Emacs.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Emacs Bugs <bug-gnu-emacs@gnu.org>

If you wish to submit further information on this problem, please
send it to 710@emacsbugs.donarmstrong.com, as before.

Please do not send mail to don@donarmstrong.com unless you wish
to report a problem with the Bug-tracking system.


-- 
710: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=710
Emacs Bug Tracking System
Contact don@donarmstrong.com with problems




^ permalink raw reply	[flat|nested] 3+ messages in thread

* bug#715: qt-special labels not syntactically recognized?
  2008-08-13 14:31 ` bug#710: qt-special labels not syntactically recognized? Alan Mackenzie
  2008-08-13 14:35   ` bug#710: Acknowledgement (qt-special labels not syntactically recognized?) Emacs bug Tracking System
@ 2008-08-13 21:21   ` dejfson
  1 sibling, 0 replies; 3+ messages in thread
From: dejfson @ 2008-08-13 21:21 UTC (permalink / raw)
  To: bug-gnu-emacs

Hi Alan,
thanks for response. In fact, I made a mistake myself for the problem
of recognition of 'protected slots:' like stuff. The mistake I did is
that I did not notice, that the current emacs mode is pure C instead
of C++ mode. This
came from my setting, after correction it is fine. However there is
still one remaining problem,this is a Q_OBJECT macro, which tells to
qmake of QT that this class derives QObject properties and metacall
system.
So if you have class like this one:

class QMyclass
{
Q_OBJECT
public:
  QMyclass (int a, int b, int c);
  ~QMyclass (void);
protected slots:
  int mystuff (int a);
}

if we look on syntaxe (in C++ mode by issuing C-c C-s), for the
Q_OBJECT line one would expect to get something like
((inclass XXX) (topmost-intro XXX) (cpp-macro)) or something like that
(to my mind Q_OBJECT is a pseudocode which gets translated by uic of
QT - i'm not 100% sure). This is of course discutable, however
Q_OBJECT
is not the only declaration which can be there (another one which
spots in my mind: Q_PROPERTY).

If you check syntax of this 'public:' line, instead of ( (inclass XXX)
(access-label YYYY) ) as you would expect you get (
(topmost-intro-cont XXXX) ). However this is clearly nothing else than
declaration
of access


thanks

d.



---- Some info:
From: David Belohrad <david.belohrad@cern.ch>
To: bug-cc-mode@gnu.org
Subject: CC Mode 5.31.5 (C++/l); as per email
X-Reporter-Void-Vars-Found: auto-fill-mode
--text follows this line--


Emacs  : GNU Emacs 22.2.1 (i686-pc-linux-gnu)
 of 2008-05-31 on sundra
Package: CC Mode 5.31.5 (C++/l)
Buffer Style: gnu
c-emacs-features: (pps-extended-state col-0-paren posix-char-classes
gen-string-delim gen-comment-delim syntax-properties 1-bit)

current state:
==============
(setq
 c-basic-offset 2
 c-comment-only-line-offset '(0 . 0)
 c-indent-comment-alist '((anchored-comment column . 0) (end-block
space . 1) (cpp-end-block space . 2))
 c-indent-comments-syntactically-p nil
 c-block-comment-prefix ""
 c-comment-prefix-regexp '((pike-mode . "//+!?\\|\\**") (awk-mode .
"#+") (other . "//+\\|\\**"))
 c-doc-comment-style '((java-mode . javadoc) (pike-mode . autodoc)
(c-mode . gtkdoc))
 c-cleanup-list '(scope-operator)
 c-hanging-braces-alist '((substatement-open before after)
(arglist-cont-nonempty))
 c-hanging-colons-alist nil
 c-hanging-semi&comma-criteria '(c-semi&comma-inside-parenlist)
 c-backslash-column 48
 c-backslash-max-column 72
 c-special-indent-hook '(c-gnu-impose-minimum)
 c-label-minimum-indentation 1
 c-offsets-alist '((inexpr-class . +)
		   (inexpr-statement . +)
		   (lambda-intro-cont . +)
		   (inlambda . c-lineup-inexpr-block)
		   (template-args-cont c-lineup-template-args +)
		   (incomposition . +)
		   (inmodule . +)
		   (innamespace . +)
		   (inextern-lang . +)
		   (composition-close . 0)
		   (module-close . 0)
		   (namespace-close . 0)
		   (extern-lang-close . 0)
		   (composition-open . 0)
		   (module-open . 0)
		   (namespace-open . 0)
		   (extern-lang-open . 0)
		   (objc-method-call-cont . c-lineup-ObjC-method-call)
		   (objc-method-args-cont . c-lineup-ObjC-method-args)
		   (objc-method-intro . [0])
		   (friend . 0)
		   (cpp-define-intro c-lineup-cpp-define +)
		   (cpp-macro-cont . +)
		   (cpp-macro . [0])
		   (inclass . +)
		   (stream-op . c-lineup-streamop)
		   (arglist-cont-nonempty c-lineup-gcc-asm-reg c-lineup-arglist)
		   (arglist-cont c-lineup-gcc-asm-reg 0)
		   (comment-intro c-lineup-knr-region-comment c-lineup-comment)
		   (catch-clause . 0)
		   (else-clause . 0)
		   (do-while-closure . 0)
		   (access-label . -)
		   (case-label . 0)
		   (substatement . +)
		   (statement-case-intro . +)
		   (statement . 0)
		   (brace-entry-open . 0)
		   (brace-list-entry . 0)
		   (brace-list-intro . +)
		   (brace-list-close . 0)
		   (block-close . 0)
		   (block-open . 0)
		   (inher-cont . c-lineup-multi-inher)
		   (inher-intro . +)
		   (member-init-cont . c-lineup-multi-inher)
		   (member-init-intro . +)
		   (topmost-intro . 0)
		   (knr-argdecl . 0)
		   (func-decl-cont . +)
		   (inline-close . 0)
		   (class-close . 0)
		   (class-open . 0)
		   (defun-block-intro . +)
		   (defun-close . 0)
		   (defun-open . 0)
		   (c . c-lineup-C-comments)
		   (string . c-lineup-dont-change)
		   (topmost-intro-cont first c-lineup-topmost-intro-cont
c-lineup-gnu-DEFUN-intro-cont)
		   (brace-list-open . +)
		   (inline-open . 0)
		   (arglist-close . c-lineup-arglist)
		   (arglist-intro . c-lineup-arglist-intro-after-paren)
		   (statement-cont . +)
		   (statement-case-open . +)
		   (label . 0)
		   (substatement-label . 0)
		   (substatement-open . +)
		   (knr-argdecl-intro . 5)
		   (statement-block-intro . +)
		   )
 c-buffer-is-cc-mode 'c++-mode
 c-tab-always-indent t
 c-syntactic-indentation t
 c-syntactic-indentation-in-macros t
 c-ignore-auto-fill '(string cpp code)
 c-auto-align-backslashes t
 c-backspace-function 'backward-delete-char-untabify
 c-delete-function 'delete-char
 c-electric-pound-behavior nil
 c-default-style '((java-mode . "java") (awk-mode . "awk") (other . "gnu"))
 c-enable-xemacs-performance-kludge-p nil
 c-old-style-variable-behavior nil
 defun-prompt-regexp nil
 tab-width 8
 comment-column 32
 parse-sexp-ignore-comments t
 parse-sexp-lookup-properties t
 auto-fill-function nil
 comment-multi-line t
 comment-start-skip "\\(//+\\|/\\*+\\)\\s *"
 fill-prefix nil
 fill-column 70
 paragraph-start "[ 	]*\\(//+\\|\\**\\)[ 	]*$\\|^\f"
 adaptive-fill-mode t
 adaptive-fill-regexp "[ 	]*\\(//+\\|\\**\\)[ 	]*\\([
	]*\\([-!|#%;>*·•‣⁃◦]+[ 	]*\\)*\\)"
 )


2008/8/13 Alan Mackenzie <acm@muc.de>:
> Hi, dejfson!
>
> On Mon, Aug 11, 2008 at 01:05:40PM +0200, dejfson wrote:
>> Dear All,
>
>> i've been working for some time on elisp and c++-mode and I have
>> noticed one thing. When using `c-show-syntactic-information' against
>> QT class header files, the label structures as 'protected slots:' and
>> 'signals:' are not recognized correctly.
>
>> I know that these are not C++ standards, however is there any way how
>> to include them to the indent-parser to be recognized?
>
> CC Mode does handle the QT constructs like "signals:" and "slots:",
> though there could well be bugs in that bit of the code.
>
>> The 'signals:' label is correctly recognized, however
>> indentation/coloring is not the same of kind as
>> 'public/protected/private:' labels in class declaration.  The combined
>> form 'protected slots' is not recognized at all. It is identified as
>> 'statement', colored as the other statements.
>
> These things are handled OK in one of CC Mode's test files.
>
> Could you send me some sample C++ code, preferably reduced to just a few
> lines, which illustrates all these problems, please.  Please describe
> exactly what you get, and also say what you expect, and how that differs
> from what you actually get.
>
> Also, most importantly, would you supply information on what versions of
> (X)Emacs/CC Mode you're using.  The easiest way to do that is with C-c
> C-b, which initialises an email buffer.  Please do this and send me all
> the configuration information that this generates.  This will help me
> track down the problem and fix it.
>
>> thanks
>
>> d.
>
> --
> Alan Mackenzie (Nuremberg, Germany).
>

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2008-08-13 21:21 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <e27db2a60808110405r308ef3c0ic85f9e21e441a431@mail.gmail.com>
2008-08-13 14:31 ` bug#710: qt-special labels not syntactically recognized? Alan Mackenzie
2008-08-13 14:35   ` bug#710: Acknowledgement (qt-special labels not syntactically recognized?) Emacs bug Tracking System
2008-08-13 21:21   ` bug#715: qt-special labels not syntactically recognized? dejfson

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).