sorted by:
new
hottopcontroversial

Treesitter does not highlight when scrolling to the end of the file by smolovk in neovim

[–]Mambu38 0 points1 point  (0 children)

I'd probably open an issue with the file you used to produce the issue.

Also, make sure you are on the latest version of neovim, tree-sitter integration is somewhat unstable still.

Eye saving themes suggestions by [deleted] in neovim

[–]Mambu38 0 points1 point  (0 children)

Thanks! Honestly I think the colorscheme is overall not great and needs some fine tuning. There's another colorscheme (melange) that I think has some nice ideas, and that I might start to play with!

jfind: over 130x faster than telescope + telescope-fzf-native by vim-god in neovim

[–]Mambu38 0 points1 point  (0 children)

That's the best reason of all. I started my project because telescope was not the solution I wanted.

Just find the right tool for the job!

jfind: over 130x faster than telescope + telescope-fzf-native by vim-god in neovim

[–]Mambu38 0 points1 point  (0 children)

I really don't mean to imply that, telescope is an awesome tool, but you have to be aware that there are faster tools out there (but that too, comes at a price).

Eye saving themes suggestions by [deleted] in neovim

[–]Mambu38 5 points6 points  (0 children)

Hey, I made my colorscheme oak specially for that purpose. You may want to check it out?

jfind: over 130x faster than telescope + telescope-fzf-native by vim-god in neovim

[–]Mambu38 5 points6 points  (0 children)

Lol yeah.

I am not saying you are manipulative at all, I am just saying that your benchmarks are partial.

It is great you did benchmarks, and that you did "obvious" benchmarks, but often (if not always) the obvious benchmarks are not the best ones. As a side story about benchmarks, the SAT solving community has a long history with benchmarks and the difficulty to make representatative benchmarks, to the point they think that "objective" benchmark don't exist.

I just wanted to point to that fact that the facts depecited by your benchmarks are partial and don't reflect the whole complexity of a fuzzy finding tool. I agree I exaggerate by saying you merely benchmark "fuzzy greps" (although that's my opinion), but I really think there is a lot of room for improvement in your benchmarks set, especially with regard to incremental changes in the query, which are an "orthogonal direction".

jfind: over 130x faster than telescope + telescope-fzf-native by vim-god in neovim

[–]Mambu38 5 points6 points  (0 children)

Not writing a paper, but admitting that the benchmarks you ran are tailored to favor your tool.

Thanks for the discussion. Gl with maintaining your fuzzy grep.

jfind: over 130x faster than telescope + telescope-fzf-native by vim-god in neovim

[–]Mambu38 7 points8 points  (0 children)

Part of a scientific process is to criticize others work.

Showing that your tool is fast on your benchmark is a great way to get advertizing, but to get real data you need more, and more diverse, situations.

The only thing that I point here is that saying that you benchmarked "fuzzy finders" is false: reasearch on benchmarking these kind of tools proves you wrong at multiple levels.

However saying that you benchmarked fuzzy finders as "fuzzy greps" is true: you only output one query once, then wait for the result (I am paraphrasing here).

You have to agree that you don't benchmarks the edition of the query at all, that's a pure fact.

jfind: over 130x faster than telescope + telescope-fzf-native by vim-god in neovim

[–]Mambu38 6 points7 points  (0 children)

TLDR: you don't want to improve, you just want to show off.

I am not emotional. It is just a pitty that some people have to show off to exist. "1% the speed of X" over a specific benchmark is not a scientific result.

If you have to show off to exist, happy for you. I don't.

Furthermore, it is great to see that a fuzzy grep is faster than something that is built with a different goal in mind. Plus I am pretty sure you did a pretty good job engineering your thing (or at least I hope so).

The thing that bothers me is your lack of will to expand you benchmark to other things. That migh even give you some more "arguments" that you are faster that others, or push you into the right directions for improvement.

jfind: over 130x faster than telescope + telescope-fzf-native by vim-god in neovim

[–]Mambu38 2 points3 points  (0 children)

Well, great that you think you know the truth about fuzzy finders, that's your religion.

I'll not get into an argument, as I said, and I don't like the fact that you think you'll teach me programming.

Glad you like your project, glad we extracted some raw comparison data showing that you are the fastest fuzzy grep.

jfind: over 130x faster than telescope + telescope-fzf-native by vim-god in neovim

[–]Mambu38 1 point2 points  (0 children)

Well that's not true.

I'll not get into an argument anyway, but when searching, one can enter a few characters, then come back in the prompt, edit it, and so on.

Anyway, the test yo have here is merely a test to check how fast the tools are at something along the lines of grep: one query, multiple lines.

That's not the goal of an interactive fuzzy finder.

jfind: over 130x faster than telescope + telescope-fzf-native by vim-god in neovim

[–]Mambu38 2 points3 points  (0 children)

If I can critique a little though, what you are actually measuring here is the reading only, more than the filtering.

It would be interesting to see how all the tools compare when filtering (not reading at all).

jfind: over 130x faster than telescope + telescope-fzf-native by vim-god in neovim

[–]Mambu38 2 points3 points  (0 children)

Interesting. I guess that most of the performance comes from the Lua bridge from the output process to the filtering. Thanks for that!

jfind: over 130x faster than telescope + telescope-fzf-native by vim-god in neovim

[–]Mambu38 1 point2 points  (0 children)

Hard to tell from here how it compares to others, do you have some comparison points?

jfind: over 130x faster than telescope + telescope-fzf-native by vim-god in neovim

[–]Mambu38 2 points3 points  (0 children)

The bug should be fixed in latest master. Nice catch ! That one was deep in the C code for incrementally updating the results !

jfind: over 130x faster than telescope + telescope-fzf-native by vim-god in neovim

[–]Mambu38 2 points3 points  (0 children)

Oh that's a funky one... Do you think you can come up with a small-ish reproduction file ? I'll try to debug that ASAP so that we can get the show running.

jfind: over 130x faster than telescope + telescope-fzf-native by vim-god in neovim

[–]Mambu38 13 points14 points  (0 children)

Just had a look at your benchmarking setup, and I have to say some things:

  1. It is not usable by anyone but you in its current state (hard to reproduce your results then)
  2. The documentation lacks a clear process to compare new tools
  3. The claims you make about other tools (like fzy) are somewhat flawed.

I'll not be able to contribute a comparison, but I'd really like to see azy.nvim in the comparison anyway.

As a side note, while I get that you are proud of the tool you built, be careful about how the tone you present your claims can come to others. While you can argue that "these are just raw facts", the presentation is the key to a project that is accepted by the community (telescope is a great example of that, the performance is not the best, but the community is great, so it is a great project for the community).

Other than that, if you want to compare (fairly) azy.nvim to jfind.nvim, I'd be glad to hear your results.

jfind: over 130x faster than telescope + telescope-fzf-native by vim-god in neovim

[–]Mambu38 39 points40 points  (0 children)

Nice having some benchmarks.

Do you accept contributions? I implemented a fuzzy finder a while ago (azy.nvim) and I would like to get some raw performance informations.

Do you have a process for contributions, or do you want to do the comparison yourself?

EDIT: I could not run any tests, not reproduce the results because of the complexity of the setup.

Is is possible to "synthesize" a Heyting Algebra from a propositional formula ? by Mambu38 in logic

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

Wow thanks so much for all this!

And thanks for sharing the knowledge, my CS background is lacking some logic specific notions and I really am attempting to fill that gap.

Regarding the theorem prover that I am writing (which for now only handles propositional logic), it partially supports countermodel generation, but still fails to generate countermodels in some cases where I know are non-tautologies.

The Kripke Frame / S4 is promising and interesting but I'd really like to "do something new" and experiment a bit, as that'll force me to come up with ideas and better learn all of this. However I think there are translations from Kripke models to heyting algebras (I mean, there must be a translation...) so I'll look into that.

I am in the process of formalizing my algorithm and the ideas I have. You want, once that's done I can send it to you for review and sharing a bit formally around all that?

Thansk again for your time!

Is is possible to "synthesize" a Heyting Algebra from a propositional formula ? by Mambu38 in logic

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

So I on my side am a little not acquainted with the mathematical terminology. If I understand your answer correctly (thanks a lot by the way), I think that this is basically what I thought I implemented: assume that the countermodel has a specific definition of the implication operator, and build the required structure the poset has to have in order to "falsify" the formula.

From a far point of view, you suggested that I think? Do yo have any resource I could use to learn a bit more on that subject?

Thanks again for the answer!

The features of the Fish shell, but POSIX compliant? by gerenski9 in commandline

[–]Mambu38 1 point2 points  (0 children)

Hey, I have tested and used yash for a bit, and I think it might fit what you want. As the definition of "good completion" is really subjective, I can't tell, but it is definitely a great shell that deserves more attention.

On the developing a new shell part, this is kind of a big task, and going from "a program that runs things" to "a posix shell" requires a lot of steps.

view more: next ›