Treemacs: In place renaming

[Compro-Prasad]

Keep the name of the file. Change the cursor type/color. Lock vertical movement of cursor so that user can edit the current file name. Clicking outside or going out of focus will cancel the action. Pressing return will rename the file.

[Alexander-Miller]

Yep, definitely getting very dired in here. The whole restrict movement part does sound all kinds of awfully complex and full of edge cases. Like what happens if the file gets deleted under your nose as you're typing?

You know I've had this idea for a package that would use a child frame for user-input. You'd pop up the frame wherever you want, in whatever size you want, without disturbing your usual windows and your overlays. No need to look to the minibuffer, it's right at the cursor, or wherever else you want it.

I think that'd be a more interesting approach than another, less awesome, wdired.

[Alexander-Miller]

There's already pos-frame that can handle the lion's share of child-frame management. That should make things considerably easier.

[Alexander-Miller]

Starting work on this now - experimental pos-frame-read package is over at https://github.com/Alexander-Miller/pfr. Before I start adding other features let's make sure it works. Can you try and see if the following code behaves property?

(let ((txt (pfr-read ">_ "))) (message "Entered '%s'" txt))

You should see a child frame pop up where point is and you can confirm the text with C-c C-c.

[Alexander-Miller]

https://github.com/melpa/melpa/pull/6183

[Alexander-Miller]

I have a working prototype now, but child frames require emacs 26, while my policy is to support the current and previous emacs version (as of now that's 25+26), and I don't want the overhead of packing everything into a temporary package and creating an interface for it. I'll put this on hold until emacs 27 is released.

[yyoncho]

It will be great if you have considered the extensions as well. It will be very useful for changing the inline value for variables view in dap-mode.

[Alexander-Miller]

I don't think there is anything for me to do on that front. cfrs is just a fancy read-string. If you have a custom function reading user input`in dap-mode then it's your decision how and when to use cfrs for it.

[Alexander-Miller]

cfrs is live now. That also means that treemacs officially no longer supports Emacs 25.

[Compro-Prasad]

Its hard to see where the cfrs window opened. Some flash, blur, transparency or window border might help.

EDIT: Theme is modus-operandi.

[Alexander-Miller]

Child frames' border color is controller by the internal-border face, but in my experience hardly any themes actually define it, so the result looks like your screenshot.

I've also now added cfrs-frame-parameters that lets you control options like the popup's border width or background color.

[Compro-Prasad]

So, I think @protesilaos would help with https://github.com/protesilaos/modus-themes to add the internal border for cfrs?

[protesilaos]

Thanks @Compro-Prasad! I will look into it in 2-3 hours.

[protesilaos]

Sorry if I am hijacking this issue: just to note @Compro-Prasad that I added a color for the internal-border face per @Alexander-Miller's guidance. If something does not feel right, can you please open an issue in my repo so that we may review it without derailing this thread? Thanks again for your feedback!

[Compro-Prasad]

It looks good now. Thanks!

[protesilaos]

Hello, I am afraid I have to revert that commit: internal-border should be left up to the user to define, because it affects all frames. Here is what I mean:

Reproduce that screenshot with:

(let ((width (if (> (display-pixel-width) 1920)
                 24
               8)))
  (add-to-list 'default-frame-alist `(internal-border-width . ,width))
  (set-frame-parameter (selected-frame) 'internal-border-width width))

As such, use this code to set the border to a color of your preference (modus-themes-with-colors and modus-themes-color are explained in the manual):

;; Either this
(modus-themes-with-colors
  (custom-set-faces
   `(internal-border ((,class :background ,fg-window-divider-inner)))))

;; Or this
(set-face-attribute 'internal-border nil
                    :background
                    (modus-themes-color 'fg-window-divider-inner))

Sorry about that!

[Alexander-Miller]

internal-border should be left up to the user to define, because it affects all frames

Why is that a problem? All the other faces affect all frames as well, and I don't think I've ever seen anyone use an internal-border greater than zero by default. On the other hand having the internal-border face defined would help every package that uses child frames, and there's 22 of them just depending on posframe.

[protesilaos]

Why is that a problem? All the other faces affect all frames as well

The issue is that it affects child frames and regular frames. We should be able to disaggregate them.

and I don't think I've ever seen anyone use an internal-border greater than zero by default

I used to believe the same, until I got three separate messages about my change affecting users' main frames. People set an inner margin so that they get a more comfortable/spacious presentation (I do keep it at zero though).

On the other hand having the internal-border face defined would help every package that uses child frames, and there's 22 of them just depending on posframe.

I recognise this is a problem and I do not like what I had to do. Packages like ivy-posframe set their own face for their border, which solves this problem, though I understand this is not an ideal solution either. Perhaps we should raise a bug report in upstream Emacs where we ask for an unambiguous internal-border-child-frame face or something to that end.

What do you think?

EDIT: fixed some typos.

[Compro-Prasad]

Perhaps we should raise a bug report in upstream Emacs where we ask for an unambiguous internal-border-child-frame face or something to that end.

That might help. I think you have the FSF agreement so you can contribute to Emacs directly so that wont be an issue. But the problem is that it will be released with Emacs 28. Till then we need to rely on something else. Maybe, I can set the face by myself for the time being. What about other users who use modus-operandi and treemacs together? They will also face a similar issue.

[Alexander-Miller]

Ok, so a general solution is out. Instead I've done the same thing as ivy-posframe and defined a dedicated cfrs-border-color face that can be safely set by the modus and other themes.

Perhaps we should raise a bug report in upstream Emacs where we ask for an unambiguous internal-border-child-frame face or something to that end.

Did it an hour ago, still waiting for the confirmation. I'll link it once it arrives.

[protesilaos]

Instead I've done the same thing as ivy-posframe and defined a dedicated cfrs-border-color face

Just added support for it. Thank you!

Did it an hour ago, still waiting for the confirmation. I'll link it once it arrives.

Very well! Let's see how it goes.

[Alexander-Miller]

Didn't get a confirmation mail for whatever reason.

Here's the link: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45620

[Crandel]

How to turn this off? Treemacs completely broken for me in swaywm(Wayland), I can't rename anymore

[Alexander-Miller]

If you're on wayland I assume you are using the pgtk build. There's general child-frame problems with that version, see also https://github.com/Alexander-Miller/cfrs/issues/4

You can go back to the default behavior by setting treemacs-read-string-input to 'from-minibuffer.

[Crandel]

@Alexander-Miller Thank you!