Long not in a working state, so no review required.

The plugin is progressing nicely. In fact, it's almost done and just a matter of polishing. I think it starts to be ready for testing.

Actions items still include:

• "Reload current document after execution": Currently not yet implemented, since I think I will run into issues with the KDirWatcher of KTextEditor. This could be a tricky one.
• "Display in Pane" is not yet implemented. My current plan is that each run creates a new ToolView on the bottom, using a QTextEdit with fixed font that displays the output. However, how to close this? The only solution I can think of right now is to add a "Close" button.
• The variables %{directory} etc all work, but currently cannot nicely be inserted via GUI. The drop-down buttons in the tool dialog are supposed to do this, but maybe there is even a more elegant way.
• I would like to change %{directory} to %{CurrentDocument:Path} etc, so match the variables of QtCreator.

Btw, for the presets in the file 'externaltools' I have the following suggestion: Add "Presets >" with submenus to the Add button. The Add button would the contain:

• Add Tool...
• Add Preset > ...
• <separator>
• Add Category

Would that be a good idea? Or would you prefer another button, i.e.: Add | Edit... | Remove <spacer> Presets // here Presets would be a drop down menu listing all the presets. Or better call it Templates?

Template sounds better than preset ;=)

I play shortly with the thing.

Really important would be the implementation that stderr ends up in a extra pane.

For the pane: I would open one toolview for the external plugin output and have just consecutive runs overwrite the output.
One might want to implement later some kind of "history", e.g. remember the last X execution outputs.
But I wouldn't do one output pane per run.

I played a bit with writing some perl script, but actually nothing happend, even if I include stderr to replace my document.
I assume my command failed.

That would be something for the external tools toolview, too.

Having there tabs, aka one for the output you requested and a second to have some meta info of what was executed. e.g. full command line printed with working dir and stuff.

I tried the plugin, these are my observations:

• From the "Edit Tool" GUI I found no help which variables can be used. Apart from the dropdown menu, a simple tooltip would serve the purpose as a first step.
  • "I would like to change %{directory} to %{CurrentDocument:Path} etc, so match the variables of QtCreator." +1

• For the following test I used this command: bash with arguments: -c "echo %{filename}"
  • Output "Display in Pane": has no effect
    • ""Display in Pane" is not yet implemented. My current plan is that each run creates a new ToolView on the bottom, using a QTextEdit with fixed font that displays the output. However, how to close this? The only solution I can think of right now is to add a "Close" button." --> I am with Christoph: only one pane, later with history. Idea: Why an extra Close button? If it should behave like regular toolview, it can just stay open. Or by configuration only be shown on error. Instead of "Close" the button could be called "Go back" or so to focus the last active tool view.
  • Output "Insert in New Document": works fine
  • Output "Append to Current Document": works fine
  • Output "Replace Current Document": works fine. Idea: restore cursor position after operation.
  • Output "Replace Selected Text": works fine
  • Output "Insert at Cursor Position": works fine, even if text is selected

• The file externaltools contains a number of tools. As I understand those should be made available under a "Add Preset" or "Add Template" button but are not visible by default which requires an initial user action, right? Thoughts about this:
  • Make these tools available by default in their respective category.
  • In the settings page those tools could appear with a postfix, e.g. "Run Shell Script [built-in]" or "Clang Format Full File [built-in] to make clear those are built-in
  • If the user needs to change one: Let him copy the built-in item and have the possibility to disable the original one. This way it will still be visible in the Tools manager for reference or later use.
  • The "built-in" postfix could also serve as a hint that this tool is proven not to do any damage because it is reviewed by the community.

• It would be nice to have a way to copy an existing tool (built-in or custom) to be used as template for a new one. Can a tool be exported to make it shareable (ideally in the ini format of the externaltools file so that good tested tools can also be easily made available there)?

• I tried to add this tool, working example: git gui blame -- README.md. Edit Tool: Executable: git, Arguments: gui blame -- %{filename}. The gui gui starts but not with the selected file to blame. When I set Working Directory to %{directory}, then it works which means the default setting which is hinted by the gray text "Use current document path if empty" does not work properly.

• %{directory} expands to e.g. ///home/gregor/kde/src/kde/applications/kate/ Are the three slashes intended?

• I set Executable to cowsay and Input: to %{selection}. As soon as there is a space in the selected text the input is automatically quoted with single-quotes which is visible in the output. Maybe instead of auto-quoting add a hint that some programs might need (manual) quoting to work properly.

• "Edit Tool" minor GUI thing:
  • I would move "Mime types:" to the bottom of the dialog (or below "Name:") because it only affects the place or occasion when the tool is shown and has no operational effect.
  • Add a hint label that each tool is automatically available in "Configure Shortcuts" to set a custom shortcut.
  • "Editor command:": Side-question: is there a list of available commands in the Command Bar? E.g. pgrep is useful but hard to discover.

• Ideas for later:
  • for Git: have a possibility to select a branch, tag or another revision as input, e.g. to make a "Diff of the current file (or folder) with another revision" tool.
  • for the Diff tool in the tab bar: have a variable that holds the path to the document under the inactive tab which was right-clicked.

The following list is my current proposal of variables. These variables already vary from Qt Creator. Not everything else matches anyways:

CurrentDocument:FileBaseName        - Current document: File base name without path and suffix.
CurrentDocument:FileName            - Current document: File name without path.
CurrentDocument:FilePath            - Current document: Full path including file name.
CurrentDocument:FileExtension       - Current document: File extension.
CurrentDocument:Text                - Current document: Contents of entire file.
CurrentDocument:Path                - Current document: Full path excluding file name.
CurrentDocument:NativeFilePath      - Current document: Full path including file name, with native path separator (backslash on Windows).
CurrentDocument:NativePath          - Current document: Full path excluding file name, with native path separator (backslash on Windows).

CurrentDocument:Cursor:Line         - Line number of the text cursor position in current document (starts with 0).
CurrentDocument:Cursor:Column       - Column number of the text cursor position in current document (starts with 0).
CurrentDocument:Cursor:XPos         - X component in global screen coordinates of the cursor position.
CurrentDocument:Cursor:YPos         - Y component in global screen coordinates of the cursor position.
CurrentDocument:Selection:Text      - Current document: Full path excluding file name.
CurrentDocument:Selection:StartLine
CurrentDocument:Selection:StartColumn
CurrentDocument:Selection:EndLine
CurrentDocument:Selection:EndColumn
CurrentDocument:RowCount            - Total number of lines in the current document.

Date:<format>                       - The current date (QDate formatstring).
Date:Locale                         - The current date in current locale format.
Date:ISO                            - The current date (ISO).

Time:<format>                       - The current time (QTime formatstring).
Time:Loca                           - The current time in current locale format.
Time:ISO                            - The current time (ISO).

Env:<value>                         - Access environment variables.

JS:<expression>                     - Evaluate simple JavaScript statements. The statements may not contain '{' nor '}' characters.

UUID                                - Generate a new UUID.

Any objections or additons to this?

@gregormi

• Output "Replace Current Document": works fine. Idea: restore cursor position after operation.
  • Given the document usually changed afterwards, "restoring the cursor position" is pretty much undefined, and almost never correct...
• Display in Pane: Working on it
• Make tools available by default: I don't want to clutter the user with hundreds of tools. That's why I proposed the "Template". In general, I am not a big fan of adding everything "just because we can".
• Copy existing tool: Noted, makes sense
• Working directory if empty: fixed
• The leading triple slsahes are not wanted, need to do more QUrl voodoo
• Auto quoting: Currently I use KShell::splitArgs(m_tool->arguments) to get a list that I can pass to the QProcess. I assumed that this is correct in mooooost of the cases. Do we really want to have manual work here? Where is your bug? ;)
• ideas for later: git, select a branch: I don't have plans to extend a general purpose tool (external tools) into something that needs a lot of special handling. If you have a general purpose solution, fine, otherwise: wish rejected.

In D17971#404900, @dhaumann wrote:

@gregormi

• Output "Replace Current Document": works fine. Idea: restore cursor position after operation.
  • Given the document usually changed afterwards, "restoring the cursor position" is pretty much undefined, and almost never correct...

Hmm. My idea came from this siutation: 1) have an XML document open, 2) cursor somewhere near the top, 3) Run Format document. => View is scrolled down to the bottom. More comfortable would feel if the view would stay somewhere around the original position (must not be exact). Especially when formatting almost correctly formatted documents the document does not change that much. In any case: a nice-to-have feature.

• Make tools available by default: I don't want to clutter the user with hundreds of tools. That's why I proposed the "Template". In general, I am not a big fan of adding everything "just because we can".

I'm looking forward to having 100 tools :-). One thing came to my mind: what if we had externalstools.default and externaltools.extra? The tools defined in the first file are added by default. The second file contains those tools that must be added via "Templates". Personal note on the name "template": for a ready-made tool that can just be used as it is (which hopefully most of the tools are), the term "template" does not fit so good.

• Auto quoting: Currently I use KShell::splitArgs(m_tool->arguments) to get a list that I can pass to the QProcess. I assumed that this is correct in mooooost of the cases. Do we really want to have manual work here? Where is your bug? ;)

My bug: cowsay Hello World

shows

 _______________ 
< 'Hello World' >
 --------------- 
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

via the plugin, instead of

 _____________ 
< Hello World >
 ------------- 
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

...let us call it a minor bug ;-) and set it aside for now.

• ideas for later: git, select a branch: I don't have plans to extend a general purpose tool (external tools) into something that needs a lot of special handling. If you have a general purpose solution, fine, otherwise: wish rejected.

I thought about a general purpose solution: What about adding a new variable "ExternalTools:ScriptsPath" which points to a (new) directory "scripts" which is located in parallel to the externaltools file? In this directory scripts can be added that fulfill more special yet useful tasks, like the mentioned git tasks. I can also imagine more complex scripts that extract useful information out of the git repo and show it as HTML file (e.g. author statistics, extended blame or log info etc.) or help to extract a subfolder as a new git repository preserving its history.

By the way: idea for later for another Output type: "Show as popup" or "Display as inline note". This could be used for tools with little output like "Git Blame / Who touched this line last?" which runs only on the currently selected line.

The following list is my current proposal of variables. These variables already vary from Qt Creator. Not everything else matches anyways:
...
Any objections or additons to this?

Looks good. Is there a specific reason why the "variables already vary from Qt Creator"? I thought a goal was to make them as similar as possible. Otherwise fine.
I am curious: Is there a use case for the global cursor coordinates (in pixels, I suppose)?
For clang-format something like "CurrentDocument:Selection:StartBytes", "CurrentDocument:Selection:EndBytes", and "CurrentDocument:Selection:ByteCount" could be helpful.

CurrentDocument:Selection:Text - Current document: Full path excluding file name.
Time:Loca - The current time in current locale format.

minor copy&paste errors

• cursor position: Ok I agree, indeed I was stumbling over this as well. So blindly set it to the previous position, and if possible keep the scroll position.
• default vs not default: The problem with default tools is always that we have no idea what users will want to do. Adding e.g. git-cola (which imho makes sense) likely does not help 95% of the users. Especially others like qmlscene preview are even more special. I am not yet convinced to have all these as defaults in the list. I would rather want to add a "External Tools > Configure" entry to make configuration more accessible.
• cowsay: I see. Still, I think in most cases you need escaping. I can have a look again into what KShell::splitArgs() supports...
• KateExternalTools::ScriptsPath: Hm... that sounds like a nice try of adding something, along the lines of "QuickCoding" that never worked for users. As soon as it gets more complicated, noone except me (who write this) will understand anymore. ...or you need much more UI, which yet has to be invented.
• I like the idea of "Show as popup" or "Display as inline note". I was misunderstanding this first, though: For "Display as inline note" I first thought of the new InlineNoteInterface, but I think you are talking about KTextEditor::Message.
• Variables/Qt Creator: Because I think some are confusing. E.g. CurrentDocument:Column is less clear to me than CurrentDocument:Cursor:Column. Further, Qt Creator uses CurrentDocument::Row, where I prefer "Line", so it's CurrentDocument:Cursor:Line. For CurrentDate, I changed to Date, since it's shorter and another Date than "Current" does not make sense at all anyways (you would hard-code it then). Well... in the end, it probably does not matter much.
• XPos, YPos: Yes, you could start a tool at a specific position of the screen, making it look as if you have a context menu on the cursor position. E.g. kdialog --geometry... (seems to not work, though). But I think it could be useful (Qt Creator has it, too)

In D17971#405295, @dhaumann wrote:

• I like the idea of "Show as popup" or "Display as inline note". I was misunderstanding this first, though: For "Display as inline note" I first thought of the new InlineNoteInterface, but I think you are talking about KTextEditor::Message.

Actually, I meant both, KTextEditor::Message for "Show as popup" and InlineNoteInterface for the other one. For first one, there are some use cases; the second one could be used to display git blame information more persistently than with a disappearing note. Both nice to have, of course.

About the variables:
there might be the wish to do some action (formatting, annotating) on the current view, therefore the suggestion:

CurrentDocument:View:StartLine    - the first line that is at least partly visible in the current view
CurrentDocument:View:EndLine      - the last line that is at least partly visible in the current view

Maybe also because we have RowCount, but I have no use case yet:

CurrentDocument:CharCount            - Total number of characters in the current document
CurrentDocument:ByteCount            - Total number of bytes in the current document

Here the link to the mentioned asyle stuff
https://community.kde.org/Policies/Kdelibs_Coding_Style#Artistic_Style_.28astyle.29_automatic_code_formatting
But there is still "--align-pointer=name" missing