-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Let's talk about treemacs and spacemacs Part 2: feedback and future plans #10432
Comments
Not directly related.. but yesterday I borrowed some ideas from your amazing treemacs cquery-tree.el Which was my attempt to help emacs-lsp/lsp-ui#73 (comment) The multiroots idea sounds like it aligns with LSP 3.6's new method |
Huh, I actually thought about adding my "treelib" idea to the future option list, but figured there'd be no demand. Treemacs can certainly be used on nested objects other than the file system, at least its building blocks can, with only minor adjustments. In fact I built a basic showcase that'll display your buffers, segregated based on major mode. The example is run with That code you see is mostly the result of copy-pasting my current treemacs macros into a new file, so there is still plenty of room for taking out and automating many manual parts. If the lsp project can use a tree-builder library (I assume the protocol has features like call/inheritance hierarchies) I'd be happy to get this rolling. |
The issue has disappeared page 2, so I'd like to give a status update, lest it looks like nothing came of all those paragraphs I spent on my grand design. As of now I am more than 40 commits in, and making good progress. A basic workspace, its automatic persistence, adding, removing and renaming projects, refreshing, There are 3 major blocks still left:
I am hoping to polish things enough to have a version worth testing by others sometime next week. Participation in the ticket has so far been less than I had hoped for. I prefer to be optimistic and assume it's because I'm doing something right, nonetheless if someone could help me fill up that global keymap that'd be great. |
@Alexander-Miller I can't talk for everybody but I mostly was pretty busy and what I've read at the time sounded good to me (and I didn't have anything worthwhile to add) so I kept silent :) One thing that bother me right now are the semantics around
In general though I don't see the value in having bindings for I'm pretty sure I'm missing something, because I remember |
Now that's the kind of answer I was looking for. First of all it's important to move away from the idea of having a single file tree whose root you arbitrarily change. The new treemacs is all about multiple static and persistent project trees, like the project explorer in eclipse. So instead of changing your root it's about adding and removing projects from your workspace. At any rate you're right on ft/T and fp/P, they are are indeed too similar, especially with M-0 thrown into the mix. Right now it's even worse with a workspace, since with multiple file trees you won't be changing roots, wich is what T & P are all about. Let's try to come up with something more consistent and intuitive:
What do you think? |
Throwing my 2 cents in real quick. I'd prefer to keep a binding of |
Sounds like you're describing It's already around on |
I am now at a point where, except for filewatch-mode, the new code is ready to be properly tested. If anyone wants to lend me a hand just grab the multiroot branch. To run a local installation just clone the package and pass its path to |
@Alexander-Miller that sounds really great to me. There's only one point I'd like to possibly see streamlined:
If I've already opened a projectile wouldn't it make sense to add the root of the current project automatically and open treemacs? Or maybe if that's suboptimal for some reason, at least add it as a config option. Regarding @axelson's comment: wouldn't this use case be covered by btw I'll try to test your branch this week 👍 |
I can try integrating something like this in treemacs-projectile. Filewatch-mode should work too now, integrating it turned out to be much easier than expected. I did however discover an issue in filewatch-mode that causes git-mode to be inaccurate. Filewatch-mode tries to be smart and do as little work as needed - for example if you change /foo/bar/baz/file.el the update code will basically just moves point to /foo/bar/baz and hits TAB twice. Directories to be updated are marked in O(1) and updated in O(log n), a clean and efficient process all around. Except that with extended git-mode /foo and /foo/bar and /foo/bar/baz now need to be fontified as (un)modified as well. Now that really puts a spoke in my wheel ... Long story short I'll need to launch another python process to take care of just that. Here's what I have on the matter. If anyone knows how to do it better, either the part of python part, I am all ears.
|
Sorry, @Alexander-Miller, I've been too busy to follow along, and this is some serious commitment you are showing here. Really looking forward to this next iteration of treemacs and how it will work out for Clojure development! |
Yeah, well, some people got me into that software craftsmanship mindset and I'm pretty sure you know the rest.
I don't think I'll be doing anything clojure-specific. That kind of specialization is not webscale. |
@Alexander-Miller I wanted to checkout your branch and did the following:
It doesn't seem to be loaded (for eg. I can still change roots), pretty sure I'm doing something wrong here 😅 |
Putting it on the load path just means that |
Small update, since it's been quiet for a while. I've simply taken a small break and development is back on track now. The git stuff from above will be done later (otherwise I'll never finish this), so I'll be moving on to tests and docs soon enough. @piotrpalek Any news on your end, did you get it working? |
Almost done now. Should only be minor cleanup left. I've rewritten the readme and added section on projects and contributing as requested on gitter. @piotrpalek First starting treemacs with an empty workspace should now preselect the current projectile project if treemacs-projectile is loaded (I just haven't tried this yet). Other than that treemacs-projectile now only contains a function to add a projectile project to the treemacs workspace (bound to C-p p), making it awfully empty in my eyes.So if anyone has an idea for another way treemacs can integrate with projectile I'm all ears. |
I would like to remain one feature - keep only one open project and sweetch between it on project switch. |
Well now that's the complete opposite of what I've been doing all this time. I don't even know what exactly you mean by project switch, but the way things are now it's probably only possible by butchering half my code base. You know that one scene in the new DOOM where the robot dude tells you that "this is the cost of progress" as you stand there surrounded by corpses? It's kind of like that. The new design is not without its limitations, however jumping between projects is perfectly achievable by adding the relevant projects to the workspace and |
@Alexander-Miller , is it possible to expand active project and collapse all other during project switch? |
Yes that's doable. I already have a similar feature in |
@myrgy I've created an issue that you can track at Alexander-Miller/treemacs#169 so you know when it's done. Right now it's not on the top of my priorities, I expect to mostly focus on bug fixes and stability once multiroot is released, but it'll be implemented in the medium-term. |
Thanks a lot! |
The changes are up on master now, so I'll close up shop here. If you've bug reports or feature requests with the new setup just open up an issue over at treemacs. I'll update the layer when I find the time, though seeing how it should be just changing some keybinds at most anyone who's interested can make that PR. |
Hello everyone,
the next big thing I am teaching treemacs to do is the ability to display multiple file trees at the same time. This feature may sound fairly simple, but will require serious amounts of changes and redesign, such that the next iteration of treemacs is an ideal point to introduce further breaking changes and break old habits.
So this thread serves the purpose of getting community feedback not just for my current multiroot design, but also for treemacs as a whole. If there is some default behaviour or feature or keybind that you want to see changed, now is your chance.
Let's also tag some people who have previously provided valuable feedback before and who might be interested in this: @seagle0128 @duianto @rswgnu @ambihelical @piotrpalek @sdwolfz @TimoFreiberg @bitterblue
Multiroot design
What I have so far
Local Keys
My current prefix choice is
C-p
. Currently the keymap looks like this:Global Keys
SPC f T
andSPC f P
need to be changed to run something like "add current dir/project" to theworkspace. Otherwise the global keymap looks as follows:
Session Persistence
Let us call the projects you've added to treemacs your workspace. I expect people will naturally want their workspaces to be persistent. I think that my current approach of integrating with
desktop-save-mode
is no longer the best fit, sinceSo there is some serious dissonance between treemacs' workspaces, its frame-locality and
desktop-save-mode
.My idea to untangle this is as follows:
desktop-save-mode
integration is removed, it's pretty hacky as it is anyway. What treemacs will always be persisting instead is your workspace. Treemacs will remain frame-local, but your workspace will be global. Each frame will have its own treemacs buffer offering a unique view on the workspace, but adding/removing/renaming projects will be a global action.Persisting, using and switcing between multiple workspaces is something I'm saving for later.
Issues
Project path independence
There is one limitation I need to enforce which may or may not annoy you, depending on your workflow. Project paths must be fully independent of each other, it will not be possible to add a project which is a subdirectory of another project. Doing so will break a very important invariant that treemacs relies on heavily: each node has a unique natural key in its absolute path. If I do away with that I wreck my backing data structures and turn (tag-)follow-mode and filewatch-mode into undefined behaviour.
No more root changing
Arbitrarily changing the root doesn't really fit into the new concept of mostly static projects file trees, especially with the above-mentioned restriction, so I've removed that option.
Future Options
And finally a list of things I plan to get around to after multiroot are done, which I'll prioritize based on feedback.
Dynamic Module
I'll rewrite treemacs in rust! At the very least I'll try and offer a native option for the current python-based tasks (git & directory-collapsing). If that goes well I'll write a native implementation of as much of the hot path (basically what happens when you press TAB) as possible.
Improved performance
Native modules aside I am already pretty much at the limit of what can be done, as far as just the rendering is concerned. One avenue still open to me is make filewatch-mode smarter with how it runs its updates. Its current approach is to refresh directories with changes (basically closing and reopening them). Depening on the amount of work it's probably much cheaper to make changes to single lines.
Mouse Faces
The nodes in treemacs currently all use the same generic mouse-over face (I think it's
region
). I want to try and give them mouse faces which are correct w.r.t. both your current theme and the nodes' actual faces, including their git state.Better tag options - tag hook
If treemacs gets its tags for a file that is not open in emacs it will use the default imenu implementation since mode-hooks are disabled to prevent bugs and improve performance. There should be an option to define some hook treemacs should use in this case when the default won't do.
Indent Guide
I want to optionally give each indent step in treemacs a consecutively darker background to make indentation better visible.
The text was updated successfully, but these errors were encountered: