content alignement in elfeed search buffer

[nicodebo]

Hello,
Is it possible to align columns in the elfeed search buffer (see picture herebelow) ?

https://imgur.com/DVxYHPs

I feel like the problem is due to the width difference between latin characters and japanese one.

[zabe40]

I've also had this issue, and it looks like theres a possible fix in Emacs 28. As per this article:

So we’ve now added a new display spec (called min-width) today that you can slap around bits of text (and in the mode line) that ensures that the width never decreases beyond a certain point.

[skeeto]

Unfortunately this is a display bug/limitation of Emacs itself. Elfeed uses string width (not length) and a monospace font to compute the search buffer layout, but Emacs' reported widths do not match rendering. It reports 2 for CJK, but then the GUI renders a definitely-not-monospace width of ~1.4 (depending on your exact font). The same results displayed in most terminals (emacs -nw) line up correctly, which better honors the supposed width. See #404.

[nicodebo]

thank you very much for the info. Indeed, the alignment is perfect in the terminal.
I searched everywhere for the past few days for this issue but forgot to look at the pull requests.
Maybe it should be mentionned in the readme ?

[yantar92]

Unfortunately this is a display bug/limitation of Emacs itself. Elfeed uses string width (not length) and a monospace font to compute the search buffer layout, but Emacs' reported widths do not match rendering.

It is expected behaviour. Docstring of `string-width` says: When calculating width of a multibyte character in STRING, only the base leading-code is considered... The effect of faces and fonts used for non-Latin and other unusual characters (such as emoji) is ignored as well, as are display properties and invisible text... Reading further: ... for accurate dimensions of text as it will be displayed, use window-text-pixel-size instead. So, maybe just use `window-text-pixel-size`? Or even `string-pixel-width` for newer Emacs.

[citrusmunch]

partial workaround

My current workaround is to add a hook to set an appropriate frame font as described in one of the answers from a similar issue with org mode table alignment mentioned in #404 (comment).

user dualism's answer:

You need to prepare the monospace font with 1:2 height-width aspect ratio, so called "narrow" font, such as Inconsolata. Most programmer's fonts have the aspect ratio of 3:5, or so called "wide" font, that can not be fit with Japanese font when used with org-mode tables.

Also, you must set your font height to be an even number. Otherwise, its width (half of height) wouldn't be an integer and would also cause problem on org-mode table alignment.

example

In the appropriate parts of my init.el:

(set-frame-font "Hack 18" nil t)

;; remap ranges of code points
(mapc (lambda (chars)
        (set-fontset-font "fontset-default" chars "Noto Sans Mono CJK TC"))
      '((#x3000 . #x303F)  ; CJK Symbols and Punctuation
        (#x4E00 . #x9FFF)  ; CJK Unified Ideographs
        (#xFF00 . #xFFEF)  ; Halfwidth and Fullwidth Forms
        ))

(defun my/elfeed-modify-search-view ()
  "Modify faces and fonts for current buffer. Intended for aligning columns
in elfeed-search."
  (face-remap-add-relative 'default '(:family "Inconsolata" :height 240))
  (set-fontset-font nil 'emoji (font-spec :height 160) nil))

(add-hook 'elfeed-search-mode-hook #'my/elfeed-modify-search-view)

It's a one-time cost, but it's worth noting this does increase elfeed's startup time for me. I had to tweak the emoji size to mostly match fullwidth. It's not perfect, but after doing a quick dive on "em height" and not finding an easy way to find absolute measurements for a given font I've left it alone for now.
I've only included character ranges for my needs, so if something isn't aligning, I recommend starting with describe-char with the suspect at point.

screenshots

before

after

see also

unicode-fonts has a similar solution that seemed too heavy-handed for me to try out. It may be faster though
"em height" for the adventurous perfectionists
a 2015 blog entry with some useful discussion