Stefan Monnier wrote:
I agree that this situation should be improved, but as long as the position
is chosen arbitrarily anyway, I don't see it as a big problem if this
arbitrary choice happens to be occasionally in the middle of the display
string rather than at one of its ends.
My weak
Date: Mon, 16 Apr 2007 22:58:47 +0200
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
CC: Juanma Barranquero [EMAIL PROTECTED], emacs-pretest-bug@gnu.org
But let me turn the table around, Lennart, and ask you: what arguments
will actually convince _you_ to change your mind on this?
Eli Zaretskii wrote:
Date: Mon, 16 Apr 2007 22:58:47 +0200
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
CC: Juanma Barranquero [EMAIL PROTECTED], emacs-pretest-bug@gnu.org
But let me turn the table around, Lennart, and ask you: what arguments
will actually convince _you_ to change your
Date: Tue, 17 Apr 2007 22:08:06 +0200
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org
But let me turn the table around, Lennart, and ask you: what arguments
will actually convince _you_ to change your mind on this? Following
Karl
Eli Zaretskii wrote:
Date: Tue, 17 Apr 2007 22:08:06 +0200
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org
But let me turn the table around, Lennart, and ask you: what arguments
will actually convince _you_ to change your mind on this?
Date: Tue, 17 Apr 2007 23:29:12 +0200
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org
I am not the easiest one to convince, but it is in no way impossible.
You again are not answering the question. I think we should end this
discussion, as
Eli Zaretskii wrote:
Date: Tue, 17 Apr 2007 23:29:12 +0200
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org
I am not the easiest one to convince, but it is in no way impossible.
You again are not answering the question. I think we should end
Oh, good, I am delaying the Unicode release! I did not think of that.
Sorry, I could not really resist. I can understand your frustration,
Your replies show that you don't even begin to understand.
--
Nick http://www.inet.net.nz/~nickrob
On 4/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote:
Then what arguments are actually convincing to you?
At this point in time, just days short of the intented release? Either
the bug crashes Emacs, or it does cause trouble for some really major
package, or it is very common and/or
Eli Zaretskii wrote:
Date: Mon, 16 Apr 2007 03:14:13 +0200
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
Cc: emacs-pretest-bug@gnu.org
Then what arguments are actually convincing to you?
Did you ever managed release of some software product, Lennart?
Because if you didn't, then there's
On 4/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote:
We are getting closer to a serious discussion, thanks.
Because you're the arbiter of when a discussion is serious enough?
Juanma
___
emacs-pretest-bug mailing list
Juanma Barranquero wrote:
On 4/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote:
We are getting closer to a serious discussion, thanks.
Because you're the arbiter of when a discussion is serious enough?
Yes, I do have an opinion about that. Disrespect is not one of the
things I
On 4/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote:
Yes, I do have an opinion about that. Disrespect is not one of the
things I respect.
Disrespect is often in the eye of the beholder. I certainly have no
trouble detecting disrespect in some of your messages, but I'm sure
you'll
Juanma Barranquero wrote:
On 4/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote:
Yes, I do have an opinion about that. Disrespect is not one of the
things I respect.
Disrespect is often in the eye of the beholder. I certainly have no
trouble detecting disrespect in some of your
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
It has not been my intent. I do get a bit upset by some type of
answers and you are right, it is then in the eye of the beholder. I
can understand if Eli feel a bit hurt. He took long time to write a
long answer and I just pointed to some a
On 4/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote:
I try to have respect for that more economic reasoning that you are
using, but I often fail there.
Economic reasoning is a good way to see it. Your defense of fixing
the bug doesn't seem very convincing, on an (informal, I'm no
Richard Stallman [EMAIL PROTECTED] writes:
Does drawing cursor in the wrong position on multi-line before-strings
cause real trouble?
Yes. Whenever the cursor is in the wrong position, that is real trouble.
Is the display of multi-line before-strings an
important
[EMAIL PROTECTED] (Kim F. Storm) writes:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
It has not been my intent. I do get a bit upset by some type of
answers and you are right, it is then in the eye of the beholder. I
can understand if Eli feel a bit hurt. He took long time to write a
David Kastrup wrote:
I will not be surprised at all if we will see after the release a
flood of problem reports currently held back by a large release pain
threshold.
Uhm. At least I have tried to avoid reporting some bugs now just because
it seems useless. We all want a release I guess.
Juanma Barranquero wrote:
I was not offended, but saying to your opponent I suggested reading
my arguments is not keep[ing your] own opinion, for example. I
point it out merely to show that it is easy to cross the line without
being aware.
Oh, yes it is easy. And I know you have told me
On 4/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote:
At least that is often a way forward in face-to-face communication.
Though one have to say it with an querying voice.
Couldn't help but remember this quote from the Subversion developers'
list. Several guys were talking about the
[EMAIL PROTECTED] (Kim F. Storm) writes:
Richard Stallman [EMAIL PROTECTED] writes:
Does drawing cursor in the wrong position on multi-line before-strings
cause real trouble?
Yes. Whenever the cursor is in the wrong position, that is real trouble.
Is the display of
Date: Mon, 16 Apr 2007 09:57:44 +0200
From: Juanma Barranquero [EMAIL PROTECTED]
Cc: emacs-pretest-bug@gnu.org
On 4/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote:
Then what arguments are actually convincing to you?
At this point in time, just days short of the intented
Date: Mon, 16 Apr 2007 10:38:14 +0200
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org
Eli Zaretskii wrote:
Date: Mon, 16 Apr 2007 03:14:13 +0200
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
Cc: emacs-pretest-bug@gnu.org
Then
Eli Zaretskii wrote:
Then what arguments are actually convincing to you?
At this point in time, just days short of the intented release? Either
the bug crashes Emacs, or it does cause trouble for some really major
package, or it is very common and/or confusing for many users.
And such bugs
Eli Zaretskii wrote:
Date: Mon, 16 Apr 2007 10:38:14 +0200
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org
Eli Zaretskii wrote:
Date: Mon, 16 Apr 2007 03:14:13 +0200
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
Cc: emacs-pretest-bug@gnu.org
A note: What makes me a bit upset is more that I get the feeling that you
think the bug is unimportant
Actually, I do think so: the position where the cursor is displayed when
placed on a before-string (or a display string) has always been
fairly approximate. E.g. Whether to display it
My main concern with such an approach is that this will be slow for
long multi-line strings filling most of the window.
That is an even more unusual case -- and being somewhat slow
is not as bad as displaying wrong.
___
emacs-pretest-bug
Kim F. Storm wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
Just another note if someone else is trying this. Having coming back
to this several times today I am starting to believe that the way to
fix this is to change cursor_row_p. This was the original way that Kim
tried to solve
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
Here is a version that I believe works. It just does local changes to
cursor_row_p. I seems to me that is sufficient. I have not seen any
problems with the display of 'display property parts, only with cursor
positioning.
Thanks for the
Richard Stallman [EMAIL PROTECTED] writes:
It seems that you and I define serious in a different way. My
criterion says that a bug where an important feature does something
that is indisputably wrong and that causes real trouble is a serious
bug.
Does drawing cursor in the wrong position on
Chong Yidong wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
Here is a version that I believe works. It just does local changes to
cursor_row_p. I seems to me that is sufficient. I have not seen any
problems with the display of 'display property parts, only with cursor
positioning.
I already explained twice what the problem is, and why it's better to
postpone the fix.
I saw your message with a patch, but it did not have an explanation.
I asked you earlier today to explain the two crucial points.
I wasn't reading the messages about this while people appeared to be
Chong Yidong [EMAIL PROTECTED] writes:
Richard Stallman [EMAIL PROTECTED] writes:
It seems that you and I define serious in a different way. My
criterion says that a bug where an important feature does something
that is indisputably wrong and that causes real trouble is a serious
bug.
From: Richard Stallman [EMAIL PROTECTED]
Date: Sun, 15 Apr 2007 09:59:10 -0400
Cc: emacs-pretest-bug@gnu.org, [EMAIL PROTECTED]
It seems that you and I define serious in a different way. My
criterion says that a bug where an important feature does something
that is indisputably wrong and
Eli Zaretskii [EMAIL PROTECTED] writes:
Frankly, I'm astonished that I need to explain such truisms that are
well known to anyone who has ever managed a software release, present
company included.
It explains why the release is long overdue.
--
Kim F. Storm [EMAIL PROTECTED]
Eli Zaretskii wrote:
From: Richard Stallman [EMAIL PROTECTED]
Date: Sun, 15 Apr 2007 09:59:10 -0400
Cc: emacs-pretest-bug@gnu.org, [EMAIL PROTECTED]
It seems that you and I define serious in a different way. My
criterion says that a bug where an important feature does something
that is
Does drawing cursor in the wrong position on multi-line before-strings
cause real trouble? Is the display of multi-line before-strings an
important feature?
And is fixing it important enough to delay the release - or risk
introducing other bugs which we only discover after the
In other words: I have seen this bug.
I'm not questioning that you have seen it, just the wisdom of ignoring the
advice of those who are experts in that part of the code and say that it is
dangerous to fix shortly before the release.
Given that you appear to be the only one to have been
Nick Roberts wrote:
In other words: I have seen this bug.
I'm not questioning that you have seen it, just the wisdom of ignoring the
advice of those who are experts in that part of the code and say that it is
dangerous to fix shortly before the release.
I am not ignoring Kim's advice,
On 4/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote:
If you read my messages carefully you will see why I do not think this
is dangerous to fix the way I have suggested.
That you don't think it is dangerous doesn't make it harmless or safe.
Redisplay code is complex. People who knows
Juanma Barranquero wrote:
On 4/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote:
If you read my messages carefully you will see why I do not think this
is dangerous to fix the way I have suggested.
That you don't think it is dangerous doesn't make it harmless or safe.
I really did
On 4/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote:
I really did not say so of course. I suggested reading my arguments.
I did. I've read this thread in full. I know nothing about the
redisplay code (I've taken a few looks at it and that's all), but
AFAIK you're not very
Juanma Barranquero wrote:
On 4/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote:
I really did not say so of course. I suggested reading my arguments.
I did. I've read this thread in full. I know nothing about the
redisplay code (I've taken a few looks at it and that's all), but
AFAIK
Date: Sun, 15 Apr 2007 23:10:04 +0200
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org, [EMAIL PROTECTED],
[EMAIL PROTECTED]
I think this analysis could be a big deal deeper and less general. I
think that would help to create a more
Date: Mon, 16 Apr 2007 00:14:46 +0200
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
Cc: emacs-pretest-bug@gnu.org, Chong Yidong [EMAIL PROTECTED],
Kim F. Storm [EMAIL PROTECTED]
In other words: I have seen this bug.
Yes, two years after its introduction. With luck, no one will see
Date: Mon, 16 Apr 2007 03:14:13 +0200
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
Cc: emacs-pretest-bug@gnu.org
Then what arguments are actually convincing to you?
Did you ever managed release of some software product, Lennart?
Because if you didn't, then there's really no way we could
Does drawing cursor in the wrong position on multi-line before-strings
cause real trouble?
Yes. Whenever the cursor is in the wrong position, that is real trouble.
Is the display of multi-line before-strings an
important feature?
before-strings is an important feature. It is
You could add code inside a conditional which tests for that case.
Then you know it won't affect any other cases.
I don't have a clue to how to write the conditional which tests for that
case.
Have you tried to figure out how?
Show what that conditional is ... then we can
Richard Stallman [EMAIL PROTECTED] writes:
You could add code inside a conditional which tests for that case.
Then you know it won't affect any other cases.
I don't have a clue to how to write the conditional which tests for that
case.
Have you tried to figure out how?
To
Chong Yidong wrote:
Richard Stallman [EMAIL PROTECTED] writes:
You could add code inside a conditional which tests for that case.
Then you know it won't affect any other cases.
I don't have a clue to how to write the conditional which tests for that
case.
Have you tried to
Lennart Borgman (gmail) wrote:
B) Moving with right arrow across the 'display part on the screen moves
point across the part of the buffer that has the 'display property. In
contrast moving with left arrow make point stop at the first of the
characters that has the overlay with the 'display
Lennart Borgman (gmail) wrote:
A) It looks like set_cursor_from_row gets called over and over again in
some circumstances. I might have done something stupid that triggers
this, I am not sure at the moment, but if I move to the end of the file
with right error this happens. If stops when I
Just another note if someone else is trying this. Having coming back to
this several times today I am starting to believe that the way to fix
this is to change cursor_row_p. This was the original way that Kim tried
to solve it. Maybe Kim's solution with an added test of if the string
has the
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
Just another note if someone else is trying this. Having coming back
to this several times today I am starting to believe that the way to
fix this is to change cursor_row_p. This was the original way that Kim
tried to solve it. Maybe Kim's
[EMAIL PROTECTED] (Kim F. Storm) writes:
(progn
(switch-to-buffer (get-buffer-create *test*))
(erase-buffer)
(insert .\n\n.\n\n)
(goto-char (point-min))
(let ((ov (make-overlay 4 7)))
(overlay-put ov 'display Ax\nyB))
(goto-char (point-max)))
With my change, moving the
Kim F. Storm wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
Just another note if someone else is trying this. Having coming back
to this several times today I am starting to believe that the way to
fix this is to change cursor_row_p. This was the original way that Kim
tried to solve
Richard Stallman [EMAIL PROTECTED] writes:
Can you track down the bug report(s) which lead up to the fix I
installed, so you can confirm that your change also fixes the old
bug(s).
It must be close to the date in the ChangeLog.
IIRC, there were quite a lot of test cases
Richard Stallman [EMAIL PROTECTED] writes:
At this stage of the release cycle, a grave bug is one that makes Emacs
crash, or causes really bad redisplay behaviour.
I think redisplay bugs are serious bugs.
As you say yourself, what someone _think_ is not a useful argument.
--
Kim F.
Richard Stallman [EMAIL PROTECTED] writes:
At this stage of the release cycle, a grave bug is one that makes Emacs
crash, or causes really bad redisplay behaviour.
I think redisplay bugs are serious bugs.
In this case, I know what the fix is (see attached patch). The
trouble is that
Lennart Borgman (gmail) wrote:
Another little question: On w32 I failed to apply this patch with the
patch program from gnuwin32 (version 2.5.9). I wonder if this is a
problem with that patch program or something else. How do I continue
when patch fails?
Most of the patch where applied. The
How can I be sure that the change only takes action in the bug case ?
You could add code inside a conditional which tests for that case.
Then you know it won't affect any other cases.
___
emacs-pretest-bug mailing list
[EMAIL PROTECTED]
Richard Stallman [EMAIL PROTECTED] writes:
How can I be sure that the change only takes action in the bug case ?
You could add code inside a conditional which tests for that case.
Then you know it won't affect any other cases.
I don't have a clue to how to write the conditional which
Eli Zaretskii wrote:
Date: Wed, 11 Apr 2007 22:48:34 +0200
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
CC: Chong Yidong [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
FWIW, I wouldn't touch this so close to the release: if no one noticed
this since July 2005, it's hardly a
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
Eli Zaretskii wrote:
Date: Wed, 11 Apr 2007 22:48:34 +0200
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
CC: Chong Yidong [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED]
FWIW, I wouldn't touch this so close to the release: if no
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
Looking at the logic it seems like it perhaps should be like below
instead? This at least works in my case. The current test just seems
useless. Or perhaps I am just very bad at reading C code?
The useless code you refer to was installed to
[EMAIL PROTECTED] (Kim F. Storm) writes:
Can you track down the bug report(s) which lead up to the fix I
installed, so you can confirm that your change also fixes the old bug(s).
It must be close to the date in the ChangeLog.
IIRC, there were quite a lot of test cases - combining before and
Kim F. Storm wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
Looking at the logic it seems like it perhaps should be like below
instead? This at least works in my case. The current test just seems
useless. Or perhaps I am just very bad at reading C code?
The useless code you refer
Kim F. Storm wrote:
At this stage of the release cycle, a grave bug is one that makes Emacs
crash, or causes really bad redisplay behaviour.
As you said yourself, this is a corner case, so it is not a grave error.
Ok, but with a corner case I meant a logical corner case. Those +-1 you
often
[EMAIL PROTECTED] (Kim F. Storm) writes:
Can you track down the bug report(s) which lead up to the fix I
installed, so you can confirm that your change also fixes the old bug(s).
I must be close to the date in the ChangeLog.
The original bug report was at
Chong Yidong wrote:
I think the current code is mistaken. The ChangeLog entry and the
comments both say that we want to set cursor_row_p to a non-zero value
in the case where the display string starts in this row. But that's
not what it's doing; Lennart is correct in pointing out that it's
Chong Yidong [EMAIL PROTECTED] writes:
I think the current code is mistaken. The ChangeLog entry and the
comments both say that we want to set cursor_row_p to a non-zero value
in the case where the display string starts in this row. But that's
not what it's doing; Lennart is correct in
Yes, I looked at the code but decided it takes me too long time at the
moment. Kim, is this easy for you?
Changes to redisplay are NEVER easy ...
I made a seemingly trivial change to fix one bug ... and two years
later someone finds a problem with it.
IMO, this is
[EMAIL PROTECTED] (Kim F. Storm) writes:
IIRC, the original problem I tried to solve is shown by this test-case:
(progn
(switch-to-buffer (get-buffer-create *test*))
(erase-buffer)
(insert .\n\n.\n\n)
(goto-char (point-min))
(let ((ov (make-overlay 4 7)))
(overlay-put ov
Chong Yidong [EMAIL PROTECTED] writes:
Thus, I think this issue should be left alone for the Emacs 22.1.
Agree.
It
is easy to work around the affected corner case, by using text
properties or a display property rather an
Date: Thu, 12 Apr 2007 08:00:37 +0200
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Eli Zaretskii wrote:
Date: Wed, 11 Apr 2007 22:48:34 +0200
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
CC: Chong Yidong [EMAIL
Chong Yidong wrote:
[EMAIL PROTECTED] (Kim F. Storm) writes:
IIRC, the original problem I tried to solve is shown by this test-case:
(progn
(switch-to-buffer (get-buffer-create *test*))
(erase-buffer)
(insert .\n\n.\n\n)
(goto-char (point-min))
(let ((ov (make-overlay 4 7)))
Lennart Borgman (gmail) wrote:
This works for me and for Kim's test case as far as I can see. However
as can be seen from the fprintf output with my test case it starts
looping when I go to the first character and then press left arrow.
This was wrong. The looping occurs without my changes.
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
/* If the row ends with a newline from a string, we don't want
the cursor there, but we still want it at the start of the
string if the string starts in this row.
If the row is continued it doesn't end in a newline.
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
Lennart Borgman (gmail) wrote:
This works for me and for Kim's test case as far as I can
see. However as can be seen from the fprintf output with my test
case it starts looping when I go to the first character and then
press left arrow.
Chong Yidong wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
/* If the row ends with a newline from a string, we don't want
the cursor there, but we still want it at the start of the
string if the string starts in this row.
If the row is continued it
Chong Yidong wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
Lennart Borgman (gmail) wrote:
This works for me and for Kim's test case as far as I can
see. However as can be seen from the fprintf output with my test
case it starts looping when I go to the first character and then
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
With current CVS, I do not observe any infloop for the test case you
sent. If you think you have observed one, please send a precise
recipe.
Could you please recompile with the fprint part of the code I sent
before? Then start with emacs
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
I trust you that it does not solve the underlying problem, but it
works in my case and in the test case Kim supplied. That said I of
course believe there can be problems with this solution, but I hope
for your comments on that.
Like I said,
Chong Yidong wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
With current CVS, I do not observe any infloop for the test case you
sent. If you think you have observed one, please send a precise
recipe.
Could you please recompile with the fprint part of the code I sent
before? Then
Chong Yidong wrote:
[EMAIL PROTECTED] (Kim F. Storm) writes:
IIRC, the original problem I tried to solve is shown by this test-case:
(progn
(switch-to-buffer (get-buffer-create *test*))
(erase-buffer)
(insert .\n\n.\n\n)
(goto-char (point-min))
(let ((ov (make-overlay 4 7)))
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
However, it is dangerous to change string_buffer_position right
now, because it's called from several places in xdisp.c. Changing
its behavior runs a serious risk of introducing subtle bugs.
Maybe. They are either in set_cursor_from_row or
Can you track down the bug report(s) which lead up to the fix I
installed, so you can confirm that your change also fixes the old bug(s).
It must be close to the date in the ChangeLog.
IIRC, there were quite a lot of test cases - combining before and
after strings as well
At this stage of the release cycle, a grave bug is one that makes Emacs
crash, or causes really bad redisplay behaviour.
I think redisplay bugs are serious bugs.
___
emacs-pretest-bug mailing list
[EMAIL PROTECTED]
Lennart Borgman (gmail) wrote:
I want to put an overlay at the top of a buffer and display several
lines of text there. I use an overlay of length 1 at point 1 with a
'before-string property to do this.
Doing this I see some strange display problems when moving point to the
beginning of
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
I want to put an overlay at the top of a buffer and display several
lines of text there. I use an overlay of length 1 at point 1 with a
before-string property to do this... the cursor is displayed at the
end of the first line of the
From: Chong Yidong [EMAIL PROTECTED]
Date: Wed, 11 Apr 2007 13:46:37 -0400
Cc: emacs-pretest-bug@gnu.org
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
I want to put an overlay at the top of a buffer and display several
lines of text there. I use an overlay of length 1 at point 1
Eli Zaretskii wrote:
From: Chong Yidong [EMAIL PROTECTED]
Date: Wed, 11 Apr 2007 13:46:37 -0400
Cc: emacs-pretest-bug@gnu.org
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
I want to put an overlay at the top of a buffer and display several
lines of text there. I use an overlay of length 1
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
if (PT == MATRIX_ROW_END_CHARPOS (row))
{
/* If the row ends with a newline from a string, we don't want
the cursor there, but we still want it at the start of the
string if the string starts in this row.
Chong Yidong wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
if (PT == MATRIX_ROW_END_CHARPOS (row))
{
/* If the row ends with a newline from a string, we don't want
the cursor there, but we still want it at the start of the
string if the string starts in
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
Yes, I looked at the code but decided it takes me too long time at the
moment. Kim, is this easy for you?
Changes to redisplay are NEVER easy ...
I made a seemingly trivial change to fix one bug ... and two years
later someone finds a
Kim F. Storm wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
Yes, I looked at the code but decided it takes me too long time at the
moment. Kim, is this easy for you?
Changes to redisplay are NEVER easy ...
I made a seemingly trivial change to fix one bug ... and two years
later
Lennart Borgman (gmail) wrote:
Kim F. Storm wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
Yes, I looked at the code but decided it takes me too long time at the
moment. Kim, is this easy for you?
Changes to redisplay are NEVER easy ...
I made a seemingly trivial change to fix
Lennart Borgman (gmail) wrote:
I looked a bit at the code. (First time I used tags, quite nice.) Is it
in set_point_both in intervals.c that the magic happens? It looks from
that code like internally an intangible property is used in cases like
this.
And that was totally wrong of course.
Chong Yidong wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
if (PT == MATRIX_ROW_END_CHARPOS (row))
{
/* If the row ends with a newline from a string, we don't want
the cursor there, but we still want it at the start of the
string if the string starts in
1 - 100 of 101 matches
Mail list logo
