oOosys

@orbitalquark : if I understand it right encoding does not change the text data represented by the buffer, so there is no need for any before/after comparison. Encoding changes only...

OK ... sorry for being wrong with my assumptions. I see, that my naive way of understanding encoding was fully wrong (not only a bit) and actually change of encoding...

Why not using the approach used in SciTE output buffer? Is there any advantage of doing it the Textadept way?

Sorry, no idea about SciTE ... I am currently looking into geany ... with a Lua plugin an interesting alternative to going back to SciTE.

Running the script below instead of `sh "%f"` at Textadept F5 command line: ``` #!/bin/sh exec 2>&1 # make FD 2 (stderr) point to what's currently on FD 1 (stdout)...

@rgieseke : > Would it be possible to lex arbitrary embedded code? Sure ... in the world of programming as good as anything you can think of is possible ......

May you show the same input/output as screenshot in one of the other terminal emulators?

What you can do to investigate this behavior is to find which font file delivers the glyphs and then put this file into the list of fallback fonts wezterm will...

Have you tried to put the font which provides the missing glyphs to the list of wezterm fallback fonts? With what effect?

So you haven't tried to put the font to the list of wezterm fallback fonts? Sometimes it is a good idea to try also what seems not to make sense...