unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: gerd.moellmann@t-online.de (Gerd Moellmann)
Cc: jsbien@mimuw.edu.pl
Subject: Re: problem of display property [Re: list-charset-chars and unicode-bmp]
Date: 28 Jan 2003 13:35:20 +0100	[thread overview]
Message-ID: <868yx5jvuf.fsf@gerd.free-bsd.org> (raw)
In-Reply-To: <200301281129.UAA16158@etlken.m17n.org>

Kenichi Handa <handa@m17n.org> writes:

> Gerd, could you help me?  What do you think about it?  The relevant
> codes are not changed from 21.1, so I think any new codes added
> later doesn't affect it.  It also means that this bug has been there
> from 21.1.

Hi Kenichi!

I admit I haven't checked your patch in depth; please bear with me if
I've overlooked something.

When current glyphs are reused, their positions are adjusted for the
changes in the buffer since the glyphs were made current.  The
function try_window_id is one such example.  I didn't see this being
done for the new slot you added to struct glyph.  (Insofar, the
comment of struct glyph doesn't appear to be that devious :).)

Be it as it may, I think I'd rather try to avoid enlarging struct
glyph.  Instead, I'd try using the function string_buffer_position in
the cursor position computation.  Strings aren't displayed frequently,
so the additional function calls shouldn't matter, and anyway,
enlarging glyphs costs performance too, and that in all cases.

  reply	other threads:[~2003-01-28 12:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87u1g3atvf.fsf@mimuw.edu.pl>
     [not found] ` <200301210831.RAA03126@etlken.m17n.org>
     [not found]   ` <871y35kej4.fsf@mimuw.edu.pl>
     [not found]     ` <rzqsmvjtrnx.fsf@albion.dl.ac.uk>
2003-01-28 11:29       ` problem of display property [Re: list-charset-chars and unicode-bmp] Kenichi Handa
2003-01-28 12:35         ` Gerd Moellmann [this message]
2003-01-29  7:39           ` Kenichi Handa
2003-01-29 12:45             ` Gerd Moellmann
2003-01-29 13:15               ` Kenichi Handa
2003-01-29 14:27                 ` Eli Zaretskii
2003-01-30  4:26                   ` Kenichi Handa
2003-01-30 20:07                     ` Eli Zaretskii
2003-01-30 20:26                       ` Stefan Monnier
2003-01-30 20:56                       ` Gerd Moellmann
2003-01-31 13:21         ` Dave Love

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=868yx5jvuf.fsf@gerd.free-bsd.org \
    --to=gerd.moellmann@t-online.de \
    --cc=jsbien@mimuw.edu.pl \
    /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.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

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).