Treemacs window is not resizable (gui)

[ambihelical]

Although the mouse changes when over the border between the treemacs window and others, dragging doesn't do anything. There is a message "No resizable window to left of this one" when I attempt this.
I looked for a configuration to enable resizing, but didn't find one. I'm assuming it doesn't exist.

I'm using current master (580cffb).

[Alexander-Miller]

The treemacs window has a fixed width to prevent it from changing sizes when other windows get deleted.

The width can still be changed by calling treemacs-reset-width with a prefix arg (bound to w). You can also make the window's width fully changeable, including with the mouse, by calling treemacs-toggle-fixed-width (bound to tw).

Manually resetting the width is something from the very early days of treemacs, when I didn't yet know how to freeze the width of the treemacs window, so I suppose I could flip the prefix arg behaviour to make things slightly more convenient, but the width should stay fixed. Unfreezing it will resize the treemacs window on any horizontal window configuration change.

[ambihelical]

Doesn't (window-preserve-size) do this without such a lock mode? I tried it on an unlocked treemacs window, and closing a vertical split window to the right did not change its size. I could still resize with the mouse (and probably other ways), but window management did not affect it. Here are the functions I used for the experiment:

(defun me:preserve-size()
  (interactive)
  (window-preserve-size (get-buffer-window treemacs--buffer-name) t t))

(defun me:no-preserve-size()
  (interactive)
  (window-preserve-size (get-buffer-window treemacs--buffer-name) t nil))

[Alexander-Miller]

I've had a different result, the size was preserved, but only as long as I did not change the window size with the mouse. Then it's back to the old behaviour. That might be an emacs version thing - I am using a self-compiled emacs26. The preservation is also done with window parameters, which is a compatibility nightmare with packages like persp and eyebrowse (this is why I dropped treemacs' side-window status).

It may be possible to make things to make things work by advising the drag with mouse functions, but I'm reluctant to get into something this complex. How about a compromise? I could add additional keybinds to quickly/slowly change the size of the treemacs window, bount to something like C-+/M-+ & C--/M--.

[ambihelical]

The setting is reset on any resizing, so some hook would need to restore it. But it sounds like there are other complications. On the compromise topic, 'tw' was the missing functionality I was looking for but couldn't find (even though I know how to look). I don't how you can improve that situation.

[Alexander-Miller]

If you tell me what terms you did look for I can at least add some aptly names aliases.

[ambihelical]

I looked for resize and enable if I remember correctly. Width didn't occur to me, but it probably should have. After thinking on it, it occurs to me that some kind of help popup could have helped if it was organized well. Something like magit's ? key or the org buffer shown when C-h m is used with ivy's mini-buffer.

[Alexander-Miller]

A hydra seems like a good fit. I'll get to making one when I'm done with #42.

[sw9]

It appears that balance-windows is also broken by using the fixed width. Isn't is also possible to advice the delete window, split window and so on, so that the width didn't change? I vaguely recall some other packages taking this approach. Though looking at neotree, looks like they took the approach of defadvice mouse-drag-vertical-line and balance-windows instead.

[Alexander-Miller]

Now with these kind of issues I definitely need a new approach. Judging by a quick test window-configuration-change-hook seems like a good place to go. Setting treemacs up there means it's generally compatible with whatever functions delete or create windows, though width still needs to be changed manually.
I'll make pushing a patch for this a priority.

[Alexander-Miller]

Patch is pushed. Behaviour should be the same, except without the problems with functions like balance-windows.

[Alexander-Miller]

Hydra is pushed now as well. It's bound to H and it should show you the most important keybinds, including any changed you made (and be probably aligned as well).

[sw9]

Need to require hydra. Also, I think you need to add a couple more spaces so that the columns line up properly. Dunno if it's just me.

[Alexander-Miller]

It's supposed to look like this. Can you post a screenshot of what it looks like for you?

[sw9]

[sw9]

Ah, I see the problem, I changed the keybinding for moving root. Nevermind.

[Alexander-Miller]

Well I mind anyway. It should still look properly aligned, unless you go for some overly long C-x M-y z combination, which I hope no one is crazy enough to do.

I've now pushed a patch that'll abridge <left> & <right> to LEFT & RIGHT.

[sw9]

Long term though, I think using columns is a cleaner way: https://github.com/abo-abo/hydra/wiki/internals#column

[Alexander-Miller]

Can't believe I missed that part. Thanks, I'll look into it.

[Alexander-Miller]

Tried the columns now, but they were misaligned, had empty filler entries in the shorter columns and lack the nice looking unicode bars and propertized strings I use. Guess I'll stick with the status quo for now.

@ambihelical What do you think, would you have quickly found how to change the window size if the helpful hydra had been around when you started looking?

[sw9]

Do you have a screenshot of it using columns and what that looks like? Not sure what you mean by empty filler entries. Kinda interested in playing around with that code as well.

Personally, I'm just used to describe-mode since that works everywhere, but maybe it's helpful for new users? Also, I guess I see hydras as more of way to enter and exit modes/states that saves you keystrokes as opposed to feature discovery.

[ambihelical]

If I had found the hydra, I think I would have found the toggle. I think ? would be more discoverable then H though, and consistent with magit, dired and probably others, even if evil users would lose their backward search binding (not a huge loss for this mode). BTW, M-k description has a typo.

[Alexander-Miller]

Do you have a screenshot of it using columns and what that looks like?

Here's what the example from the wiki looks like. All columns but the first have at least one filler entry.

Also, I guess I see hydras as more of way to enter and exit modes/states that saves you keystrokes as opposed to feature discovery.

Yeah, I'm putting the hydra on its head here. I just want a nice menu to quickly look up keybinds and features, like resizing the window. Just like describe-mode, but in a pretty table that fits into the minibuffer. Spacemacs does that quite often, but calls it a transient state.

and consistent with magit, dired and probably others

I put in on H because of evil, but everyone else going with ? is good enough an argument for me, so I'll change it.

M-k description has a typo.

Fixed.

[sw9]

That's weird, here's how it looks for me: . Maybe there's something wrong with your version of hydra?

That said, I'm really digging the unicode table, looks so much cleaner, even though having to manually align everything feels kinda hacky.

[Alexander-Miller]

Maybe there's something wrong with your version of hydra?

Just tried pulling a new version. I'm at hydra-20170903.218 now, and it's still misaligned. It does work correctly with emacs -Q, so it's probably some spacemacs interference.

That said, I'm really digging the unicode table, looks so much cleaner, even though having to manually align everything feels kinda hacky.

Lucky for you all the hacky manual alignment falls on me. And I think the good looks are worth some manual corrections from time to time. I don't think I'll be adding that many new keybound features that this'll become a serious annoyance. Treemacs doesn't lack in features, but it could use some better UX and discoverability, and a nice looking comprehensive help window is great for both.

[Alexander-Miller]

The hydra's taken care of the issue of discoverability now, so I'll close up here.

[didibus]

I'm not sure I understand what treemacs-toggle-fixed-width does? In my case, no matter if it is locked or unlocked, I still can't resize its width using the mouse, and I can always resize the width using treemacs-set-width?

[Alexander-Miller]

Looks like that feature didn't work for a while, you're just the first to tell me about it. Should be fixed with 82ba951.

[andreyorst]

Looks like that feature didn't work for a while, you're just the first to tell me about it. Should be fixed with 82ba951.

Seems that it doesn't work for me. Unlocking width with tw and trying to resize resize another window, but treemacs stays the same width:

Before resize:

After resize:

Rightmost window increased it's size, and treemacs is the same as before.

[Alexander-Miller]

It works the same way even without treemacs, unless you push the most-right window so far to the left that the one in the middle starts pushing into the left-most window. Unlocking the width means that you can change the size of treemacs directly with the mouse or something like `enlarge-window-horizontally`. It also means that treemacs will be affected by commands line `balance-windows-area`.

[andreyorst]

Unlocking the width means that you can change the size of treemacs
directly with the mouse

Which I can't do actually, as shown above. When I resize Treemacs with mouse, it doesn't get resized, but another window does. And enlarge-window-horizontally doesn't do anything, since Treemacs goes back to it's defined width immediately.

One more question. Is there any command that could temporarily increase Treemacs width to maximum? Our project has deeply nested structure and pretty much all the time filenames are not visible with sensible width of Treemacs.

[Alexander-Miller]

When I resize treemacs with mouse, it doesn't get resized, but another window does.

This is what it like for me: https://imgur.com/a/JKgZjyi Does it work if you run this: ``` (with-selected-window (treemacs-get-local-window) (setq treemacs--width-is-locked nil window-size-fixed nil)) ```

Is there any command that could temporarily increase Treemacs width to maximum?

Not yet, but it's on the list with #439. Newer versions of treemacs can alleviate at least part of the problem via `treemacs-eldoc-display`.

[andreyorst]

Does it work if you run this:

(with-selected-window (treemacs-get-local-window)
  (setq treemacs--width-is-locked nil
        window-size-fixed nil))

No.

This is what it like for me: https://imgur.com/a/JKgZjyi

Interesting. This is what it looks like on my PC: https://imgur.com/a/SEEvT1v
I was dragging borders with mouse but pointer didn't recorded for some reason.

My configuration is simple:

(use-package treemacs
  :commands (treemacs
             treemacs-follow-mode
             treemacs-filewatch-mode
             treemacs-fringe-indicator-mode)
  :bind (("<f8>" . treemacs)
         ("<f9>" . treemacs-select-window))
  :init
  (when window-system
    (setq treemacs-width 27
          treemacs-is-never-other-window t
          treemacs-indentation 0
          treemacs-space-between-root-nodes nil)
    (treemacs-follow-mode t)
    (treemacs-filewatch-mode t)
    (treemacs-fringe-indicator-mode nil)
    (treemacs)
    (other-window 1)))

[andreyorst]

Found it. Which Key configuration causing this issue:

(use-package which-key
  :commands which-key-mode
  :init
  (which-key-mode))

Removing this snippet, or disabling which-key-mode fixes issue for me. But I don't want to loose which-key functionality. Perhaps fix for this issue is related to my problem #376

[Alexander-Miller]

Yeah, the which-key code isn't quite right. I've reopened #376 for it.

[bk138]

@Alexander-Miller Is there a possible configuration that makes the Treemacs window resizable per default from emacs' start on?
I played around with treemacs-toggle-fixed-width in my init file: the Treemacs window is resizable with the mouse then, but takes up half of the frame width no matter what size is configured.

[andreyorst]

It also would be nice if treemacs could become re-sizable when user attempts to resize, but after resize it will use fixed size, so treemacs couldn't be resized by resizing the frame.

[Alexander-Miller]

I'll take it up in #514.

[hongyi-zhao]

Found it. Which Key configuration causing this issue:

(use-package which-key
  :commands which-key-mode
  :init
  (which-key-mode))

Removing this snippet, or disabling which-key-mode fixes issue for me. But I don't want to loose which-key functionality. Perhaps fix for this issue is related to my problem #376

I can't reproduce this problem with the latest versions of which-key and treemacs.

[goldfita]

I also can't get treemacs-toggle-fixed-width to work (version 0.4). The function treemacs-set-width only seems to work when the treemacs window is selected. How can you make it work from use-package?

[goldfita]

Now that I've looked at the code, I see that treemacs-set-width does not take a parameter to set the size; it only reads from input. The correct way to do this is with the customizations:

  (treemacs-width-is-initially-locked nil)
  (treemacs-width 40)

You can also adjust the size in increments with 'shift-<' and 'shift->'.

[Alexander-Miller]

Another potentially useful feature is treemacs-fit-window-width, bound to =. It'll make sure that the treemacs window is large (or small) enough to exactly fit its entire content.