[Meir]

Dear community,

I raised this issue with Yutaka in a private communication. (I was locked out due to hackers from my corner of the world…) I am posting this here for the community to show support.

What I am suggesting is to add to the core something akin to the “Projects” plugin. The current one, as a plugin, is most useful. Links are provided to modules not in the same directory tree, and of different types (.cpp, .txt, .h, etc.). Files are instantly available and it is easy to add and remove links.

But it has some severe limitations:

More than one project cannot be open in different windows (“groups”) at the same time.
It is not part of the workspace and a corresponding project doesn’t open when you ask for a different project/group/workspace.

I would like to see a consolidation of the notions of “project”, “workspace” “window” and “group” into one, “Project”. That’s what defines our work as software developers. You switch projects, mentally and physically, you then open a new (or an existing) window in which another workspace, another list of software modules links, and files are open.

Com’mon folks! Show your support

[Paul]

First, I have some sympathy for this idea.

However, I’m not certain I support moving this into the core, unless it’s the only way to make it happen. I don’t use Projects normally. In my use, EmEditor is a super powerful, hyper-fast, syntax highlighting text editor, not an IDE. The editor’s speed is the thing that keeps me coming back. When files open at the speed of thought, it’s hard to use one that makes you wait, even if for only a couple of seconds. The more built-in functionality, the slower the editor will be, and the less attractive for my usage. If the idea would work as a plug-in (and I confess that I don’t know what the limitations of a plug-in are in this area), I would prefer that.

That said, I admit to not using these features much, but I might use them if they worked better together. Having the workspace global across all open instances of EmEditor makes it not terribly useful for me, so I have to use scripts to support a similar, not as useful, functionality. Having used Atom and Visual Studio Code before dumping them in favor of EmEditor does make the concept of a Project Folder attractive, although not as the central file management feature, and I hesitate to ask for the complexity needed to make something like that optional.

Not exactly what you’re looking for, I know. But I’m not sure that merging all of those together into the core will be useful for those of us who don’t mainly use EmEditor in the “project” aspect.

[Meir]

Dear Paul,

I absolutely agree with you regarding how important is the lightning-speed of EE, including when opening files, no buts! And I always opposed features that cause EE to bloat. Speed of opening files is why I use and like so much the Projects plugin. You click on a filename in the project tree and it is instantly open, even ones which are a few megabytes large. And source code files are tens of kilobytes at most. So I never hesitate to close a file if it clutters my desktop.

But the limitations of the projects plugin (see in my original post) are really annoying. And I agree with you that the way Workspaces are now they are not that useful, and they are already part of the core! So are Groups, which are part of the core for years now.

So what I am suggesting is to rename “Groups” as “projects”, associate them, one-to-one, with a workspace and just add the Project tree of hyperlinks.

I defer to Yutaka to answer how will that impact speed, if at all. I wouldn’t be surprised if it would even speed up the beast… :-)

Warm regards
Meir

[Paul]

Meir,

My hesitation, after playing with the workspaces and projects plug-in this morning, is the Groups integration. Groups, to me, are a way to get EmEditor to dynamically set up related files and not worry about how the file set was generated or having to save the file set. Combining the groups into the project arena may negatively affect this capability.

Combining the Project and Workspace I don’t have as much problem since I don’t use either one. I do like that workspaces are integrated into the core and appear on the tray icon menu and have their files auto-open when the workspace is open. If other open groups could be (optionally) left open when a workspace is opened then I would be far more likely to use it. Projects are too heavy weight for me, and with all the different menu options appear to be bloat if added to the core, but others may have different opinions/needs.

[Meir]

Dear Paul,

I can assure you that we are not in disagreement. But I am not sure why you think the project part is a heavy load. All it does is providing hyperlinks arranged in a two levels tree, “Solutions” and “Projects”. All one can do, other than click a tree branch hyperlink to open a file, is to add a file-branch to the tree and remove one. That’s it!

All I wish for is that when I open a workspace, it will open in a separate window (a “Group” by any other name…), including the Projects tree on the left. And the opposite – a “Save Workspace” operation should save the current state of the tree together will everything else. That’s it. “Open Project” will in fact be “Open Workspace” and similarly “Save Project” is “Save Workspace, and I don’t care which name is used…)

Best Regards,
Meir

[Paul]

Meir,

I’m guessing you never opened a Visual Studio Solution? When I do that, the Project Plug-in also allows me
to

1. generate and view a list of symbols,
2. change the default configuration of the Solution,
3. change the default platform,
4. Build/Clean/Rebuild the solution
5. Check files in and out of Source Safe

in its Visual Studio configuration ( which is installed along side the EmEditor template – I certainly never set that up).

The plug-in itself It also lets me to create new solution templates (similar to EmEditor’s configuration) that contain tools, set up new keyboard shortcuts for that template, and set up new configurations and platforms with their own macros. There might be more, but that’s all I see on the menu.

It also has its own toolbar that allows access to all that.

That’s why I say the plug-in is more heavy weight.

[Meir]

Dear Paul,

You are right, I never worked in Visual Studio. And we use ‘git’ to share access to project files and as our source control and repository.

And I never use all these additional functions you mentioned, so I can’t appreciate their impact.

Anyway, I am waiting for Yutaka to pick up the glove…

Best regards,
Meir

[Author]

Posts