Open daFreeMan opened 7 years ago
In other words, set the modified modules' state to ParserState.Pending
(need to check if that alone would set the "global" state to "Pending" as well) and let the user trigger the re-parse manually?
How about adding a setting to enable/disable auto-reparse?
[ ] Parse project automatically after modifying the code.
I'm not to warm about introducing a delay to allow manual code changes - it's literally asking for the parser to fail because you're still in the middle of typing something when it caches your module's content.
IIUC, RD wouldn't necessarily know the correct position of each line after the refactor, although the AST will help that, so currently, a reparse is required.
Encapsulating fields in a class is a PITA from the outset, so perhaps RD should offer an Encapsulate Fields approach, or #875 needs more attention.
@retailcoder : If there were a quick button on the tool bar where I could disable it because I know that I'm about to run EF a bunch of times, then, when I'm done, re-enable and manually reparse, I think that would be good. If I have to rummage through the menus & settings, not so much.
Am I getting so lazy & dependent on RD's cool nifty awesome little features that I can't be bothered to wait a few extra moments?
@ThunderFrame :
If I highlight 10 rows of private
, then it runs EF
on each, prompting for the new property name and the option to chose Let/Set as appropriate, then does one reparse when they've all completed, I think that would be great!
I like the togglebutton idea very much. Even more than a yet another setting
I like the option of having a toggle for automatic reparses on the RD toolbar - there are several areas where RD is automatically kicking off a reparse (which is fantastic, usually), and having easy control over that would be great.
I like the idea of being able to select a range of code and a Refactor
function and have the refactoring apply to each line in the selection even more. If this could be applied to all the single-line refactorings that would be great. I think Rename
, Move Closer to Usage
, and Encapsulate Field
would be the ones affected by this.
Renamed the issue because the original idea is more or less moot with the rewriting but the subsequent discussion of enabling multiple refactoring on a selection would be very useful.
The fact that the code automatically reparses after executing
Refactor|Encapsulate Field
is awesome! Except when I'm starting a new class, and I've got 5... 10... 50 private variables that I need to encapsulate with Get/Let pairs.Would it be possible to put in a delay of say 5 to 10 seconds after the
EF
has finished to see if I'm going toEncapsulate
another field, prior to starting the reparse? It could set the IsDirty flag to a special value (Sorta
:) ) that would be acceptable for theEF
function, but every other RD function would treat it as Dirty and prevent more actions.Since
EF
seems to find its own space to put the new properties, it could simply insert the new code immediately following the location of the previous code.As it stands now, it takes about 30 seconds for the parse to finish and let me start another
EF
operation. Fortunately, I've only got 5 properties to deal with in this instance, but it would be very painful if there were many, many more.