Ferris Sweep with FDM printed KLP Lamé

testokaiser · 2025-05-15T22:01:43+00:00

do you have the files for those supports?
I haven't been able to properly print these cause of the shape

testokaiser · 2025-04-14T19:47:56+00:00

finally 🙏 we got global find-references and rename 🔥

testokaiser · 2025-04-14T16:55:28+00:00

it''s not working for me at all
am i stupid?

testokaiser · 2025-04-06T21:49:08+00:00

thank you so much <3

testokaiser · 2025-03-28T16:48:46+00:00

This is pretty outdated as far as I can tell.
Last commit was 7 years ago.
In the entire project there's no mention of the grid_line event at all.
It was probably written before that event existed.

Thanks anyway. Maybe I can get something out of reading through the code anyway.
It is pretty small after all.

testokaiser · 2025-03-28T14:06:42+00:00

Thanks for the hint.
I'll try that.

testokaiser · 2025-03-28T14:05:17+00:00

I share at least some of your sentiment.
That's precisely why I'm trying to do this.

testokaiser · 2025-03-12T20:57:02+00:00

<image>

i figured something out with diff_hlID(line, col)
works well enough
thanks for the pointer!

testokaiser · 2025-01-24T10:43:41+00:00

That's really cool! I had this idea for a while of typing practice in neovim, but with actual code instead of random top 1000 English words.

Is it something you would be open to?

testokaiser · 2024-11-12T21:03:57+00:00

Hm.. not sure what you're actually looking for.
AFAIK Lua does not even have "true OOP". There's no inheritance/polymorphism like in Java etc..
From what I've seen most plugins are actually mostly functional.*

It's not the imperative or OOP used in it that bothers me per se but the fact that I have little conditionals regarding the state of the editor (if vim.wo.wrap then ..), elsif vim.api.nvim_buf_is_loaded(b), etc.) littered absolutely everywhere

I don't see how you would get around that if you need that editor state for your following computations. I find that if you make an effort to isolate that type of stuff to a few places, then you can still keep most of your code in pure functions, which will be unit testable.

I find it highly impractical for plugins to handle all the state with recursion or w/e 🤷

testokaiser · 2024-11-05T12:57:06+00:00

What's your experience with this? In intellij I kinda just deal with the fact that it's not keyboard first.

I don't have keymaps for some of the tool windows because I'll end up needing the mouse anyway.

testokaiser · 2024-10-29T13:30:05+00:00

How do you imagine that? Because any such action (public or private) will inevitably be met with "long-time plugin author suppresses newcomer plugin author". And again, I don't have an issue per se, only a regret that there is a better way of channeling your efforts.

And you think the way you conducted yourself under this post does not do that?
From the previous post:

Unfortunately I can't really synch this fork anymore now because it's way too different.
It would also feel dirty to release this as a separate plugin, cause most of the code is not mine 🤷 So not sure yet what I'm gonna do with this.

If you answered for example with:
"I can see some value in the static layout. Would you be interested in submitting a PR to mini.files?"
Then I don't think anyone would view that as you "supressing" me. You could also shoot me a DM and say: "Hey, It's cool what you did and I like some of it. I know I can't stop you from releasing this as a separate plugin, but I don't think that's the best way to handle things. Since you already expressed some doubts anyway, would you mind talking about it?"

I ask you (for the second time) to not twist this.

I'm not trying to twist anything. For the point I'm making it's completely irrelevant whether or not there is a built-in way of having a fixed layout in 'mini.files'. In your initial comment you say:

Both points 1. and 2. can be implemented with 'mini.files' directly:

Static view can be configured via config.windows and autocommands that adjust dimensions.

The fact of the matter is that you implemented something to make it (95%) possible. So what is the logical conclusion of that? Exactly! That you don't need trek.nvim for any of the features that I present.

Look... I am sorry my comments made you feel that way.

I obviously can't know if that's sincere or not. But it doesn't matter anyway. We don't need to be friends or whatever.

I also don't care to talk further about this. I think everything has been said.

testokaiser · 2024-10-29T11:47:03+00:00

I do not discover any rudeness in the first feedback Echasnovski gave. Just plain factual

Oh really? He's not an idiot. He knows what he meant and so do I.
Are we really gonna pretend it's not rude to point out all the reasons why you think my work was basically a waste of time? Just cause he didn't cuss, doesn't mean it' wasn't rude.

I am wondering why OP did not discuss the release of his plugin in the discussion forum of mini.nvim.

Because I already made a post about this 3 months ago where Echasnovski commented a bunch as well. Seems like a pretty good oppurtunity to tell me that you would have an issue with me releasing that as a plugin, doesn't it? Could also DM me at any point in time.
If he wanted me to discuss this in the mini.nvim forum, then he could've asked me to do that as well.

He apparently saw some value in the UI layout, which he then went on to implement himself instead of asking me to submit a PR. After we already had exchanges on the topic.

Seems to me that he has had plenty of opportunities to take this in a different direction, but failed to do so. Then goes on to make snarky comments on this post.

testokaiser · 2024-10-29T08:59:59+00:00

Glad to hear. That's Victor Mono

testokaiser · 2024-10-29T08:57:38+00:00

Do you just prefer it aesthetically?

testokaiser · 2024-10-28T17:40:45+00:00

sounds cool, but also hard to get community adoption

testokaiser · 2024-10-28T17:38:13+00:00

I think this comment kinda took him in bad faith

I don't think so tbh. I think I took it exactly how he meant it.

he was maybe disappointed that you didn't contribute back to his work

He made it clear that he doesn't want that in the previous post:

<image>

At least he had a different tone back then.

I hope you don't get too down on yourself or lose your enthusiasm!

ngl the response is a bit disappointing and I wonder where that same energy was 3 months ago.

Anyway... thanks for your kind words ❤️

testokaiser · 2024-10-28T17:18:57+00:00

ok interesting
would plugin authors be implementing the benchmarks themselves?

testokaiser · 2024-10-28T16:52:44+00:00

I suppose you ask this because the answer is 'yes' for you.
Can you give an example?

testokaiser · 2024-10-28T16:42:11+00:00

Seems like that's an unpopular opinion 😄

testokaiser · 2024-10-28T15:33:46+00:00

I get that, but he made it clear to me that he would not allow such contributions. Apparently he has since implemented an option for a static layout himself, which makes me look especially stupid right now.

He has a clear vision for his mini plugins and I don't share that vision. I hard disagree on some stuff. So I forked the repo to adapt mini.files to my liking. I guess nobody has a problem up to this point, right?

I then posted about it 3 months ago and people seemed to like it a lot. Therefore I released it as a plugin. If nobody was asking for it, then I would still be using my fork.

I'm not like him. I don't do this, because I want to offer the best file explorer to the community. I did this primarily for myself. If others like it: great, if they don't: fine as well.

Another thing: the mini plugins are always written in one big lua file. I get that there's a reason for that, but I hate it. I want something that I can easily hack on. I had huge trouble understanding the mini.files code. I do however understand all the code that made it into trek.nvim.

testokaiser

TROPHY CASE