I've applied the single-buffer patch from the st FAQ. As advertised,
it lets w3mimgdisplay work in st; this helps not only w3m, but other
tools (e.g. ranger) that use w3mimgdisplay.
Is there a downside to having applied this patch? In a couple days of
heavy use, I have yet to notice any anomalous
code point.
This is the same behavior exhibited by the Unicode variants of xterm
and rxvt; the difference is that they work OK without disabling the
NotoColorEmoji font.
On Wed, Aug 9, 2017 at 10:33 AM, David Lamkins wrote:
> I also specified different fonts on the command line, using an
I also specified different fonts on the command line, using an st
built with the default config.def.h. For example: ./st -f
DejaVuSansMono .
Same outcome.
On Wed, Aug 9, 2017 at 10:19 AM, David Lamkins wrote:
> With default config *except for* font, which is:
>
> char font[] = &qu
gc=0, argv=0x7fff7c90) at x.c:1764
On Wed, Aug 9, 2017 at 9:49 AM, David Lamkins wrote:
> st output upon exit:
>
> X Error of failed request: BadLength (poly request too large or
> internal Xlib length error)
> Major opcode of failed request: 138 (RENDER)
> Minor opc
st output upon exit:
X Error of failed request: BadLength (poly request too large or
internal Xlib length error)
Major opcode of failed request: 138 (RENDER)
Minor opcode of failed request: 20 (RenderAddGlyphs)
Serial number of failed request: 1408
Current serial number in output strea
Compiling with the default config resolves the issue. (OTOH, I can't
use the default font...)
I've attached a diff of my config.def.h .
On Wed, Aug 9, 2017 at 8:55 AM, Antenore Gatta wrote:
> On Wed, 9 Aug 2017 08:36:49 -0700
> "David B. Lamkins" wrote:
>
>> \xf0\x9f\x96\x96\n
>
> I cannot repr
