[Cscope-devel] Repository move required.

[Hans-Bernhard Bröker <HBBroeker@t-...>]

Hello everyone,

I'll assume most of you have heard that SF.net is about to discontinue 
CVS service next month.  In preparing for this, I propose we change over 
to a git repository (still at SF.net).  SVN would be available, too, but 
we might as well make the leap to what everybody is using these days...

One key element for such a move is a mapping of SF.net user names to 
mail addresses and time zone preferences.  An autogenerated first draft 
would be this:

horman = Neil Horman <nhorman@...>
uzi = Joshua Uziel <uzi@...>
darrylo = Darrylo Okahata <darrylo@...>
hops1 = Mike Hopkirk <hops@...>
petr = Petr Sorfa <petr@...>
cvs-fast-export = cvs-fast-export <cvs-fast-export>
broeker = Hans-Bernhard Broeker <broeker@...> 
Europe/Berlin

Anyone wanting this changed should speak up soon-ish.

[Cscope-devel] Clearing backlog of reported bugs?

[Alex <alexinbeijing@gm...>]

Dear cscope devs,

I'm a cscope user who was just browsing your project page and noticed a
very long backlog of bug reports, some more than 10 years old. At first I
thought the project may have been unmaintained for years, but it seems
that's not the case.

Are you interested in accepting patches which fix some of those bugs? If
so, would you accept a contribution of a test suite first (to help prevent
regressions when working on the bugs)?

Thank you,
Alex Dowad

[Cscope-devel] cscope-15.8b released

[Hans-Bernhard Bröker <HBBroeker@t-...>]

Hello everybody,

I decided that the bug fix in egrep.y needed to be spread out more, so I 
made a new release of cscope today.  It's tagged v15_8b in CVS, and the 
release tar ball is out on SourceForge.net.

Hans-Bernhard Broeker

Re: [Cscope-devel] Build Specific Cscope Search Results

[Roberto E. Vargas Caballero <k0ga@sh...>]

> there was a way to limit the search results to only contain hits for source
> files that had actually been used for the last build it would be awesome.

You can generate a cscope.files using a find command where access time
of the files must be bigger than date of last build (date when make was
called, not date of last executable).

-- 
Roberto E. Vargas Caballero

Re: [Cscope-devel] Build Specific Cscope Search Results

[Hans-Bernhard Bröker <HBBroeker@t-...>]

On 07.05.2014 20:17, Jemiah Aitch wrote:

> I've been using cscope for years and there's one feature that I think would
> be awesome. Specifically when using it with the Linux kernel many of the
> search results aren't relevant to the build that's being worked on.

While that may be so, please keep in mind that cscope is a tool for 
inspecting the source.  As in: all of it.  It'll index code in non-taken 
#if/#else blocks, code in functions that aren't ever actually called, 
etc.  And that's actually a good thing, because that way you won't miss 
stuff that's just disabled at the moment.  Finding more than you were 
looking for may seem to hurt, but it's nowhere near as bad as _not_ 
finding stuff that you were, indeed, looking for, and never knowing 
about it.

If you don't even see large parts of the source, any idea you form about 
the source by looking at that subset, and more so any change you make to 
it, is endangered by tunnel vision.  You'll end up checking/changing 
"all" occurrences of a given name, but missing a good deal of them, 
because they weren't in your current filtered view.

People will be _very_ cross with you if you submit a change that breaks 
virtually all builds of the kernel except the particular one you were 
looking at.

> If there was a way to limit the search results to only contain hits
> for source files that had actually been used for the last build it
> would be awesome.

So run cscope with a file list that holds only those files.  Easy.

Building that list is none of cscope's business, though.  That would 
violate the "one tool <--> one task" principle of Unix.  To make any 
sense, this file has to be built by make itself, using the actual 
Makefiles, and the same configuration options used to build the kernel + 
modules itself.

The kernel Makefile already builds such a cscope.files, but it puts all 
available C sources in there, not just the active ones.  IMHO, that's 
the correct way of doing it.

[Cscope-devel] Build Specific Cscope Search Results

[Jemiah Aitch <jemiaha@gm...>]

I've been using cscope for years and there's one feature that I think would
be awesome. Specifically when using it with the Linux kernel many of the
search results aren't relevant to the build that's being worked on. If
there was a way to limit the search results to only contain hits for source
files that had actually been used for the last build it would be awesome.
This could be done by looking for a matching object file in the same
directory as the source or, even better, looking at the makefiles to see if
the source files was used to generate an existing object file. I did some
searching but didn't see any indication that this feature exists. I'd be
curious to here what other people think about the idea.

Thanks
.

Re: [Cscope-devel] cscope: issue with symlinks in tools/testing/selftests/powerpc/copyloops/

[Michael Ellerman <mpe@el...>]

On Thu, 2014-04-03 at 15:16 +0200, Yann Droneaud wrote:
> Hi,
> 
> I'm using cscope to browse kernel sources, but I'm facing warnings from
> the tool since following commit:
> 
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=22d651dcef536c75f75537290bf3da5038e68b6b
> 
>     commit 22d651dcef536c75f75537290bf3da5038e68b6b
>     Author: Michael Ellerman <mpe@...>
>     Date:   Tue Jan 21 15:22:17 2014 +1100
> 
>     selftests/powerpc: Import Anton's memcpy / copy_tofrom_user tests

Ooops, sorry.

> cscope reports error when generating the cross-reference database:
> 
>     $ make ALLSOURCE_ARCHS=all O=./obj-cscope/ cscope
>       GEN     cscope
>     cscope: cannot find
> file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/copyuser_power7.S
> 
> It's a rather uncommon side effect of having (for the first time ?)
> sources files as symlinks: looking for symlinks in the kernel sources
> returns only:
> 
>     $ find . -type l
>     ./arch/mips/boot/dts/include/dt-bindings
>     ./arch/microblaze/boot/dts/system.dts
>     ./arch/powerpc/boot/dts/include/dt-bindings
>     ./arch/metag/boot/dts/include/dt-bindings
>     ./arch/arm/boot/dts/include/dt-bindings
>     ./tools/testing/selftests/powerpc/copyloops/copyuser_power7.S
>     ./tools/testing/selftests/powerpc/copyloops/memcpy_64.S
>     ./tools/testing/selftests/powerpc/copyloops/memcpy_power7.S
>     ./tools/testing/selftests/powerpc/copyloops/copyuser_64.S


Right.

I did check that there were other symlinks already in the tree, but you're
correct I seem to be the first clever person to add symlinks to source files.

> So one can wonder if having symlinked sources files is an expected
> supported feature for kbuild and all the various kernel
> tools/infrastructure ?

Kbuild is not involved really, these files are just built with plain Makefiles,
at least from the symlink side.

FWIW ctags seems to cope, that's what I use.

But I didn't think of cscope.


Given you're the only person who's noticed I suspect most other things haven't
broken, fingers crossed :)

cheers

[Cscope-devel] Performance improvements

[Elad Lahav <e2lahav@gm...>]

I was made aware that the sorting code I wrote for min-cscope a few years
ago (primarily targeted at Windows) was not performing very well on Linux
and FreeBSD. I re-wrote the code which now runs faster than GNU sort (at
least for the postings list produced by Cscope and compared with the sort
version on Ubuntu 12.04). The code is also much more compact and fits
nicely within a single source file. Consequently, I would like to propose
its inclusion in the main Cscope code. The attached patch provides the new
sort.c and sort.h files, the necessary changes to build.c, crossref.c,
invlib.c and Makefile.am. It also replaces a linear search within invmake()
with a binary search, which gives an additional performance boost.

Performance results:
Ran a clean Cscope build on the Linux 3.13.7 tree (~35K files) with a warm
cache (i.e., ran a clean build first and discarded the results).

Vanilla Cscope:
elahav@...:~/src/linux-3.13.7$ time /usr/bin/cscope -b -k -q

real    0m52.349s
user    1m13.193s
sys     0m2.680s

Modified Cscope:
elahav@...:~/src/linux-3.13.7$ time ~/tmp/cscope/src/cscope -b -k -q

real    0m33.800s
user    0m30.874s
sys     0m1.224s

Verified that the generated DB is sane by running a query for all
references to '.*kernel.*' (there are 7647 of those) and made sure the
vanilla and modified versions produced the same results.

Note: after applying the patch, you need to run autoreconf to update the
various build configuration files.

--Elad

P.S.,
There are annoying inconsistencies in indentation throughout the code, with
a mixture of tabs and spaces, even within single files. Should probably be
cleaned-up at some point.

Re: [Cscope-devel] cscope: issue with symlinks in tools/testing/selftests/powerpc/copyloops/

[Hans-Bernhard Bröker <HBBroeker@t-...>]

On 07.04.2014 14:42, Gerhard Sittig wrote:

> So there are valid reasons to not process those filesystem
> entries.  Would it be useful to not emit the warnings then?

The warnings wouldn't even appear if cscope were allowed to do the tree 
traversal by itself.  I.e. cscope -R already skips symlinks silently, 
without emitting any warnings (see issrcfile() testing for S_ISREG()).

You only get those warnings if cscope was explicitly told, by way of a 
name list file (cscope.index, or -i option), to index a given set of 
files, and there are symlinks in that list.  All you would have to do is 
keep the symlinks out of that name list file.

I don't see a need for a change in cscope here.  The desired behaviour 
can be had without changing cscope.

Re: [Cscope-devel] cscope: issue with symlinks in tools/testing/selftests/powerpc/copyloops/

[Neil Horman <nhorman@tu...>]

On Mon, Apr 07, 2014 at 02:42:59PM +0200, Gerhard Sittig wrote:
> On Mon, 2014-04-07 at 06:42 -0400, Neil Horman wrote:
> > 
> > On Thu, Apr 03, 2014 at 03:16:15PM +0200, Yann Droneaud wrote:
> > > 
> > > [ ... ]
> > > 
> > > cscope reports error when generating the cross-reference database:
> > > 
> > >     $ make ALLSOURCE_ARCHS=all O=./obj-cscope/ cscope
> > >       GEN     cscope
> > >     cscope: cannot find
> > > file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/copyuser_power7.S
> > >     cscope: cannot find
> > > file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/memcpy_64.S
> > >     cscope: cannot find
> > > file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/memcpy_power7.S
> > >     cscope: cannot find
> > > file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/copyuser_64.S
> > > 
> > > And when calling cscope from ./obj-cscope/ directory, it reports errors
> > > too.
> > > 
> > > Hopefully it doesn't stop it from working, so I'm still able to use
> > > cscope to browse kernel sources.
> > > 
> > No, it won't stop it from working, it just won't search those files.  I don't
> > recall exactly the reason, but IIRC there was a big discussion long ago about
> > symlinks and our ability to support them (around version 1.94 I think).  We
> > decided to not handle symlinks, as they would either point outside our search
> > tree, which we didn't want to include, or would point to another file in the
> > search tree, which made loading them pointless (as we would cover the search in
> > the pointed file).
> 
> So there are valid reasons to not process those filesystem
> entries.  Would it be useful to not emit the warnings then?  Or
> to silent those warnings when the user knows it's perfectly legal
> to skip those filesytem entries?  Like what you can do with the
> ctags(1) command and its --links option.
> 
I would see no problem with an option to do that.  I'd like to make it opt-in,
so that people who want to know about symlink issues will still see them, but
I'd be supportive of an option to quiet them
Neil

> 
> virtually yours
> Gerhard Sittig
> -- 
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office@...
> 

Re: [Cscope-devel] cscope: issue with symlinks in tools/testing/selftests/powerpc/copyloops/

[Neil Horman <nhorman@tu...>]

On Thu, Apr 03, 2014 at 03:16:15PM +0200, Yann Droneaud wrote:
> Hi,
> 
> I'm using cscope to browse kernel sources, but I'm facing warnings from
> the tool since following commit:
> 
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=22d651dcef536c75f75537290bf3da5038e68b6b
> 
>     commit 22d651dcef536c75f75537290bf3da5038e68b6b
>     Author: Michael Ellerman <mpe@...>
>     Date:   Tue Jan 21 15:22:17 2014 +1100
> 
>     selftests/powerpc: Import Anton's memcpy / copy_tofrom_user tests
>     
>     Turn Anton's memcpy / copy_tofrom_user test into something that can
>     live in tools/testing/selftests.
>     
>     It requires one turd in arch/powerpc/lib/memcpy_64.S, but it's 
>     pretty harmless IMHO.
>     
>     We are sailing very close to the wind with the feature macros. We 
>     define them to nothing, which currently means we get a few extra 
>     nops and include the unaligned calls.
>     
>     Signed-off-by: Anton Blanchard <anton@...>
>     Signed-off-by: Michael Ellerman <mpe@...>
>     Signed-off-by: Benjamin Herrenschmidt <benh@...>
> 
> 
> cscope reports error when generating the cross-reference database:
> 
>     $ make ALLSOURCE_ARCHS=all O=./obj-cscope/ cscope
>       GEN     cscope
>     cscope: cannot find
> file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/copyuser_power7.S
>     cscope: cannot find
> file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/memcpy_64.S
>     cscope: cannot find
> file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/memcpy_power7.S
>     cscope: cannot find
> file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/copyuser_64.S
> 
> And when calling cscope from ./obj-cscope/ directory, it reports errors
> too.
> 
> Hopefully it doesn't stop it from working, so I'm still able to use
> cscope to browse kernel sources.
> 
No, it won't stop it from working, it just won't search those files.  I don't
recall exactly the reason, but IIRC there was a big discussion long ago about
symlinks and our ability to support them (around version 1.94 I think).  We
decided to not handle symlinks, as they would either point outside our search
tree, which we didn't want to include, or would point to another file in the
search tree, which made loading them pointless (as we would cover the search in
the pointed file).

Neil

> It's a rather uncommon side effect of having (for the first time ?)
> sources files as symlinks: looking for symlinks in the kernel sources
> returns only:
> 
>     $ find . -type l
>     ./arch/mips/boot/dts/include/dt-bindings
>     ./arch/microblaze/boot/dts/system.dts
>     ./arch/powerpc/boot/dts/include/dt-bindings
>     ./arch/metag/boot/dts/include/dt-bindings
>     ./arch/arm/boot/dts/include/dt-bindings
>     ./tools/testing/selftests/powerpc/copyloops/copyuser_power7.S
>     ./tools/testing/selftests/powerpc/copyloops/memcpy_64.S
>     ./tools/testing/selftests/powerpc/copyloops/memcpy_power7.S
>     ./tools/testing/selftests/powerpc/copyloops/copyuser_64.S
>     ./obj-cscope/source
>     ./Documentation/DocBook/vidioc-g-sliced-vbi-cap.xml
>     ./Documentation/DocBook/vidioc-decoder-cmd.xml
> ...
>     ./Documentation/DocBook/media-func-ioctl.xml
>     ./Documentation/DocBook/vidioc-enumoutput.xml
> 
> 
> So one can wonder if having symlinked sources files is an expected
> supported feature for kbuild and all the various kernel
> tools/infrastructure ?
> 
> Regarding cscope specifically, it does not support symlink, and it's the
> expected behavior according to the bug reports I was able to find:
> 
> #214 cscope ignores symlinks to files 
> http://sourceforge.net/p/cscope/bugs/214/
> 
> #229 -I options doesn't handle symbolic link
> http://sourceforge.net/p/cscope/bugs/229/
> 
> #247 cscope: cannot find file 
> http://sourceforge.net/p/cscope/bugs/247/
> 
> #252 cscope: cannot find file *** 
> http://sourceforge.net/p/cscope/bugs/252/
> 
> #261 Regression - version 15.7a does not follow symbolic links 
> http://sourceforge.net/p/cscope/bugs/261/
> 
> 
> Regards.
> 
> -- 
> Yann Droneaud
> OPTEYA
> 
> 
> 

Re: [Cscope-devel] xcscope.el maintainership

[Dima Kogan <cscope@di...>]

cscope@... writes:

> Dima Kogan <cscope@...> writes:
>
> I tested several flavors of emacs. Xemacs 21 and GNU emacs 23+ appear to
> work. It doesn't make sense to support anything older, I don't think.
> Does that sound reasonable?

Gentlemen:

The copy of xcscope.el that lives here appears to be stable, so I
started a new project with JUST xcscope.el:

 https://github.com/dkogan/xcscope.el

I don't consider this a fork, since the in-tree code doesn't really
change.

The main changes are listed at that page. This new code is now
distributed in MELPA and in Ubuntu and in Debian. As I said before, this
tree fixes bugs and adds features, but tries not to break anything or
change any functionality that existing users may rely on.

I ask that at the very least a note be added to the in-tree xcscope.el
to point users to the new tree. If yall agree to do this, I'll reply
with the bug tracker and patch tracker entries that have now been
handled.

Thanks

dima

Re: [Cscope-devel] A small addition to cscope

[Hans-Bernhard Bröker <HBBroeker@t-...>]

On 05.12.2013 22:15, asharpe@... wrote:

>I have a
> sourceforge account, but I am unclear about the actual mechanics of how I
> can get code reviewed and added into the code. Any help you folks could
> provide would be greatly appreciated.

You could post it as a patch to the corresponding tracker on the project 
page at SourceForge.  One of the team members may decide to put it into 
CVS from there.

[Cscope-devel] A small addition to cscope

[<asharpe@an...>]

Hi folks,

About 20 years ago, I added some features to cscope, like the progress bar
and the concept of using TAB to go back and forth in the interface and a
variable number of results shown based on screen size, and a few others
(my name is in the README already). I also added the ability to toggle
showing the full paths of the files. That last change apparently never got
in, so, I've just reimplemented it on top of cscope-15.8a. I have a
sourceforge account, but I am unclear about the actual mechanics of how I
can get code reviewed and added into the code. Any help you folks could
provide would be greatly appreciated.

Andrew

Re: [Cscope-devel] xcscope.el maintainership

[Dima Kogan <cscope@di...>]

Dima Kogan <cscope@...> writes:

> I only tested this in emacs 24. What is the oldest version of xemacs
> you were targeting? How about GNU emacs? I'll test these once I know
> what they are.

Hi.

I tested several flavors of emacs. Xemacs 21 and GNU emacs 23+ appear to
work. It doesn't make sense to support anything older, I don't think.
Does that sound reasonable?

dima

Re: [Cscope-devel] Some patches for cscope

[Hans-Bernhard Bröker <HBBroeker@t-...>]

On 25.09.2013 09:24, Roberto E. Vargas Caballero wrote:
>> Actually you don't need to change the code at all to get that
>> effect. CSCOPE_EDITOR exists, and does what you want to use VISUAL
>> for.
>
> VISUAL is a standard variable and is used by all Unix programs.

You're trying to argue against the cold facts there: cscope is one of 
the oldest Unix programs there is, and it evidently never bothered with 
VISUAL.  Nor does any of the Unix standardization efforts (outside 
Linux) appear to have included it (not POSIX, not SUS).

As-is, cscope already chooses between 4 different programs to run as the 
viewer/editor: $CSCOPE_EDITOR, $VIEWER, $EDITOR and plain vi.  I don't 
see how adding yet another one makes anything any simpler.


Regarding the idea of smuggling a tag letter into the search string:

> Uhmmmm, it's true. I usually use cscope for c programs, but it is
> possible to use it in other very different ways. I think this funcionality
> is great, because there is a lot of information in the cscope index
> that can be very usueful to the users,

Unfortunately this aspect of the information in the database also 
appears to be routinely rather out of touch with reality, particularly 
where the definitions of enum/struct/union are concerned.  That doesn't 
disturb normal operation of cscope, because these are never actually 
displayed.  But exposing this level of detail would tend to cause quite 
some irritation --- quite possibly more than the feature's worth.

cscope is not a replacement for the browsing capabilities of tools 40 
years younger than itself like, say, the CDT brower in Eclipse.  Nor 
should it even try to be, IMHO.

Re: [Cscope-devel] Some patches for cscope

[Roberto E. Vargas Caballero <k0ga@sh...>]

> Actually you don't need to change the code at all to get that
> effect. CSCOPE_EDITOR exists, and does what you want to use VISUAL
> for.

VISUAL is a standard variable and is used by all Unix programs. If I
have to define a new variable for each program I use then I will define
dozens of them. You can take a look about VISUAL-EDITOR in these pages:

http://www.faqs.org/docs/artu/ch10s04.html#id2942810
http://en.wikibooks.org/wiki/Guide_to_Unix/Environment_Variables
http://unixhelp.ed.ac.uk/CGI/man-cgi?more
http://pubs.opengroup.org/onlinepubs/007908799/xbd/envvar.html
https://help.ubuntu.com/community/EnvironmentVariables


> >Patch 0003: This patch adds a way of filtering the results in finddef function,
> >	    since we have information about the kind of symbol. I have add
> >	    a solution which doesn't increment the number of options in the
> >	    graphical interface (it is already big), and it is basically
> >	    add the kind of definition in the search pattern. I don't have
> >	    modified the manual page, because I don't know if this change
> >	    will be good for you.
> 
> I'm tending to reject this, on the basis of it modifying more than
> it really should. The character '@' isn't quite as forbidden to
> appear in search patterns as you might think.  Many people are using
> cscope on untopical input.  Those would hate us for making @
> unusable in searches.


Uhmmmm, it's true. I usually use cscope for c programs, but it is
possible to use it in other very different ways. I think this funcionality
is great, because there is a lot of information in the cscope index
that can be very usueful to the users, and define a new menu option
for each of them is no a way. Maybe the solution is looking for a
less intrusive way of defining the type of search, or defining a
escape character or something like this.

Best regards,

-- 
Roberto E. Vargas Caballero
----------------------------
k0ga@...
http://www.shike2.com

Re: [Cscope-devel] Some patches for cscope

[Hans-Bernhard Bröker <HBBroeker@t-...>]

On 24.09.2013 10:46, Roberto E. Vargas Caballero wrote:

> Patch 0001: Use VISUAL variable when it is avaible and the terminal is not a
> 	    dumb terminal. I have to add this patch because I usually have to
> 	    connect to system which terminal interfaces dumb type, so my
> 	    EDITOR and VISUAL variables have different values, but I usually
> 	    want see sources with vi and not with ex.

Actually you don't need to change the code at all to get that effect. 
CSCOPE_EDITOR exists, and does what you want to use VISUAL for.

> Patch 0002: This patch is only a small addition to the manual page, because
> 	    the assignmenet case was not showed in it.

Accepted as-is.

> Patch 0003: This patch adds a way of filtering the results in finddef function,
> 	    since we have information about the kind of symbol. I have add
> 	    a solution which doesn't increment the number of options in the
> 	    graphical interface (it is already big), and it is basically
> 	    add the kind of definition in the search pattern. I don't have
> 	    modified the manual page, because I don't know if this change
> 	    will be good for you.

I'm tending to reject this, on the basis of it modifying more than it 
really should. The character '@' isn't quite as forbidden to appear in 
search patterns as you might think.  Many people are using cscope on 
untopical input.  Those would hate us for making @ unusable in searches.

[Cscope-devel] Some patches for cscope

[Roberto E. Vargas Caballero <k0ga@sh...>]

Hello,

	I send you some modifications I have done to cscope and I hope can be
useful for other users.

Patch 0001: Use VISUAL variable when it is avaible and the terminal is not a
	    dumb terminal. I have to add this patch because I usually have to
	    connect to system which terminal interfaces dumb type, so my
	    EDITOR and VISUAL variables have different values, but I usually
	    want see sources with vi and not with ex.

Patch 0002: This patch is only a small addition to the manual page, because
	    the assignmenet case was not showed in it.

Patch 0003: This patch adds a way of filtering the results in finddef function,
	    since we have information about the kind of symbol. I have add
	    a solution which doesn't increment the number of options in the
	    graphical interface (it is already big), and it is basically
	    add the kind of definition in the search pattern. I don't have
	    modified the manual page, because I don't know if this change
	    will be good for you. 


	I would like listen your opinion about these changes and if they
must be modified or something.


Best regards, 


-- 
Roberto E. Vargas Caballero
----------------------------
k0ga@...
http://www.shike2.com

Re: [Cscope-devel] xcscope.el maintainership

[Dima Kogan <cscope@di...>]

Darryl Okahata <darrylo@...> writes:

> Can I get a patch for this?  I'd like to see what's changed, and I don't 
> see a patch in the cscope tickets.
>
> (As long as there isn't unnecessary code duplication, I should be able 
> to merge it pretty quickly.)
>
> Thanks.

Hi Darryl.

A diff between the 15.8a release and the latest code is here:

 http://pub.secretsauce.net/xcscope.el.2013_09_16.patch

However I ask that you do not commit it. This patch is large, and is
made up of many discrete commits in version control. There is value in
preserving the history, so if the changes look good to you, the git repo
should be imported rather than squashing it all into a single patch.

The history is here for easy review:

 https://github.com/dkogan/cscope/commits/xcscope_patches[1]

If we decide that leaving xcscope.el as part of the larger cscope
repository makes sense then I can do the import into CVS. There was a
question of coupled releases I asked in an earlier email.

Also it would be great to get this code a bit more tested before doing a
merge; if you can try it out, that'd be great. As I mentioned to you
earlier, I only tested this in emacs 24. What is the oldest version of
xemacs you were targeting? How about GNU emacs? I'll test these once I
know what they are.

Thanks.

dima

Re: [Cscope-devel] xcscope.el maintainership

[Darryl Okahata <darrylo@so...>]

Can I get a patch for this?  I'd like to see what's changed, and I don't 
see a patch in the cscope tickets.

(As long as there isn't unnecessary code duplication, I should be able 
to merge it pretty quickly.)

Thanks.

> Dima Kogan <mailto:cscope@...>
> Sunday, September 15, 2013 2:50 AM
>
> Hi all.
>
> I went through xcscope.el code, and the bugtracker entries. I now have a
> git tree that merges some of the contributed patches, fixes various bugs
> and adds some major features I've wanted for a while. Incidentally the
> biggest feature I've added (handling of multiple searches) was the
> subject of the larger bugtracker patches. I consider my implementation
> much better than what was contributed, so those patches were not merged.
> A changelog is at the bottom of this email. I haven't yet made any
> comments on the bug tracker itself since the future of my tree isn't
> decided yet.
>
> Now about logistics. I added some features, but there are more I'd like
> to write when I have some time. If xcscope.el lives in the cscope tree,
> then any release of xcscope.el is attached to a release of cscope. At
> least in the near future xcscope.el is going to be a faster-moving
> project than cscope, so would we be ok with making releases mostly for
> the sake of xscope.el?
>
> Hans-Bernhard and Darryl: I take it you are against splitting this code
> out of the main cscope tree? I still think this is the best option, but
> if more frequent releases are possible, then staying joined maybe is ok.
> I do NOT want to create a fork, so let's try to work something out.
>
> The updated xcscope.el tree is at
>
> https://github.com/dkogan/cscope/tree/xcscope_patches
>
> The feature changelog:
>
> - New searches are appended to the *cscope* buffer, instead of 
> overwriting. The
> user thus sees a history of cscope search results in this buffer, and 
> is able
> to navigate through all fo them. There is a size limit to keep the 
> buffer from
> growing out of control.
>
> - The *cscope* buffer can be navigated and edited similarly to emacs 
> Diff buffers:
>
> - n/p navigates over individual results
> - k kills individual results
>
> - N/P or M-n/M-p navigates over file results
> - M-k kills file results
>
> - M-N/M-P navigates over result sets
> - M-K kills result sets
>
> - Navigation from outside the *cscope* buffer (C-c s n/p/N/P) is 
> restricted to
> the result set at (point)
>
> - Previous searches can be re-run with the 'r' key in the *cscope* 
> buffer. These
> are written in-place, overwriting the older results.
>
> - Fuzzy matching is now enabled/disabled for specific types of 
> searches. This
> was implemented earlier, but the implementation had a bug and wasn't 
> working
>
> - xcscope.el can now work remotely over TRAMP
>
> - The cscope-index output now goes to the echo area instead of an 
> explicit new
> buffer that the user must deal with
>
> - Fuzzy searching now works for non-trivial regex searches
>
> - The mouse face respects cscope-use-face
>
> - Better mouse support:
> - button3 opens a popup menu that runs prompt-less searches
> - shift-button3 reruns the last search on the point. This is thus even 
> more
> prompt-less
>
>
> dima
>
> ------------------------------------------------------------------------------
> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, 
> SharePoint
> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack 
> includes
> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13.
> http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk
> _______________________________________________
> Cscope-devel mailing list
> Cscope-devel@...
> https://lists.sourceforge.net/lists/listinfo/cscope-devel
>
> Hans-Bernhard Bröker <mailto:HBBroeker@...>
> Sunday, July 28, 2013 4:09 AM
> On 28.07.2013 09:02, Dima Kogan wrote:
>
>> These are all assigned to Darryl, who I assume is no longer active.
>
> Well, you could always ask Darryl directly.  Haven't heard from him in a
> long time, but he might still be reachable.
>
>> and I'd like to ask: does it make sense for these bindings to continue
>> being distributed here? How would yall feel about splitting out that
>> part of the repository into a separate project, and I can then take on
>> maintainership of that code. I am a regular user of those bindings, so
>> this should be a working arrangement.
>
> Or you could do that inside the cscope project.  Our release cycle has
> been very slow these last few year, but it should be possible to
> organize a release of cscope once you have done all those xcscope
> patches you consider necessary.
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Cscope-devel mailing list
> Cscope-devel@...
> https://lists.sourceforge.net/lists/listinfo/cscope-devel
> Dima Kogan <mailto:cscope@...>
> Sunday, July 28, 2013 12:02 AM
> Hi.
>
> I noticed that the cscope emacs bindings (xcscope.el) appear to be
> relatively unmaintained. The last commit was a patch I submitted earlier
> this year:
>
> https://sourceforge.net/p/cscope/patches/79/[1]
>
> The last commit before that happened in 2002. In the meantime there are
> plenty of patches and bugs in the tracker that have been open for years.
> These are all assigned to Darryl, who I assume is no longer active.
>
> I just fixed another bug, and submitted a patch:
>
> https://sourceforge.net/p/cscope/bugs/285/[2]
>
> and I'd like to ask: does it make sense for these bindings to continue
> being distributed here? How would yall feel about splitting out that
> part of the repository into a separate project, and I can then take on
> maintainership of that code. I am a regular user of those bindings, so
> this should be a working arrangement.
>
> Thanks
>
> dima
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Cscope-devel mailing list
> Cscope-devel@...
> https://lists.sourceforge.net/lists/listinfo/cscope-devel

Re: [Cscope-devel] xcscope.el maintainership

[Dima Kogan <cscope@di...>]

Hans-Bernhard Bröker <HBBroeker@...> writes:

> On 28.07.2013 09:02, Dima Kogan wrote:
>
>> and I'd like to ask: does it make sense for these bindings to continue
>> being distributed here? How would yall feel about splitting out that
>> part of the repository into a separate project, and I can then take on
>> maintainership of that code. I am a regular user of those bindings, so
>> this should be a working arrangement.
>
> Or you could do that inside the cscope project.  Our release cycle has 
> been very slow these last few year, but it should be possible to 
> organize a release of cscope once you have done all those xcscope 
> patches you consider necessary.

Hi all.

I went through xcscope.el code, and the bugtracker entries. I now have a
git tree that merges some of the contributed patches, fixes various bugs
and adds some major features I've wanted for a while. Incidentally the
biggest feature I've added (handling of multiple searches) was the
subject of the larger bugtracker patches. I consider my implementation
much better than what was contributed, so those patches were not merged.
A changelog is at the bottom of this email. I haven't yet made any
comments on the bug tracker itself since the future of my tree isn't
decided yet.

Now about logistics. I added some features, but there are more I'd like
to write when I have some time. If xcscope.el lives in the cscope tree,
then any release of xcscope.el is attached to a release of cscope. At
least in the near future xcscope.el is going to be a faster-moving
project than cscope, so would we be ok with making releases mostly for
the sake of xscope.el?

Hans-Bernhard and Darryl: I take it you are against splitting this code
out of the main cscope tree? I still think this is the best option, but
if more frequent releases are possible, then staying joined maybe is ok.
I do NOT want to create a fork, so let's try to work something out.

The updated xcscope.el tree is at

 https://github.com/dkogan/cscope/tree/xcscope_patches

The feature changelog:

- New searches are appended to the *cscope* buffer, instead of overwriting. The
  user thus sees a history of cscope search results in this buffer, and is able
  to navigate through all fo them. There is a size limit to keep the buffer from
  growing out of control.

- The *cscope* buffer can be navigated and edited similarly to emacs Diff buffers:

  - n/p navigates over individual results
  - k kills individual results

  - N/P or M-n/M-p navigates over file results
  - M-k kills file results

  - M-N/M-P navigates over result sets
  - M-K kills result sets

  - Navigation from outside the *cscope* buffer (C-c s n/p/N/P) is restricted to
    the result set at (point)

- Previous searches can be re-run with the 'r' key in the *cscope* buffer. These
  are written in-place, overwriting the older results.

- Fuzzy matching is now enabled/disabled for specific types of searches. This
  was implemented earlier, but the implementation had a bug and wasn't working

- xcscope.el can now work remotely over TRAMP

- The cscope-index output now goes to the echo area instead of an explicit new
  buffer that the user must deal with

- Fuzzy searching now works for non-trivial regex searches

- The mouse face respects cscope-use-face

- Better mouse support:
  - button3 opens a popup menu that runs prompt-less searches
  - shift-button3 reruns the last search on the point. This is thus even more
    prompt-less


dima

[Cscope-devel] Text search question

[Tony Li <tony.li@to...>]

Hi,

I'm using version 15.8a on OS X 10.8.4.

Using the curses interface, I'm trying to a text replacement, looking for "free(badptr);" and replacing it with "better_free(goodptr);"  [Names have been changed to protect the guilty as sin. ;-) ]

I'm able to search for "free", or "badptr", but I can't get scope to find "free(" or "free\(".


What's the magic here?

Thanks,
Tony

Re: [Cscope-devel] xcscope.el maintainership

[Dima Kogan <cscope@di...>]

Darryl Okahata <darrylo@...> writes:

> I'm still here, although I've had no time for anything.  If the patches 
> are still in the tracker, point me to them, and I'll take a look and try 
> to merge them.  I'll have to again learn how to use sourceforge, 
> though.  I think I still have commit permission for the .el files.  This 
> may have to wait until the weekend, however.
>
> -- Darryl

Hi Darryl. It's good you're around and thank you very much for writing
the emacs interface to begin with; I use it all the time.

The tracker items in question are in the "bugs" and "patches" trackers:

 https://sourceforge.net/p/cscope/bugs/
 https://sourceforge.net/p/cscope/patches/

As you can see there are quite a few items assigned to "Darryl". I
haven't done the work to go through them all, so I can't comment on the
quality of the reports.

After the maintainership/hosting situation is figured out, I'd like to
at least merge the history patch:

 https://sourceforge.net/p/cscope/patches/65/

and fix its warts (I've been using it for a while; mostly it's good).
I'd like to make some UI adjustments. I've seen a patch floating around
that moves from one-cscope-process-per-search to
one-cscope-process-per-instance. This should help with performance on
larger repos. In that same vein, adding support for the interted index
would be a good feature. Maybe that should simply be the default.

Let me know if you intend to deal with some of the open issues in the
tracker. If not, I'm happy to take on both that and further maintenance;
ideally outside of sourceforge and CVS.

dima

Re: [Cscope-devel] xcscope.el maintainership

[Darryl Okahata <darrylo@so...>]

I'm still here, although I've had no time for anything.  If the patches 
are still in the tracker, point me to them, and I'll take a look and try 
to merge them.  I'll have to again learn how to use sourceforge, 
though.  I think I still have commit permission for the .el files.  This 
may have to wait until the weekend, however.

-- Darryl

> Dima Kogan <mailto:cscope@...>
> Wednesday, July 31, 2013 3:57 PM
>
> OK. Let me contact Darryl before moving forward on this thread.
>
> Thanks
>
> dima
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> _______________________________________________
> Cscope-devel mailing list
> Cscope-devel@...
> https://lists.sourceforge.net/lists/listinfo/cscope-devel
>
> Hans-Bernhard Bröker <mailto:HBBroeker@...>
> Tuesday, July 30, 2013 1:57 PM
> On 30.07.2013 21:04, Dima Kogan wrote:
>
>> What do you suggest I ask him? Whether he'll soon review the
>> patches/bugs in the tracker assigned to him? It's been years, so I think
>> we know the answer to that.
>
> There's always the possibility that he just forgot about cscope, and
> needs a reminder.  The only way to actually find out the answer is to
> ask the question.
>
>> That's definitely a possibility. I'd personally prefer not to deal with
>> sourceforge/cvs, but this is fine if we can agree that the current place
>> for that code is the right one. My reasoning for splitting out this code
>> is that there are many other interfaces to cscope, and most of them are
>> NOT in the repo.
>
> There be many interfaces, but most of those are stand-alone shells on
> top of cscope.  xcscope.el and the VIM cscope package are unique in that
> they sit _between_ two programs, which makes them depend on both of
> them.  Distributing such two-way interfaces with either the editor or
> cscope makes a good deal more sense than it would for, say, kscope or
> other GUIs.
>
>> This one is in the repo; is this because at one point
>> Darryl was actively maintaining it here?
>
> That's exactly the reason.
>
>> As it stands right now, the
>> presense of xcscope.el in the main repo implies that this interface is
>> somehow more actively supported than the others, and this simply isn't
>> true.
>
> Which is why we owe it to Darryl Okahata to at least ask him before we
> change this, either way.
>
>> I could join the project as "the xcscope.el guy". Would that be
>> preferable to splitting it out? Or should I just go through the tracker
>> and send you patches?
>
> If you're going to be acting on this on any kind of regular basis, you
> should join up.  I cannot meaningfully review patches to elisp anyway,
> so there would be no point in passing them by me.
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> _______________________________________________
> Cscope-devel mailing list
> Cscope-devel@...
> https://lists.sourceforge.net/lists/listinfo/cscope-devel
> Dima Kogan <mailto:cscope@...>
> Tuesday, July 30, 2013 12:04 PM
> Hans-Bernhard Bröker<HBBroeker@...>  writes:
>
>> On 28.07.2013 09:02, Dima Kogan wrote:
>>
>>> These are all assigned to Darryl, who I assume is no longer active.
>> Well, you could always ask Darryl directly.  Haven't heard from him in a
>> long time, but he might still be reachable.
>
> What do you suggest I ask him? Whether he'll soon review the
> patches/bugs in the tracker assigned to him? It's been years, so I think
> we know the answer to that.
>
>
>>> and I'd like to ask: does it make sense for these bindings to continue
>>> being distributed here? How would yall feel about splitting out that
>>> part of the repository into a separate project, and I can then take on
>>> maintainership of that code. I am a regular user of those bindings, so
>>> this should be a working arrangement.
>> Or you could do that inside the cscope project.  Our release cycle has
>> been very slow these last few year, but it should be possible to
>> organize a release of cscope once you have done all those xcscope
>> patches you consider necessary.
>
> That's definitely a possibility. I'd personally prefer not to deal with
> sourceforge/cvs, but this is fine if we can agree that the current place
> for that code is the right one. My reasoning for splitting out this code
> is that there are many other interfaces to cscope, and most of them are
> NOT in the repo. This one is in the repo; is this because at one point
> Darryl was actively maintaining it here? As it stands right now, the
> presense of xcscope.el in the main repo implies that this interface is
> somehow more actively supported than the others, and this simply isn't
> true.
>
> I could join the project as "the xcscope.el guy". Would that be
> preferable to splitting it out? Or should I just go through the tracker
> and send you patches?
>
> Thanks
>
> dima
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> _______________________________________________
> Cscope-devel mailing list
> Cscope-devel@...
> https://lists.sourceforge.net/lists/listinfo/cscope-devel
> Hans-Bernhard Bröker <mailto:HBBroeker@...>
> Sunday, July 28, 2013 4:09 AM
> On 28.07.2013 09:02, Dima Kogan wrote:
>
>> These are all assigned to Darryl, who I assume is no longer active.
>
> Well, you could always ask Darryl directly.  Haven't heard from him in a
> long time, but he might still be reachable.
>
>> and I'd like to ask: does it make sense for these bindings to continue
>> being distributed here? How would yall feel about splitting out that
>> part of the repository into a separate project, and I can then take on
>> maintainership of that code. I am a regular user of those bindings, so
>> this should be a working arrangement.
>
> Or you could do that inside the cscope project.  Our release cycle has
> been very slow these last few year, but it should be possible to
> organize a release of cscope once you have done all those xcscope
> patches you consider necessary.
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Cscope-devel mailing list
> Cscope-devel@...
> https://lists.sourceforge.net/lists/listinfo/cscope-devel
> Dima Kogan <mailto:cscope@...>
> Sunday, July 28, 2013 12:02 AM
> Hi.
>
> I noticed that the cscope emacs bindings (xcscope.el) appear to be
> relatively unmaintained. The last commit was a patch I submitted earlier
> this year:
>
> https://sourceforge.net/p/cscope/patches/79/[1]
>
> The last commit before that happened in 2002. In the meantime there are
> plenty of patches and bugs in the tracker that have been open for years.
> These are all assigned to Darryl, who I assume is no longer active.
>
> I just fixed another bug, and submitted a patch:
>
> https://sourceforge.net/p/cscope/bugs/285/[2]
>
> and I'd like to ask: does it make sense for these bindings to continue
> being distributed here? How would yall feel about splitting out that
> part of the repository into a separate project, and I can then take on
> maintainership of that code. I am a regular user of those bindings, so
> this should be a working arrangement.
>
> Thanks
>
> dima
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Cscope-devel mailing list
> Cscope-devel@...
> https://lists.sourceforge.net/lists/listinfo/cscope-devel