slothg / flexformatter

Automatically exported from code.google.com/p/flexformatter
0 stars 0 forks source link

Formating adobe classes #2

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
When you have 'format on save' selected and, by mistake save in one of
framework classes it is also formatted, and to get it back to normal state
you have to uncheck 'format on save', undo changes, save it and check
'format on save' again.

Would that be possible to not formatting framework classes?

Original issue reported on code.google.com by Mczaicki on 18 Jun 2009 at 6:26

GoogleCodeExporter commented 8 years ago
I don't think I know what the framework classes are.  Are you otherwise editing 
the
framework classes, you just don't want to change the formatting of them?

I think the best I could come up with would be a preference that let you exclude
files from auto formatting by package.

Original comment by Ernest.P...@sas.com on 7 Jul 2009 at 11:49

GoogleCodeExporter commented 8 years ago
If you Crtl + click (or use F3) on clases like Canvas, Button etc you would 
jump into
framework class.
By them I mean everything what is provided by Adobe.

About your solution.
We have four cases I think.

1. These framework clases, which should be blocked for formatting  by default 
(if you
change them, and then use this jumping shortcuts, you are jumping to wrong 
methods etc.)

2. Libs I included in project. Lets use TweenLite as an example. I would be 
really
great, as you proposed, to have possibility to exclude whole gs.* package (and
subpackages) from formating.

3. Sometimes I would want to exlude my class from formating. In that case, 
maybe lets
use something like that:

//format:false
public class myClass{
}

4. Another thing, really helpful, would be excluding parts of code from 
formating. I
think that the best way to do that would be to use tag from point 3. 

var a:int = 20 //line would be formated

//format:false
var b:int = 20 //line would NOT be formated
//format:true

var c:int = 20 //line would be formated

So format:false used before class definition would block formating of whole 
file.
This tag used in other place would block it until next format:true

Original comment by Mczaicki on 11 Jul 2009 at 6:38

GoogleCodeExporter commented 8 years ago
1. Hmm.  It seems like the real problem here is why the source code for Adobe
framework classes isn't marked read-only on the file system.  There's no reason 
why
those files should be editable at all.  I think there should be an Adobe defect 
on that.

2. I've written some code to allow you to exclude paths (not packages, but disk
paths, but I think that's close enough) using regular expressions.  I think 
this will
work for most cases.

3&4. I'll have to look and see how difficult it would be to observe the 
comments and
temporarily turn off formatting.  Out of curiosity, what's your motivation for 
this
feature?  Is there code that you share with someone else and you don't want to 
mess
with their formatting?  Are there some pieces of code that FlexFormatter can't 
do
properly, so you just want an easy way to ignore them?

Original comment by Ernest.P...@sas.com on 11 Jul 2009 at 4:27

GoogleCodeExporter commented 8 years ago
I found this existing defect: http://bugs.adobe.com/jira/browse/FB-15752

I think I won't worry about that since it's an Adobe issue, but if I allow you 
to
specify excludes to autoformatting, then you could add the adobe package if you
wanted to.

Original comment by Ernest.P...@sas.com on 11 Jul 2009 at 4:39

GoogleCodeExporter commented 8 years ago
1. Yes you have right - they should not allow to change them

2. Great!

3&4. For example matrix like that one in attachment.

Original comment by Mczaicki on 11 Jul 2009 at 6:01

Attachments:

GoogleCodeExporter commented 8 years ago
The 0.6.25 release contains the addition to the auto-update page that lets you
exclude paths, and a new command (search for "exclude block" in the keys 
dialog) that
will add comments to prevent formatting.  Let me know if you have problems.

Original comment by Ernest.P...@sas.com on 21 Jul 2009 at 10:08