jonmorehouse / vim-flow Goto Github PK

Flowconfig should reread the configuration each time, or just simply read from the variables.

Ability to add in global flow-flags for directory

It seems to me like we can simplify this module drastically. Specifically, let's create the concept of a .flow.yml which declares all of the logic to handle a specific file runner.

A sample file looks like:

all: 
   tmux_pane: 1
   tmux_session: 0
   cmd: |
       echo {{filename}}

py: 
  cmd: |
       echo {{filename}}

It seems to me like we can make this stupid simple. VimFlow does the following:

• identifies the current file's extension
• walks up the directory path and fines the closest ".flow.yml"
• fetches the extension command or the "all" command and executes it

We can remove all of the builtin flows, in favor of having users specify a .flow.yml. This should automagically re-load each file each time (there is no caching, anywhere) and runs the command in either the current window or a background tmux window.

We'll support the following variable templates:

templates = {
    "{{filename}}": os.path.abspath(filepath),
    "{{directory}}": os.path.dirname(filepath),
}

FWIW - we should still "lock" files, but it seems like almost everything else can go in favor of this simpler work flow.

So right now we build commands and execute them directly... it seems to me like a better way to do this would be to treat each command as a unique script.

For instance... given the following command:

---
cmd: |
    clear && \
    if [[ ! -d /tmp/venv ]]; then echo "hi"; fi

We are going to try and wrap this into a single line command to send to tmux, and will have to deal with all sorts of issues around escaping and later unescaping characters.

What if we take a different approach:

• check the command to see if it has a hashbang syntax, defaulting to whatever the current shell is in its place
• write the command to a temporary file which is executable
• send a command to tmux / vim to execute this file directly
• remove the created file.

This also has the nice side effect of allowing us to do some more fun things in our flow files; for instance the above example now turns into:

---
cmd: | #!/usr/bin/zsh 
if [[ ! -d /tmp/venv ]];
     then echo "hi";
fi 

You know, using this more and more, I realized that there isn't anything particularly vim-specific about vim-flow in a lot of ways.

What if vim-flow became a small wrapper around a flow script, which was a standalone binary which could run commands.

Specifically, this would allow us to run commands from outside of vim and would make it much easier to bring vim-flow to new editors and things

vim-flow greedily picks the first .flow.yml file it can find.

This is a problem in the case where I've declared a local .flow.yml file and only want to override a certain type of file (ie: I haven't declared an all block).

It seems to me like we ought to update flow.get_defs to accept an extension. We should continually walk the path upwards until we find a .flow.yml file which has either a corresponding extension block or an all block.

Thinking through some of the previous workflows that I had, I think it's sometimes helpful to specify a command for a specific filename.

For instance, let's say you are working on a Vagrantfile and want to run a vagrant command as part of your dev/test flow, we could support something like:

---
Vagrantfile:
     cmd: cd ~/vagrant && vagrant up

It almost seems like we need a "file" flow and a "project" flow concept.

For instance, I find myself working on a golang project with a yaml file or json file and would like to validate that file with my default work flow. It'd be great to call ProjectFlow and FileFlow.

I had to remove the bit of code that removes the temp script after we run it. Let's clean that up

Filetypes

• haskell
• golang
• python
• coffee / package.json
• ruby
• vim
• javascript

We need to update the readme:

• features section
• .flow.yml section
• podcast?!
• file locking
• usage / installation

Let's add a neovim runner which allows us to send output to a neovim buffer.

This will involve finding or creating the neovim term buffer and then calling a shell command that points to the flow script from within it.

Heh - I had this feature before, where vim-flow would try to make a best effort at creating the tmux pane/session.

A few thoughts ...

1.) we probably would want this to be optional
2.) to be fair, this is currently accomplishable by creating a standard cmd that controls tmux for you ...
3.) this would increase the surface area of each individual runner

It looks like the following .flow.yml file breaks things:

---
py:
    cmd: | 
           cd ~ && \
           echo "test" && \
           echo "here"

Let's update the runner.vim_runner method to support this use case

I am trying to use vim-flow with the default .flow.yml provided in the repo.
When I'm trying to :FlowRun any script, I get the following error:
'.flow.yml' file at $HOME/.flow.yml is not parseable yaml
Any idea how to fix it?

It looks like the tmux runner doesn't output too nicely for vim-flow. Specifically, we'll want to capture the stdout / stderr within vim and "print" it so that the dialog window disappears correctly and doesn't leave artifacts.

So just thinking through a work flow I'm working on now ...

I've got a small server running in another window, and I'd love to 1.) build the server, 2.) start the server and 3.) curl the server fetching the response.

It'd be pretty awesome if I could set up several commands to do this for me. This is technically possible now, but it would be pretty elegant to be able to specify multiple commands for a single "flow" def.

Let's support screen!

So I'm currently working on gatekeeper which is a deeply structured go app. It seems to me like it'd be really nice to be able to run a flow for *_test.go files.

How would we support this? Well, one approach would be to try and see if the the .flow.yaml keep is a regex, and if it is, then we could use that to check the current buffer.

^.*_test.go$:
   cmd: go test -v .

Seems like this could be problematic WRT to escaping / handling special characters.

1.) Parse for a shebang

• grab first line
• check if two words, if one word then parse path, if two then take second
  2.) Check for programs that should be executed with this
  3.) Respect orders. Filename match should supercede everything else