Bug 1650312

re [comment 0]:
> Rarely (it has always been on "systemctl status <something>" command),
> I hit a segmentation fault, but that should be tractable (will remember
> to analyse that next time around).

It's actually reliable, and the backtrace has the lower frame corrupted,
rest is:

> rxvt_term::scr_refresh() (this=this@entry=0x5600ace51660) at screen.C:2478
> rxvt_term::flush() (this=0x5600ace51660) at command.C:1008
> ev_invoke_pending() () at ./../libev/ev.c:3314
> ev_run(int) (flags=flags@entry=0) at ./../libev/ev.c:3717
> main(int, char**) (argc=3, argv=0x7ffd672d8288) at rxvt.C:38

in scr_refresh():
2477│           else
2478├>            font->draw (*drawable, xpixel, ypixel, text, count, fore, back);
2479│

May be caused with the circle point that is in "systemctl status",
but "echo ●" doesn't cause this problem alone.

> It's actually reliable, and the backtrace has the lower frame
> corrupted

Actually, it was because of null pointer dereference, for "font" being
NULL.  Apparently, it is not expected for the preceding code to return
like that:

2458│           /*
2459│            * Actually do the drawing of the string here                                         
2460│            */
2461│           rxvt_font *font = (*fontset[GET_STYLE (rend)])[GET_FONT (rend)];
2462│

where the index-like access is actually a C++ overloaded operator, so
more investigation would be needed as to why this happens.

... and the workaround is to use 'systemctl --no-pager'.

Apparently, this is because of some bad interaction with
"less -FRSXMK".  Also removing 'R' from implicit SYSTEMD_LESS seems
to help (i.e., export SYSTEMD_LESS=FSXMK), but at the cost of degrading
the output.

Regarding the stated systemctl problem, it disappears when
enable-wide-glyphs.patch is omitted.  Good news is that initially
illustrated problem with rendering extra characters in the man
page doesn't return in that case.

Also this character from powerline-go is not rendered correctly unless
rxvt-unicode compiled with font-width-fix.patch (between quote marks):
"⚑" (used to denote something git repo related, perhaps number of files
     affected with uncommitted changes)

Is there a reason upstream does not include these patches?  My preference would be to include them there first unless it's impossible for some reason.

No idea, went the easy way, grabbed the patches from the other
downstream, my problem went away.  Sure, upstream would be an optimum
as always, what may be slightly problematic is the authorship/licensing
concerns.  That might be worked around with figuring out the weak
spot from existing patches and fixing the same anew, but IANAL.

One would have hoped that the original patch author would push it
upstream on his/her own.

I took at closer look at the patches.  There are five in total.  As far as I can tell, you're asking for these two (but correct me if I'm wrong):

- font-width-fix.patch is recommended against by the maintainer of that fork; see https://github.com/blueyed/PKGBUILD-rxvt-unicode-wide/commit/f32975b117205707fc43298fcb0b96b4050b94c9

- line-spacing-fix.patch has no information on where it came from, so we can't include that anyway.

The other three:

- enable-wide-glyphs.patch was rejected by upstream as well: http://lists.schmorp.de/pipermail/rxvt-unicode/2014q4/002043.html .  It also appears to cause a systemd pager bug you mention above.

- sgr-mouse-mode.patch came from a random gist and has no authorship info.

- add-space-to-extent_test_chars.patch seems to have been rejected by upstream already: http://lists.schmorp.de/pipermail/rxvt-unicode/2016q4/002309.html

So some questions for you.

1. Can you restate the problem you're seeing?
2. Does setting "URxvt*letterSpace: -1" on unpatched urxvt fix it?
3. If not, are both font-width-fix and line-spacing-fix required to fix it, or would only one work (and if so, which one)?

I'm not comfortable including patches that we can't prove authorship information for.  I'd like also to get upstream's opinion on anything we include (and preferably, have them commit it first).  This would probably require you (or someone else experiencing the problem) to submit them upstream (or find upstream's comments if they've already been submitted), but we can deal with that when we get there.

Timed out; please reopen if you can answer any of the above.

Ok, I see, I want it, I shall invest some effort here.

Currently don't have the capacity for that and it may turn
out to be rather long-winded.

I am reopening this bug nonetheless, since it can be trivially checked
that the same problem as in the attached screenshot comparison is
present in rxvt-unicode-9.22-18.fc32.x86_64, it didn't go away.

Feel free to reassign it to me if it generates any kind of bad feelings
for you.

I am going to eventually take a crack on this if nobody beats me to it,
rxvt-unicode (its flagship) is my daily driver.

Sounds good.  To be clear, I'm not opposed to having this fixed, but I can't take any patches we don't know the copyright on.  If you plan to fix it, that's great news :)

This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle.
Changing version to 33.

Jan's account has been disabled, so I'm closing this out.  Jan (or anyone else), feel free to submit patches, though of course it'd be better if you sent them upstream :)