RD needs a move to folder command

[MDoerner]

As mentioned in issue #3323 the support for folders lacks some usability.

I would like to suggest a first step towards a better usability: a command that moves a module into a specified folder.

What I imagine is requesting the name of the desired folder in a dialog, maybe with a potentially already existing current folder prefilled. On confirmation a refactoring gets calles that inserts/updates the module with the corresponding folder annotation at the right place.

We could bind this to a new menu item in the context menu in the code explorer.

[Vogel612]

This should be pretty simple. The only thing this needs to watch out for is existing folder annotations. It can additionally be used to subsequently implement a "Drag'n'Drop" feature for CE, which would just call the command on drop.

Especially of note here: it's not necessary to force reparses, nor do any references actually change, so as opposed to other programming languages this is not a rename.

[Profex13]

A nice feature would be to be able to drag/drop the modules into existing folders. The module being moved could just replace it's @folder annotation with the destination. Also, creating an empty module(s) as a placeholder for "New Folder" wouldn't be the worst thing in the world. Once you drag a "Real" module in, you could remove the placeholder module. Maybe it could even be just one module called "Folders" with multiple @Folder.Empty() annotations (or something that wouldn't ignore the multiple annotations).

[retailcoder]

@Profex13 agreed on drag & drop into existing folders - however one of the strengths of Rubberduck is its ability to avoid spilling artifacts into the user's VBA project and polluting it with things that are useless without Rubberduck (for example unit testing requires RD to run, but remain useful documentation even without, and there's next to zero boilerplate needed, at least compared to other unit testing solutions in VBA): I'd consider an empty "new folder" module one such artifact... I'd rather not have it, at least not in the project itself. Given a "project file" though (ref. #4306), I wouldn't exclude storing "project folder metadata" in there - that could even remove the need for a @Folder annotation altogether.

[MDoerner]

Regarding the comment that a reparse is not necessary, this is not the case. Adding a folder annotation will change the position of other code in the module. Accordingly, we have to reparse the module. Moreover, without reparsing the affected module, the annotation remains invisible to RD.

[MDoerner]

Do we want moving to a folder to be considered a refactoring, i.e. also put it into the refactoring menus?

The implementation should probably feature soem IModuleToFolderMover doing the actual moving, which can later be reused for the Dreag & Drop command. For the usual one, we would need a dialog, which makes it look very much like the Rename refactoring.

[Vogel612]

Considering that a folder move always involves a rewrite, it makes sense to handle it like a refactoring, even if VBA does not support namespacing semantics beyond the project scope.