I would like to dynamically debug a vim script. My current workflow is that I have the autoload plugin opened on a tmux pannel and the running application on the other pannel. I also set a tail -f vim.log and I launched vim with vim -V15vim.log. My goal is to monitor the execution of the plugin by adding plenty of echom.
Actually I was expecting something more useful that what I actually got.
I need to restart vim everytime I add a new echom
Nothing really useful is displayed on the log file vim.log
This method is obviously not the right one
I also tried to add breakpoints with breakadd func myfunc#test but it is not really working because the debugger windows interfers with the main window and change the way the plugin I am debuging behave.
How to improve my vim-script debug workflow?
HINT
I am actually trying to debug the vim-multiple-cursor plugin which does not work with a column block selection and virtualedit enabled. I would like to fix it.
:breakadd is the most powerful tool, but yes, its output and interaction may interfere with certain plugin actions, and trigger additional autocmds. It may help if you specify the optional [lnum] offset to only stop executing inside the function.
I need to restart vim everytime I add a new echom
It should be enough if you just :source the changed plugin script again. Scripts inside ~/.vim/plugin/ usually employ a multiple inclusion guard that you need to work around, though. My ReloadScript plugin can help with that.
Alternatively, the Decho plugin might offer a different approach worth looking at.
Related
Lately, VS has been getting more and more annoying about warning me about editing code while debugging. Regardless of whether it is a popup telling me that a file has been edited, purple underlining, or a warning that gets grouped with the compiler warnings and errors, I don't want it. I wish it would just let me edit, continue running the program that was built, and keep quiet about it.
Is there a way to tell it to do that?
Incidentally, I have already disabled edit and continue. See Edit and Continue: "Changes are not allowed when..."
You can apply changes to the source code in debug mode when you stop at a breakpoint.
Manual: How to: Apply Edits in Break Mode with Edit and Continue (Visual Basic)
This is a workaround but some workarounds, well, work.
Run two instances of VS on the same solution. Debug one and encounter needed edit. Ctrl+TAB to the other instance and make the edit (without saving... by the way use auto-save). Continue until you’re done, and then save the files in instance 2. After debug, the changes are available to both instances.
Rarely (at least in my experience) do you actually want edit-and-continue; usually you’re watching the code under debug and realize it is wrong and want to fix it, but also want to see some downstream effects without killing the debug session.
This gives you that with a minor inconvenient task switch.
I am downloading data from a remote server using curl in Build Phases > Run Script. Downloading takes 5-15s, not that much, but multiple times a day it consumes considerable time. Is there a better way to skip a script than commenting it out? Ideally, it would be some kind of confirmation at compile time (e.g Do you really need to download X? y/n).
You can’t make the run script interactive in the console as far as I know. But you can use a shell conditional with an AppleScript interactive dialog, because AppleScript itself blocks while dialog is shown. See for example https://cantina.co/adding-interactivity-to-the-xcode-build-process/.
However, introducing uncertainty into a build is dangerous. Plus you’d never be able to automate the build. In my view you’d be better off flipping a custom build setting / environment variable.
The javascript debugger in Cloud9 is great, but it only appears to work if I run 'node' rather than using something like 'nodemon'.
I'd like the run command to restart if a file changes, and I also want to use the debugger. Anyone know a quick fix for this?
Discovered that there's no need to restart the runner - changes are applied to the run environment / configuration immediately. Even better!
That's what I wanted to write, it applies changes automatically.
Though, if you make changes to routes, you have to restart the server,
at least that's what I was having to do.
I use Vim every day to write shell scripts. I have been reading about the quickfix window, and I think it could speed up my productivity in the edit-run-fix cycle.
If I understood properly, I have to write my own errorformat function in order to Vim to be able to catch the errors and introduce them into the quickfix window. But this seems to be really complicated.
Is there an easier/more convenient way to take advantage of the quickfix window in Vim when writing Bash scripts?
Vim's quickfix window is designed to speed up the edit-compile-edit cycle. Since Bash scripts do not get compiled, we have to substitute something else for that step that can point out errors in the current script.
What you want is a static analysis tool for Bash scripts. There are two good ones: shellcheck and checkbashisms. You'll want to install at least shellcheck, as it's the more comprehensive of the pair, but installing checkbashisms will help catch a few more issues.
To integrate those two tools into Vim, you need a plugin called Syntastic. Check the project page for installation instructions.
Once you've got everything installed, you'll be able to get immediate feedback on basic issues in your Bash script:
Use :SyntasticCheck to force the checker to run
If you want the "quickfix" window to appear, run :Errors
I am quite curious to know if there is a way to achieve the same that you get, when in Xcode you press cmd-u (or select Test from the menu).
I am writing some UI tests for an application, and would love to automate the whole thing.
So far, any attempt to automate via applescript has been quite unsuccessful (I told myself how hard it is to simulate 2 button pressed...); so I thought that maybe there is a proper way to just run the command line commands and have the simulator to pop and run the tests, like it does in Xcode.
Altho if this function was known, I would find something online, but it seems that there is no way to simulate the test command via console.
Am I missing something?
Have you checked out the xcodebuild command?
The man page says:
buildaction ...
Specify a build action (or actions) to perform on the target. Available build actions are:
test Test a scheme from the build root (SYMROOT). This requires specifying a scheme.
So, perhaps that will do what you want.