Thank you. I will merge the optlib-based Forth parser first.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3557#issuecomment-1717625885
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #3557 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3557#event-10359642528
You are receiving this because you are subscribed to this thread.
Message ID:
I have evaluated the performance of the .ctags based Forth parser with
https://github.com/universal-ctags/codebase.
```
[yamato@dev64]~/var/codebase% ./codebase ctags --ctags ~/bin/ctags Forth
version: db9fe7e0
features: +wildcards +regex +iconv +debug +option-directory +xpath +json
+interacti
(Please let me know if I asked the same question ago.)
In Universal Ctags, people can write a parser in C language or .ctags language,
which I named optlib.
The code written in optlib is translated into C language with regcomp/regexec
calls while building a ctags executable. The optlib is extre
@techee, thank you.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3510#issuecomment-1571067997
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #3510 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3510#event-9396269668
You are receiving this because you are subscribed to this thread.
Message ID:
Thank you. How about `long` returned from mio_tell and passed to mio_seek? I
will introduce `mio_long` or `mio_off_t`. Is it acceptable?
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3510#issuecomment-1570598082
You are receiving this because you ar
> @masatake AFAICT there is no difference between latest git ctags
> [mio.c](https://github.com/universal-ctags/ctags/blob/master/main/mio.c) and
> latest git Geany
> [mio.c](https://github.com/geany/geany/blob/master/ctags/main/mio.c).
@elextr thank you for responding.
I'm very surprised at t
ctags links modified version of mio.
geany may also link genuine mio.
Why is no trouble reported ever in this area?
Do you use any unique tricks?
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3510
You are receiving this because you are subscribed t
u-ctags now supports R6Class(x) ( and setClass() ).
See https://github.com/universal-ctags/ctags/pull/2671.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/2376#issuecomment-719132970
As far as trying the input directly with u-ctags, it captures all expected tags.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/349#issuecomment-629691440
I'm working this topic in u-ctags side.
With the change I proposed in
https://github.com/universal-ctags/ctags/pull/2543, ctags can capture `foo`
well:
```
$ cat /tmp/foo.c
#define BLEH
struct foo BLEH { int _; };
$ u-ctags --param-CPreProcessor:_expand=1 --fields-C=+{macrodef} --fields=+S -o
As far as my short studying,
```
Hello :: h
```
is incorrect (in meaning of syntax) fortran code.
See http://www.icl.utk.edu/~mgates3/docs/fortran.html#Variable for an example.
For such garbage input, u-ctags emits garbage.
ctags captures i, test1, test2 and h itself If you put the `Hello` in `
I extended Tex parser of u-ctags agressively.
https://github.com/universal-ctags/ctags/pull/2424
Commands in \newcommand are captured.
https://github.com/universal-ctags/ctags/pull/2424/commits/3e2c7ce909cd73f12ada1cf0d59b470f5db6a87c
If you think u-ctags captures more things, please, consider t
@mittelmark, I'm rewriting R parser in token oriented way in the upstream.
https://github.com/universal-ctags/ctags/pull/2452
The support for assignment operators is improved. It includes '->'.
The class supports come later. However, if test cases are given, I would like
to merge your change.
--
@b4n, thank you. I understand the situation. I will add comments to the tlib
test case.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/2227#issuecomment-515929721
Closed #2227.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/2227#event-250711
Thank you for answering.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/2227#issuecomment-514744430
> When there's a mismatch, Geany refuses to start and writes an error message
> including the name of the parser.
Nice. It is the best way.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issu
Oh, I see.
Defining the API is the best. However, it is not easy and cannot be done now.
On the other hand, a new kind is already added to u-ctags source tree.
So I will write a prototype tool for reporting the changes of the API in and
send a pull request to Geany. We can use it as the start
...I think it is nothing about symbol. (the output of nm doesn't help us, e.g.)
We have to solve the issue by designing work-flows.
I would like to explain a situation causing a trouble.
I will receive a pull request from a volunteer extending a parser which adds a
kind to the parser.
If I hav
Sharing parser code between Geany and u-ctags (= making ctags a library) is in
progreass.
(The pull request for sharing was opened by @techee, and I merged them slowly.)
I, a head maintainer of u-ctags, must take care not breaking the interface
between Geany and u-ctags when introducing a chang
> However, libctags is already there.
> @masatake I assume you mean the libctags that Geany builds?
Yes, I mean "libctags in Geany source tree". It already works well, as you
know.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
@elextr,
> If it was a proper library then both Geany and ctags and others should be
> able to use it as a library. There should be no need to import ctags code
> into Geany at all if it was a proper library, just link to the API.
This is ideal but I would like to focus on the interface between
I guess libctags in geany may disable some unwanted features.
It is understandable to me. Some features I have added to u-ctags is so
immature.
u-ctags should provide the way to disable such features at build-time or
run-time.
Could you write a short document about libctags internal?
Based on th
After merging #2132, I think I should stop introducing new code to ctags side.
How about moving libctags code to u-ctags?
If it is in u-ctags side, I can take care not to break the interface.
You can add a test case that represents an expectation of Geany side.
I don't want Geany people to take ti
Allow me to join the discussion.
> The regex engine used by Geany does not match the one used by upstream ctags
How about replacing the regex engine of u-ctags?
https://github.com/universal-ctags/ctags/issues/1861
I'm very surprised that @b4n has rewritten two parsers of u-ctags.
Improving Cobol
@techee, thank you. We can add kind letter remapping feature uctags side.
I'm thinking about adding parameters for specifying remapping to ctagsInit() in
ctags-api.h.
I'll report to Geany team when I get progress about this topic.
--
You are receiving this because you are subscribed to this thre
Closed #2052.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/2052#event-2098970827
@b4n, I don't understand well "internally" means.
I guess Geany uses kind names only after getting tags information from ctags.
ctags may return 'p' or 'f' kind tags. Both are unified to "function" by
calling
ctagsGetKindName.
Am I correct?
--
You are receiving this because you are subscribe
@elextr, thank you for replying.
I would like to know the workflow of geany side.
Consider parser for X is alrady merged. It means X is maintained u-tags side,
and geany imports X from u-ctags. I added a very interesting feature or
performance improvements to X yesterday. You may want
to re-imp
I'm thinking about this issue.
A. copying all parsers that are in geany and not in u-ctags to u-ctags.
B. making geany using u-ctags parsers only if they have enough quality (as
default, see C.)
C. providing the way to override to geany: if geany doesn't want to use a
parser implementation in u-
I have a question about VhdlKinds table in geany/ctags/parsers/vhdl.c.
```
static kindOption VhdlKinds [] = {
...
{ true, 'f', "function", "functions" },
{ true, 'p', "function", "procedure" },
```
Why is 'p' kind named to "function"?
The kind name is already used for 'f'.
33 matches
Mail list logo
