From: storm@cua.dk (Kim F. Storm)
Cc: rms@gnu.org, emacs-devel@gnu.org
Subject: Re: [kobayays@otsukakj.co.jp: vertical-motion]
Date: Mon, 28 Aug 2006 00:41:55 +0200 [thread overview]
Message-ID: <m3u03xdcng.fsf@kfs-l.imdomain.dk> (raw)
In-Reply-To: <85r6z13k5b.fsf@lola.goethe.zz> (David Kastrup's message of "Mon, 28 Aug 2006 00:10:08 +0200")
David Kastrup <dak@gnu.org> writes:
> There have been so many changes in that area that it would be hard to
> point to any particular one. There was progressive deterioration.
> There was even a time where the screen display and the behavior could
> get out of sync (the cursor displays at a different point than it
> behaves) and I am not sure this has not occured recently.
>
> Since you said no fixes where intended before the release, I stopped
> actively checking for things like that since it would only annoy me to
> no good cause.
.. unless I can find some way to fix it which isn't too complex ..
If you can provide more test cases that I can look at, maybe I can
find the right fix.
> And there are things where clicking on some highlighted line (probably
> not fully visible) will cause the line to jump away in some manner of
> recentering, thus evading the click action, and jump back afterwards.
> Sort of click-avoidance-mode.
This is news to me. So examples please!
I have fixed a few redisplay issues with "cursors outside visible part
of window" -- one of those might have broken image display or behaviour
with highlighting.
> I just don't understand how stuff like that tests as an improvement.
Fixing one bug often leads to another bug -- so please report problems
that you think are related to _recent_ changes.
It's a bit annoying for the to be told that fixes I might have made
a year ago broke something else, and I wasn't told at the time -- now
I have to use a lot of time to find out what changes may have broken
things.
>>> The last bug reports I sent in were basically met with "this is not
>>> going to get fixed before the release".
>>
>> I would like to fix it ... but this is not trivial, and I've yet to
>> find a good way to do it (which doesn't break a lot of other code).
And now you tell me, that things degraded gradually, so there are
probably several things that influences the current bad behaviour.
Which is actually also my experience with trying to solve it. :-(
>> Do forward-char / backward-char work better in these cases??
>
> Irrelevant. I use the equivalent of auto-reveal-mode on
> forward-char/backward-char.
Too bad -- as I have found that using those keys typically
do scroll images in cases where the scrolling commands don't.
So far, I've found that it is primarily the scrolling commands which
are broken -- often they make false decisions when chosing a new
window start in the presense of a partially visible image.
I'll give fixing it another shot this week.
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
next prev parent reply other threads:[~2006-08-27 22:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-27 8:39 [kobayays@otsukakj.co.jp: vertical-motion] Richard Stallman
2006-08-27 8:49 ` David Kastrup
2006-08-27 21:51 ` Kim F. Storm
2006-08-27 22:10 ` David Kastrup
2006-08-27 22:41 ` Kim F. Storm [this message]
2006-08-28 22:10 ` Richard Stallman
2006-08-28 9:52 ` Richard Stallman
2006-08-28 22:00 ` Chong Yidong
2006-08-29 22:17 ` Chong Yidong
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=m3u03xdcng.fsf@kfs-l.imdomain.dk \
--to=storm@cua.dk \
--cc=emacs-devel@gnu.org \
--cc=rms@gnu.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.
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).