[ jEdit-devel ] [ jedit-Plugin Feature Requests-3105585 ] Console commando ideas

Plugin Feature Requests item #3105585, was opened at 2010-11-08 16:36
Message generated for change (Comment added) made by kog13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=3105585&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Damien (kog13)
Assigned to: Nobody/Anonymous (nobody)
Summary: Console commando ideas

Initial Comment:
I have a couple ideas to enhance commando a little bit.

First, I don't like how fields with EVAL defined can't persist values. There is no reason to change the fields at all if they must be changed every time something is compiled, so I have an idea for a solution that uses the value of EVAL to determine the default value, and then saves the value as a buffer-local property rather than a jEdit global one. I'm not entirely certain if this would be the ideal solution for this, but I would like there to be some way to persist values defined by EVAL.

Second, I've been playing around with the idea of running commando commands while bypassing the dialog. On slower computers, the dialog can take a second to appear, which in a quick workflow can become annoying, and running commands manually in the console misses the benefit of global shortcuts for compiling and running. A separate pair of actions could be created that would either use the dialog's default values, or run a command configurable in the options pane. Again, I'm not sure what the best way to implement this would be.

Third, and probably simplest, there should be a way to enable customizing the commands without needing the toolbar. Currently, the only way I know to customize a command is to first enable the toolbar, right-click on its button and select "Customize," and then disable it again. This is cumbersome for people who don't use the toolbar by default.

----------------------------------------------------------------------

Comment By: Damien (kog13)
Date: 2010-11-30 16:08

Message:
The commando dialog is slowest on first invocation, and I don't think
removing the combo box helps much. I implemented a method in ConsolePlugin
to simply get one command by name rather than a full list, but there's
still a slight delay when first used. Beyond first use it doesn't seem to
be much of an issue.

Another idea for making compiling/running more flexible would be to
replace the massive list of combo boxes in "compile & run" with:

- a single combo box at the top to specify the edit mode
- for compiling and interpreting, there would be two options, selectable
with radio buttons
-- the first option is to use a commando command
-- the second is to specify an arbitrary system command, with useful
environment variables listed (e.g. $f for the buffer's path, $d for its
directory, etc.)

Allowing a custom command to be specified for an edit mode would give
advanced users more flexibility and allow things to be compiled more
quickly by not requiring the dialog window to pop up.

I've also been considering creating another plugin (but which could
potentially be incorporated into Console, although I'm not sure at this
point) to help with project management. My initial idea was to separate
ProjectBuilder into its two distinct functions, project creation and
project compilation, making them more flexible and independent of each
other.

For project compilation, my new idea is to create something that is aware
of possible build tools and their respective buildfiles (e.g.
ant/build.xml, make/Makefile, maven/pom.xml, etc.), and when compilation is
activated, look in the project root for a buildfile; if one is found,
execute its corresponding tool. This could be extended to create an action
set for different build targets, configurable on a project-by-project basis
with a set of default, common ones. Project run configurations would have
to be handled differently, but could also have pre-defined methods (e.g.
Java Application, Executable, etc.).

Again, this won't necessarily be included in Console, but direct support
for project compilation shouldn't be implemented twice.

----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2010-11-27 16:30

Message:
What we need is a new option:
x  Show combobox in Commando Dialog

When checked, then the other commandos are added to the dialog along with
the combobox. 
When not checked, then we only see the commando we asked for in a dialog.



----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2010-11-16 13:47

Message:
I've also been noticing how slow the commando is taking to create.

I think perhaps we should also think of making the commando dialog
creation faster. Do we really need a combobox selector to switch to any of
the other commandos when we pop up one of them? It's parsing and creating
all of them each time, instead of just the one that is asked for! If one is
invoked directly via shortcut, it should be as fast as possible.

Or at least, don't bother creating the "hidden" commands from that
dialog.


----------------------------------------------------------------------

Comment By: Damien (kog13)
Date: 2010-11-09 13:41

Message:
1) BufferLocal isn't necessary for creating buffer properties. The buffer
class supports setting properties; BufferLocal just persists them, which I
don't think would be necessary.

2) The only problem then becomes the best way to handle it. Should it use
the commando's default values, or be something else entirely?

3) One idea would be to create an action called "customize commando" or
similar, which would bring up a window displaying all available commands;
double-clicking on one could then close the window and open that file as a
buffer. As a side note, I don't think this should replace right-clicking on
the toolbar, but rather be an addition.

I like the idea for the run configurations, but would that simply create
new actions in console? There's a distinct difference between compiling a
buffer and building a project.

----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2010-11-09 11:43

Message:
Actually, where the Console  should persist its properties should be more
on a project-wide basis rather than a buffer-local property... And I think 
it should be stored in the projectviewer's plugin options area for that
project.
Further, it might also be nice to have a "Run Configurations"
Projectviewer options pane provided by Console that shows all of those
options and perhaps others that are related to execution of things.



----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2010-11-09 11:38

Message:
For the first point, does this make console depend on bufferlocal, or is it
an optional dependency?
i hope the latter.

Second point - execute (no dialog). great idea. I agree it is slow
sometimes.

For the last point, a way to customize commando buttons, i first thought
of offering that from
the plugin options under toolbar, but what should it do? currently the way
to customize is to open a buffer and edit it. We can't do that from a modal
dialog, users will think nothing has happened (unless we tell the user to
edit the buffer after closing the options dialog, but that seems weird).

So maybe we need dynamically generated actions for each of the existing
commando buttons for a "customize" as well as an "execute".



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997936&aid=3105585&group_id=588