Added ability to parse (naively) filetype from buffer
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?
~~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
@Conni2461 is this PR useful or should it be removed? I assume dangling PRs aren't worth a whole heck of a lot
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 ?
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!