vscode-jupyter VS debugpy

https://github.com/microsoft/vscode/issues/4490

It looks like there are a number of vscode extensions for recording macros:

- https://www.google.com/search?q=vscode+macro+recorder

- https://marketplace.visualstudio.com/search?term=Macro&targe...

- the macro-commander README explains its JSON-based macro language. YAML might be easier to maintain than JSON. https://github.com/jeff-hykin/macro-commander#what-are-some-...

For teams with multiple editors, you can specify workflow automation scripts with shell scripts or ci container/cmd YAML, and/or pre-commit.yml instead of with an IDE-specific tool.

Isn't there native real-time collaboration functionality in vscode/vscodium that would be useful for a native macro recording feature? (Edit) Live Share can't be installed in vscodium. https://github.com/VSCodium/vscodium/issues/128

Support for jupyter-collaboration Y.js CRDT could be added to vscode-jupyter and/or a more generic extension: "Support for real-time collaboration in the extension?" https://github.com/microsoft/vscode-jupyter/discussions/1293...

jupyterlab/jupyter-collaboration:

Check out this GitHub issue. Similar to your needs, the reply said

It looks like this. I resubmitted a new feature request.

I don't like the fact that Visual Studio Code thinks a notebook has changed, while Git knows it isn't. According to issue #9514, this is something that should be fixed in the core of Visual Studio Code. So, I'm not really sure why issue #83232 (or #24883) is closed.

I wish for a simple option in VS Code: On close of a Jupyter Notebook clear its output. Or something that separate the display of the output from the saved file (Still `ipnyb` file). See [1].

[1]: https://github.com/microsoft/vscode-jupyter/issues/9514

jupyter won't work on vs-code

If that doesn't fix it, can you log an issue here? https://github.com/microsoft/vscode-jupyter/issues

debugpy description from it's repository:

I'd love to see what it can do with https://github.com/microsoft/debugpy - and especially how it would handle vendored dependencies.

I read that nvim-dap-python uses debugpy which has all these configuration parameters of which one of them is `cwd` which represents the "absolute path to the working directory of the program being debugged".

Hey all, I'm not sure if this is normal or not but, when debugging with nvim-dap, nvim-dap-ui, and nvim-dap-python (which uses debugpy) over a remote session, dap runs exactly once and then closes the entire process. This even happens when I just call `require("dap").restart()`. It's pretty frustrating to deal with and is not something that I was used to when I used to debug with vimspector, which let me restart the debug remotely as many times as I wanted without killing the application that I was connected to. Is this happening for anyone else? How do I disable it? I didn't see anything in debugpy's configuration options. I'm rereading dap's vim :help but haven't found any mention of auto-close / terminate logic yet.

-- Debug adapter plug-in. Debug anything in Neovim { "mfussenegger/nvim-dap", config = function() vim.keymap.set("n", "d", ":DapContinue") vim.keymap.set("n", "dl", ":DapStepInto") vim.keymap.set("n", "dj", ":DapStepOver") vim.keymap.set("n", "dh", ":DapStepOut") vim.keymap.set("n", "dz", ":ZoomWinTabToggle") vim.keymap.set( "n", "dgt", -- dg as in debu[g] [t]race ":lua require('dap').set_log_level('TRACE')" ) vim.keymap.set( "n", "dge", -- dg as in debu[g] [e]dit function() vim.cmd(":edit " .. vim.fn.stdpath('cache') .. "/dap.log") end ) vim.keymap.set("n", "", ":DapStepOut") vim.keymap.set("n", "", ":DapStepOver") vim.keymap.set("n", "", ":DapStepInto") vim.keymap.set( "n", "d-", function() require("dap").restart() end ) vim.keymap.set( "n", "d_", function() require("dap").terminate() require("dapui").close() end ) end, lazy = true, }, -- A default "GUI" front-end for nvim-dap { "rcarriga/nvim-dap-ui", config = function() require("dapui").setup() -- Note: Added this dd duplicate of because somehow the -- mapping keeps getting reset each time I restart nvim-dap. Annoying but whatever. -- vim.keymap.set( "n", "dd", function() require("dapui").open() -- Requires nvim-dap-ui vim.cmd[[DapContinue]] -- Important: This will lazy-load nvim-dap end ) end, dependencies = { "mfussenegger/nvim-dap", "mfussenegger/nvim-dap-python", -- Optional adapter for Python }, }, -- TODO: Make sure that debugpy is installed. Otherwise, disable -- Reference: https://github.com/mfussenegger/nvim-dap-python#installation -- { "mfussenegger/nvim-dap-python", config = function() require("dap-python").setup("/path/to/python/here") -- XXX: Replace this with your preferred Python, if wanted -- An example configuration to launch any Python file, via Houdini -- table.insert( -- require("dap").configurations.python, -- { -- type = "python", -- request = "launch", -- name = "Launch Via hython", -- program = "${file}", -- python = "/opt/hfs19.5.569/bin/hython" -- -- ... more options, see https://github.com/microsoft/debugpy/wiki/Debug-configuration-settings -- } -- ) end, dependencies = { "mfussenegger/nvim-dap", "nvim-treesitter/nvim-treesitter", }, }, -- Remember nvim-dap breakpoints between sessions, ``:PBToggleBreakpoint`` { "Weissle/persistent-breakpoints.nvim", config = function() require("persistent-breakpoints").setup{ load_breakpoints_event = { "BufReadPost" } } vim.keymap.set("n", "db", ":PBToggleBreakpoint") end, }

After testing I have the same situation. I reported this issue on GitHub, you can follow up.

vim.fn.sign_define('DapBreakpoint', {text='🛑', texthl='', linehl='', numhl=''}) dap.configurations.python = { { -- The first three options are required by nvim-dap type = 'python'; -- the type here established the link to the adapter definition: `dap.adapters.python` request = 'launch'; name = "Launch file"; -- Options below are for debugpy, see https://github.com/microsoft/debugpy/wiki/Debug-configuration-settings for supported options program = "${file}"; -- This configuration will launch the current file if used. pythonPath = function() -- debugpy supports launching an application with a different interpreter then the one used to launch debugpy itself. -- The code below looks for a `venv` or `.venv` folder in the current directly and uses the python within. -- You could adapt this - to for example use the `VIRTUAL_ENV` environment variable. return os.getenv("VIRTUAL_ENV") .. "/bin/python" or '/usr/bin/env python' end; }, }

You should take a look at DAP (Debug Adapter Protocol). There exist a Python module implementing this protocol (debugpy) and you can probably find some client applications that can hook into it (like this neovim plugin).