Ideas/Goals/Discussion

[sum01]

General ideas

• [ ] Allow variable file-name detection with $1-esque syntax

Unsure of how to go about this, as I'm not sure how the settings.json is parsed.

• [ ] Add a pipe operator for piping output into the target command.

• [x] Allow changing of if the view is horizontal or vertical, instead of only doing horizontal.

Should be easy with a setting in settings.json and checking it in new_view()

[sum01]

I'm going to release a v1 in a little bit so that this can be installed with plugin install cmdlog, since using a nightly tag seems to be broken.

[ghost]

I'd vote for a /plugins/cmdlog/cmdlog.json

/plugins/cmdlog/cmdlog.json

{
    "ft:c": {
        "cmd": "gcc-7 $file.c -o $file.out; ./$file.out; rm *.out"
    },
    "ft:java": {
        "cmd": "javac $file.java; java $file; rm *.class"
    },
    "ft:crystal": {
        "cmd": "crystal run --release --lto=thin --no-debug $file.cr; rm *.dwarf"
    },
    "ft:haskell": {
        "cmd": "ghc $file.hs -o $file.out; ./$file.out; rm $file.o; rm $file.hi"
    },
}

or even just

/plugins/cmdlog/cmdlog.json

{
    "ft:c"       : "gcc-7 $file.c -o $file.out; ./$file.out; rm *.out",
    "ft:java"    : "javac $file.java; java $file; rm *.class",
    "ft:crystal" : "crystal run --release --lto=thin --no-debug $file.cr; rm *.dwarf",
    "ft:haskell" : "ghc $file.hs -o $file.out; ./$file.out; rm $file.o; rm $file.hi",
}

sidenote: if someone git-clones this repo into the plugin folder by hand, its folder needs to be renamed cmdlog to match the name of the plugin

[sum01]

Just working on the README before I tag and push to master...

[sum01]

I do like the look of the second json example, but I'd like to look into how the current settings.json is parsed before I go off the rails and create my own json parser. I'm hoping that there's a way to use variables like $file so I don't have to reinvent the wheel.

[sum01]

Hmm. It seems changing to a real version didn't fix the previous issue that I thought was nightly's fault

[sum01]

Looks like this entire project might be pointless soon https://github.com/zyedidia/micro/issues/243#issuecomment-355412608

[ghost]

well it still does not provide a way to run commands using a shortcut based on the current filetype so that issue would remain open

[sum01]

If it's implemented with Bash-like syntax, something like that might work without a plugin. But I have no idea what kind of functionality it'll provide.

[ghost]

maybe it's best to take some time and see how it turns out in some days/ weeks

[sum01]

I looked at the term dependency he's using, and it seems to use the users shell, whichever they have. So I'm guessing any syntax that works in your shell will work in Micro's term. But that's just a guess.

[sum01]

Trying it out, and it's like I thought, it just opens a Bash shell (on Linux). So anything I can do in Bash is valid. This plugin is feeling pretty pointless now.

[ghost]

As of yet does not look very useful to me, I could just as well open a second terminal.

To me it's only usefull if it integrates with the editor (which was nice in your approach with the vsplit) in some way e.g. by providing different commands executed by key combos based on filetype or something similar.

[ghost]

I see this as an exaple of very well configurable shortcuts

"dynamicActions": [
    {
        "id": "my.execute.script",
        "name": "Execute my script",
        "type": "exec",
        "args": ["/path/to/script", "arg1", "${currentFile}", "${currentDir}"]
    },
    {
        "id": "my.open.application",
        "name": "Open in Sublime Text",
        "type": "application",
        "name": "Sublime Text",
        "args": ["${currentFile}"]
    }
]

based on this I could actually do the switch based on the filetype myself

and another neat trick: "a pipe command"

• if something is selected, provide this selection as a parameter to the shortcut like ${currentFile}, ${currentSelection} and have an option to replace the selected text with the response of the exec command

• if there is no current selection, the output of exec should be shown in a nice window just like you implemented it

(I'm just speaking/ summarizing ideas, no pressure, just in case you like them as well...)

[sum01]

Detecting the pipe, then using JobSpawn's onStdout to edit input so the output would feed into the target might work, but...

The problem is that would increase complexity quite a bit (reading json and parsing/handling pipe commands), and introduce a lot of corner-cases as well. At that point, it might be better to just use HandleShellCommand, but that doesn't work right now.

I understand that term doesn't integrate with the editor too cleanly, but it seems the dev has plans to improve it quite a bit. It is nightly after all.

I'm just kind of weary of working on this a bunch when he's working on the in-editor term.

[ghost]

reading json and parsing/handling pipe commands), and introduce a lot of corner-cases as well

to me this seems as easy as taking the selected text and doing string interpolation with "echo #{selectedText} | #{cmd}" (if there is some text selected and the specific shortcut of the #{cmd} is pressed) The pipe comand would not really be part of the json, just the #{cmd} would be part of it so there should be no special parsing (as far as I have thought).

I'm just kind of weary of working on this a bunch when he's working on the in-editor term.

sure, maybe the dev^{TM} will read here at some point as well and take inspiration or we'll just wait and see

[sum01]

I don't have any interest in continuing development of this, so I'm going to archive this repo.