Hi,
On Tue, 2013-07-23 at 10:14 +0200, David Herrmann wrote:
> If you don't implement it properly, you will soon notice that stuff
> like vim will fail. They rely on these features.
Sorry, I just found the problem with vim.
I will re-send the patch after fixing the vim glyph display.
In the past
Hi
On Tue, Jul 23, 2013 at 9:49 AM, Peng Wu wrote:
> Hi,
>
> On Tue, 2013-07-23 at 09:22 +0200, David Herrmann wrote:
>> Please first address the issues I mentioned in v1. You cannot just
>> redraw characters and be fine. That's not how it works. You need to
>> adjust handle_char() to move the cu
Hi,
On Tue, 2013-07-23 at 09:22 +0200, David Herrmann wrote:
> Please first address the issues I mentioned in v1. You cannot just
> redraw characters and be fine. That's not how it works. You need to
> adjust handle_char() to move the cursor two columns for
> wide-characters.
>
Actually I also ad
Hi
On Tue, Jul 23, 2013 at 4:44 AM, Peng Wu wrote:
> Yes, I just followed the gnome vte terminal widget code.
> I will try to send v3 patch set to remove glib dependencies soon.
Please first address the issues I mentioned in v1. You cannot just
redraw characters and be fine. That's not how it wo
Yes, I just followed the gnome vte terminal widget code.
I will try to send v3 patch set to remove glib dependencies soon.
On Sun, 2013-07-21 at 23:22 -0500, Thomas Daede wrote:
> This is for a VT-100 style terminal emulator, right? It's designed to
> implement a grid of characters. Therefore, dra
This is for a VT-100 style terminal emulator, right? It's designed to
implement a grid of characters. Therefore, drawing it like a grid
based on single or double character widths makes a lot more sense than
detecting the length of a string. On any other UI element, detecting
the string length would
Frankly speaking, I suspect that your new fix will break some program
which uses newt with proportional font.
PS: newt is a library for text mode user interfaces.
On Thu, 2013-07-18 at 11:23 -0700, Bill Spitzak wrote:
> I propose the drawing code be changed to something like this:
>
>char* s
Peng Wu wrote:
On Wed, 2013-07-17 at 09:53 -0700, Bill Spitzak wrote:
For a demo
client I would skip trying to interpret wcwidth on incoming text,
just
act like each glyph takes one character cell.
But this will cause rendering problems when display CJK characters.
The CJK glyphs will overl
On Wed, 2013-07-17 at 09:53 -0700, Bill Spitzak wrote:
> For a demo
> client I would skip trying to interpret wcwidth on incoming text,
> just
> act like each glyph takes one character cell.
But this will cause rendering problems when display CJK characters.
The CJK glyphs will overlap each othe
The wcwidth is necessary to make the terminal and the curses library
agree and should only be used to interpret how to turn the incoming data
into a resulting display. After that you have the glyphs you want to
draw on the screen and you should use that to figure out where to draw
underscores a
Some CJK glyphs are wide, which occupy two columns.
If the glyph is wide, then use two columns instead of one.
---
clients/Makefile.am | 2 +-
clients/terminal.c | 45 +++--
2 files changed, 40 insertions(+), 7 deletions(-)
diff --git a/clients/Makefile.a
11 matches
Mail list logo
