Hi
For some filetypes, Kakoune offers an alt command. For example, to switch back and forth between foo.cc and foo.hh. Same for test/spec files in languages like Ruby.
Looks like the external program could deal with more cases:
For an external program, I would have seen something more data-driven than having the support for alternates in the source code directly. Some frameworks can have multiple alternate files too.
3 Likes
Having something like this that cycles through all the files sort of related would actually be awesome. I don’t mind a mostly hardcoded/out of the box solution – reminds me of DumbJump in emacsland.
Having sort of a “related” instead of just “alt” that cycles through all the files related (headers, tests, spec, etc) would be kinda amazing.
I like this a lot, too. In fact, I’ve been thinking about implementing :alt for Clojure, and am a little sad that it always replaces the buffer. So I was trying to figure out how to separate finding the alternate file, with how it gets there.
So, this seems obvious.
I’ve been thinking about this. Theres various other nice things we can do with nice little POSIX programs like this: initially populating an empty file, tab indent rules, maybe an external highlighter?
So I’m thinking, “What if we named them prefixed with filetype?” E.g. clojure-alt, and ruby-alt. Now we can have a repo for Clojure support and a repo for Ruby support. These would be basically editor agnostic (ok, I guess the external highlighter wouldn’t really be, but…)
Then we could have a driver program which invokes $filetype-$0 "$@" based on detecting the language. This could use file.
This is a bit of a rough story. Using file is nice, but packages can’t really install file rules, can they? Can this be refined?
A little late to the party, but I quite like how vim-projectionist handles this, as it’s highly configurable on a per-project basis.
1 Like