Source Formatter

[Ceniza]

What it would be also good, would be the possibility to define and register new styles. In this was users could define more than one custom style.

That could even be considered a Feature Request for the current plugin, but if any of you do that it'd mean pending work for me (right, I'm the maintainer of the plugin, but some bug reports and requests are for AStyle itself, not the plugin) . I'll have it in mind

IMHO, the code should also thought extensible and scalable to allow integration of e.g., another parser.

IYHO, you still insist (I agree, but it'd be even more work)

If this plugin goes somewhere (instead of just converting the current file in a (token, lexeme) pair as it does now), it could have the same luck of the CodeCompletion plugin (redisign) . I wonder if Rick would like to suffer with this one too... :twisted:

The AStyle way is not so bad actually, it is simple and it works. But there are just a few things which AStyled does not do the way I like it (for example, it compresses white space in comments and around '=', and always puts {} in a new line, so if you spend a lot of time laying out things properly, the code formatter destroys it later). Also you can only configure everything from hand, or nothing, which is annoying (for example, I like the way ANSI style looks, but I don't like spaces for indentation).

I've had it in mind since you sent me that PM, so don't worry. If it gets somewhere I'll try to get that working... eventually

Why don't you make a simple "choose one out of n" interface (list box, for example). The actual configuration is read in from a config file, and you just provide 3-4 such configs. If somebody wants something different from ANSI, Gnu, or K&R, then he can write his own config and is not limited to a stiff GUI. Most people will use one of the default sets, so they have a 1-click configuration.

So, have a simple "choose one of..." interface and save the stiff GUI for customization so everybody will stick with the 3-4 configs. Understood

(Oh, and thanks, you just suggested the name for the customization button: "Stiff GUI"

... (designing a GUI takes 90% of your time, but only 10% of the people use it 1% of their time...).

I love that sentence, but I bet it'sn't yours :wink:

It's now time to focus on the Stiff GUI...

[thomas]

... (designing a GUI takes 90% of your time, but only 10% of the people use it 1% of their time...).

I love that sentence, but I bet it'sn't yours :wink:

I guess you could call it a free interpretation of the good old 90/10 rule, or of the hot spot concept which derives from it

[Michael]

IMHO, the code should also thought extensible and scalable to allow integration of e.g., another parser.

IYHO, you still insist (I agree, but it'd be even more work)

If this plugin goes somewhere (instead of just converting the current file in a (token, lexeme) pair as it does now), it could have the same luck of the CodeCompletion plugin (redisign) . I wonder if Rick would like to suffer with this one too... :twisted:

Sorry :oops:. I do not want to make you crazy about my extensibility and scalability bla bla .

In a previous project, I have had several problems in hard-coding things and do not thinking about extensibility/scalability. I still remember the nights where I was re-working my classes...... :roll:

May be you can make your hard code parts easier to be successively re-coded. Of course, if this does not mean too much additional work for you .

Michael

[yop]

... (designing a GUI takes 90% of your time, but only 10% of the people use it 1% of their time...).

I love that sentence, but I bet it'sn't yours :wink:

I guess you could call it a free interpretation of the good old 90/10 rule, or of the hot spot concept which derives from it

Funny I've only read the Meyer's 80-20 law

[thomas]

Funny I've only read the Meyer's 80-20 law

I guess Meyers was not even a child when they made the 90/10 rule. It is a really, really old rule, dating way back before computers were invented

On an interesting side note, the X Window system's design philosophy follows a  kind of 90/10 rule, too, which is addmittedly quite clever. It says something like "if you can get 90% of your features implemented with 10% of the trouble, then leave it at that".

[Ceniza]

I was working a bit more in the lexer. I'm kinda tired so it wouldn't be strange if I introduced a few bugs.

I just wanted to add that I got WebSVN working

http://svn.cenizasoft.cjb.net/websvn/

P.S.: Still waiting for ideas regarding the Stiff GUI. Screenies welcomed

[edit]
The WebSVN link has changed to http://svn.cenizasoft.cjb.net/
[/edit]

[280Z28]

I started writing a plugin that would format just what you were working on as you type, but gave up when no one answered this:

http://forums.codeblocks.org/index.php?topic=1927.0

All it was going to do is format the current statement or block after you hit ; or } but I thought it would be interesting.

I also wanted to make an option to word wrap a comment block without having to redo whatever delimiter you put at the beginning of a comment line.

[Michael]

I started writing a plugin that would format just what you were working on as you type, but gave up when no one answered this:

http://forums.codeblocks.org/index.php?topic=1927.0

All it was going to do is format the current statement or block after you hit ; or } but I thought it would be interesting.

It was interesting . You should not give up. May be such a real-time functionality could be implemented in what Ceniza is doing.

Michael
 

[280Z28]

I started writing a plugin that would format just what you were working on as you type, but gave up when no one answered this:

http://forums.codeblocks.org/index.php?topic=1927.0

All it was going to do is format the current statement or block after you hit ; or } but I thought it would be interesting.

It was interesting . You should not give up. May be such a real-time functionality could be implemented in what Ceniza is doing.

Michael
 

Maybe. I've been really busy working on another part.

[takeshimiya]

Still waiting for ideas regarding the Stiff GUI. Screenies welcomed

Here they are:

These are current drawbacks of the AStyle GUI, which you can take in account:

Code::Blocks AStyle Plugin
Actual behaviour:
Not a big problem, but the sample TextCtrl doesn't reflects the editor settings (font, colors, etc)
Expected behaviour:
The sample TextCtrl should be a cbEditor in the case it's not that difficult.
Maybe also letting the user can change the text example in real time wouldn't be bad.

Actual behaviour:
The window and TextCtrl is rather small, the text itself also, thus reviewing styles becomes hard.
Expected behaviour:
The text example should include more cases like classes, etc.

Actual behaviour:
The Custom style doesn't show any text at all.
Expected behaviour:
It should show the text and run AStyle over it in each change made to the custom settings.
At the time we'll have this working, the Sample TextCtrl should be shared across the 3 tabs.

Hope that helps a little

[Ceniza]

Time to ask before writing a complex parser when it's maybe unnecessary...

Customizing AStyle plugin provides:

Indentation:

• Indentation size (in spaces)
• Force using TABs
• Convert TABs to spaces
• Fill empty lines with the whitespace of their previous lines
• Indent classes
• Indent switches
• Indent case: statement in switches
• Indent brackets
• Indent blocks
• Indent namespaces
• Indent labels
• Indent multi-line preprocessor definitions

Formatting

• Brackets
• Pad empty lines around header blocks
• Break 'else if()' header combinations into separate lines
• Insert space padding around operators
• Insert space padding around parenthesis
• Don't break complex statements and multiple statements residing in a single line
• Don't break one-line blocks

Good, now: what to keep, what to add, what to remove or just a full redisign that allows even further customizations (this one was my idea, but it'd take longer to implement)?

Takeshi Miya: that could be implemented in the current plugin, with some time

[edit]
Takeshi Miya: I just added a Preview button and removed the READONLY flag for the wxTextCtrl in AStyle's plugin. I still need to redesign it to share the wxTextCtrl across the 3 trabs.

Patch to change the wxTextCtrl for a cbEditor that reflects the editor settings is welcomed

Another text sample that includes more cases is also welcomed
[/edit]

[tiwag]

the only thing which really bugs me using Astyle is, that
wxWidgets-typical macro constructs like

Code

BEGIN_EVENT_TABLE(MainFrame, wxFrame)
    EVT_ERASE_BACKGROUND(MainFrame::OnEraseBackground)
    EVT_SIZE(MainFrame::OnSize)
    EVT_UPDATE_UI(idViewStatusbar, MainFrame::OnViewMenuUpdateUI)
    EVT_MENU_RANGE(wxID_FILE1, wxID_FILE9, MainFrame::OnFileReopen)
    EVT_PROJECT_ACTIVATE(MainFrame::OnProjectActivated)
    EVT_SHOW_DOCK_WINDOW(MainFrame::OnRequestShowDockWindow)
END_EVENT_TABLE()

lose their format. this maybe owns potential for enhancements ...

[Ceniza]

tiwag: that'd need some kind of hack. That's what you get when playing with macros

Since it could also contribute with SourceFormatter's dialog, here's an example of AStyle's dialog with the Sample wxTextCtrl out of the wxNoteBook.



Evil for resolutions under 1024x768, and not that pretty IMHO, and couldn't find what else to add where the wxStaticTextSizer with title "Info" is now (maybe some random picture of a naked girl would make people launch that dialog more often, changing that 90/10/1 rule ).

[thomas]

Good, now: what to keep, what to add, what to remove or just a full redisign that allows even further customizations (this one was my idea, but it'd take longer to implement)?

I am not sure if a redesign really takes that much longer. Adapting something existing (especially if you did not write it in the first place) is often tedious.

[thomas]

tiwag: that'd need some kind of hack. That's what you get when playing with macros

Hey! Why not an "indent between <regex> and <regex>" option? That might be good for other things, too (not just event tables).