|
|
Re: Disable Automatic Refactor [message #1703507 is a reply to message #1703505] |
Sat, 01 August 2015 18:12 |
Colton Murphy Messages: 6 Registered: July 2015 |
Junior Member |
|
|
(us/we) = my organization.
So you are saying that to rename a folder / header I have to do it on the file system...
This is a horrible feature for our usage. There are reasons why our header includes need to be named a certain way due to organization. For instance, I have "" in the includes and not <>. Eclipse doesn't seem to care and renames everything using <> with an absolute path. Also, it has actually messed up include paths while renaming causing compile errors.
Based on CDT's history, CDT has a horrible track record with us as eclipse users. The indexer is an abomination and half the time it fails to work. When it does work sometimes it fails to resolve 'everything'. This has propagated to us not trusting the renaming "feature" at all. Unless a feature can be reliable 100% of the time, we do not wish to use it. Why would I use a feature when I have to worry about the 10% of the time it fails which can cause obscure bugs or compile errors? This has already happened using the latest CDT.
The indexing / code completion / intellisense features of CDT are all an abomination; however, that is a different discussion. I will note however that visual studio has no problem in any of these areas in their latest releases. I don't have to worry about 're indexing' every time I change a header or move something around. In fact, its transparent to the user.
Why don't we use visual studio you ask? Believe me, we have been looking for years. Visual studio is not a fully mature platform with regards to the debugging on embedded targets yet.
I apologize for starting a rant. I came here looking for how to disable the feature, not start a rant. If you are telling me that I have to rename things outside of eclipse just because the CDT developers said "Yay, this feature is amazing. Nobody could possibly not ever want to use it", that is a huge ding in an already bad track record..
|
|
|
|
Re: Disable Automatic Refactor [message #1703510 is a reply to message #1703509] |
Sat, 01 August 2015 19:27 |
Colton Murphy Messages: 6 Registered: July 2015 |
Junior Member |
|
|
Every possible path? Eclipse has options for literally every possible path for EVERYTHING else. Don't sit there and tell me disabling auto rename is such a big deal. The number of options Eclipse has for everything is obnoxious. Bad comparison.
If I can't rename a folder in Eclipse without it failing (which it has) and have to do it outside the environment, I would argue that CDT / Eclipse whatever is useless. Renaming things is one of the most basic user operations that an IDE should provide. File and folder handling in a project inside an IDE is one of the most basic necessities for an IDE. Eclipse can't even get that right.
Having the feature in Eclipse is a great option. Don't force it on everyone if it DOES NOT work. Have the option to disable it. For those of you that want to use the feature and deal with the 10% of failure cases, more power to you. Don't force your buggy features on the rest of us.
Join in the development? So you want me to waste my time fixing the bad design decisions of other people? I am not wasting my time with software that is not even worth the two pennies I throw at it.
My opinions aside, there have been several other topics around the web stating the same reasoning that I have for having the option of disabling this feature. If your organization has rules for include paths and eclipse goes and screws them up, that is probably not a good thing.
I was not asking for a new feature. I was asking how to disable it. Now that I know there is no way to do that, it's not worth my time to keep up this discussion. It will literally save me effort just using the workaround even it it puts a huge smudge on eclipse's name.
We are done here, I request a mod to take this post down or close it. Not worth my time.
[Updated on: Sat, 01 August 2015 19:42] Report message to a moderator
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04079 seconds