ctags-devel — Discussions regarding ctags development

[Ctags-devel] @interface in Java

[Masatake Y. <ya...@re...>]

Hi,

I'm a contributor of universal ctags (a.k.a. fishman-ctags).

I would like to get comments from both java and ctags users about @interface of Java.
(I don't know well about Java.)

Consider following lines as input for ctags --language-force=Java:

    public @interface bug1777340 {
	String n() default "ninjas; monkeys!";
	String m();
    }

Currently bug1777340 is recorded as as i(interface).
I wonder whether I should introduce a new kind a(annotation)
or not for @interface. As far as reading a book about Java,
I sould introduce and prepare the way to distinguish from
normal interface.

Masatake YAMATO

[Ctags-devel] Fwd: [ctags:bugs] #358 Vim parser: Segmentation fault when reaing empty vim file

[David F. <dfi...@gm...>]

Darren,

Any idea why I cannot assign any bugs to myself?
Have my permissions on the project changed?

I still seem my name listed as part of the development team.

Perhaps I just am missing how to assign the issue from this web page.  What
am I supposed to click on to make the assignment.  I used to do this all
the time before, but everything appears to be read only.

http://sourceforge.net/p/ctags/bugs/358



Username: dfishburn

Thanks,
David

---------- Forwarded message ----------
From: Masatake YAMATO <m_y...@us...>
Date: Tue, May 12, 2015 at 1:28 PM
Subject: [ctags:bugs] #358 Vim parser: Segmentation fault when reaing empty
vim file
To: "[ctags:bugs]" <35...@bu...>


David, still you cannot assign the issue to you?
------------------------------

* [bugs:#358] <http://sourceforge.net/p/ctags/bugs/358> Vim parser:
Segmentation fault when reaing empty vim file*

*Status:* open
*Group:*
*Created:* Fri Jun 20, 2014 09:47 AM UTC by Ariya Mizutani
*Last Updated:* Fri Sep 19, 2014 04:44 PM UTC
*Owner:* nobody

This patch solves the problem.

diff --git a/vim.c b/vim.cindex fb971ea..d1285eb 100644--- a/vim.c+++
b/vim.c@@ -717,6 +717,11 @@ static void findVimTags (void)

        line = readVimLine();
+       if (line == NULL)+       {+               return;+       }+
        if ( strncmp ((const char*) line, "UseVimball", (size_t) 10) == 0 )
        {
                parseVimBallFile (line);

------------------------------

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/ctags/bugs/358/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[Ctags-devel] Github collaboration flow

[Vitor A. <vit...@gm...>]

Dear all,

Let me start by apologizing for creating a new thread, but I was not
subscribed to this mailing list before and, as such, can't reply directly
to the original one.

I've been collaborating in the development at Github and I am interested in
having our effort merged into main ctags. I am strongly against the
creation of a fork. Open source initiatives suffer too much from these
splits and I do not want to see this happen also in ctags.

So, let me propose the following flow:

1. Bleeding edge development will/can be done in Github. I feel that we can
take advantage of the fork/pull-request flow to bring in changes, fixes and
updates with much more ease than what is currently possible in Sourceforge.
2. Some (or all) main developers at Github will frequently submit the
changes to Sourceforge, be it through mailing list or by having direct
access to the subversion repository at Sourceforge.
3. Developers at Github synchronize what was submitted at Sourceforge using
git-svn and merge it to guarantee that the differences between the two
trees are always tracked.

IMHO, this will allow everyone to keep their preferred work flow, but still
adding a collaborative alternative development at Github.

If everyone agrees, I would be so bold as to suggest that we start by
sending in the patches for the new verification environment, which will not
break ctags code directly but will benefit the current verification at
Sourceforge. As such, it would be a perfect candidate to test if this flow
would work.

It is just a matter of defining how these patches will be delivered to
Sourceforge.

Thanks for reading,
Vitor

Re: [Ctags-devel] Future of ctags

[Frank F. <ff...@us...>]

Hi Darren,

Let me try to answer your two questions: Why move from SVN to git? And
why move from SF to GitHub?

To try to answer the second one first.

I think others (basically everybody how responded) have given extended
and valid arguments why we think github is better platform at this
moment than SF.

The summary for me is:
- A large and active(!) community is at GitHub nowadays. More new
people have send useful PRs to our repo (and we've merged them) in the
last couple of weeks then there were patches submitted to SF in the
last years.
- GitHub's Pull Requests (PRs) makes it easy for anyone to submit a
patch and for maintainers to discus it and merge it in the repo.
- Travis CI integration. This automatically compiles the code and runs
the units tests after every commit.

The first two really make a huge difference. We are convinced that on
SF we never would have had anything close to this number of
contributers and contributions. Also see the links in my previous mail
why Microsoft open sourced their .NET code on GitHub and not on their
own codeplex.

As I wrote before we would continue to use SF to webhosting, downloads
of releases and the mailing list (although GitHub could fill our needs
on the first two if needed/wanted).

Now about the first problem, SVN or git.
There are many many sites that describe much better then I can ever do
why you would choose git over SVN. But if you don't want to use git,
GitHub has SVN support. I have checkout the repo through SVN (svn co
https://github.com/fishman/ctags) and kept it up to date (svn update)
for a over a week now. It just works. I assume committing is no
problem either. You don't need to say goodbye to SVN if you don't feel
comfortable with git yet.

Have you already looked at the current repo at GitHub? Have you seen
how much work has been done?
The repo has 2328 commits at the moment of writing (based upon the SVN
revision number), while the SVN at SF is at revision 816. A large
portion of that is from the last 12 months, over 55 commits this
February.
All the changes made in the SVN at SF have been integrated in our
repo, so no work is lost.
Various patches that were submitted to SF have been included in the
repo as well. See
https://github.com/fishman/ctags/blob/master/docs/tracking.rst
13 new parsers have been added and many improvements to existing
parsers have been made. A new units testing system has been introduced
and as well as other sophisticated new features. Too much to mention
here. See https://github.com/fishman/ctags/blob/master/docs/news.rst
for more information.
With all the work done, we feel it is time to start to work towards
the release of ctags v6.0

Know that when we move the personal repo we are using right now to an
organization, all the issues and PR linked to the repo are moved as
well, so no history is lost. We would obviously make you co-owner of
that organization.

Regards,
Frank

2015-02-03 6:31 GMT+01:00 Darren Hiebert <dhi...@us...>:
> Hello Frank,
>
> I haven't forgotten you. My main apprehensions have been migrating to Git, and hosting off of SourceForge.
>
> We began using git on a project at work and it has been a ride. While I knew how to use Subversion thoroughly, I do not have such a comfort level with git and don't know how to undo problems that occur. We have had changes wiped out at work that had to be restored when folks would push from their local repository that didn't get fully merged with changes from others. This necessitated the only two guys who know how to get us out of the mess in order to restore the files that got overwritten with older files. Considering how often this has happened, I have some trepidation.
>
> Secondly, I prefer that ctags be hosted on SourceForge. I am uncertain how we can use git to do that, but still host on SourceForge. Can you please explain further to me how that can be done?
>
> Darren
>
>> On Jan 28, 2015, at 10:00 AM, Frank Fesevur <ff...@us...> wrote:
>>
>> Hi Darren,
>>
>> Is there anything we can do to help you? Any questions we can answer?
>> Problems we can solve?
>>
>> If you are still in doubt about git and GitHub, please read these
>> blogposts by the .NET team of Microsoft. MS has integrated git in
>> Visual Studio quite nicely IMHO (Yes, the idea of Linus Torvalds -
>> maybe even code he has written - is used a MS product), they are
>> active contributing to the development of libgit2 and MS is moving at
>> least some of their open source project from their own CodePlex
>> platform to GitHub, simply because that is where the community is.
>> http://blogs.msdn.com/b/dotnet/archive/2014/11/12/net-core-is-open-source.aspx
>> http://blogs.msdn.com/b/vbteam/archive/2015/01/10/we-re-moving-to-github.aspx
>>
>> And see how your project has been revived at GitHub. An active
>> community has grown there. This week an quite detailed issue and a
>> pull request were submitted by two new people. People are finding
>> ctags at github and willing to contribute.
>>
>> And we really want to move forward, together with you! We'll continue
>> to use Sourceforge for the webhosting, the mailing list and probably
>> as the download platform, but move the main code repo and issue
>> tracker to the GitHub organization. Then fix some last known bugs,
>> update the documentation including the man page and prepare for the
>> release of exuberant ctags 6.0
>>
>> Kind regards,
>> Frank
>>
>>
>> 2014-12-19 6:23 GMT+01:00 Darren Hiebert <Da...@da...>:
>>> Frank,
>>>
>>> If I understand you correctly, you are proposing that the source code no longer be hosted at SourceForge, which is what I would prefer. What are the reasons that you believe that SourceForge cannot provide the support necessary?
>>>
>>> Darren
>>>
>>>> On Dec 12, 2014, at 2:41 AM, Frank Fesevur <ff...@us...> wrote:
>>>>
>>>> Hi Darren,
>>>>
>>>> How are things going? Are you running into problems? If so, is there
>>>> anything I can do to help you?
>>>>
>>>> Regards,
>>>> Frank
>>>>
>>>>
>>>> 2014-11-19 17:24 GMT+01:00 Frank Fesevur <ff...@us...>:
>>>>> 2014-11-19 7:15 GMT+01:00 Darren Hiebert <dhi...@us...>:
>>>>>> Hello Frank,
>>>>>>
>>>>>> I am here and ready to talk about making this happen. I need a few days to come up to date on the links you posted, and get myself back in shape for building a release. How do you propose merging? Merging the changes in the github back into the Subversion repository on SourceForge?
>>>>>>
>>>>>> Darren
>>>>>
>>>>> Great to hear from you!
>>>>>
>>>>> The easiest way is to build it is to clone the github repo (git clone
>>>>> https://github.com/fishman/ctags.git) and do the normal building
>>>>> steps.
>>>>>
>>>>> All the code in the SVN is already in the github repo. We think the
>>>>> best way is to start/continue using git and store the repository at
>>>>> github.
>>>>>
>>>>> At the moment the repo is a personal repository of Reza Jelveh aka
>>>>> "fishman". We want to convert that repository into an organization.
>>>>> One of the advantages of organizations on github is that is gives you
>>>>> more control over permissions and it is not tied to one person
>>>>> anymore. And by converting the repo all the history already build is
>>>>> preserved. Once it is converted, we use that git repository as the new
>>>>> upstream repository.
>>>>>
>>>>> I already created an organization named "exuberant-ctags"
>>>>> https://github.com/exuberant-ctags
>>>>>
>>>>> At this moment it is still empty, but I will set it up any time soon.
>>>>> That means adding the collaborators of the current repo as owner or
>>>>> developer and then move the repository. I want to add you as an owner
>>>>> as well, but I need to know your github account name for that. Of
>>>>> course, the original members of the sf-team can be added as well if
>>>>> they are still interested in ctags.
>>>>>
>>>>> After that I think we can prepare a release. Some cleanup (both code
>>>>> and docs) has to done, but it is pretty stable code.
>>>>>
>>>>> Regards,
>>>>> Frank
>>>>
>>>> Ctags-devel mailing list
>>>> Cta...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/ctags-devel
>>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming. The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Ctags-devel mailing list
>> Cta...@li...
>> https://lists.sourceforge.net/lists/listinfo/ctags-devel
>>
>

Re: [Ctags-devel] Future of ctags

[Jan L. <li...@ma...>]

Hi Darren,

Darren Hiebert <dhi...@us...>:
> We began using git on a project at work and it has been a ride. While I knew
> how to use Subversion thoroughly, I do not have such a comfort level with
> git and don't know how to undo problems that occur. We have had changes
> wiped out at work that had to be restored when folks would push from their
> local repository that didn't get fully merged with changes from others. This
> necessitated the only two guys who know how to get us out of the mess in
> order to restore the files that got overwritten with older files.
> Considering how often this has happened, I have some trepidation.

First off, as I mentioned in an earlier mail GitHub actually allows accessing
repositories with Subversion as well:
https://help.github.com/articles/support-for-subversion-clients/
https://github.com/blog/1178-collaborating-on-github-with-subversion

This would not be possible with a Git repository hosted on SourceForge.

I would also like to weigh in with support for Git in general. I have been
using Git since about 2007, and CVS and Subversion before that, and I find Git
to be a vast improvement in every way. It is certainly more in the "with great
power comes great responsibility" camp than Subversion, and I obviously don't
know what happened at your company, but in my experience it is actually quite
hard to really mess up a Git repository unless you're liberally using advanced
commands without really understanding them, and ignoring warnings. The
important thing to remember is that Git is very different from Subversion in
many ways, but once you understand the basic concepts of Git everything else
really follows naturally from there. Here are two documents about how Git
works that I really recommend reading:

https://github.com/pluralsight/git-internals-pdf/releases
https://jwiegley.github.io/git-from-the-bottom-up/

> Secondly, I prefer that ctags be hosted on SourceForge. I am uncertain how
> we can use git to do that, but still host on SourceForge. Can you please
> explain further to me how that can be done?

I really would recommend not staying on SourceForge. SourceForge was useful 10
years ago, but by now its features and usability are so far behind the
alternatives that it is rapidly becoming irrelevant. I can guarantee you that
this project would receive a *lot* more contributions on GitHub than on
SourceForge, because people don't want to have to put up with an interface
from over a decade ago. The GitHub repository that this thread is about has
already had more contributions in the last few months than the official ctags
one had in several years. You are probably aware that there are several ctags
forks on GitHub where people have added support for one or two languages, but
none of them have made it into the official repository yet. If the official
repository were on GitHub the authors of those forks could have very easily
sent a pull request with their changes, but since this is not possible with
SourceForge contributing is too much hassle for most people.

-Jan

-- 
-[ OpenPGP key ID: 00A0FD5F ]-
The most dangerous phrase in the language is, "We've always done it this
way."
                -- Grace Hopper

Re: [Ctags-devel] Future of ctags

[Colomban W. <lis...@he...>]

Hi,

Le 03/02/2015 06:31, Darren Hiebert a écrit :
> I haven't forgotten you. My main apprehensions have been migrating to
> Git, and hosting off of SourceForge.
> 
> We began using git on a project at work and it has been a ride. While
> I knew how to use Subversion thoroughly, I do not have such a comfort
> level with git and don't know how to undo problems that occur. We
> have had changes wiped out at work that had to be restored when folks
> would push from their local repository that didn't get fully merged
> with changes from others. This necessitated the only two guys who
> know how to get us out of the mess in order to restore the files that
> got overwritten with older files. Considering how often this has
> happened, I have some trepidation.

Admittedly Git allows the user to do a lot more, and this includes
breaking everything.  However I believe that with a small learning time
you can get comfortable with Git if you don't try and do complex things
without taking time to properly understand them.  Sure, Git allows you
to rewrite history, force push and the like, but that's not commonly
required.  I guess what you saw was people trying to force a push
because some other changes happened and they didn't know what to do --
though, at least recent Git versions will tell you you probably should
pull and then try again -- as with SVN you couldn't even commit if your
clone was outdated.

Anyway, I believe that if you restrict yourself to the basics required,
like commit, checkout, add, push, pull, merge, branch and the like,
without trying weird stuff everything should be OK.  Also, Git has
lightweight branches [1], and you're advised to make extensive use of
them.  Basically, instead of working on master (Git's "trunk") you'd
work on a branch and merge [2] it when you're done, or make a pull
request out of it.

I can understand that one has to get used to the decentralized model
when coming from a long centralized experience, and that Git may let the
user do a little too much too easily -- but I believe there is much to
gain.  My first VCS experience was SVN (though I admit I didn't know
much about it), and it was just fine, but I wouldn't trade Git for it
for the world anymore :)

One thing for example I find very useful with Git and missing with SVN
is the ability for anyone to work on the repository.  With SVN, if you
don't have commit access you cannot prepare commits, and you pretty much
can only provide one single patch for inclusion with svn diff.  With
Git, you can commit on a local branch as much as you like, and easily
export several commits, allowing to break things into relevant units
rather than one large thing.  Or you can publish your repository and ask
for commits to be pulled from it -- that's what PR are basically, just
with a nicer interface.
For me as a developer it makes things a lot easier, because I can work
on whatever I have to (even several branches at once if I need to) and
take the time and steps I need to prepare clean commits [3].


[1] lightweight branches may be a concept that might be a bit weird to
SVN users, like SVN branches are a bit weird to me :)
But basically a Git branch is local unless explicitly pushed on a
remote, and "replaces" the current file tree.  There is no
/branches/trunk/ or /branches/otherbranch/, you just switch between
states of the one and only file tree.  Git branches are references to
the last commit on them, and checking a branch out gives you the state
of that last commit.

[2] you may not want to know, but if you want, Git also allows you to
avoid a merge by "importing" the commits instead of creating a merge,
that's the call of the person trying to "merge" the branch.

[3] and with Git's advanced features, I can even fix my commits (if they
haven't been pushed) if I realize there's something wrong in them.  OK,
admittedly that's the kind of power-feature that Git users grew to love
but that can easily scare people off and lead to some breakage if misused :)

> Secondly, I prefer that ctags be hosted on SourceForge. I am
> uncertain how we can use git to do that, but still host on
> SourceForge. Can you please explain further to me how that can be
> done?

SourceForge supports Git repositories just like they support SVN ones.
However, AFAIK they don't provide the whole pull request and review
interface people like on GitHub and similar platforms.

However, if your concern is that you want to also have the code on
SourceForge, it's not a problem: with Git (and any decentralized VCS
actually) you can have as many public repositories you want, and they
all are as much complete as the next one (so are local ones).  So, we
could very well push all changes to SourceForge in addition to any other
platform (like GitHub for example) we want.  We could even probably have
a "hook" [4] that would automatically propagate the changes to whichever
mirror we want.

For example with Geany, we have a hook set up so that any change pushed
to our GitHub repository is propagated to our own server mirror
http://git.geany.org/geany/


[4] automated action triggered by some event, typically push or commit.
 I'm not sure GitHub has a builtin one for propagating to sourceforge,
but without having tested it it should be possible to get something to work.



I hope this helps a bit and didn't scare you further off :)

Regards,
Colomban

Re: [Ctags-devel] Future of ctags

[Martin d'A. <mar...@gm...>]

Hello Daren,

Please, let me weight in wrt to Git. I am a ctags user and usually a 
silent observer on this list. I used to have similar apprehensions, Git 
is a very complicated SCM. Recently I got involved in a couple of 
projects hosted on GitHub, and discovered the GitHub workflow with 
forked repositories and pull requests. This workflow puts "checks" 
around Git that prevent people from propagating unwanted changes beyond 
their own repository: the pull requests must be reviewed and approved by 
a real person before they are approved for merge into the "central" 
repository. Maybe pull requests can be configured to be automatically 
accepted but I would not turn that on unless there was an extensive 
automated test suite. The projects I participate in on GitHub have both 
human code reviews and automated testing. Project maintainers will not 
review nor accept the pull requests unless the tests have passed. For 
example: 
https://github.com/jenkinsci/validating-string-parameter-plugin/pull/3

So I encourage you to try the GitHub workflow of forked repositories and 
pull requests. To me this is the game changer that finally makes Git 
usable. This workflow does not prevent anyone from deeply messing up 
their local repository and their fork, but it certainly prevents them 
from propagating their mistakes to others, and I can deal with that.

Cheers,
Martin

On 15-02-03 12:31 AM, Darren Hiebert wrote:
> Hello Frank,
>
> I haven't forgotten you. My main apprehensions have been migrating to Git, and hosting off of SourceForge.
>
> We began using git on a project at work and it has been a ride. While I knew how to use Subversion thoroughly, I do not have such a comfort level with git and don't know how to undo problems that occur. We have had changes wiped out at work that had to be restored when folks would push from their local repository that didn't get fully merged with changes from others. This necessitated the only two guys who know how to get us out of the mess in order to restore the files that got overwritten with older files. Considering how often this has happened, I have some trepidation.
>
> Secondly, I prefer that ctags be hosted on SourceForge. I am uncertain how we can use git to do that, but still host on SourceForge. Can you please explain further to me how that can be done?
>
> Darren
>

Re: [Ctags-devel] Future of ctags

[Darren H. <dhi...@us...>]

Hello Frank,

I haven't forgotten you. My main apprehensions have been migrating to Git, and hosting off of SourceForge.

We began using git on a project at work and it has been a ride. While I knew how to use Subversion thoroughly, I do not have such a comfort level with git and don't know how to undo problems that occur. We have had changes wiped out at work that had to be restored when folks would push from their local repository that didn't get fully merged with changes from others. This necessitated the only two guys who know how to get us out of the mess in order to restore the files that got overwritten with older files. Considering how often this has happened, I have some trepidation.

Secondly, I prefer that ctags be hosted on SourceForge. I am uncertain how we can use git to do that, but still host on SourceForge. Can you please explain further to me how that can be done?

Darren

> On Jan 28, 2015, at 10:00 AM, Frank Fesevur <ff...@us...> wrote:
> 
> Hi Darren,
> 
> Is there anything we can do to help you? Any questions we can answer?
> Problems we can solve?
> 
> If you are still in doubt about git and GitHub, please read these
> blogposts by the .NET team of Microsoft. MS has integrated git in
> Visual Studio quite nicely IMHO (Yes, the idea of Linus Torvalds -
> maybe even code he has written - is used a MS product), they are
> active contributing to the development of libgit2 and MS is moving at
> least some of their open source project from their own CodePlex
> platform to GitHub, simply because that is where the community is.
> http://blogs.msdn.com/b/dotnet/archive/2014/11/12/net-core-is-open-source.aspx
> http://blogs.msdn.com/b/vbteam/archive/2015/01/10/we-re-moving-to-github.aspx
> 
> And see how your project has been revived at GitHub. An active
> community has grown there. This week an quite detailed issue and a
> pull request were submitted by two new people. People are finding
> ctags at github and willing to contribute.
> 
> And we really want to move forward, together with you! We'll continue
> to use Sourceforge for the webhosting, the mailing list and probably
> as the download platform, but move the main code repo and issue
> tracker to the GitHub organization. Then fix some last known bugs,
> update the documentation including the man page and prepare for the
> release of exuberant ctags 6.0
> 
> Kind regards,
> Frank
> 
> 
> 2014-12-19 6:23 GMT+01:00 Darren Hiebert <Da...@da...>:
>> Frank,
>> 
>> If I understand you correctly, you are proposing that the source code no longer be hosted at SourceForge, which is what I would prefer. What are the reasons that you believe that SourceForge cannot provide the support necessary?
>> 
>> Darren
>> 
>>> On Dec 12, 2014, at 2:41 AM, Frank Fesevur <ff...@us...> wrote:
>>> 
>>> Hi Darren,
>>> 
>>> How are things going? Are you running into problems? If so, is there
>>> anything I can do to help you?
>>> 
>>> Regards,
>>> Frank
>>> 
>>> 
>>> 2014-11-19 17:24 GMT+01:00 Frank Fesevur <ff...@us...>:
>>>> 2014-11-19 7:15 GMT+01:00 Darren Hiebert <dhi...@us...>:
>>>>> Hello Frank,
>>>>> 
>>>>> I am here and ready to talk about making this happen. I need a few days to come up to date on the links you posted, and get myself back in shape for building a release. How do you propose merging? Merging the changes in the github back into the Subversion repository on SourceForge?
>>>>> 
>>>>> Darren
>>>> 
>>>> Great to hear from you!
>>>> 
>>>> The easiest way is to build it is to clone the github repo (git clone
>>>> https://github.com/fishman/ctags.git) and do the normal building
>>>> steps.
>>>> 
>>>> All the code in the SVN is already in the github repo. We think the
>>>> best way is to start/continue using git and store the repository at
>>>> github.
>>>> 
>>>> At the moment the repo is a personal repository of Reza Jelveh aka
>>>> "fishman". We want to convert that repository into an organization.
>>>> One of the advantages of organizations on github is that is gives you
>>>> more control over permissions and it is not tied to one person
>>>> anymore. And by converting the repo all the history already build is
>>>> preserved. Once it is converted, we use that git repository as the new
>>>> upstream repository.
>>>> 
>>>> I already created an organization named "exuberant-ctags"
>>>> https://github.com/exuberant-ctags
>>>> 
>>>> At this moment it is still empty, but I will set it up any time soon.
>>>> That means adding the collaborators of the current repo as owner or
>>>> developer and then move the repository. I want to add you as an owner
>>>> as well, but I need to know your github account name for that. Of
>>>> course, the original members of the sf-team can be added as well if
>>>> they are still interested in ctags.
>>>> 
>>>> After that I think we can prepare a release. Some cleanup (both code
>>>> and docs) has to done, but it is pretty stable code.
>>>> 
>>>> Regards,
>>>> Frank
>>> 
>>> Ctags-devel mailing list
>>> Cta...@li...
>>> https://lists.sourceforge.net/lists/listinfo/ctags-devel
>>> 
>> 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Ctags-devel mailing list
> Cta...@li...
> https://lists.sourceforge.net/lists/listinfo/ctags-devel
> 

Re: [Ctags-devel] Future of ctags

[Frank F. <ff...@us...>]

Hi Darren,

Is there anything we can do to help you? Any questions we can answer?
Problems we can solve?

If you are still in doubt about git and GitHub, please read these
blogposts by the .NET team of Microsoft. MS has integrated git in
Visual Studio quite nicely IMHO (Yes, the idea of Linus Torvalds -
maybe even code he has written - is used a MS product), they are
active contributing to the development of libgit2 and MS is moving at
least some of their open source project from their own CodePlex
platform to GitHub, simply because that is where the community is.
http://blogs.msdn.com/b/dotnet/archive/2014/11/12/net-core-is-open-source.aspx
http://blogs.msdn.com/b/vbteam/archive/2015/01/10/we-re-moving-to-github.aspx

And see how your project has been revived at GitHub. An active
community has grown there. This week an quite detailed issue and a
pull request were submitted by two new people. People are finding
ctags at github and willing to contribute.

And we really want to move forward, together with you! We'll continue
to use Sourceforge for the webhosting, the mailing list and probably
as the download platform, but move the main code repo and issue
tracker to the GitHub organization. Then fix some last known bugs,
update the documentation including the man page and prepare for the
release of exuberant ctags 6.0

Kind regards,
Frank


2014-12-19 6:23 GMT+01:00 Darren Hiebert <Da...@da...>:
> Frank,
>
> If I understand you correctly, you are proposing that the source code no longer be hosted at SourceForge, which is what I would prefer. What are the reasons that you believe that SourceForge cannot provide the support necessary?
>
> Darren
>
>> On Dec 12, 2014, at 2:41 AM, Frank Fesevur <ff...@us...> wrote:
>>
>> Hi Darren,
>>
>> How are things going? Are you running into problems? If so, is there
>> anything I can do to help you?
>>
>> Regards,
>> Frank
>>
>>
>> 2014-11-19 17:24 GMT+01:00 Frank Fesevur <ff...@us...>:
>>> 2014-11-19 7:15 GMT+01:00 Darren Hiebert <dhi...@us...>:
>>>> Hello Frank,
>>>>
>>>> I am here and ready to talk about making this happen. I need a few days to come up to date on the links you posted, and get myself back in shape for building a release. How do you propose merging? Merging the changes in the github back into the Subversion repository on SourceForge?
>>>>
>>>> Darren
>>>
>>> Great to hear from you!
>>>
>>> The easiest way is to build it is to clone the github repo (git clone
>>> https://github.com/fishman/ctags.git) and do the normal building
>>> steps.
>>>
>>> All the code in the SVN is already in the github repo. We think the
>>> best way is to start/continue using git and store the repository at
>>> github.
>>>
>>> At the moment the repo is a personal repository of Reza Jelveh aka
>>> "fishman". We want to convert that repository into an organization.
>>> One of the advantages of organizations on github is that is gives you
>>> more control over permissions and it is not tied to one person
>>> anymore. And by converting the repo all the history already build is
>>> preserved. Once it is converted, we use that git repository as the new
>>> upstream repository.
>>>
>>> I already created an organization named "exuberant-ctags"
>>> https://github.com/exuberant-ctags
>>>
>>> At this moment it is still empty, but I will set it up any time soon.
>>> That means adding the collaborators of the current repo as owner or
>>> developer and then move the repository. I want to add you as an owner
>>> as well, but I need to know your github account name for that. Of
>>> course, the original members of the sf-team can be added as well if
>>> they are still interested in ctags.
>>>
>>> After that I think we can prepare a release. Some cleanup (both code
>>> and docs) has to done, but it is pretty stable code.
>>>
>>> Regards,
>>> Frank
>>
>> Ctags-devel mailing list
>> Cta...@li...
>> https://lists.sourceforge.net/lists/listinfo/ctags-devel
>>
>

Re: [Ctags-devel] Future of ctags

[Frank F. <ff...@us...>]

Hi Darren,

I don't have much to add to other posts (all of them have contributed
to the github repo).

The two most important features for me are github's Pull Requests (PR)
and the Travis CI integration.

With the way gibhub allows you to fork/copy a repo, do your changes
and submit a PR, it is very easy for everybody to submit their
improvements to the upstream project. Most of the code that is
contributed the last months has been PRs.

The Travis CI integration is also very useful. This means that the
code gets compiled every time something is pushed to the repo. This
way we make sure the code compiles in Linux and Windows. And with the
new introduced units tests, Travis CI checks if the new code does not
break old code. Because this also works for submitted PRs those basic
checks are done before new code is reviewed.

Regards,
Frank



2014-12-19 6:55 GMT+01:00 Darren Hiebert <dhi...@us...>:
> Frank,
>
> If I understand you correctly, you are proposing that the source code no longer be hosted at SourceForge, which is what I would prefer. What are the reasons that you believe that SourceForge cannot provide the support necessary?
>
> Darren
>
>> On Dec 12, 2014, at 2:41 AM, Frank Fesevur <ff...@us...> wrote:
>>
>> Hi Darren,
>>
>> How are things going? Are you running into problems? If so, is there
>> anything I can do to help you?
>>
>> Regards,
>> Frank
>>
>>
>> 2014-11-19 17:24 GMT+01:00 Frank Fesevur <ff...@us...>:
>>> 2014-11-19 7:15 GMT+01:00 Darren Hiebert <dhi...@us...>:
>>>> Hello Frank,
>>>>
>>>> I am here and ready to talk about making this happen. I need a few days to come up to date on the links you posted, and get myself back in shape for building a release. How do you propose merging? Merging the changes in the github back into the Subversion repository on SourceForge?
>>>>
>>>> Darren
>>>
>>> Great to hear from you!
>>>
>>> The easiest way is to build it is to clone the github repo (git clone
>>> https://github.com/fishman/ctags.git) and do the normal building
>>> steps.
>>>
>>> All the code in the SVN is already in the github repo. We think the
>>> best way is to start/continue using git and store the repository at
>>> github.
>>>
>>> At the moment the repo is a personal repository of Reza Jelveh aka
>>> "fishman". We want to convert that repository into an organization.
>>> One of the advantages of organizations on github is that is gives you
>>> more control over permissions and it is not tied to one person
>>> anymore. And by converting the repo all the history already build is
>>> preserved. Once it is converted, we use that git repository as the new
>>> upstream repository.
>>>
>>> I already created an organization named "exuberant-ctags"
>>> https://github.com/exuberant-ctags
>>>
>>> At this moment it is still empty, but I will set it up any time soon.
>>> That means adding the collaborators of the current repo as owner or
>>> developer and then move the repository. I want to add you as an owner
>>> as well, but I need to know your github account name for that. Of
>>> course, the original members of the sf-team can be added as well if
>>> they are still interested in ctags.
>>>
>>> After that I think we can prepare a release. Some cleanup (both code
>>> and docs) has to done, but it is pretty stable code.
>>>
>>> Regards,
>>> Frank
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Ctags-devel mailing list
>> Cta...@li...
>> https://lists.sourceforge.net/lists/listinfo/ctags-devel
>>
>

Re: [Ctags-devel] Future of ctags

[Jan L. <li...@ma...>]

Darren Hiebert <dhi...@us...>:
> If I understand you correctly, you are proposing that the source code no
> longer be hosted at SourceForge, which is what I would prefer. What are the
> reasons that you believe that SourceForge cannot provide the support
> necessary?

I also want to chime in with a preference for GitHub. GitHub is essentially
were most of the developers are nowadays, and with good reason. I have used
SourceForge for years before GitHub was around, but now that GitHub has shown
how convenient project hosting can be it is hard to go back to SourceForge,
and every time I have to do it I find the SF interface very cumbersome.
Especially contributing a quick patch is dead easy with GitHub, you just clone
the repository, commit your patch, and send a pull request. There are even
tools to do this with a few commands on the command line.

And this is even without all the benefits that Git itself brings for
developers. I myself would not want to miss them, I even use subversion
repositories (almost) exclusively through git-svn instead of the normal svn
client. But if someone does want to stick with the svn client for some reason
it is possible to access GitHub repositories as subversion repositories. I
don't think that is possible on SourceForge.

So the short version is that a project hosted on GitHub will not only be more
convenient for the core developers, but will almost certainly also attract a
lot more outside contributions.

-Jan

-- 
-[ OpenPGP key ID: 00A0FD5F ]-
But I don't have to know an answer. I don't feel frightened by not knowing
things, by being lost in the mysterious universe without having any purpose
— which is the way it really is, as far as I can tell. Possibly. It doesn't
frighten me.
                -- Richard Feynman

Re: [Ctags-devel] Future of ctags

[Dmitri T. <dti...@ya...>]

Sourceforge can provide the support, but Github is the new hot thing.  Consider Exuberant Ctags itself.  There are over *fifty* forks of Exuberant Ctags on Github:

  https://github.com/search?q=exuberant+ctags&type=Repositories&ref=searchresults

and only one on Sourceforge:

  http://sourceforge.net/directory/?q=exuberant%20ctags

Most of those forks on Github have modifications to one parser or another and most could probably be easily merged into the official tree if it were hosted on Github.

Then there is also Travis-CI, which is a testing service that can be integrated with GIthub.  I am not sure whether something like this exists on Sourceforge.

But most importantly, I feel that there is just more awareness about Github and most programmers now choose to host their projects there.  (I say "feel" because I don't have number to back it up.  My own anecdotal evidence: I am much more likely to come across Github links in my daily web browsing than Sourceforge links.)

Those are my arguments in favor of Github.

--------------------------------------------
On Fri, 12/19/14, Darren Hiebert <dhi...@us...> wrote:

 Subject: Re: [Ctags-devel] Future of ctags
 To: "Frank Fesevur" <ff...@us...>
 Cc: "ctags-devel Development" <cta...@li...>
 Date: Friday, December 19, 2014, 12:55 AM
 
 Frank,
 
 If I understand you correctly,
 you are proposing that the source code no longer be hosted
 at SourceForge, which is what I would prefer. What are the
 reasons that you believe that SourceForge cannot provide the
 support necessary?
 
 Darren
 
 > On
 Dec 12, 2014, at 2:41 AM, Frank Fesevur <ff...@us...>
 wrote:
 > 
 > Hi
 Darren,
 > 
 > How are
 things going? Are you running into problems? If so, is
 there
 > anything I can do to help you?
 > 
 > Regards,
 > Frank
 > 
 > 
 > 2014-11-19 17:24
 GMT+01:00 Frank Fesevur <ff...@us...>:
 >> 2014-11-19 7:15 GMT+01:00 Darren
 Hiebert <dhi...@us...>:
 >>> Hello Frank,
 >>> 
 >>> I am
 here and ready to talk about making this happen. I need a
 few days to come up to date on the links you posted, and get
 myself back in shape for building a release. How do you
 propose merging? Merging the changes in the github back into
 the Subversion repository on SourceForge?
 >>> 
 >>>
 Darren
 >> 
 >>
 Great to hear from you!
 >> 
 >> The easiest way is to build it is to
 clone the github repo (git clone
 >> https://github.com/fishman/ctags.git)
 and do the normal building
 >>
 steps.
 >> 
 >>
 All the code in the SVN is already in the github repo. We
 think the
 >> best way is to
 start/continue using git and store the repository at
 >> github.
 >> 
 >> At the moment the repo is a personal
 repository of Reza Jelveh aka
 >>
 "fishman". We want to convert that repository into
 an organization.
 >> One of the
 advantages of organizations on github is that is gives
 you
 >> more control over permissions
 and it is not tied to one person
 >>
 anymore. And by converting the repo all the history already
 build is
 >> preserved. Once it is
 converted, we use that git repository as the new
 >> upstream repository.
 >> 
 >> I already
 created an organization named "exuberant-ctags"
 >> https://github.com/exuberant-ctags
 >> 
 >> At this
 moment it is still empty, but I will set it up any time
 soon.
 >> That means adding the
 collaborators of the current repo as owner or
 >> developer and then move the
 repository. I want to add you as an owner
 >> as well, but I need to know your
 github account name for that. Of
 >>
 course, the original members of the sf-team can be added as
 well if
 >> they are still interested
 in ctags.
 >> 
 >>
 After that I think we can prepare a release. Some cleanup
 (both code
 >> and docs) has to done,
 but it is pretty stable code.
 >> 
 >> Regards,
 >>
 Frank
 > 
 >
 ------------------------------------------------------------------------------
 > Download BIRT iHub F-Type - The Free
 Enterprise-Grade BIRT Server
 > from
 Actuate! Instantly Supercharge Your Business Reports and
 Dashboards
 > with Interactivity, Sharing,
 Native Excel Exports, App Integration & more
 > Get technology previously reserved for
 billion-dollar corporations, FREE
 > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
 >
 _______________________________________________
 > Ctags-devel mailing list
 > Cta...@li...
 > https://lists.sourceforge.net/lists/listinfo/ctags-devel
 >
 
 
 
 ------------------------------------------------------------------------------
 Download BIRT iHub F-Type - The Free
 Enterprise-Grade BIRT Server
 from Actuate!
 Instantly Supercharge Your Business Reports and
 Dashboards
 with Interactivity, Sharing,
 Native Excel Exports, App Integration & more
 Get technology previously reserved for
 billion-dollar corporations, FREE
 http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
 _______________________________________________
 Ctags-devel mailing list
 Cta...@li...
 https://lists.sourceforge.net/lists/listinfo/ctags-devel
 

Re: [Ctags-devel] Future of ctags

[Colomban W. <lis...@he...>]

Hi,

Le 19/12/2014 06:55, Darren Hiebert a écrit :
> If I understand you correctly, you are proposing that the source code
> no longer be hosted at SourceForge, which is what I would prefer.

If we switch to Git (and I love Git!), we can have the code hosted on
several places very easily (with any DVCS actually).  We can push it
both to SF and GitHub and whatnot.  With hooks it's even very easy to
maintain copies in sync.

My point is only that using a DVCS means we don't have to remove the
code from anywhere.

> What are the reasons that you believe that SourceForge cannot provide
> the support necessary?

Unfortunately, AFAIK SF doesn't provide something similar to Pull
Requests (also called Merge Requests on some other platforms), which are
a really handy way of submitting and reviewing changes.  GitHub's UI
there is very nice I must admit.

Also, I know many people facing recurrent login issues with SF, like
getting disconnected very often, sometimes in the middle of an action
making them lose the content of a form and these kind of things.  And SF
has other weird issues, but that's (partly) another topic.
Anyway, as much as I hate switching from a more-or-less open platform to
a closed one, GitHub seems a lot more practical to use today, at least
for the code part (I can't really tell for the bug tracker part, but GH
has one that while having seemingly less features seem to work just fine
in practice).

However note that there are open alternatives to GitHub if that's one
thing that annoys you, one just has to search a bit -- and often, host
it, which is both great and not so much.

Regards,
Colomban


PS: oops, I missed the list last time and only answered Darren.

Re: [Ctags-devel] Future of ctags

[Darren H. <dhi...@us...>]

Frank,

If I understand you correctly, you are proposing that the source code no longer be hosted at SourceForge, which is what I would prefer. What are the reasons that you believe that SourceForge cannot provide the support necessary?

Darren

> On Dec 12, 2014, at 2:41 AM, Frank Fesevur <ff...@us...> wrote:
> 
> Hi Darren,
> 
> How are things going? Are you running into problems? If so, is there
> anything I can do to help you?
> 
> Regards,
> Frank
> 
> 
> 2014-11-19 17:24 GMT+01:00 Frank Fesevur <ff...@us...>:
>> 2014-11-19 7:15 GMT+01:00 Darren Hiebert <dhi...@us...>:
>>> Hello Frank,
>>> 
>>> I am here and ready to talk about making this happen. I need a few days to come up to date on the links you posted, and get myself back in shape for building a release. How do you propose merging? Merging the changes in the github back into the Subversion repository on SourceForge?
>>> 
>>> Darren
>> 
>> Great to hear from you!
>> 
>> The easiest way is to build it is to clone the github repo (git clone
>> https://github.com/fishman/ctags.git) and do the normal building
>> steps.
>> 
>> All the code in the SVN is already in the github repo. We think the
>> best way is to start/continue using git and store the repository at
>> github.
>> 
>> At the moment the repo is a personal repository of Reza Jelveh aka
>> "fishman". We want to convert that repository into an organization.
>> One of the advantages of organizations on github is that is gives you
>> more control over permissions and it is not tied to one person
>> anymore. And by converting the repo all the history already build is
>> preserved. Once it is converted, we use that git repository as the new
>> upstream repository.
>> 
>> I already created an organization named "exuberant-ctags"
>> https://github.com/exuberant-ctags
>> 
>> At this moment it is still empty, but I will set it up any time soon.
>> That means adding the collaborators of the current repo as owner or
>> developer and then move the repository. I want to add you as an owner
>> as well, but I need to know your github account name for that. Of
>> course, the original members of the sf-team can be added as well if
>> they are still interested in ctags.
>> 
>> After that I think we can prepare a release. Some cleanup (both code
>> and docs) has to done, but it is pretty stable code.
>> 
>> Regards,
>> Frank
> 
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Ctags-devel mailing list
> Cta...@li...
> https://lists.sourceforge.net/lists/listinfo/ctags-devel
> 

Re: [Ctags-devel] Future of ctags

[Frank F. <ff...@us...>]

Hi Darren,

How are things going? Are you running into problems? If so, is there
anything I can do to help you?

Regards,
Frank


2014-11-19 17:24 GMT+01:00 Frank Fesevur <ff...@us...>:
> 2014-11-19 7:15 GMT+01:00 Darren Hiebert <dhi...@us...>:
>> Hello Frank,
>>
>> I am here and ready to talk about making this happen. I need a few days to come up to date on the links you posted, and get myself back in shape for building a release. How do you propose merging? Merging the changes in the github back into the Subversion repository on SourceForge?
>>
>> Darren
>
> Great to hear from you!
>
> The easiest way is to build it is to clone the github repo (git clone
> https://github.com/fishman/ctags.git) and do the normal building
> steps.
>
> All the code in the SVN is already in the github repo. We think the
> best way is to start/continue using git and store the repository at
> github.
>
> At the moment the repo is a personal repository of Reza Jelveh aka
> "fishman". We want to convert that repository into an organization.
> One of the advantages of organizations on github is that is gives you
> more control over permissions and it is not tied to one person
> anymore. And by converting the repo all the history already build is
> preserved. Once it is converted, we use that git repository as the new
> upstream repository.
>
> I already created an organization named "exuberant-ctags"
> https://github.com/exuberant-ctags
>
> At this moment it is still empty, but I will set it up any time soon.
> That means adding the collaborators of the current repo as owner or
> developer and then move the repository. I want to add you as an owner
> as well, but I need to know your github account name for that. Of
> course, the original members of the sf-team can be added as well if
> they are still interested in ctags.
>
> After that I think we can prepare a release. Some cleanup (both code
> and docs) has to done, but it is pretty stable code.
>
> Regards,
> Frank

Re: [Ctags-devel] Future of ctags

[Frank F. <ff...@us...>]

2014-11-19 7:15 GMT+01:00 Darren Hiebert <dhi...@us...>:
> Hello Frank,
>
> I am here and ready to talk about making this happen. I need a few days to come up to date on the links you posted, and get myself back in shape for building a release. How do you propose merging? Merging the changes in the github back into the Subversion repository on SourceForge?
>
> Darren

Great to hear from you!

The easiest way is to build it is to clone the github repo (git clone
https://github.com/fishman/ctags.git) and do the normal building
steps.

All the code in the SVN is already in the github repo. We think the
best way is to start/continue using git and store the repository at
github.

At the moment the repo is a personal repository of Reza Jelveh aka
"fishman". We want to convert that repository into an organization.
One of the advantages of organizations on github is that is gives you
more control over permissions and it is not tied to one person
anymore. And by converting the repo all the history already build is
preserved. Once it is converted, we use that git repository as the new
upstream repository.

I already created an organization named "exuberant-ctags"
https://github.com/exuberant-ctags

At this moment it is still empty, but I will set it up any time soon.
That means adding the collaborators of the current repo as owner or
developer and then move the repository. I want to add you as an owner
as well, but I need to know your github account name for that. Of
course, the original members of the sf-team can be added as well if
they are still interested in ctags.

After that I think we can prepare a release. Some cleanup (both code
and docs) has to done, but it is pretty stable code.

Regards,
Frank

Re: [Ctags-devel] Future of ctags

[Darren H. <dhi...@us...>]

Hello Frank,

I am here and ready to talk about making this happen. I need a few days to come up to date on the links you posted, and get myself back in shape for building a release. How do you propose merging? Merging the changes in the github back into the Subversion repository on SourceForge?

Darren

> On Nov 10, 2014, at 1:44 PM, Frank Fesevur <ff...@us...> wrote:
> 
> Dear Darren,
> 
> We know you are going through a tough time in your life and we fully
> understand that ctags is not the top priority on your list.
> Nevertheless we hope you have the time to discuss the future of this
> project with us.
> 
> At this moment not much is happening in the official exuberant ctags
> project. Very few SVN check-ins, little traffic on the mailing list.
> The project appears to have stalled. But all the GNU/Linux
> distributions mention this project as upstream. Exuberant ctags is
> still a strong name!
> 
> A couple of developers, most of them subscribed to this list, want to
> keep the development of ctags alive. Since we don't have access to the
> SVN we decided to contribute to the most active repository on github
> https://github.com/fishman/ctags This started as a simple personal
> fork of the SVN repo (including all the history) but has grown heavily
> over the last couple of months. We believe a lot of good things are
> being done in this repository and think all the work done justifies a
> the release of ctags v6.0. Obviously the repo is kept up-to-date with
> the current SVN. No work is lost.
> 
> As a next step we would like to create a github organization and
> convert the personal repository into the new official upstream
> repository. We gladly add you as admin of that organization. This way
> everything that has been going on in this repo is saved. After that
> the final work can be done to prepare the release.
> 
> I am writing on behalf of the developers at "fishman". We really hope
> you have time to discuss this with us. Please know that all we want is
> to keep *this* project alive, but to accomplish that we need your
> help!
> 
> To see the most important changes we created a changelog:
> https://github.com/fishman/ctags/blob/master/docs/f-news.rst
> We also kept track of the issues mentioned here and in other places
> that we addressed:
> https://github.com/fishman/ctags/blob/master/docs/f-tracking.rst
> 
> Kind regards,
> Frank Fesevur

[Ctags-devel] Future of ctags

[Frank F. <ff...@us...>]

Dear Darren,

We know you are going through a tough time in your life and we fully
understand that ctags is not the top priority on your list.
Nevertheless we hope you have the time to discuss the future of this
project with us.

At this moment not much is happening in the official exuberant ctags
project. Very few SVN check-ins, little traffic on the mailing list.
The project appears to have stalled. But all the GNU/Linux
distributions mention this project as upstream. Exuberant ctags is
still a strong name!

A couple of developers, most of them subscribed to this list, want to
keep the development of ctags alive. Since we don't have access to the
SVN we decided to contribute to the most active repository on github
https://github.com/fishman/ctags This started as a simple personal
fork of the SVN repo (including all the history) but has grown heavily
over the last couple of months. We believe a lot of good things are
being done in this repository and think all the work done justifies a
the release of ctags v6.0. Obviously the repo is kept up-to-date with
the current SVN. No work is lost.

As a next step we would like to create a github organization and
convert the personal repository into the new official upstream
repository. We gladly add you as admin of that organization. This way
everything that has been going on in this repo is saved. After that
the final work can be done to prepare the release.

I am writing on behalf of the developers at "fishman". We really hope
you have time to discuss this with us. Please know that all we want is
to keep *this* project alive, but to accomplish that we need your
help!

To see the most important changes we created a changelog:
https://github.com/fishman/ctags/blob/master/docs/f-news.rst
We also kept track of the issues mentioned here and in other places
that we addressed:
https://github.com/fishman/ctags/blob/master/docs/f-tracking.rst

Kind regards,
Frank Fesevur

PS. This mail has been sent to the ctags-devel mailing list and BCC'ed
to Darren's personal address mentioned on his website. Sorry Darren,
that you receive it twice.

Re: [Ctags-devel] E-CTags development & maintenance

[Masatake Y. <ya...@re...>]

On Thu, 18 Sep 2014 12:37:00 +0900 (JST), Masatake YAMATO <ya...@re...> wrote:
>> I see there is a very active fork:
>> 
>>   https://github.com/fishman/ctags/commits/deploy
>> 
>> Are any distros going to pick it up?  
> 
> No. Not ready. If ready, I will contact the maintainer at Fedora at least.

I'd like you, who are interested in ctags, to know three progresses in
fishman/ctags fork.

1. I wrote NEWS file, in which some important(from my view) changes were listed.
   https://github.com/fishman/ctags/blob/master/docs/f-news.rst

2. I started contacting with the ctags package maintainer at Fedora.
   https://bugzilla.redhat.com/show_bug.cgi?id=853552#c3

   At least I can prepare unofficial rpm package in soon.
   
3. I started contacting with a Geany developer for sharing the efforts for
   maintaining parsers. still in very early stage.
   
   https://github.com/fishman/ctags/issues/63
   
Thanks,
Masatake YAMATO
   

[Ctags-devel] Cannot assign bugs to myself

[David F. <dfi...@gm...>]

I used to be able to assign submitted bugs to myself, then fix and close
them.

I have successfully logged into SourceForge.
I still see my name as a member of Exuberant Tags.

I can still submit code.

But I cannot see how to assign a bug in the bug tracker to myself so I can
mark it as closed.

Thanks,
David

Re: [Ctags-devel] E-CTags development & maintenance

[Masatake Y. <ya...@re...>]

Hi,

I'm co-maintainer of fishman-ctags.
I wanted announce the project here but have not yet because some of
code and documentation are not mature.

> I see there is a very active fork:
> 
>   https://github.com/fishman/ctags/commits/deploy
> 
> Are any distros going to pick it up?  

No. Not ready. If ready, I will contact the maintainer at Fedora at least.

> Can we get Darren to give someone else co-maint on the sourceforce web site?

No. However, patches, regardless merged or not merged yet appeared on 
exuberant(mailing list, bug/feature tracking system, and svn repo) are merged to 
fishman. See https://github.com/fishman/ctags/blob/deploy/TRACKING

I have maintained TODO list which I (and/or other contributor(s)) have
to do before announcing the project here. https://github.com/fishman/ctags/labels/Before%20ANNOUNCEMENT
But this is a good time to advertise it. If you are really interested in
better ctags, please, read https://github.com/fishman/ctags/blob/deploy/FISHMAN

I have a question. Can I use here, this mailing list, for discussing
fishman-ctags?  In many case, github provides enough facilities for
developing. However, sometimes I need a mailing list. If you say NO,
I have to create a new list somewhere. If you say YES, could you add
Reza Jelveh <rez...@gm...> to this list? His request for
joining the list have been pending for a long time(This is the
one of the reason that the announcement is delayed.)

Masatake YAMATO

Re: [Ctags-devel] E-CTags development & maintenance (was Re: New PHP parser)

[Dmitri T. <dti...@ya...>]

I see there is a very active fork:

  https://github.com/fishman/ctags/commits/deploy

Are any distros going to pick it up?  Can we get Darren to give someone else co-maint on the sourceforce web site?

 


On Tuesday, October 15, 2013 5:43 PM, Frank Fesevur <ff...@us...> wrote:
 


2013/10/15 David Fishburn:
> There were many more people on the dev list that kept changes updated.
>
> They have been silent for some time now.
> I was beginning to wonder if they in fact have already forked exuberant tags
> and starting working on their own port.
>
> Has anyone looked for another fork?

The only active fork I am aware of is the Geany fork.
https://github.com/geany/geany/tree/master/tagmanager/ctags
AFAIK Colomban (how started this thread with his offer) is one of the
maintainers of Geany. He (user b4n) committed to that branch recently.

>From what I understand Geany uses ctags as a library and not as an
external program. And they renamed language specific kind to common
kinds, don't know why. But their parsers seem very well maintained.

Other then that, there are several personal forks. But I haven't seen
a real fork of ctags. Maybe they lost interest, or hope for more
activity here.

Regards,

Frank

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
_______________________________________________
Ctags-devel mailing list
Cta...@li...
https://lists.sourceforge.net/lists/listinfo/ctags-devel

[Ctags-devel] Don't parse empty files

[Kenichi I. <ken...@gm...>]

Hi,

Is it unnecessary to parse empty files and make tags?
If unnecessary, you do this.

diff --git a/main.c b/main.c
index ffd45ac..3c7822c 100644
--- a/main.c
+++ b/main.c
@@ -299,7 +299,7 @@
static boolean createTagsForEntry (const char *const entryName)
        resize = recurseIntoDirectory (entryName);
    else if (! status->isNormalFile)
        verbose ("ignoring \"%s\" (special file)\n", entryName);
-   else
+   else if (status->size)
        resize = parseFile (entryName);

    eStatFree (status);

Regards,
Kenichi

[Ctags-devel] [PATCH] Add support for installing readtags command with --with-readcmd

[Maxime C. <fr...@gm...>]

Hello,

Here is a patch that enable installing the readtags command along with
ctags. readtags is already useful as is, and provides a nice shell
based way of retrieving information from the tags file, so it makes
sense to provide a way to install it.

More specifically, Kakoune (my code editor) ctags support relies
on the readtags binary being available, so I'd like to make its
installation as easy as possible.

Cheers,

Maxime Coste.

---
 Makefile.in  | 14 ++++++++++++--
 configure.ac | 10 ++++++++++
 2 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/Makefile.in b/Makefile.in
index 68ef039..339021c 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -87,6 +87,7 @@ CTAGS_EXEC	= $(CTAGS_PROG)$(EXEEXT)
 ETAGS_EXEC	= $(ETAGS_PROG)$(EXEEXT)
 DEST_CTAGS	= $(bindir)/$(CTAGS_EXEC)
 DEST_ETAGS	= $(bindir)/$(ETAGS_EXEC)
+DEST_READ_CMD	= $(bindir)/readtags$(EXEEXT)
 DEST_READ_LIB	= $(libdir)/$(READ_LIB)
 DEST_READ_INC	= $(incdir)/$(READ_INC)
 DEST_CMAN	= $(man1dir)/$(CMAN)
@@ -95,7 +96,7 @@ DEST_EMAN	= $(man1dir)/$(EMAN)
 #
 # primary rules
 #
-all: $(CTAGS_EXEC) $(READ_LIB)
+all: $(CTAGS_EXEC) $(READ_LIB) readtags$(EXEEXT)
 
 $(CTAGS_EXEC): $(OBJECTS)
 	$(CC) $(LDFLAGS) -o $@ $(OBJECTS) $(LIBS)
@@ -137,6 +138,7 @@ install-bin: install-cbin install-ebin install-lib
 install-cbin: $(DEST_CTAGS)
 install-ebin: $(DEST_ETAGS)
 install-lib: $(DEST_READ_LIB) $(DEST_READ_INC)
+install-cmd: $(DEST_READ_CMD)
 
 $(DEST_CTAGS): $(CTAGS_EXEC) $(bindir) FORCE
 	$(INSTALL_PROG) $(CTAGS_EXEC) $@  &&  chmod 755 $@
@@ -170,11 +172,16 @@ $(DEST_READ_LIB): $(READ_LIB) $(libdir) FORCE
 $(DEST_READ_INC): $(READ_INC) $(incdir) FORCE
 	$(INSTALL_PROG) $(READ_INC) $@  &&  chmod 644 $@
 
+#
+# install the readtags command
+#
+$(DEST_READ_CMD): readtags$(EXEEXT) $(bindir) FORCE
+	$(INSTALL_PROG) readtags$(EXEEXT) $@  &&  chmod 755 $@
 
 #
 # rules for uninstalling
 #
-uninstall: uninstall-bin uninstall-lib uninstall-man
+uninstall: uninstall-bin uninstall-lib uninstall-cmd uninstall-man
 
 uninstall-bin:
 	- rm -f $(DEST_CTAGS) $(DEST_ETAGS)
@@ -182,6 +189,9 @@ uninstall-bin:
 uninstall-lib:
 	- rm -f $(DEST_READ_LIB) $(DEST_READ_INC)
 
+uninstall-cmd:
+	- rm -f readtags$(EXEEXT)
+
 uninstall-man:
 	- rm -f $(DEST_CMAN) $(DEST_EMAN)
 
diff --git a/configure.ac b/configure.ac
index 719634b..e989d13 100644
--- a/configure.ac
+++ b/configure.ac
@@ -146,6 +146,9 @@ AC_ARG_WITH(posix-regex,
 AC_ARG_WITH(readlib,
 [  --with-readlib          include readtags library object during install])
 
+AC_ARG_WITH(readcmd,
+[  --with-readcmd          include readtags command during install])
+
 # AC_ARG_WITH(perl-regex,
 # [  --with-perl-regex       use Perl pcre interface, if available])
 
@@ -204,6 +207,13 @@ if test yes = "$with_readlib"; then
 else
 	AC_MSG_RESULT(no)
 fi
+AC_MSG_CHECKING(whether to install readtags command)
+if test yes = "$with_readcmd"; then
+	AC_MSG_RESULT(yes)
+	install_targets="$install_targets install-cmd"
+else
+	AC_MSG_RESULT(no)
+fi
 AC_SUBST(install_targets)
 
 if test "$enable_custom_config" = no -o "$enable_custom_config" = yes ; then
-- 
1.8.5.2

Re: [Ctags-devel] Infinite loop in vim.c

[Alexey R. <ale...@gm...>]

NB: In the 'case 8' in isMap() constant '8' inside strncmp() must also be
'len' as in other cases.


2014/1/13 Alexey Radkov <ale...@gm...>

> Hi David.
>
> Today i encountered same issue again. (Infinite loop in ctags). This time
> the issue was due to presence of external code in viml. Here is content of
> abusing code:
>
>
> python<<EOF
> # We register openers with PandocRegisterExecutor.
> # We take its first argument as the name of a vim ex command, the second
> # argument as a mapping, and the rest as the description of a command,
> # which we'll pass to pandoc_open.
>
> # pandoc_register_executor(...) adds a tuple of those elements to a list of
> #executors. This list will be # read from by ftplugin/pandoc.vim and
> commands
> #and mappings will be created from it.
> pandoc_executors = []
>
> def pandoc_register_executor(com_ref):
>     args = com_ref.split()
>     name = args[0]
>     mapping = args[1]
>     type = args[2]
>     command = args[3:]
>     pandoc_executors.append((name, mapping, type, " ".join(command)))
> EOF
>
> command! -nargs=? PandocRegisterExecutor exec 'py
> pandoc_register_executor("<args>")'
>
> " We register here some default executors. The user can define other custom
> " commands in his .vimrc.
> "
> " Generate html and open in default html viewer
> PandocRegisterExecutor PandocHtml <LocalLeader>html html pandoc -t html
> -Ss -o %:r.html %%
> " Generate pdf w/ citeproc and open in default pdf viewer
> PandocRegisterExecutor PandocPdf <LocalLeader>pdf pdf markdown2pdf
> PANDOC#P_BIBS -o %:r.pdf %%
> " Generate odt w/ citeproc and open in default odt viewer
> PandocRegisterExecutor PandocOdt <LocalLeader>odt odt pandoc -t odt
> PANDOC#P_BIBS -o %:r.odt %%
>
>
> This was taken from vim pandoc plugin. Try to do
>
> ctags -f - --format=2 --excmd=pattern --fields=nksSa --extra= --sort=yes
> --language-force=vim --vim-kinds=vfacm pandoc.vim
>
> and you'll get infinite loop!
>
> I attached a patch that will fix it: readVimLine() checks whether it is
> inside external code context and skips until the endmarker found. There is
> a new auxiliary function skipExternalCode() for that. I also reimplemented
> function isMap() as far as skipExternalCode() is very similar and i found
> that checks like
>
> strncmp ((const char*) line, "nno",      (size_t) 3) == 0 ||
> strncmp ((const char*) line, "nnor",     (size_t) 4) == 0 ||
> strncmp ((const char*) line, "nnore",    (size_t) 5) == 0 ||
> strncmp ((const char*) line, "nnorem",   (size_t) 6) == 0 ||
> strncmp ((const char*) line, "nnorema",  (size_t) 7) == 0 ||
> strncmp ((const char*) line, "nnoremap", (size_t) 8) == 0 ||
>
> have little sense because if last condition triggers then all the previous
> must also trigger. Additionally the new version checks that the word is a
> lexem (i.e. is a complete word). I tested the patch on my large .vimrc and
> all worked fine.
>
> Cheers, Alexey.
>
>
>
>
> 2012/6/20 Alexey Radkov <ale...@gm...>
>
>> Hi David.
>>
>> Your change works really well:
>>
>>
>> ./ctags -f - --format=2 --excmd=pattern --fields=nksSa --extra=
>> --sort=yes --language-force=vim --vim-kinds=vfacm
>> /home/lyokha/.vim/Align.vba
>>
>> (no output, no delay)
>>
>> ./ctags -f - --format=2 --excmd=pattern --fields=nksSa --extra=
>> --sort=yes --language-force=vim --vim-kinds=vfacmn
>> /home/lyokha/.vim/Align.vba
>> autoload/Align.vim    /home/lyokha/.vim/Align.vba
>> /^autoload\/Align.vim    [[[1$/;"    n    line:2432
>> autoload/AlignMaps.vim    /home/lyokha/.vim/Align.vba
>> /^autoload\/AlignMaps.vim    [[[1$/;"    n    line:3562
>> doc/Align.txt    /home/lyokha/.vim/Align.vba    /^doc\/Align.txt
>> [[[1$/;"    n    line:836
>> plugin/AlignMapsPlugin.vim    /home/lyokha/.vim/Align.vba
>> /^plugin\/AlignMapsPlugin.vim    [[[1$/;"    n    line:47
>> plugin/AlignPlugin.vim    /home/lyokha/.vim/Align.vba
>> /^plugin\/AlignPlugin.vim    [[[1$/;"    n    line:4
>> plugin/cecutil.vim    /home/lyokha/.vim/Align.vba
>> /^plugin\/cecutil.vim    [[[1$/;"    n    line:298
>>
>> (listed all files to be installed).
>>
>> Probably author of tagbar would like to add the new option 'n' by default.
>>
>> Thank you, Alexey.
>>
>>
>>
>> 2012/6/20 David Fishburn <dfi...@gm...>
>>
>>>  Good Morning Alexey.
>>>
>>> I have checked in a change for this.
>>>
>>> Now, when .vba files (Vimball Archive) are used, they are parsed
>>> differently from .vim files.
>>> I also added a new kind:
>>>     { TRUE,  'n', "filename", "vimball filename" },
>>>
>>> So the full list is:
>>>     Vim
>>>         a  autocommand groups
>>>         c  user-defined commands
>>>         f  function definitions
>>>         m  maps
>>>         v  variable definitions
>>>         n  vimball filename
>>>
>>>
>>> If you use the taglist or tagbar plugins, then you will want to add the
>>> following to your vimrc, so these new kinds show up automatically.
>>>
>>> let g:tlist_vim_settings  = 'vim;p:Project;a:autocommand
>>> groups;c:user-defined commands;f:function definitions;m:maps;v:variable
>>> definitions;n:vimball filename'
>>>
>>> let g:tagbar_type_vim  = {
>>>             \ 'ctagstype' : 'vim',
>>>             \ 'kinds'     : [
>>>             \ 'p:Project',
>>>             \ 'a:autocommand groups',
>>>             \ 'c:user-defined commands',
>>>             \ 'f:function definitions',
>>>             \ 'm:maps',
>>>             \ 'v:variable definitions',
>>>             \ 'n:vimball filename'
>>>             \ ]
>>>             \ }
>>>
>>>
>>> Opening the Align.vba file will now show the following tags:
>>> vimball filename
>>>     autoload/Align.vim
>>>     autoload/AlignMaps.vim
>>>     doc/Align.txt
>>>     plugin/AlignMapsPlugin.vim
>>>     plugin/AlignPlugin.vim
>>>     plugin/cecutil.vim
>>>
>>> Thanks for reporting the problem.
>>>
>>> If you wouldn't mind verifying the fix and if you have suggested
>>> changes, feel free to mention them.
>>> I will post this information to the Vim_use list in a couple of days.
>>>
>>> Dave
>>>
>>>
>>>
>>> On 19/06/2012 10:20 AM, Alexey Radkov wrote:
>>>
>>> Hi David.
>>>
>>> Here is the link (from official vim scripts page):
>>>
>>> http://www.vim.org/scripts/download_script.php?src_id=18148
>>>
>>> Downoad it, then unzip it and do the ctags command on it
>>>
>>> Cheers, Alexey.
>>>
>>>
>>> 2012/6/19 David Fishburn <dfi...@gm...>
>>>
>>>>  Thanks for the report Alexey.
>>>>
>>>> Could you send me the Align.vba script and I will try it out.
>>>>
>>>> Dave
>>>>
>>>>
>>>> On 19/06/2012 5:15 AM, Alexey Radkov wrote:
>>>>
>>>>  Hi.
>>>>
>>>> Recently i tried to update latest Align.vba in vim and my vim hung.  I
>>>> found that this was due to the autoopen feature of plugin tagbar during
>>>> which following command takes place:
>>>>
>>>> /usr/local/bin/ctags -f - --format=2 --excmd=pattern --fields=nksSa
>>>> --extra= --sort=yes --language-force=vim --vim-kinds=vfacm
>>>> /home/lyokha/.vim/Align.vba
>>>>
>>>> I tried to issue it in command-line and it hung. The backtrace of the
>>>> hung command is:
>>>>
>>>> (gdb) bt
>>>> #0  0x00000000004242a5 in parseCommand (line=<optimized out>, line@entry=0xbb6c13
>>>> "command (ie. they are left justified, too).") at vim.c:396
>>>> #1  0x0000000000424f90 in parseVimLine (line=0xbb6c13 "command (ie.
>>>> they are left justified, too).") at vim.c:584
>>>> #2  parseVimFile (line=<optimized out>) at vim.c:618
>>>> #3  findVimTags () at vim.c:633
>>>> #4  0x000000000041aee7 in createTagsForFile (passCount=1, language=40,
>>>> fileName=0x7fffbd832f22 "/home/lyokha/.vim/Align.vba") at parse.c:617
>>>> #5  createTagsWithFallback (language=40, fileName=0x7fffbd832f22
>>>> "/home/lyokha/.vim/Align.vba") at parse.c:639
>>>> #6  parseFile (fileName=fileName@entry=0x7fffbd832f22
>>>> "/home/lyokha/.vim/Align.vba") at parse.c:666
>>>> #7  0x0000000000413f87 in createTagsForEntry (entryName=0x7fffbd832f22
>>>> "/home/lyokha/.vim/Align.vba") at main.c:303
>>>> #8  0x00000000004024c0 in createTagsForArgs (args=0xb68120) at
>>>> main.c:348
>>>> #9  makeTags (args=0xb68120) at main.c:494
>>>> #10 main (argc=<optimized out>, argv=<optimized out>) at main.c:562
>>>> (gdb) l
>>>> 391         * Strip off any spaces and options which are part of the
>>>> command.
>>>> 392         * These should preceed the command name.
>>>> 393         */
>>>> 394        do
>>>> 395        {
>>>> 396            if (isspace ((int) *cp))
>>>> 397            {
>>>> 398                ++cp;
>>>> 399            }
>>>> 400            else if (*cp == '-')
>>>> (gdb)
>>>> 401            {
>>>> 402                /*
>>>> 403                 * Read until the next space which separates options
>>>> or the name
>>>> 404                 */
>>>> 405                while (*cp && !isspace ((int) *cp))
>>>> 406                    ++cp;
>>>> 407            }
>>>> 408        } while ( *cp &&  !isalnum ((int) *cp) );
>>>> 409
>>>> 410        if ( ! *cp )
>>>>
>>>> Evidently it tries to parse line
>>>>
>>>> "command (ie. they are left justified, too)."
>>>>
>>>> in Align.vba source (the line is not correct vim command of course, but
>>>> rather some comment or help), and ctags is unable to go over the do-loop
>>>> with check for  !isalnum() (*cp is '(' here and the pointer never changes).
>>>>
>>>> Btw current release version works fine with it, i suppose it changed
>>>> after revision r762:
>>>>
>>>> ------------------------------------------------------------------------
>>>> r762 | dfishburn | 2010-07-28 15:38:19 +0400 (Ср., 28 июля 2010) | 9
>>>> lines
>>>>
>>>> VIM Parser updates for bug 3032253.
>>>>
>>>> Vim parser did not handle an invalid 'command' format and hung".
>>>> Now it handles and checks for these formats:
>>>>    command.
>>>>    command!.
>>>>    comma!.
>>>>    comma! ThisIsValid
>>>>
>>>>
>>>> Cheers, Alexey.
>>>>
>>>>
>>>>  ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>> will include endpoint security, mobile security and the latest in malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Ctags-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/ctags-devel
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond.
>>>> Discussions
>>>> will include endpoint security, mobile security and the latest in
>>>> malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Ctags-devel mailing list
>>>> Cta...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/ctags-devel
>>>>
>>>>
>>>
>>>
>>>
>>
>