rougier / mu4e-thread-folding

Functions for folding threads in mu4e headers view
GNU General Public License v3.0
136 stars 12 forks source link

Prefix string is sometimes incorrectly indented #10

Open FrostyX opened 3 years ago

FrostyX commented 3 years ago

I think it will be best to show you a screenshot rather than describing the issue

2021-02-17-235223_5760x1080_scrot

I am sorry, I needed to censor some private messages.

Please see, that in the second half of the screenshot, some of the mu4e-thread-folding-root-folded-prefix-string are indented with two spaces instead of one. I have no idea why.

Though I have observed, that the incorrectly indented messages have cropped the first letter from the first column ("artin" was cropped from "Martin", "ilip" was cropped from "Filip", etc)

rougier commented 3 years ago

I think you need to add a fake column with 2 spaces as explained in the README. Did you do that? That might explain the problem:

(add-to-list 'mu4e-header-info-custom
             '(:empty . (:name "Empty"
                         :shortname ""
                         :function (lambda (msg) "  "))))

(setq mu4e-headers-fields '((:empty         .    2)
                            (:human-date    .   12)
                            (:flags         .    6)
                            (:mailing-list  .   10)
                            (:from          .   22)
                            (:subject       .   nil)))
FrostyX commented 3 years ago

I did. Although on the screenshot my M-: mu4e-headers-fields returns ((:empty . 0) (:from . 20) (:subject . 65)), I tried to configure it to exactly what you are suggesting and even though the empty column was wider, the symbols were still misaligned.

rougier commented 3 years ago

Do you know why do you have (empty . 0) instead of (empty . 2)?

FrostyX commented 3 years ago

It was on purpose, I tried if having a bigger or smaller empty space somehow affects the issue. But it doesn't matter, (empty . 0), (empty . 2), or (empty . 8) some folding symbols are always misaligned by one space.

rougier commented 3 years ago

You have also to make sure that the size of prefix (e.g. "> " or "< ") is smaller than the size of the empty space. Also, you can try to modify the prefix position : (9 . 11) to (8 . 10) to see if it changes anything. I don't really undersatn dwhy it is 9 (that I found by trial and error and it may e completely wrong)

FrostyX commented 3 years ago

Thank you @rougier for the hints, I appreciated the help. Especially since we don't know whether it is a bug or I am just messing something up.

You have also to make sure that the size of prefix (e.g. "> " or "< ") is smaller than the size of the empty space.

This should be fine when using the default configuration from your readme, right? I also tried leaving the space from the prefix ">". Doesn't help

you can try to modify the prefix position : (9 . 11) to (8 . 10) to see if it changes anything.

It moves the symbols in the empty column to the left or to the right up until the point when they leave the column and are not visible anymore. But they are still misaligned and when I set the lowest or highest value, at that point I see only those misaligned ones.

I also tried to change the

:function (lambda (msg) "  "))))

to

:function (lambda (msg) "xy"))))

to see where those "spaces" appear. And they are always bellow or right of the > symbol. I really don't understand where the redundant space on the left comes from.

2021-02-18-223248_5760x1080_scrot

rougier commented 3 years ago

Can you try to reduce the display to one or two mails and see if the problem persist. If so, can you send yourself the same mail (only subject) to check if you get the same faulty display (don't forward or it'll be part of the thread).

rougier commented 3 years ago

Another test would be to have "abcde" for prefix, 11-12 for prefix position and ">" or "v" for prefix such that we can see where it lands in the abcde strings. From your last screen shots, the "From" is misaligned on the first fewlines indicating the marker is probably at the wrong place.

One reason for such shift would be to have an overlay that extend over n characters (n=2 in this case) but the prefix string would be shoret (n-k). In this case we should have a shift of k (I was wrong previously, the prefix string must match the overlay position). May you can also try 9 10 instead of 9 11.

rougier commented 3 years ago

This should be fixed with latest commit.

FrostyX commented 3 years ago

That is great news, thank you. I will update and test it