Introducing Process Palette


#1

Hello everyone

I’d like some input from the community on Process Palette.

It allows one to add entries to the Command Palette to execute arbitrary shell commands. It works quite well when used in combination with toolbar packages such as command-toolbar and flex-tool-bar.

Please try it out! Any comments and suggestions are welcome. Also, let me know if the documentation isn’t clear enough.

Thus far I’ve only been able to test it on OSX. I’d appreciate it if some of the Windows users can take it for a spin!


#2

This looks fantastic!
I haven’t tried it out yet, but from the description I particularly like the manifold ways of targeting input and output, which should make it really useful as a tooling helper. Very cool idea!


#3

Same here, already seeing many applications for it in my daily works.

The documentation looks quite complete to me, there’s a lot of possibilities and you seems to have already thought about a lot of use case. Maybe you can add some words about how environment variables are handled (ie. are you reusing process.env?).

I think there could be a fifth output target that opens a new text editor and puts the content in it (useful for commands that generate stuff in the console you generally pipe to a file after that). Having only the option to paste the output into the current editor may be a bit hazardous sometime.

I also think you could add an option in the command for additional environment variables, it’s not uncommon to have many ways to run a command by setting an environment variable prior to the command call.

Keep up the good work!


#4

Thanks! I made it to help me with my own tool chain, so I’ll be glad if others can also find it useful.


#5

The new output target is a great idea! I’ll definitely add that feature.

At the moment I’m not making provision for environmental variables. I’m not familiar with process.env, but I quickly looked it up. Thanks for suggesting it! I’ll work on making use of it. I’ll also look into configuring environment variables as part of the configuration.

Thank you for your reply and the great suggestions!


#6

Thanks for the great package. One thing: I was confused by the examples for defining new shell commands. If you define a command using

{
  "namespace": "Process Palette",
  "action": "Defaults Example",
}

then it is not callable from init.coffee. For example, I was expecting to be able to use the following construct in init.coffee out of the box:

atom.commands.add 'atom-text-editor',
  "test:command": (event) ->
  editorElement = atom.views.getView(atom.workspace.getActiveTextEditor())
  atom.commands.dispatch(editorElement, 'process-palette:defaults-example')

But, this only works if you define the new shell command using

{
  "namespace": "process-palette",
  "action": "defaults-example",
}

#7

Hi @masonlr

I’ve never tried to use it like that before. I took another look at the commands API and it actually says the following:

If either part consists of multiple words, these must be separated by hyphens. E.g. awesome-package:turn-it-up-to-eleven. All words should be lowercased.

The example works when running it from the command palette, but I guess when using the commands API directly like that one needs to adhere to the requirement as stated. To be honest, given the requirement, I’m not 100% why the example works at all :confused: Maybe the command palette is a bit more lenient. Sorry, I don’t have enough insight into how Atom treat commands in the background to be able to shed light on this behaviour…


#8

Thanks @morassman. Would it be possible to add a note to the readme that explains this behaviour for the sake of new users? My use case was that I was trying to include a process palette command as part of a chain of commands to be linked to a single keybinding (following the documentation here: http://flight-manual.atom.io/behind-atom/sections/keymaps-in-depth/#composed-commands).

The following approach doesn’t work:

In process-palette.json:

{
  "namespace": "Process Palette",
  "action": "Defaults Example",
}

In init.coffee:

atom.commands.add 'atom-text-editor',
  "test:command": (event) ->
  editorElement = atom.views.getView(atom.workspace.getActiveTextEditor())
  # dispatch additional commands...
  atom.commands.dispatch(editorElement, 'Process Palette:Defaults Example')
  # dispatch additional commands...

Note: Process Palette:Echo Example exists in atom.commands.registeredCommands but can’t be called from init.cofee.

The following approach does work:

In process-palette.json:

{
  "namespace": "process-palette",
  "action": "defaults-example",
}

In init.coffee:

atom.commands.add 'atom-text-editor',
  "test:command": (event) ->
  editorElement = atom.views.getView(atom.workspace.getActiveTextEditor())
  # dispatch additional commands...
  atom.commands.dispatch(editorElement, 'process-palette:defaults-example')
  # dispatch additional commands...

Note: process-palette:echo-example exists in atom.commands.registeredCommands and can be called from init.cofee.

A suggestion…

Maybe the default naming convention could be as follows:

That way three things work: (1) the command shows correctly as “Process Palette: Echo Test” in the command palette, (2) the command shows correctly as “Process Palette: Echo Test” in the process palette, (3) the command can be dispatched using the identifier 'process-palette:defaults-example' from init.coffee.


#9

Sure. I think what I’ll do is enforce it in the editor and explain the reason for it in there and also in the documentation.

I added an issue for this.


#10

Great plugin! I didn’t see it in the docs, but is there a way to change what shell to use? And if not, what do you think about adding that feature? My default is zsh, but none of my zsh aliases work unfortunately.


#11

I haven’t tested it myself, but from the documentation it seems to be supported. I added an issue for this and will look into it.

Would you prefer to set this globally or per command? I can support both by letting the command specific setting override the global setting, but I guess that it would make more sense to always use the same shell.


#12

Hi @alexheyd. I’ve added a setting to version 0.9.1 for specifying the shell to be used. This setting will be used for all commands. I tested it with /bin/zsh and zsh was indeed used when I ran a command. I can’t guarantee that your aliases will work. I hope they do, but I see no reason why they shouldn’t. If this doesn’t work the way you expect it to then feel free to log an issue.


#13

Great thank you @morassman! I didn’t get a notification for your first reply, apologies. I’ll check out the new setting and will let you know if I run into any issues.


#14

I am using this and works well. The one thing I want to do is have a “save” issued before my shell script. I have this all set to run my shell scripts making and compiling. But can’t seem to get a save command issued before the make. I use a mac with the latest O/S. Anything you can do to help me out with that would be appreciated.

Thanks.


#15

Commands can be configured to save files in the workspace before the command gets executed. This is disabled by default, but it can be configured to either save all the unsaved files or only those that are referenced by the command being executed.

If you have been using this, but it doesn’t work then there may be a bug. If that is the case then log an issue and I’ll look into it.

Screenshot from configuration editor:


#16

I’ve started using Process Palette, and it’s been very helpful for what I’m trying to do. Thanks for contributing it! I’m having a bit of trouble accomplishing what I’m trying to do, and wondering if you could give me some input.

I’m using Process Palette to invoke a python script that downloads a text file from a server. I’d like for that file to be opened in the current Atom window upon completion.

I haven’t figured out a good way to do this. I considered setting the target to Active Editor, and then sending the contents of the file to stdout in my python script. The issue with that is that there’s other output from the script that describes what it’s doing, and I don’t want that getting mixed in with the file’s contents.

Any thoughts on how I could do this?

Thanks!

Dan


#17

You should probably just write to a file. You wouldn’t have to mess with stdout at all.


#18

It’s actually a file that I’m transferring in the first place. The issue is that I haven’t found a reliable way to get that file to open in the current workspace after being transferred.

My solution right now is just to invoke

atom path/to/file/filename

at the end of my python script that does the transfer. This will sometimes open it as a tab in the current workspace, but sometimes it will open it in a new window, which is not what I want. The behavior is not consistent (see https://github.com/atom/atom/issues/5138). For now it works most of the time the way I’m doing it, but I’d eventually like a solution that’s more consistent.


#19

If you know the location of the file on disk, you can use atom.workspace.open() on it.


#20

My first thought was to just open the file at the end of the script like you’ve already tried. It’s a pity that it opens in a new window though. That would have been the simplest solution.

I don’t think atom.workspace.open() will work in this case. One will have to call that after the process has completed, but Process Palette doesn’t have a callback that one can hook into to execute custom code.

The only solution I can think of at the moment, without having to add a new feature, is to echo the full path of the file once the download is complete. Process Palette will detect the file path in the output and create a link of it that you can click on to open the file. I know that you’d like the file to be opened automatically, but if you’re willing to have a manual step then this approach might be sufficient for now.