Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to change the behavior of quitting cscope display buffer #26

Closed
wanghaiqiangk opened this issue Oct 19, 2020 · 5 comments
Closed

How to change the behavior of quitting cscope display buffer #26

wanghaiqiangk opened this issue Oct 19, 2020 · 5 comments

Comments

@wanghaiqiangk
Copy link

When press q, the cscope display buffer is closed and replaced with a second source code buffer. Therefore, there are two buffers for the source code and I have to manually kill one of them.

I hope, when press q, the cscope display buffer can be completely closed and return the focus to source code buffer. I think this can be customized by modifying cscope-display-buffer-args, do you have any idea about how to change and achieve this feature?

@wanghaiqiangk wanghaiqiangk changed the title How to change the behavior of quiting cscope display buffer How to change the behavior of quitting cscope display buffer Oct 19, 2020
@dkogan
Copy link
Owner

dkogan commented Oct 19, 2020 via email

@wanghaiqiangk
Copy link
Author

I managed to figure out how and that's what you said.

I changed (bury-buffer) to (quit-window) in cscope-bury-buffer. Since quit-window also evokes bury-buffer, the *cscope* is the least candidate for switching buffer. To bring *cscope* to the first one, maybe a simple (delete-window) can work.

I prefer the behaviour of killing the window. Because I want to focus on the source code window. After finishing the use of cscope, I don't want to invoke extra typing to just close its buffer/window. But maybe some people prefer the original one. Thereby, an option to control such behaviour can be a choice.

I created a PR and please check it.

@dkogan
Copy link
Owner

dkogan commented Oct 19, 2020 via email

@wanghaiqiangk
Copy link
Author

That's it.

@dkogan
Copy link
Owner

dkogan commented Oct 25, 2020

Fixed in 8e441ef

@dkogan dkogan closed this as completed Oct 25, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants