Fully qualified c++ scopes would be a great feature #1547
Comments
|
Could you show small example input C++ file? Don't forget to use triple back quote chars to quote source code (and tags output) like |
|
Ultra speedy your replies! Wow!
The source is from Scintilla editor 3.75
Line 3 "^Accessor::Accessor(" is not fully qualified "Scintilla::^Accessor::Accessor(" is fully qualified 1. Accessor.h *header* 18 |D:\\Accessor.cxx| ???? /^#include "Accessor.h"/ ![-]! 2. Scintilla *using* 21 |D:\\Accessor.cxx| ???? /^using namespace Scintilla;$/ ![-]! 3. Accessor *function* 24 |D:\\Accessor.cxx| class ??Accessor?? /^Accessor::Accessor(IDocument *pAccess_, PropSetSimple *pprops_) : LexAccessor(pAccess_), pprops(/ ![-]!
The function tag follows as a first line after some header tags and a using tag in unsorted mode which is ok with me.
File: Accessor.h
#ifndef ACCESSOR_H#define ACCESSOR_H
#ifdef SCI_NAMESPACE // SCI_NAMESPACE is definednamespace Scintilla {#endif
enum { wsSpace=1, wsTab=2, wsSpaceTab=4, wsInconsistent=8 };
class Accessor;class WordList;class PropSetSimple;
typedef bool (*PFNIsCommentLeader)(Accessor &styler, Sci_Position pos, Sci_Position len);
class Accessor : public LexAccessor {public: // Line 24 PropSetSimple *pprops; Accessor(IDocument *pAccess_, PropSetSimple *pprops_); int GetPropertyInt(const char *, int defaultValue=0) const; int IndentAmount(Sci_Position line, int *flags, PFNIsCommentLeader pfnIsCommentLeader = 0);};
#ifdef SCI_NAMESPACE}#endif
#endif
On Thursday, September 7, 2017 4:32 PM, Masatake YAMATO <notifications@github.com> wrote:
Could you show small example input C++ file?
I don't know C++ well. Real, small and well simplified example drives me.—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
I don't understand what you wrote. The code in your post is difficult to read. Source code quotation with line-folded way killed me.
|
|
No one wants to kill you, guarantied! It's just an old copy / paste issue between editors.
- It has nothing to do with a fully qualified symbol name, that is an entirely different issue.I am not sure as of yet if this will be implemented in my case.I came across the post and think the right way to implement that is the scope and not the symbol name despite.a code editor might request to enter a fully qualified symbol name.
- You use some different settings than I do, so let me play with yours a bit.Your resulting tags are OK considering that the implementation follows a fully qualified symbol name and not the fully qualified scope which again is wrong. So we have the mess.Symbols are members of any part in code. The scope refers to the part where symbols are used and namespaces organize symbols. Think simply of namespace, class and so on. Looking at it this way makes one understand that namespaces are referenced in scopes.Strictly speaking namespaces are not considered symbols.So give me the fully qualified symbol name of a namespace in a namespace,is killing me.
On Thursday, September 7, 2017 8:42 PM, Masatake YAMATO <notifications@github.com> wrote:
I don't understand what you wrote. The code in your post is difficult to read. Source code quotation with line-folded way killed me.// Scintilla source code edit control
/** @file Accessor.h
** Interfaces between Scintilla and lexers.
**/
// Copyright 1998-2010 by Neil Hodgson <neilh@scintilla.org>
// The License.txt file describes the conditions under which this software may be distributed.
#ifndef ACCESSOR_H
#define ACCESSOR_H
#ifdef SCI_NAMESPACE
namespace Scintilla {
#endif
enum { wsSpace=1, wsTab=2, wsSpaceTab=4, wsInconsistent=8 };
class Accessor;
class WordList;
class PropSetSimple;
typedef bool (*PFNIsCommentLeader)(Accessor &styler, Sci_Position pos, Sci_Position len);
class Accessor : public LexAccessor {
public:
PropSetSimple *pprops;
Accessor(IDocument *pAccess_, PropSetSimple *pprops_);
int GetPropertyInt(const char *, int defaultValue=0) const;
int IndentAmount(Sci_Position line, int *flags, PFNIsCommentLeader pfnIsCommentLeader = 0);
};
#ifdef SCI_NAMESPACE
}
#endif
#endif
u-ctags --kinds-C++=+p --language-force=C++ --extras=+q -o - Accessor.h
u-ctags --kinds-C++=+p --language-force=C++ --extras=+q -o - Accessor.h
ACCESSOR_H Accessor.h /^#define ACCESSOR_H$/;" d
Accessor Accessor.h /^ Accessor(IDocument *pAccess_, PropSetSimple *pprops_);$/;" p class:Scintilla::Accessor
Accessor Accessor.h /^class Accessor : public LexAccessor {$/;" c namespace:Scintilla
GetPropertyInt Accessor.h /^ int GetPropertyInt(const char *, int defaultValue=0) const;$/;" p class:Scintilla::Accessor typeref:typename:int
IndentAmount Accessor.h /^ int IndentAmount(Sci_Position line, int *flags, PFNIsCommentLeader pfnIsCommentLeader = 0);$/;" p class:Scintilla::Accessor typeref:typename:int
PFNIsCommentLeader Accessor.h /^typedef bool (*PFNIsCommentLeader)(Accessor &styler, Sci_Position pos, Sci_Position len);$/;" t namespace:Scintilla typeref:typename:bool (*)(Accessor & styler,Sci_Position pos,Sci_Position len)
Scintilla Accessor.h /^namespace Scintilla {$/;" n
Scintilla::Accessor Accessor.h /^class Accessor : public LexAccessor {$/;" c namespace:Scintilla
Scintilla::Accessor::Accessor Accessor.h /^ Accessor(IDocument *pAccess_, PropSetSimple *pprops_);$/;" p class:Scintilla::Accessor
Scintilla::Accessor::GetPropertyInt Accessor.h /^ int GetPropertyInt(const char *, int defaultValue=0) const;$/;" p class:Scintilla::Accessor typeref:typename:int
Scintilla::Accessor::IndentAmount Accessor.h /^ int IndentAmount(Sci_Position line, int *flags, PFNIsCommentLeader pfnIsCommentLeader = 0);$/;" p class:Scintilla::Accessor typeref:typename:int
Scintilla::Accessor::pprops Accessor.h /^ PropSetSimple *pprops;$/;" m class:Scintilla::Accessor typeref:typename:PropSetSimple *
Scintilla::PFNIsCommentLeader Accessor.h /^typedef bool (*PFNIsCommentLeader)(Accessor &styler, Sci_Position pos, Sci_Position len);$/;" t namespace:Scintilla typeref:typename:bool (*)(Accessor & styler,Sci_Position pos,Sci_Position len)
Scintilla::__anon194cc2ce0103 Accessor.h /^enum { wsSpace=1, wsTab=2, wsSpaceTab=4, wsInconsistent=8 };$/;" g namespace:Scintilla
Scintilla::wsInconsistent Accessor.h /^enum { wsSpace=1, wsTab=2, wsSpaceTab=4, wsInconsistent=8 };$/;" e enum:Scintilla::__anon194cc2ce0103
Scintilla::wsSpace Accessor.h /^enum { wsSpace=1, wsTab=2, wsSpaceTab=4, wsInconsistent=8 };$/;" e enum:Scintilla::__anon194cc2ce0103
Scintilla::wsSpaceTab Accessor.h /^enum { wsSpace=1, wsTab=2, wsSpaceTab=4, wsInconsistent=8 };$/;" e enum:Scintilla::__anon194cc2ce0103
Scintilla::wsTab Accessor.h /^enum { wsSpace=1, wsTab=2, wsSpaceTab=4, wsInconsistent=8 };$/;" e enum:Scintilla::__anon194cc2ce0103
__anon194cc2ce0103 Accessor.h /^enum { wsSpace=1, wsTab=2, wsSpaceTab=4, wsInconsistent=8 };$/;" g namespace:Scintilla
pprops Accessor.h /^ PropSetSimple *pprops;$/;" m class:Scintilla::Accessor typeref:typename:PropSetSimple *
wsInconsistent Accessor.h /^enum { wsSpace=1, wsTab=2, wsSpaceTab=4, wsInconsistent=8 };$/;" e enum:Scintilla::__anon194cc2ce0103
wsSpace Accessor.h /^enum { wsSpace=1, wsTab=2, wsSpaceTab=4, wsInconsistent=8 };$/;" e enum:Scintilla::__anon194cc2ce0103
wsSpaceTab Accessor.h /^enum { wsSpace=1, wsTab=2, wsSpaceTab=4, wsInconsistent=8 };$/;" e enum:Scintilla::__anon194cc2ce0103
Scintilla::Accessor::Accessor is recorded well.
If you are talking about scope field, see #1510.—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
... so what I should do? |
|
Thank you Masatake, I will use e-mail editor from now on.
Feature or Bug?Lets work with what we have to avoid major changes and turning existing user code upside down.Since tags can contain fully qualified symbol names the solution is almost there because the scope is a copy of this string without the symbol name meaning cutting the string at the last occurrence of "::". So the symbol name "acb::xyz::Accessor" turns in the scope to "acb::xyz". (acb = namespace, xyz = class, Accessor = function) and leaves the symbol name to "Accessor ".
I suggest for simplicity to add a feature. I leave the choice of feature naming up to you. Perhaps xformat and kinds (arguments) need to be extended in this case.
On Thursday, September 7, 2017 11:21 PM, Masatake YAMATO <notifications@github.com> wrote:
... so what I should do?
I don't understand the direction of this issue. Are you talking about a bug or feature enhancement?
If, yes, an example is needed: input, cmdline and output.
Obviously a better editor is needed.—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
I'm not sure I follow either, because given @masatake example, the scope is fully qualified just as you asked for ( |
|
@b4n, thank you. From the your comment, I can guess the original request a bit. Input: Cmdline: The output: YOUR expected output: Introducing -U optoin for undefining a cpp macro may help to get the expected output. This is nothing to do with scope. This is just about cpreprocessing as @b4n wrote. |
|
#1536 is really beautiful issue. Quite understandable. |
|
ColombanCtags traces namespaces in preproc directives just fine as output shows. SCI_NAMESPACE is in a header file and thus known besides commented as known. Providing the whole source puts Masatake to the afterlife as he explains. We need him a bit longer, he's great! So what you see is narrowed down to the issue.
What's left is that the scope definition is used for symbols and seems to be correct there. Again this is ok for a code editor but wrong as scope definition.The reported scope in tags is a crumbled string of no value as of now.It causes havoc. Copy the code and change one namespace, perhaps even nest them. You are in trouble with an older Ctags resp. no request for fully qualified symbols and certainly in major custom code change. But we can ignore changes in symbols to avoid trouble. A scope is a reference for a code range. Do not go into details and start refering about scopetype. Scopetype can remain as is and perhaps serve as further reference.
The suggested way of feature implementation considered elegant and minimal change of the source for Masatake besides no incompatibilities with existing custom code. Since fully qualified symbols seem to be correct move the scope part of it into scope. All that only on output.2 flags need to be set. Simple?
Masatake, I need a bit more time to verify. I run about 20+ projects in parallel which also are interwoven.
On Friday, September 8, 2017 7:33 PM, Masatake YAMATO <notifications@github.com> wrote:
#1536 is really beautiful issue. Quite understandable.—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
CTags doesn't tracks inclusions, so it can only guess preprocessing branches. I think the new parser might (?) be using the defines it saw in the file and the ones from the options (
I think the problem was that your message is not formatted in a way that shows anything meaningful on GitHub (or in my email for that matter), maybe you could paste it again using GitHub's markup for code. I think that would keep @masatake's heart in check ;)
If the example @masatake and I see doesn't show the issue, it's no real help for understanding what you're searching for :)
What is the problem with scopes like I myself see only one problem with it, which is that I would love to have a way to know which tag is the actual parent (e.g. more precisely than a name that could appear twice), but that's not always 100% possible for all languages (e.g. in C++ implementations it references scopes not declared in that file), and we'd need a new field/technique for that anyway (but that'd probably be a great feature one day: e.g. having a unique identifier for each tag, and using that identifier for knowing which tag is the parent).
Hum, if the fully qualified tag names are OK, what's the problem, doesn't the scope match? AFAIK the C++ parser uses the exact same info for the scope and the qualifying part in FQ tags, so I don't understand where you're going at. Could you provide an example of what you have, and what you'd like? |
|
Masatake, I have narrowed it down. This causes errors. For some function and all parameter, local and some member tags. (my code) Works ok here but is russian roulett.
ACCESSOR_H macro 9 |D:\Accessor.h| ???? /^#define ACCESSOR_H$/ ![-]!
xfmt = "-x --_xformat="%N %z %n |%F| %p ??%s?? %P ![%t]! " "; --extras=+q creates double entries, it's not the way to go.(Scintilla: 21'250 vs. 15'700) I am running automated tagging over multiple projects for: |
|
More requests:
|
|
I wll never read unformatted long list. |
masatake I welcome latest changes in Ctags and am fond of your quick response! Thanks a lot!
Ctags Aug. 22 2017
It is hard to trace xref outputs having a qualified scope only besides it is prone to errors (implementation of example the same function in different namespaces same class name).
Fully qualified: Namespace::class:function........ (this is not implemented)
Qualified: class::function........ (this is implemented in various versions)
The trouble is seen for sorted as well as unsorted tag output. Even in unsorted output I see a function tag before the definition of the class tag. I run a categorized analysis (1. Namespaces, 2.Classes, 3.structures....) and run with a bigger project in trouble.
BTW: Regards to Alaska from nearby Equator.
The text was updated successfully, but these errors were encountered: