You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
(54) |
May
(109) |
Jun
(2) |
Jul
(4) |
Aug
(10) |
Sep
(19) |
Oct
(25) |
Nov
(17) |
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
|
Mar
(2) |
Apr
(7) |
May
(5) |
Jun
(26) |
Jul
(28) |
Aug
(47) |
Sep
(30) |
Oct
(22) |
Nov
(11) |
Dec
(6) |
| 2002 |
Jan
(37) |
Feb
(9) |
Mar
(69) |
Apr
(18) |
May
(10) |
Jun
(16) |
Jul
(63) |
Aug
(21) |
Sep
(10) |
Oct
(6) |
Nov
(9) |
Dec
(25) |
| 2003 |
Jan
(13) |
Feb
(4) |
Mar
(10) |
Apr
(9) |
May
(13) |
Jun
(17) |
Jul
(14) |
Aug
(33) |
Sep
(25) |
Oct
(16) |
Nov
(6) |
Dec
(2) |
| 2004 |
Jan
(20) |
Feb
(18) |
Mar
(12) |
Apr
(12) |
May
(2) |
Jun
(15) |
Jul
(14) |
Aug
(3) |
Sep
(16) |
Oct
(11) |
Nov
(19) |
Dec
(32) |
| 2005 |
Jan
(31) |
Feb
(38) |
Mar
(8) |
Apr
(33) |
May
(9) |
Jun
|
Jul
(4) |
Aug
(30) |
Sep
(8) |
Oct
(16) |
Nov
(21) |
Dec
(12) |
| 2006 |
Jan
(5) |
Feb
(16) |
Mar
(12) |
Apr
(24) |
May
(15) |
Jun
(21) |
Jul
(14) |
Aug
(5) |
Sep
(22) |
Oct
(33) |
Nov
(53) |
Dec
(47) |
| 2007 |
Jan
(20) |
Feb
(51) |
Mar
(30) |
Apr
(69) |
May
(66) |
Jun
(99) |
Jul
(128) |
Aug
(45) |
Sep
(10) |
Oct
(20) |
Nov
(26) |
Dec
(14) |
| 2008 |
Jan
(9) |
Feb
(31) |
Mar
(57) |
Apr
(175) |
May
(17) |
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
(4) |
Apr
(2) |
May
|
Jun
|
Jul
(5) |
Aug
(3) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
(5) |
Oct
(1) |
Nov
|
Dec
(1) |
| 2011 |
Jan
(5) |
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
(8) |
Oct
(3) |
Nov
(14) |
Dec
(9) |
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(6) |
Aug
(2) |
Sep
(7) |
Oct
(1) |
Nov
|
Dec
(2) |
| 2014 |
Jan
(1) |
Feb
|
Mar
|
Apr
(4) |
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: Alex <alexinbeijing@gm...> - 2015-10-18 15:07:00
|
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 |
|
From: Hans-Bernhard Bröker <HBBroeker@t-...> - 2015-04-04 20:51:38
|
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 |
|
From: Roberto E. Vargas Caballero <k0ga@sh...> - 2014-05-08 06:18:20
|
> 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 |
|
From: Hans-Bernhard Bröker <HBBroeker@t-...> - 2014-05-07 22:06:29
|
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. |
|
From: Jemiah Aitch <jemiaha@gm...> - 2014-05-07 18:17:28
|
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 . |
|
From: Michael Ellerman <mpe@el...> - 2014-05-02 01:35:06
|
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 |
|
From: Elad Lahav <e2lahav@gm...> - 2014-04-20 12:20:49
|
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. |
|
From: Hans-Bernhard Bröker <HBBroeker@t-...> - 2014-04-07 21:05:07
|
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. |
|
From: Neil Horman <nhorman@tu...> - 2014-04-07 15:37:12
|
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@... > |
|
From: Neil Horman <nhorman@tu...> - 2014-04-07 11:27:32
|
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 > > > |
|
From: Dima Kogan <cscope@di...> - 2014-01-03 06:13:00
|
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 |
|
From: Hans-Bernhard Bröker <HBBroeker@t-...> - 2013-12-05 22:01:27
|
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. |
|
From: <asharpe@an...> - 2013-12-05 21:30:23
|
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 |
|
From: Dima Kogan <cscope@di...> - 2013-10-16 09:02:40
|
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 |
|
From: Hans-Bernhard Bröker <HBBroeker@t-...> - 2013-09-25 21:43:11
|
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. |
|
From: Roberto E. Vargas Caballero <k0ga@sh...> - 2013-09-25 07:24:52
|
> 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 |
|
From: Hans-Bernhard Bröker <HBBroeker@t-...> - 2013-09-24 22:23:46
|
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. |
|
From: Roberto E. Vargas Caballero <k0ga@sh...> - 2013-09-24 08:46:13
|
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 |
|
From: Dima Kogan <cscope@di...> - 2013-09-16 23:52:11
|
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 |
|
From: Darryl Okahata <darrylo@so...> - 2013-09-16 18:11:21
|
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 |
|
From: Dima Kogan <cscope@di...> - 2013-09-15 10:08:57
|
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 |
|
From: Tony Li <tony.li@to...> - 2013-08-15 04:49:32
|
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
|
|
From: Dima Kogan <cscope@di...> - 2013-08-01 21:12:45
|
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 |
|
From: Darryl Okahata <darrylo@so...> - 2013-07-31 23:03:23
|
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 |
|
From: Dima Kogan <cscope@di...> - 2013-07-31 22:57:54
|
Hans-Bernhard Bröker <HBBroeker@...> writes: > 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. OK. Let me contact Darryl before moving forward on this thread. Thanks dima |