For users a tag is <this> so the naming can be confusing.
The only exception where we probably shouldn't use the word symbol is the
"tags file" (*.tags) containing global tags - this has already the "tags"
extension and is more related to ctags and using "symbols file" is a bit
strange in this case.
As a result, the only places where this patch leaves the word "tag" are:
* phrase "tags file(s)"
* phrase "tags parser(s)"
* documentation mentioning the "tags" directory
* documentation mentioning the *.tags extension
and of course where it means the HTML/XML markup <thing>. The rest of the
uses of the word "tag" is replaced with "symbol".
Documentation is updated accordingly.
Fixes#579.
- do not write out scintilla_object_* functions
- remove scioutput file parameter
- do not open output file until after xml parsing to avoid stale files
- fixed simplesect handling
- handle output being a pipe to head or tail
- split doxygen make recipe up
- rename geany_includedir to geany_gtkdocincludedir
- removed all references to geany-scintilla-gtkdoc.h
Also, remove geany-scintilla-gtkdoc.h from .gitignore
This prevents a make-time error later if it can't be imported. lxml is
considered optional so there's no build failure if Python doesn't exist or if
the lxml package can't be imported.
748137bd1dfa648948d9d127aa3e27b6857db764 improved return types, but as
this test case was added in parallel it wasn't updated as needed for
the new, more correct, results.
The script reads the doxygen xml output and generates two headers (optionally
a single header) that contains all of the plugin API in gtk-doc format.
Two headers because it's preferrable to group Scintilla related stuff
into its own namespace. This is a lot easier if g-ir-scanner can
work with a separate header file. If we change minds later on the script is
prepared to generate only one header.
A script will use the xml to generate a gtkdoc'ized header of the plugin API.
The xml files are also installed so that external users can use the xml
that corresponds to the installed version of Geany.
For now a separet doxyfile is used because the gtkdoc'ized header needs
a few types to be documented which not desired to be documented generally.
We only perform search based on variable name so if a variable is e.g. of
the type std::Foo, we can drop the std:: prefix and search only for the
Foo type.
This is far from perfect and contains a lot of guessing. It showed
good results based on our tests cases, fixing several issues and not
introducing any more issues (admittedly, after working around a subtle
one regarding D static ifs).
Closes#845.
Also, don't perform subtractions to check pointer bounds, to avoid
unsigned value wraparound. This is very unlikely as it would either
mean a very large `nth` value or a very small value for the current
line pointer, but better safe than sorry.
See http://en.cppreference.com/w/cpp/language/string_literalCloses#877.
---
This contains a pretty ugly hack to fetch the previous character, in
order not to get fooled by string concatenation hidden behind a macro,
like in `FOUR"five"`, which is not a raw string literal but simply the
identifier `FOUR` followed by the string `"five"`.
While this may sound uncommon, it is not and lead to complaints [2][3]
when Scintilla [1] broke this when they introduced C++11 raw string
literal support themselves.
The implementation here still contains a bug with line continuations: a
raw literal of the form:
```c
const char *str = R\
"xxx(...)xxx";
```
is not properly recognized as such, although it's perfectly valid (yet
probably very uncommon). For the record, Scintilla has also suffers
from this but nobody complained about it yet.
[1] http://scintilla.org/
[2] https://sourceforge.net/p/scintilla/bugs/1207/
[3] https://sourceforge.net/p/scintilla/bugs/1454/
