Both Gabor and Herbert have been discussing what they see as desirable in an editor.
I think most of the specifics of what this tool should do or that tool should do are largely irrelevant, because as a user interface we're facing what is fundamentally an "Open Problem".
What we can do, however, is identify the underlying effects that we need to achieve in the creation of tools for wide audiences, and then refer back to effects when looking at individual features.
I tend to see the creation of these wide-availability user-oriented tools as simultaneously enforce three main principles.
1. To allow the user to impose their will on the machine.
2. To educate the human on both the tool and the machine.
3. To optimise the above for both the human and the machine.
Being an open problem, any progress towards achieving these principles is going to be loaded with competing tensions and involve endless work.
But there is a certain symmetry between the challenge of optimising the machine elements and optimising the human elements.
Given any task on either the machine or human, we should first try to aim for an O(0) result, then an O(1) result, then O(log N), then O(N), and so on.
If our tool can achieve such perfect encapsulation of a concept that the user can impose their will on the machine without the need to be educated about the concept at all, then we should do so. If we can go further and know perfectly if and when the human needs to apply that concept, we should just do it for them. O(0) results for both education and imposition.
If the encapsulation is not perfect and will break down occasionally, then we should move on to implementing additional O(1) options for education such as well worded error messages that point directly to the appropriate education material and ways to tweak the imposition of the concept that allow for O(1) "Always/Never do it this way", or a further fallback to O(log N) "Always/Never for this website" or to O(N) "Always ask me".
And of course, achieving this result lazily is preferable to doing so up front (so you in aggregate you only require a partial subset to suffer the fallbacks).
You can optimise the machine along similar lines.
The ideal O(0) situation is to make it so the machine never has to address a problem, because you can prove in advance that the problem has always either already been addressed, or will always be addressed later.
Failing that, you try to address the problem O(1) with something like a constant (lazily if possible), or O(log N) with caching or various other methodologies, and so on, and so forth.
Most of the tools we use push up against one aspect of optimisation or the other, sometimes with sacrifices.
For example, Perl::Critic helps both helps educate developers and reduce the time cost of bugs and weird uses of Perl, but at the expense of having to maintain nocritic entries permanently, which themselves have education and time costs.
And the goal of the Perl Critic team is that the education and time cost of using Perl::Critic is significantly less than the education and time costs of NOT using Perl::Critic.
When it comes to editors, what annoys me the most is a failure to appreciate the differentiation between languages and deal with them correctly.
By aiming for "support" every damned language in the universe, general editors like my favoured Ultraedit create LOSSES of efficiently.
Even something as simple as a configuration option for "Always strip trailing spaces on save" can have huge problems, because (for example) you can't safely strip all trailing whitespace from Perl, because trailing whitespace in POD can be significant.
And since most of these editors either don't deal with the language distinctions properly, and then worse don't make the configuration option language-dependant, you end up with a feature that is worse than useless, because it will silently damage your code (some of the time).
This leads to the principle that wherever possible you should implement your software language tools in the same language as the one the tools works on. The code has better understand of it's own language, and the humans writing the tools are already educated on the specifics of the language.
Contrasting against this in the case of editors is the sheer expense of writing all the support infrastructure for an editor.
Resolving the tension between the benefits and the costs leads, I suspect to two optimal solutions.
1. Hugely bloated tools you already know, but struggle to deal with language issues well. (Emacs, Eclipse)
2. Language-specific tools that work well, but require an investment in training (perlcritic)
I would imagine that generalist programmers will be naturally attracted to the former, while language specialists will be naturally attracted to the latter.
As a member of the latter type, the challenge for Padre is that it needs to be SO good as a tool for working on Perl code that it is worth switching to it from your general purpose editor.
So this then, is what I plan to use as my guide for hacking on Padre.
I want to be in the position where vim users, and Emacs users, and Eclipse users, and Ultraedit users, are all switching over to Padre "just for a while" to do some specific task.
I want Padre to be SO good at working with Perl, and SO good at helping you impose your will on your code, that you'll hate your general purpose editor for not being good enough and making you change.
I want to achieve this WITHOUT pandering to the general purpose editors and implementing support for their magic project file formats, and their magic embedded comment formats, and all the other crap that only exists because they don't understand Perl well enough to Just Work.
And I totally expect the language generalists are going to hate it.
I write Perl. Screw compatibility.
This leads to the principle that wherever possible you should implement your software language tools in the same language as the one the tools works on.
I quite see how your argument leads to that.
I want Padre to be SO good at working with Perl, and SO good at helping you impose your will on your code, that you'll hate your general purpose editor for not being good enough and making you change.
Interpreting that this way, I would like to change... my editor so that it can use Padre's features. Ideally(?) replacing the whole or parts of the PerlySense Perl backend.
For that to happen, Padre needs to be designed so that the "editor" part is fairly cleanly separated from the "Perl aware IDE" parts (which it may well be, I haven't read any code).
Re:Integration requires decoupling
Alias on 2008-09-25T00:13:55
Just because I want Padre to rock isn't an excuse for not building it in a modular form, so that logical functionality can't be reused.
So yes, wherever possible things are being implemented in a standalone fashion, so that at least other Perl editors can reuse the logic.
For example, the debugger integration that Gabor wrote is quite likely going to appear in Kephra as well.
Re:Integration requires decoupling
Aristotle on 2008-09-25T15:50:10
Which is good, because while you hope to make Padre so good that I’ll hate Vim for not being Padre, I already know with near-certainty that I’m going to hate Padre for not being Vim.
:-) For sheer economy of motion, the Vim editing model is hard to beat. (It’s also wired deep into my muscle memory now. I constantly do things like hit [Esc] or type dd or such into HTML textareas or Gaim or anywhere else I edit text. I would try to
:wq shells before I got ZZ and Ctrl-D wired into my fingers.)
