Bug 14550 - Code formatting still broken with custom braces/indentation ALSO on brace closing
Summary: Code formatting still broken with custom braces/indentation ALSO on brace clo...
Status: VERIFIED NOT_REPRODUCIBLE
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Text Editor ()
Version: 4.0.10
Hardware: Macintosh Mac OS
: Low normal
Target Milestone: 4.2.4 (from master)
Assignee: Mike Krüger
URL:
Depends on:
Blocks:
 
Reported: 2013-09-09 07:55 UTC by Andy
Modified: 2014-03-13 09:39 UTC (History)
3 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
VERIFIED NOT_REPRODUCIBLE

Description Andy 2013-09-09 07:55:31 UTC
I keep getting replies that code formatting is fixed, at least on closing curly brackets (not while typing on the fly, which is bad enough). However, this is really not the case: next line shifted is ignored for the most part.

I think after two years it's time to fix this, or at least make VS work decently with Xamarin.iOS, at the moment I have to edit in VS and debug on the Mac...
Comment 1 Mike Krüger 2013-09-09 08:02:36 UTC
it's not released - I didn't get any time working on that the last 6 years :(.
Fortunately I now got some :) - and expect that 4.0.14 will have all my fixes.
Comment 2 Andy 2013-09-09 08:25:42 UTC
Well, thanks, I hope this time it's really fixed. Not doubting your word, but it appears to be a tough thing to do after all this time. 
I don't know your internal organization within the project, but it seems a tad unusual to me to take care of this only after all the new features, which, while cool enough, are worthless if the IDE does not work properly...
Thanks
Comment 3 Mike Krüger 2013-09-09 09:34:56 UTC
Hm, I say since years that we should work on code formatting/typing behavior. I think it's even now not #1 on the prio list :/ 
But we've tons of work to do you can imagine and at the end it's not really my decision. 

btw. I would even switch the formatting style to vs.net as default to make the switch between the IDEs easier - but I doubt that this will ever happen - what do you think about our code formatting default settings ?
Comment 4 Andy 2013-09-09 11:21:17 UTC
The default code formatting ? It's absolutely the opposite of what I use :) but I guess this is really up to how everyone learned and feel comfortable. I applaud the possibility of customizing the code formatting, I also understand perfectly there is a ton of work, what I actually don't understand (but this is probably my limit) it's how a product like this (which is actually relatively costly after the price hike) can be offered with such a buggy IDE...

I don't want to sound harsh, it's just that in my view the first thing to take care of - before all the Async stuff and the other cool extras (which are extras nontheless) - should be the basics. 

The other side of this coin is VS integration: in my experience it is so painful that I'm not even considering it is there anymore. I lost probably a week of work fixing a bug in the VS integration, so now I regressed to just sharing the files, edit code on VS and build/edit the project on the Mac. I think this issue and the code formatting/IDE are somehow related, fix one and the other is less important (of course debugging from VS would be cool).

Thanks for your time and good luck with your work
Comment 5 Andy 2014-01-06 12:05:42 UTC
It's still a mess, sadly

This never fails:

- create new project
- chose VS code formatting default
- set braces to 'next line shifted' wherever the default is 'next line'
- create a series of methods with a couple of if/else, etc
- braces line up correctly
- delete and recreate the last brace in the file (the namespace closure)
- recreate it -> it won't 'shift' one tab
- now every closing brace won't shift anymore. Other indentation is broken too
Comment 6 Mike Krüger 2014-01-07 03:42:12 UTC
fixed
Comment 7 Andy 2014-01-07 06:18:25 UTC
Thanks. How can I know when this goes into a release ? There are no changelogs for betas
Comment 8 Andy 2014-01-11 08:42:47 UTC
What should I do for all the remaining issues in indentation ? Reopen this ? File more bugs ? I feel there's still a lot to fix...

See example

public static void SubmitScore(Int64 scoreToSubmit)
            {
....
....
....
            GKScore.ReportScores(gkScores, delegate(NSError error)
                {
                if(error != null)
                    Helpers.ShowAlert(error.ToString());
                else
						Helpers.ShowAlert("Submitted score " + scoreToSubmit + " for: " + scoreName);
				});

this line gets shifted by one tab too much
Helpers.ShowAlert("Submitted score " + scoreToSubmit + " for: " + scoreName);
Comment 9 Andy 2014-01-11 08:55:05 UTC
Just to be more clear, it should either indent all the delegate code, or none. It indents only the last line
Comment 10 Mike Krüger 2014-01-13 02:31:33 UTC
File more bugs - btw. the example works for me in latest master - I think that got fixed.

If we handle all those issues in a single bug it's too difficult to track it's state.
Comment 13 Sadik Ali 2014-03-03 06:16:00 UTC
Below are steps:

1. Create Console project.
2. set "Braces" for the "Method declaration" "Next Line Shifted"
3. Create a new method.
4. Delete opening braces and back one tab, and add "{" you will see opening braces not indented automatically one tab next.

Refer screen cast: http://screencast.com/t/pH1L8Rs6y
Comment 14 Mike Krüger 2014-03-03 06:18:41 UTC
You need to set all of them to next line shifted...

The indenter isn't smart enough to determine all cases - that's what the formatter is for. I think in the case of it's not capable it falls back to statement indentation or something like that.
Comment 15 Sadik Ali 2014-03-13 09:39:28 UTC
I have checked this issue what I have mentioned in comment 11 on below environments:

All Mac
Xamarin Studio
Version 4.2.4 (build 13)
Build Information
Git revision: 575c3e95ccd43e4c066755bda27b698fdfd59e3c
Xamarin addins: 79a1e35d2f486ba15541d74724e764c81878ab16

1. Create Console project.
2. set "Braces" for the all "Next Line Shifted"
3. Create a new method.
4. Delete opening braces and back one tab, and add "{"  noticed that indentation is working.
Refer screen shot: http://screencast.com/t/rqjuKpqVnN

Hence I marked this as verified.