plenary.nvim icon indicating copy to clipboard operation
plenary.nvim copied to clipboard

Added ability to parse (naively) filetype from buffer

Open miversen33 opened this issue 3 years ago • 3 comments

Added ability to (naively) establish filetype from the current buffer, even if the buffer isn't saved to disk

Note: I have not added any unit tests for this yet, kinda hoping to get some discussion around this (namely, if this is something that would be useful here, and I'm not super fond of how I wrapped the existing logic for the now optional filepath)

Also: Should I be submitting this PR to master?

miversen33 avatar Sep 05 '22 04:09 miversen33

~~Looks like the existing unit tests are breaking a bit, I will clean up this patch to work with those, but I would still consider this a WIP/POC~~ Dun

~~Edit: For the 2 unit tests that failed (python shebang and fennel shebang), I am not sure where the files its trying to read are located within the unit testing framework so I don't know exactly how to deal with this lol.~~ I am dum

miversen33 avatar Sep 05 '22 04:09 miversen33

@Conni2461 is this PR useful or should it be removed? I assume dangling PRs aren't worth a whole heck of a lot

miversen33 avatar Oct 01 '22 15:10 miversen33

I am not against adding it but i dont like that its part of the filetype.detect method. Its a breaking change if filepath is now optional. It also makes the function no longer api-fast. It also isnt a great interface, and we now have to check if filetype is nil multiple times in the stack.

Why not just add a second detect method. Something like detect_buffer which can take a optional bufnr, default to 0 ?

Conni2461 avatar Oct 08 '22 05:10 Conni2461

I'm going to close this out for now. I haven't had the time I thought I would to revisit this and I feel like a dangling PR is not helpful (and clogs up other PRs). I will maybe revisit this in the future :) I appreciate you!

miversen33 avatar Dec 16 '22 00:12 miversen33