Hydra last line is misaligned

[memeplex]

Just look at the screenshot:

I tested some other hydras and they look well, but they don't have the "vertical lines" the one for treemacs shows, so I don't know... I'm not an hydra user.

[memeplex]

Also notice the separator before H: has a different face than the other ones.

[Alexander-Miller]

I don't know what's going on here. The hydra looks correct on my end and that strange face has no right to be there, there's nothing special happening with that separator. Have you tried reinstalling?

[duianto]

The hydra looks fine here as well.

Tested in Emacs GUI, and in both the windows command line and windows powershell.

System Info 💻

• OS: windows-nt
• Emacs: 26.1
• Spacemacs: 0.300.0
• Spacemacs branch: develop (rev. e61575343)
• Graphic display: t
• Distribution: spacemacs
• Editing style: vim
• Completion: helm
• Layers:

(autohotkey colors emacs-lisp git helm html markdown multiple-cursors org spell-checking treemacs version-control)

• System configuration features: XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS THREADS LCMS2

[memeplex]

This is with emacs -Q:

You can see that the color of that face is slightly different.

~:: emacs --version
GNU Emacs 26.1.91

Pretty much the last from emacs-26 branch.

This is the value of hydra-str before calling defhydra:

#("\nTreemacs v2.4-2019.02.17 @ 26.1.91 Helpful Hydra\nNavigation              │ Opening Nodes              │ File Management    │ Toggles                 │ Projects              │ Misc.\n――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――\n_n_:     next Line        │ _TAB_:   dwim TAB            │ _c f_:   create file │ _t f_:   follow mode      │ _C-p a_: add project    │ _g_:     refresh\n_p_:     prev line        │ _RET_:   dwim RET            │ _c d_:   create dir  │ _t a_:   filewatch mode   │ _C-p d_: remove project │ _w_:     (re)set width\n_M-n_:   next neighbour   │ _o o_:   open no split       │ _R_:     rename      │ _t g_:   git mode         │ _C-p r_: rename project │ _y y_:   copy path\n_M-p_:   prev neighbour   │ _o h_:   open horizontal     │ _d_:     delete      │ _t h_:   show dotfiles    │                       │ _y r_:   copy root\n_u_:     goto parent      │ _o v_:   open vertical       │ _y f_:   copy        │ _t w_:   resizability     │                       │ _s_:     re-sort\n_M-N_:   down next window │ _o a a_: open ace            │                    │ _t v_:   fringe indicator │                       │ _b_:     bookmark\n_M-P_:   up next window   │ _o a h_: open ace horizontal │                    │                         │                       │\n                        │ _o a v_: open ace vertical   │                    │                         │                       │\n                        │ _o x_:   open externally     │                    │                         │                       │\n                        │ _H_:     close parent        │                    │                         │                       │\n" 1 49 (face treemacs-help-title-face) 50 60 (face treemacs-help-column-face) 76 89 (face treemacs-help-column-face) 105 120 (face treemacs-help-column-face) 126 134 (face treemacs-help-column-face) 152 160 (face treemacs-help-column-face) 176 181 (face treemacs-help-column-face))

I tried reinstalling. The problem is still there and now I have no icons at all :(. While installing I get the error:

treemacs-async.el:37:15:Error: Opening directory: No such file or directory, /home/carlos/.emacs.d/elpa/treemacs-20190215.627

The current install is in treemacs-20190219.603, not treemacs-20190215.627.

There is a match for treemacs-20190215.627 in elpa/treemacs-20190219.603/treemacs-icons.elc.

[memeplex]

Well, I fixed the last problem by uninstalling, restarting and installing again (have you tried turning it off and on again).

But the hydra is still wrongly aligned.

[memeplex]

This isn't happening for the stable release. I guess it could be caused by some changes recently done by Eli, related to visual line num mode (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=32337).

I'm closing this since the problem is probably in emacs core.

[duianto]

I tested with Emacs 26.1.91 in Windows 10 and the hydra is aligned correctly here as well.

[Eli-Zaretskii]

There's contradictory evidence here: some say it's okay with 26.1, but not with the latest emacs-26 branch, others say that 26.1.91, which for all practical purposes is the latest emacs-26, is also okay.

Would someone who sees the problem please go to the problematic character and tell what describe-text-properties say about it? And how is that different from other bar characters in the same buffer?

[memeplex]

@Eli-Zaretskii I would like to do that but is there any quick way to deactivate the fancy hydra settings that make the window auto-close on almost every event?

[Alexander-Miller]

Would someone who sees the problem please go to the problematic character and tell what describe-text-properties say about it?

That'll be difficult. AFAIU that text is generated by lv.el, it is basically a static minibuffer message that cannot be interacted with. @abo-abo is it possible to get to a hydra's text properties?

[Eli-Zaretskii]

As long as the buffer where this text is generated still exists, you can do something like

     M-: (describe-text-properties POS nil BUFFER) RET

where POS is the buffer position of that character, and BUFFER is the buffer where the text is kept (could be *Minibuf-1* (with the leading SPC).

[Eli-Zaretskii]

Also, minibuffer messages are generally recorded in *Messages*, so maybe the text is also there.

[memeplex]

Ok, if anyone figures out how to blink without closing the hydra window, please chime in. Meanwhile I'll keep bisecting.

[Alexander-Miller]

I've got something. You can grab the hydra's text by changing lv-message:

(defun lv-message (format-string &rest args)
  "Set LV window contents to (`format' FORMAT-STRING ARGS)."
  (let* ((str (apply #'format format-string args))
         (n-lines (cl-count ?\n str))
         deactivate-mark
         golden-ratio-mode)
    (with-selected-window (lv-window)
      (unless (and (string= (buffer-string) str)
                   (null lv-force-update))
        (delete-region (point-min) (point-max))
        (insert str)
        (when (and (window-system) lv-use-separator)
          (unless (looking-back "\n" nil)
            (insert "\n"))
          (insert
           (propertize "__" 'face 'lv-separator 'display '(space :height (1)))
           (propertize "\n" 'face 'lv-separator 'line-height t)))
        (set (make-local-variable 'window-min-height) n-lines)
        (setq truncate-lines (> n-lines 1))
        (let ((window-resize-pixelwise t)
              (window-size-fixed nil))
          (fit-window-to-buffer nil nil 1)))
      (print (buffer-string))
      (goto-char (point-min)))))

The second to last line outputs the entire string, including all text properties. Now we just need to find the position of the badly fontified character.

[memeplex]

@Eli-Zaretskii the offending commit seems to be 71c92d89137b7fdde6c2bd4bed9b8dfda5fa53dd.

This kinda make sense

    Fix copying text properties by 'format'
    
    * src/editfns.c (styled_format): Add the spec beginning index
    to the info recorded for each format spec, and use it to
    detect the case that a format spec and its text property end
    where the next spec with another property begins.  (Bug#32404)
    
    * test/src/editfns-tests.el (format-properties): Add tests for
    bug#32404.

[Eli-Zaretskii]

Thanks. If this is the commit which breaks the code, then it's likely a bug in the code that became broken, and that commit just exposed the bug. Or maybe I'm missing something.

Can someone please point me to the code which generates the text in question, including the properties? Is that the lv-message function shown above? If so, I'd need to see the code which calls it, because that's where the arguments, including format-string, come from.

[Alexander-Miller]

That particular hydra is a special case, it always shows your actual keybinds instead of a static text. That is accomplished with eval magic, but unfortunately that seems to prevent me from expanding the defhydra macro. I'll try and make it static.

[memeplex]

I forgot to reopen this at the time. Alexander, have you advanced your understanding of the issue? I'm asking that because I'm unsure about reporting this to the emacs tracker.

[Alexander-Miller]

Do you see the same problem with this hydra:

(defhydra TESTHYDRA (:exit nil :hint nil :columns 5)
  "
Treemacs x Helpful Hydra
Navigation           │ Opening Nodes           │ File Management │ Toggles              │ Projects           │ Misc.
――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
_X_:  next Line        │ _X_:  dwim TAB            │ _X_:  create file │ _X_:  follow mode      │ _X_:  add project    │ _X_:  refresh
_X_:  prev line        │ _X_:  dwim RET            │ _X_:  create dir  │ _X_:  filewatch mode   │ _X_:  remove project │ _X_:  (re)set width
_X_:  next neighbour   │ _X_:  open no split       │ _X_:  rename      │ _X_:  git mode         │ _X_:  rename project │ _X_:  copy path
_X_:  prev neighbour   │ _X_:  open horizontal     │ _X_:  delete      │ _X_:  show dotfiles    │                    │ _X_:  copy root
_X_:  goto parent      │ _X_:  open vertical       │ _X_:  copy        │ _X_:  resizability     │                    │ _X_:  re-sort
_X_:  down next window │ _X_:  open ace            │ _X_:  move        │ _X_:  fringe indicator │                    │ _X_:  bookmark
_X_:  up next window   │ _X_:  open ace horizontal │                 │                      │                    │
                     │ _X_:  open ace vertical   │                 │                      │                    │
                     │ _X_:  open externally     │                 │                      │                    │
                     │ _X_:  close parent        │                 │                      │                    │
"
  ("X" #'ignore)
  ("X" #'ignore)
  ("X" #'ignore)
  ("X" #'ignore)
  ("X" #'ignore)
  ("X" #'ignore)
  ("X" #'ignore)
  ("X" #'ignore)
  ("X" #'ignore)
  ("X" #'ignore)
  ("X" #'ignore)
  ("X" #'ignore)
  ("X" #'ignore)
  ("X" #'ignore)
  ("X" #'ignore)
  ("X" #'ignore)
  ("X" #'ignore)
  ("X" #'ignore)
  ("X" #'ignore)
  ("X" #'ignore)
  ("X" #'ignore)
  ("X" #'ignore)
  ("X" #'ignore)
  ("X" #'ignore)
  ("X" #'ignore)
  ("X" #'ignore)
  ("X" #'ignore)
  ("X" #'ignore)
  ("X" #'ignore)
  ("X" #'ignore)
  ("X" #'ignore)
  ("X" #'ignore)
  ("X" #'ignore)
  ("X" #'ignore)
  ("X" #'ignore)
  ("X" #'ignore)
  ("X" #'ignore)
  ("X" #'ignore)
  ("?" nil "Exit"))

[memeplex]

No, and neither do I see the original problem anymore as of:

GNU Emacs 26.1.92 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.5) of 2019-02-28
[Treemacs] v2.5-2019.02.22 @ 26.1.91

I'm closing it. Thanks!

[Alexander-Miller]

¯\_(ツ)_/¯