public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Tom Tromey <tom@tromey.com>
To: Tom Tromey <tom@tromey.com>
Cc: vaag--- via Gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [patch v2] Fix cyrillic symbols show in tui
Date: Sun, 05 Apr 2020 10:10:47 -0600	[thread overview]
Message-ID: <875zed9am0.fsf@tromey.com> (raw)
In-Reply-To: <87o8sccw5l.fsf@tromey.com> (Tom Tromey's message of "Tue, 31 Mar 2020 10:43:34 -0600")

>>>>> "Tom" == Tom Tromey <tom@tromey.com> writes:

Tom> Perhaps this code needs convert to wchar_t and back again.  That seems
Tom> pretty unfortunate though.  The other alternative would be if there's a
Tom> way to change tui_puts so that over-long lines are (optionally)
Tom> truncated rather than overflowing.  I don't know if curses offers that
Tom> or not.

I researched this a little.

Curses doesn't directly support control over this.  Bleah curses.

However, it seems it can maybe be accomplished anyway.  A few
approaches.

1. Use waddnstr or mvaddnstr to limit how many characters are emitted.
   To do this, I suppose that do_tui_putc would have to be reimplemented
   (to fix the \t hack), and also tui_puts_internal would have to be
   changed so that it does not emit a single character at a time.
   Instead, tui_puts_internal would be changed to emit strings of
   characters (limited to the remaining horizontal space), then check
   the column to see where the cursor ended up.

2. Use winsstr to insert characters rather than append them.  In theory
   this should cause characters to the right to be pushed off and
   disappear -- not wrap.  (The ncurses docs say this but as with all
   things curses, one must try it.)  For this to work we'd have to clear
   to the end of the line before emitting things.

3. Use pads instead of windows, and make sure the pads are sized so that
   wrapping cannot occur.  This would be a somewhat larger change.  I
   suppose it would have to be limited to the source window, since it
   wouldn't really be possible for the assembly window.

I'm not sure if #1 or #2 is more desirable.

Tom

  reply	other threads:[~2020-04-05 16:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-31  9:16 vaag
2020-03-31 13:59 ` Simon Marchi
2020-03-31 16:43 ` Tom Tromey
2020-04-05 16:10   ` Tom Tromey [this message]
2020-04-05 20:41     ` Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=875zed9am0.fsf@tromey.com \
    --to=tom@tromey.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).