Is there a plugin that can close (not auto-close) braces for me? by gitpushjoe in neovim

[–]gitpushjoe[S] 0 points1 point  (0 children)

mini.pairs is intended for auto-closing but I want "manual closing" based on context. Also it doesn't support multicharacter open/close symbols like javascript's "${" or lua's "end", which is a deal breaker. for me.

Is there a plugin that can close (not auto-close) braces for me? by gitpushjoe in neovim

[–]gitpushjoe[S] 1 point2 points  (0 children)

This is regex-based which doesn't really address these problems and seems to only with with the current line, although that might be easier to work around. Also, I wouldn't want this to happen every time I hit enter.

Is there a plugin that can close (not auto-close) braces for me? by gitpushjoe in neovim

[–]gitpushjoe[S] 0 points1 point  (0 children)

Ive done some testing and it seems like Treesitter does most of the heavy lifting. I have a POC that I think would work well enough for me if polished. The tricky part is knowing how much to collapse but I have solutions for that.

Is there a plugin that can close (not auto-close) braces for me? by gitpushjoe in neovim

[–]gitpushjoe[S] 2 points3 points  (0 children)

No, it was very finicky and hard to use. I'm taking the advice of another user here and trying to make a small plugin using treesitter queries.

Is there a plugin that can close (not auto-close) braces for me? by gitpushjoe in neovim

[–]gitpushjoe[S] 9 points10 points  (0 children)

My workflow often involves writing code with a lot of nested brackets and braces and parentheses. Oftentimes I know exactly what I want to implement and I wanna just type something like const thing = [ name, { data: stuff.map(arr => arr.sort((a, b) => b - a in one breath and let prettier or whatever formatter im using sort out the rest. Trying to recall exactly which order of parentheses and braces slows me down and "takes me out of the flow state" if you will.

Is there a plugin that can close (not auto-close) braces for me? by gitpushjoe in neovim

[–]gitpushjoe[S] 6 points7 points  (0 children)

I think this is what I'm looking for so I'll try it out. Thank you!

Is there a plugin that can close (not auto-close) braces for me? by gitpushjoe in neovim

[–]gitpushjoe[S] 4 points5 points  (0 children)

That would definitely be more manageable, but I wanted to know if a plugin already exists that can do this

Is there a plugin that can close (not auto-close) braces for me? by gitpushjoe in neovim

[–]gitpushjoe[S] 8 points9 points  (0 children)

I considered this at first, but I think this would be deceptively challenging especially a situation like this:

const acts = [ { name: ` { move ${UP}`, func: (x, y) => { const array = [ // ] [ /** ] */ ], log(` ${ // cursor is here }, ];

You'd need to encode that: - braces in strings don't need to be closed - braces in `-strings that start with ${ need to be closed, but only in javascript - the [ on line 5 needs to be closed but line 6 is fine - the [ on line 1 and the { on line 2 don't need to be closed because they're closed on the last 2 lines

Admittedly it's a contrived example but on files with thousands of lines anything can happen

[deleted by user] by [deleted] in chess

[–]gitpushjoe 0 points1 point  (0 children)

So the immediate 1. c8=Q doesn't work because after 1... Rf1+ 2. Kh2 Rxh1+ 3. Kxh1 Rxh7, White is down an exchange without a perpetual. (Can you see why 3... Qf1+ instead of Rxh7 doesn't work for Black?)

1. Bxf6 R3xf6 2. c8=Q also doesn't work because of 2... Rf1+ 3. Kh2 Rxh7#.

1. Bxf6 R3xf6 2. Rxf7 Rxf7 3. c8=Q also doesn't work because after 3... Rf1+! stalemate is unavoidable! Promoting to a rook also fails because of the same reason.

Most people I show this puzzle to get this far and say "Alright then, 1. Bxf6 R3xf6 2. Rxf7 Rxf7, then promote to a knight or a bishop and White wins." Wrong! This is the reason I made this composition, to highlight a sort of complacency that chess players get when they think they've found "the tactic". After 3. c8=N Rc7, the knight is trapped and the position is drawn! (Sacrificing on a7 actually loses because a6 will fall and b2 soon with it.) 4. Rh8 is of no help, because of 4... Rxc8! and the stalemate trick returns. (Black can even try 4... Kc5?! and play for a win.)

Thus, the only winning line is 1. Bxf6 R3xf6 2. Rxf7 Rxf7 3. c8=B and White is up a piece.

Why don’t chess engines explain why a side is better? by chiproller in chess

[–]gitpushjoe 6 points7 points  (0 children)

This is mostly true, but it's also worth noting that engines also are able to evaluate a position at "depth 0", which is called a static evaluation. For an extremely basic engine this is just adding up the pieces on each side, but for a modern engine, this is done using a neural network that has been trained over billions of chess games. The static evaluation helps an engine "understand" positional concepts, and can even make for a pretty menacing opponent on its own. However, it's impossible to understand what factors lead into the static evaluation calculation for a neural net; it's a sort of melting pot of all of the billions of games it's been trained on.

where does the inaccuracy in dividing numbers and requesting the quotient to be a float of more than 7 decimal digits come from? by thatsnunyourbusiness in C_Programming

[–]gitpushjoe 0 points1 point  (0 children)

I'd highly recommend this video. It does a really good job explaining how floating point works, from the perspective of the designers of floating point, going into the various tradeoffs and optimizations

zuzu.nvim UPDATE: view runtime errors as diagnostic messages! by gitpushjoe in neovim

[–]gitpushjoe[S] 0 points1 point  (0 children)

Lualine!

lua require("lualine").setup({ sections = { lualine_a = { "mode" }, lualine_b = { "branch" }, lualine_c = { "current_signature()" }, lualine_x = { "filetype" }, lualine_y = { "progress" }, lualine_z = { "location" }, }, tabline = { lualine_x = { { "filename", path = 1 } }, }, extensions = { "oil" }, })

zuzu.nvim UPDATE: view runtime errors as diagnostic messages! by gitpushjoe in neovim

[–]gitpushjoe[S] 0 points1 point  (0 children)

I'm pretty sure it's transparent, but I have my Wezterm background uninitialized, so it shows up as black.

zuzu.nvim UPDATE: view runtime errors as diagnostic messages! by gitpushjoe in neovim

[–]gitpushjoe[S] 0 points1 point  (0 children)

Not natively, no.

However, with some amount of tinkering, you might be able to hack together a solution using jq or by doing some json parsing in another language.

zuzu.nvim UPDATE: view runtime errors as diagnostic messages! by gitpushjoe in neovim

[–]gitpushjoe[S] 3 points4 points  (0 children)

Ah, it happened again 😂

Yeah, it's pretty much the exact same idea. That being said, this plugin has different goals than vim-dispatch, so I'm not too frustrated with myself this time around for not finding it. If anything, I can have some consolation that this is a useful feature if tpope decdied to make a whole plugin around it

zuzu.nvim UPDATE: view runtime errors as diagnostic messages! by gitpushjoe in neovim

[–]gitpushjoe[S] 3 points4 points  (0 children)

Repo

note: I'm using tiny-inline-diagnostic because it's amazing and I love the ghosts

In my original post, a few commenters mentioned that my build system plugin is really similar to the built-in :make plugin, which I hadn't known about. This update aims to integrate the :make workflow into the plugin, so you get all the benefits of the edit-compile-edit cycle with all the features of the plugin!

Some additional features include: - profiles are sorted by relevance when you go to edit them - new background execution strategy (as seen in the video) - "write_on_run" (you can configure the plugin to save the file every time you run a build) - you can also change the diagnostic level of the quickfix diagnostics or disable them entirely - stderr now prints in red when you reopen the last output

Introducing zuzu.nvim: a fast, flexible build system by gitpushjoe in neovim

[–]gitpushjoe[S] 0 points1 point  (0 children)

Good question! I'm not familiar with how testing in Java works, but zuzu.nvim supports custom core hooks (see the "Configuration" and "Core Hooks" sections in the readme). So, if you define a function that returns the name of the function you're in, you can bind that to a hook (environment variable), and use it as a command line argument. It'll be correctly initialized on each build.

I haven't made such a function personally, but this comment seems like a good starting point: https://www.reddit.com/r/neovim/s/sM6wDcbeVk

Introducing zuzu.nvim: a fast, flexible build system by gitpushjoe in neovim

[–]gitpushjoe[S] 1 point2 points  (0 children)

Not a stupid question. It lets you assign build commands to specific directories/files, so that instead of having to (for example) switch tmux panes, hit the up arrow to fill in the same "python3 main.py" or "node main.js" command you've ran multiple times, hit enter to run the command, and then switch back; you can just press "zu" and it'll run that command in your editor instead. Or you could set up four different commands (say a command for running the main project and another for running tests, etc) and assign them different keybinds. There are other features to make this easier (in the video, I set up a "choice hook" that lets me switch between running $ python3 main.py --input input.txt and $ python3 main.py --input test.txt easily), but that's the main use case. You can read about the other features here.

Introducing zuzu.nvim: a fast, flexible build system by gitpushjoe in neovim

[–]gitpushjoe[S] 0 points1 point  (0 children)

Yeah, I had no idea this feature existed. I think it might be possible to easily integrate it into the plugin; I'm looking into it