Hans-Bernhard Bröker <hbbroe...@t-online.de> 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 ------------------------------------------------------------------------------ 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cscope-devel
