I have started to develop Padre about four months ago and version 0.14 that has just arrived to CPAN is already slightly usable.
I'd like to get your help to find out what are the most important things I should focus in the next four months?
I am sure you either use vi or emacs and you are totally satisfied with your development environment but, please for a short time imagine you are stuck in a well paying job and your management mandates you to use Padre.
Please give me the 5 most important things that are still missing from it so you can also say it is usable.
In order to do this obviously you will have to install it which might be a bit difficult if your OS does not come with binary version of wxPerl. On the other hand if you are lucky you'll only have to type cpan Padre, answer a few questions and wait till all the prereqs get installed. For some help with the installation check out the download page.
Thank you for your help
For those who want to cheat and skip the installation process there is a binary version of Padre for Linux and a Portable Strawberry Perl with Padre for Windows. Both can be found via the same download page.
Re:What is missing from Padre?
Alias on 2008-10-29T01:15:17
Patches welcome
:) Re:What is missing from Padre?
gabor on 2008-10-29T05:47:52
I have added a small change to Padre that should do the trick. So far I see Hungarian accented characters working fine but they worked earlier as well.Hebrew on the other hand is still broken:
I can type the letters and sometimes they show up. The direction is unclear but it is not RTL.All that on Ubuntu with locale being set to UTF-8. On my Windows for some reason I could not install the Hebrew keyboard.
So there is more work to do. Even if you can't patch it I'd appreciate if you checked out from SVN and ran it from there telling us if there is any improvement on your side and/or what is still broken.
First thing: auto-indent.
Second: I like that you've got Ack but I'm really loving my Ack/Vim integration so you'll have to be as good. That means hyper-linking the results.
Re:Auto indention.
gabor on 2008-10-29T10:21:25
1. "Show indention guide" when set, should show a vertical bar in the text on every line where the indentation is at least 2 levels deep. It worksforme on both Windows and Linux. If you still cannot see, please file a bug with details of your installation.2. Auto indentation was added. If you have time please check out from Subversion (r562 or later) and let me know if it works for you?
Re:one showstopper, 3 important misses.
gabor on 2008-11-04T09:26:12
1. and 2.a (autoindent) are implemented in 0.15 Can you please check and explain what do you mean by tab manipulation?There are tickets for 3. and 4.
thanks
Re:one showstopper, 3 important misses.
jquelin on 2008-11-04T15:44:42
ok, it detects if file has changed when saving... but that's a bit too late imho. i'd like padre to monitor open files on a regular basis (every 10 seconds?) to warn asap, and propose to reload file / ignore changes.
tab manipulation: ability to change all tabs to spaces. or pressing tab / shift+tab anywhere on a line indents / unindents the line. (or whatever key combination)file changed on disk
gabor on 2008-11-04T15:56:45
so what happens if the file changed, you get a popup and you say ignore?Should that stop checking till you save or reload next time?
Should it bugger you every 10 seconds?
Should it warn again only if the file changes again on the disk?
Something else?
Re:file changed on disk
jquelin on 2008-11-04T16:16:44
i'd say it warns again only if the file changes again on the disk.
but that would be a judgement call with stop checking till save/reload.
something.pl. But they do all start with a #! line. Padre should have mulitple ways to check the type of file if it's going to do the check./\w+(::\w+)*/ Right now it looks like it's only getting the first identifier.Re:What a padre needs...
duff on 2008-10-29T21:38:10
Ah, it looks like I'm not the only one to have this idea. For a poor-man's version of vim+textmate marriage, see http://vimmate.rubyforge.org/
It's no where near as full featured or as "clean" as I would want it though.
Re:What a padre needs...
Alias on 2008-10-30T03:15:24
Responses:
The
.pl files limitation is imposed by the first (pre-document-model) generation of file type code. We should be able to upgrade this fairly easily by adding perl type awareness to the ::Document::Perl class and then upgrading the limitation. The tabbed list on the right is a want-to-have already, you can see it's currently got that extra space at the top where the tabs should hopefully appear. Additionally, a file tree needs to wait for Project support.
Anything that allows linking to function documentation will also allow us to add documentation for installed modules. I personally think we need to add a bit better support for HTML rendering of POD first though.
Compatibility modes for other programs will probably need to wait for a bit, at least until key commands are configurable.
Integrated test support requires the implementation of Projects first.
Note: As I am writing this post I have not been able to install Padre yet, as some failure in my local Module::Build prevents me from installing the last dependencies (App::Ack and Wx::Perl::Dialog) and I am too tired to investigate this today.
Re:syntax highlighting
gabor on 2008-10-31T08:38:17
The default perl5 syntax highlighter of scintilla might not do it for you but with Padre you can actually write your own syntax highlighter in Perl.So if you have the time for that, it would be great to try to implement such a thing. I'd recommend using PPI. Though Adam said it might be too slow for this purpose and he knows a bit more about PPI than I do
:-), you might still beat him at his own game. That would be awesome. There are very naive syntax highlighters in some of the Padre::Document::* modules that you can look at to see how to colourise() once you know what part you want to be red or green.
Re:syntax highlighting
jrockway on 2008-11-02T03:06:57
FWIW, I have experimented with PPI-based highlighting in emacs. It is fast enough.Re:syntax highlighting
Alias on 2008-11-02T19:28:24
It may be that if we make sure to disable PPI past a certain threshold (say, more than 1 second of CPU for a reflow, which would happen at around 2000 lines) we could make it fast enough.
Re:syntax highlighting
gabor on 2008-11-05T09:33:52
We just found out that the version of Scintilla we are using does not support 5.10 so we seriously need to look into alternative syntax highlighting.There is already a first version in place but it is slow.
Could you share your results/experience/code with us?
maybe on #padre ?
Re:syntax highlighting
jrockway on 2008-11-02T03:06:04
No other editor on the market currently offers highlighting as rich as in vim
If by vim, you mean emacs. Trust me, cperl-mode is much more complete than anything vim has.
This is my first time playing, so far it seems like a very good start. All the basics are covered and didn't stumble in to anything that would completely stop me from getting work done if this was my only option. That said though there are some things that I find missing when compaired with my current editor of choice (vim + perl-support.vim).
On to the issues, there might be some historical reasons for some decisions that I've missed but here are my thoughts:
I'll keep playing and see if there's anything else that I can come up with, other then that though it seems like a great editor in the making.
Re:another 30 second review
gabor on 2008-11-04T09:49:12
Thanks for your reply.some of these already have tickets, for others I opened now.
tabs => X spaces is in Edit/Preferences
change font size fixed but I think only after 0.15 came out
Ctrl+t Ctrl+n swapped, but I think we'll change it back and then give you the option to change it as you want.
You are welcome on #padre or send an e-mail if you really don't want to create an account.
- The options already available in the menus (specially "Edit", "View" and "Perl") should really also be available as shortcut icons in the toolbar. Oh, you should also be able to control the toolbar adding/removing icons like (MS|Open)Office, but it's not really a problem for now, so don't bother - just keep it in mind
- Enabling/Disabling the right thingie that shows the subroutines via the "View" menu.
- I agree with jquelin, a non intrusive search box (preferably in the toolbar) would be great, like the approaches from vim and firefox.
- I'd also like to be able to set (and load, the latter probably in a submenu from "new") some code templates for new files (for pl, pm, even TT)
- I loved the Module::Starter integration, but it really should be a submenu entry for "new" ("new->module" or "new->module for cpan" or whatever). Also, since you're wrapping the module-starter helper so nicely, why not also wrap the catalyst.pl helper in "new->catalyst project" (or whatever)? Which brings me to the next feature request...
- Projects!
- One last (but not so easy imho) thing, if it's not too much to ask: debugger integration =)
So far you've done an amazing job! Congratulations (and many thanks!)
Re:small things, big difference (for me)
gabor on 2008-11-04T09:53:35
Thanks for your comments. All missing issues were added to trac and see my grant request for debugger integration
1. if my manager will will mandate on using some editor i will just ignore him. that makes no sense.
2. another this that makes no sense is to write another editor these days. gabor why do you waste you talent and time on creating editor??? there are so many to choose and if you are missing some feature - contribute to one.
i'm subscribed to test-automation-tips@szabgab.com since the beginning and there were two post in ~5 months. there is plenty to say about testing. that will be better spend time.
to people looking for editor written in perl i recommend Kephra - http://search.cpan.org/perldoc?Kephra it's working and it has plenty of features already.
Re:why another editor?
Alias on 2008-11-02T19:33:10
Historically, it has been somewhat difficult to contribute to Kephra.
Additionally, the source code for it is rather large and somewhat monolithic.
I certainly feel that there may be some advantages to having a pair of competing editors. Certainly we are already seeing some evidence that they are driving each other forwards to implement things.
Being able to edit files across disparate systems would be spiffy.