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

[Feature Request]: Set code window buffer to nomodifiable #360

Closed
MTBorg opened this issue Feb 25, 2021 · 16 comments
Closed

[Feature Request]: Set code window buffer to nomodifiable #360

MTBorg opened this issue Feb 25, 2021 · 16 comments
Labels
needs votes +1 the issue or vote on the trollo card if you would like this

Comments

@MTBorg
Copy link

MTBorg commented Feb 25, 2021

When starting the debugger the code window is modifiable, making it possible to do accidentaly changes to the code while debugging.

Instead i think the code window should be non modifiable, possibly through the nomodifiable option.

It could be possible to do this myself automatically using some autocmd but i think it makes sense for vimspector to do this automatically.

@puremourning
Copy link
Owner

You can do this with these auto commands if you want to. https://github.com/puremourning/vimspector#custom-mappings-while-debugging

modifiable is buffer-local not window-local so I can't set it in general, as that would affect any other open windows the user might have.

In fact, personally I prefer the buffers to be modifiable, for instance so that hot code replacement works

@puremourning
Copy link
Owner

puremourning commented Feb 25, 2021

Here's an extension to the example in support/custom_ui_vimrc.vim that does what you want, roughly:

ben@BeniMac2020 vimspector % git diff
diff --git a/support/custom_ui_vimrc b/support/custom_ui_vimrc
index 3b132b4..934d9f0 100644
--- a/support/custom_ui_vimrc
+++ b/support/custom_ui_vimrc
@@ -105,7 +105,10 @@ function! s:OnJumpToFrame() abort
   nmap <silent> <buffer> <LocalLeader>di <Plug>VimspectorBalloonEval
   xmap <silent> <buffer> <LocalLeader>di <Plug>VimspectorBalloonEval

-  let s:mapped[ string( bufnr() ) ] = 1
+  let s:mapped[ string( bufnr() ) ] = { 'modifiable': &modifiable }
+
+  setlocal nomodifiable
+
 endfunction

 function! s:OnDebugEnd() abort
@@ -124,6 +127,8 @@ function! s:OnDebugEnd() abort
         silent! nunmap <buffer> <LocalLeader>dc
         silent! nunmap <buffer> <LocalLeader>di
         silent! xunmap <buffer> <LocalLeader>di
+
+        let &l:modifiable = s:mapped[ bufnr ][ 'modifiable' ]
       endtry
     endfor
   finally

@puremourning
Copy link
Owner

puremourning commented Feb 25, 2021

I tried this out and I kind of like it. Not sure if that means it should be in the core though. I'm a little torn. will think on it.

I've added it to my own custom layer and I'm going to see how I like it.

@MTBorg
Copy link
Author

MTBorg commented Feb 25, 2021

You can do this with these auto commands if you want to. https://github.com/puremourning/vimspector#custom-mappings-while-debugging

Ah, i missed that, will definitely check it out.

modifiable is buffer-local not window-local so I can't set it in general, as that would affect any other open windows the user might have.

That makes sense, but i think it would be neat if it at least was configurable. In my case when i use vimspector the code window is the only window to the source file open so it couldn't affected any other open windows, and being able to modify the source code while debugging statically compiled languages make little, if any, sense as far as i can see.

@puremourning
Copy link
Owner

neat if it at least was configurable

it's configurable in the sense that you can customise it as above. it's extremely unlikely that I would make an option for this. I have resisted options for everything else so far :)

@MTBorg
Copy link
Author

MTBorg commented Feb 25, 2021

The diff you sent does the trick. Except for that i wanted only the code window to be non-modifiable, which was solved by adding the line

call win_gotoid( g:vimspector_session_windows.code )

This what i added to my .vimrc:

let s:mapped = {}

function! s:OnJumpToFrame() abort
  if has_key( s:mapped, string( bufnr() ) )
    return
  endif

  let s:mapped[ string( bufnr() ) ] = { 'modifiable': &modifiable }
  " Set nomodifiable for code window
  call win_gotoid( g:vimspector_session_windows.code )
  setlocal nomodifiable
endfunction

function! s:OnDebugEnd() abort
  try
    for bufnr in keys( s:mapped )
      try
        let &l:modifiable = s:mapped[ bufnr ][ 'modifiable' ]
      endtry
    endfor
  finally
  endtry

  let s:mapped = {}
endfunction

augroup CodeWindowNoModifiable
  au!
  autocmd User VimspectorJumpedToFrame call s:OnJumpToFrame()
  autocmd User VimspectorDebugEnded call s:OnDebugEnd()
augroup END

Although, i'll admit i'm not sure whether or not all the logic around s:mapped is needed (i'm not too vim-savvy). Would it suffice to only add the

call win_gotoid( g:vimspector_session_windows.code )
setlocal nomodifiable

in s:OnJumpToFrame()? I did a short test and it seems to produce the same result.

@puremourning
Copy link
Owner

puremourning commented Feb 25, 2021

the win_gotoid should not be needed, unless there is a bug, as the current window should be the code window when the autocommand is triggered.

Your OnDebugEnd is also busted because it doesn't set the current buffer. Then again, it can be simplified for your case by using setbufvar:

function !s:onDebugEnd() abort
  for buffer in keys( s:mapped )
    call setbufvar( buffer, 'modifiable', s:mapped[ buffer ][ 'modifiable' ] )
  endfor
  let s:mapped = {}
endfunction

@puremourning puremourning added the needs votes +1 the issue or vote on the trollo card if you would like this label Feb 25, 2021
@MTBorg
Copy link
Author

MTBorg commented Feb 26, 2021

Ah, yes that works. Thanks a lot :)
This is what i added:

let s:mapped = {}

function! s:OnJumpToFrame() abort
  if has_key( s:mapped, string( bufnr() ) )
    return
  endif

  let s:mapped[ string( bufnr() ) ] = { 'modifiable': &modifiable }
  setlocal nomodifiable
endfunction

function! s:OnDebugEnd() abort
  for buffer in keys( s:mapped )
    call setbufvar( buffer, 'modifiable', s:mapped[ buffer ][ 'modifiable' ] )
  endfor
endfunction

augroup CodeWindowNoModifiable
  au!
  autocmd User VimspectorJumpedToFrame call s:OnJumpToFrame()
  autocmd User VimspectorDebugEnded call s:OnDebugEnd()
augroup END

I agree that this is the way in which this should be configurable, so i'll go ahead and close this.

@MTBorg MTBorg closed this as completed Feb 26, 2021
@MTBorg
Copy link
Author

MTBorg commented Feb 26, 2021

Actually, using it a bit i noticed some strange behavior.

  1. I run vimspector
  2. The program i run expects user input, so i switch to the output window and enter some input (maybe this is bad?)
  3. Program contiues to run and It switches me back to the code window
  4. I exit vimspector using vimspector#Reset()
  5. The code is no longer modifiable

To be clear it works if i don't switch to the output window and enter some input.
I use the same augroup as in the previous comment.
Any idea what could be going on?

@MTBorg MTBorg reopened this Feb 26, 2021
@puremourning
Copy link
Owner

I can't reproduce. Not obvious why you are getting this, but you are certainly missing let s:mapped = {} at the bottom of your s:OnDebugEnd() compared to what.i use.

so i switch to the output window

Which exact window is this?

@MTBorg
Copy link
Author

MTBorg commented Feb 28, 2021

but you are certainly missing let s:mapped = {} at the bottom of your s:OnDebugEnd()

Adding this didn't fix it :(

Which exact window is this?

The one opened in the top right when starting vimspector (i use the default ui), containing the output of the program (i'm not sure how to give an exact answer).

Here's a short C program that i am able to reproduce the issue with:

#include <stdio.h>

int main(int argc, char *argv[])
{
	printf("Please enter a number: ");
	int input;
	scanf("%d", &input);
	printf("I received number %d\n", input);
	return 0;
}

@MTBorg
Copy link
Author

MTBorg commented Feb 28, 2021

I should aslo probably mention i use neovim.
Output of nvim --version:

NVIM v0.4.4
Build type: Release
LuaJIT 2.0.5
Compilation: /usr/bin/cc -D_FORTIFY_SOURCE=2 -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -O2 -DNDEBUG -DMIN_LOG_LEVEL=3 -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=always -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -I/build/neovim/src/build/config -I/build/neovim/src/neovim-0.4.4/src -I/usr/include -I/build/neovim/src/build/src/nvim/auto -I/build/neovim/src/build/include
Compiled by builduser

Features: +acl +iconv +tui
See ":help feature-compile"

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/usr/share/nvim"

Run :checkhealth for more info

I also tried disabling all plugins and remove all custom settings i have, but nothing worked.

@puremourning
Copy link
Owner

Oh sigh. I didn’t try neovim. Do you see the same behaviour in vim?

@MTBorg
Copy link
Author

MTBorg commented Feb 28, 2021

Yes, i do :(

Edit, vim version:

VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Feb 09 2021 23:51:55)
Included patches: 1-2489
Compiled by Arch Linux

@puremourning
Copy link
Owner

Ok thanks. Let me see if I can repro.

@puremourning
Copy link
Owner

https://asciinema.org/a/YB650ZRpePHVuG0bQyVCVvajd

Sory no matter what I do, I can't repro in vim. If you think this is a vimspector bug, then please re-raise as an issue report, completing the issue template including steps to reproduce using minimal config.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 3, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
needs votes +1 the issue or vote on the trollo card if you would like this
Projects
None yet
Development

No branches or pull requests

2 participants