> OK, I would have expected something like this indeed. The only possibly
> worrysome part would be not missing any location that has to be updated, in
> case tag names get used some other places in the future.
Exactly, that was my worry too. The patch seems to work for our parsers but one
> The patch is not something too horrible, something like 80LOCs, but not some
> trivial one-liner so better to post it separaterly. Basically it just simply
> goes through the tags and renames the anonymous ones the way we need but in
> addition, we also have to update scopes where these tags
@eht16 yay, thanks! I just committed your fix slightly modified to improve
overall ordering of the checks, but it should have the same result.
@eht16 however, did the bundled regex got used, or did your MSYS have
`regcomp()`? Same question for `fnmathc()`. If MSYS has it, it's less
relevant
> Depending on what the patch you're talking about involves, would you think
> upstream would accept a mean of selecting which method is used? It actually
> could make sense to use their hash version when generating tag files so
> there's no (likely) duplicates, but use plain numbers when
@b4n pushed 1 commit.
c5303c9499bb6f0d632e0ca5b42e15f84d64ac52 Check for asprintf and tempnam and
cleanup function checks
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Tested on Windows:
https://download.geany.org/snapshots/geany-1.38_setup-pr2666.exe
I got:
```
/bin/sh ../libtool --silent --tag=CC --mode=compile ccache gcc
-DHAVE_CONFIG_H -I. -I.. -I./main -I./parsers
-DEXTERNAL_PARSER_LIST_FILE=\"../src/tagmanager/tm_parsers.h\"
Here's a little test setup to formalize the use-case:
```
mkdir r1
cd r1
git init
echo "f1" >> f1
git add f1
git commit -a -m "added f1"
git config user.name testuser
git config user.email testuser@
git commit -a -m "added f1"
git worktree add ../w1 -b work1
echo "f1:r1" >> f1
git status
cd
> > @b4n I had a brief look at the regex patches and they look good to me
> > (haven't tried them though) - should I add them to this pull request?
>
> If you're OK with them, yes, please.
Actually I can do it myself, and as you seemed to approve I just did.
--
You are receiving this because
@b4n pushed 2 commits.
33fc269ea8d4d03453489ca55a9ca208ec15aae2 Add GNU regex bundle from upstream
ctags and use it if missing
b1c9096394c9819342747f1215274af469a19483 Add bundled fnmatch from upstream
ctags
--
You are receiving this because you are subscribed to this thread.
View it on
@eht16 or @codebrainz could you try a Windows build to see if that works
reasonably well? The Travis build is OK with my changes mentioned above, but I
didn't actually test it, so although I'm fairly optimistic it'll work just as
well as upstream CTags do, I can't be sure.
--
You are
> @b4n I had a brief look at the regex patches and they look good to me
> (haven't tried them though) - should I add them to this pull request?
If you're OK with them, yes, please.
> > ...we have a very minimal patch that would hopefully disappear one day...
>
> I actually have a patch
@b4n I had a brief look at the regex patches and they look good to me (haven't
tried them though) - should I add them to this pull request?
> ...we have a very minimal patch that would hopefully disappear one day...
I actually have a patch modifying our tag manager to achieve that - it's not
@kugel- I'm not familiar with subtrees, yet they look tempting. However, here
we only use a subset of upstream, so how would we only get what we want? If
deleting/renaming is messy, I would expect this to be a huge pain if we have
the whole of upstream. And if we only copy a subset of
@techee So for the moment I suggest to bundle GNU regex and fnmatch just the
same as upstream ctags does, so we at least have something that build, and
should hopefully behave the same as upstream. Here is what I got (that build
happily, yet I can't test as we don't run the cross builds):
You probably opened it and saved it once before, and its saved in the user
config so as to not modify the system files.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
according to https://dlang.org/spec/lex.html#string_postfix, it seems to be a
builtin alias.
huh, that's odd... when i open filetypes.d via the tools menu, it seems to only
have the line `[build-menu]` in it ? is there a different filetypes.d i should
be changing somewhere?
--
You are
16 matches
Mail list logo
