Re: Display problems with `before-string' in overlay
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 memory whispers something about that this has been improved quite a while ago, but I am not sure. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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? Following Karl Popper, if your answer is ``nothing will change my mind'', then this is a religious type of argument that we should just stop, because it has no hope of any agreement whatsoever. That is a good question. Which you didn't answer, sigh... ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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 mind on this? Following Karl Popper, if your answer is ``nothing will change my mind'', then this is a religious type of argument that we should just stop, because it has no hope of any agreement whatsoever. That is a good question. Which you didn't answer, sigh... In what sense did I not answer it? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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 Popper, if your answer is ``nothing will change my mind'', then this is a religious type of argument that we should just stop, because it has no hope of any agreement whatsoever. That is a good question. Which you didn't answer, sigh... In what sense did I not answer it? In the sense that I still do not know what would convince you to change your mind. For example, if I would to argue with someone which of two apples to buy, telling me that one is 10 times cheaper than the other might make me change my mind. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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? Following Karl Popper, if your answer is ``nothing will change my mind'', then this is a religious type of argument that we should just stop, because it has no hope of any agreement whatsoever. That is a good question. Which you didn't answer, sigh... In what sense did I not answer it? In the sense that I still do not know what would convince you to change your mind. For example, if I would to argue with someone which of two apples to buy, telling me that one is 10 times cheaper than the other might make me change my mind. I am not the easiest one to convince, but it is in no way impossible. I tried to point out the answer. What is needed is not very different from when you meet other people. You must try to meet me where I am. And I failed for similar reasons to make it possible to convince you. You were arguing from a managerial standpoint. I tried to mix this standpoint with estimates of some details in the problem. If you wanted to convince me I then I think you should have to follow me a bit on that road. It would be nice if you commented on this because I honestly fail to understand why you did not do that. I can of course think of a lot of reasons, lack of time for example. Or that you did not find my arguments valuable. Whichever it was I think it would have been easier to get a bit longer on the road to convincing me if you explained your reasons for the turn you took. I tried in the prev-previous mail to do explain something similar from my point of view, but I think I missed something there since you thought I did not answer you. I have a feeling that the difficulties to meet is for some reason mainly a lack of trust. That may be personal for me, I do not know. It is easy for me to say that I trust your experience and appreciate your concerns, but that I think differently. But it is not easy to get the message through to you. Maybe because of the media and the way we communicate. Maybe because we actually have different styles of thinking as I understand it. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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 it became futile. Please read Karl Popper if you wish to understand what kind of answer I asked for, and why I think there's no point in continuing this discussion with you. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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 this discussion, as it became futile. Please read Karl Popper if you wish to understand what kind of answer I asked for, and why I think there's no point in continuing this discussion with you. It is hard for me to understand how you think Popper's thinking could be used here so if you want me to understand I believe you must point out what claim of knowledge you have from a falsifiability standpoint and maybe how you think I relate to that. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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 confusing for many users. If you just want to say that you do not want that change to be made now that is also ok. Is not that I don't want, and what I want is largely irrelevant. Is that IMO you have not justified it enough in the urgency scale, release-wise. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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 really no way we could convince you, since you lack a significant experience of having to decide what needs to be fixed before the release and what's after it. Of course experience is good. Did I ever say something else? Or why did you say the above? I know that both Kim and Chong hesitate to do the changes now. My argument is not that I do not trust them. I try to look at the actual changes and estimate the chances that it can go wrong. This estimation on the one hand, and the estimated seriousness of the bug on the other, is the fundamental issue. We are getting closer to a serious discussion, thanks. If you cannot see how the former is much larger than the latter, then we have no real basis for a reasonable discussion. And now you are leaving it again. That's because everyone else but you look at this issue at a fundamentally different level. You look at the details, but no amount of details will ever lead you to the bigger picture--that we need to release soon, and that Emacs is ready for that. And now you have left it totally. Instead of asking me you say that I am thinking in a certain way. If you discuss that way you will always win a discussion. If you please separate my opinion from my arguments it will be much nicer. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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 emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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 respect. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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 disagree. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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 messages, but I'm sure you'll disagree. 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 little bit weaker points in the answer. So, Eli, there I missed your point and I apologize for that. I try to have respect for that more economic reasoning that you are using, but I often fail there. (On the other hand I often try to tell people that I learned one thing from that kind of reasoning and that is that you sometimes have to take a decision without having all the knowledge of the details that you wish you had.) And I often prefer to keep my own opinion even under strong pressure. It is unusual, but it is not out of disrespect. Though those things are close in a way it is still possible to distinguish them. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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 little bit weaker points in the answer. IMO, there are _no weak points_ in Eli's message. In one sentence: All software have bugs, so to ever make a release, someone must decide when enough is enough. Sadly RMS does not see it that way either ... so we'll probably never see a release, no matter how close we get to one (unless of course, people stop reporting bugs in the pretests, even when they find one). I try to have respect for that more economic reasoning that you are using, Eli talked about management - not economics. -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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 economist) cost-benefit analysis :) And I often prefer to keep my own opinion even under strong pressure. It is unusual, but it is not out of disrespect. 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. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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 feature? before-strings is an important feature. It is true that multi-line before-strings are not often used. But we should make such a feature work correctly in all cases, not just most cases. Chong, I suggest you install the patch (the one you feel most comfortable about), make a new pretest, and let's get on with the release. -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
[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 long answer and I just pointed to some a little bit weaker points in the answer. IMO, there are _no weak points_ in Eli's message. In one sentence: All software have bugs, so to ever make a release, someone must decide when enough is enough. Sadly RMS does not see it that way either ... so we'll probably never see a release, no matter how close we get to one (unless of course, people stop reporting bugs in the pretests, even when they find one). 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. -- David Kastrup ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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 about this one before, but in some situations it is easy to forget. The only way avoiding this is probably beeing very carefully when one is commenting on the opponents view. Perhaps it works in this kind of communication to clearly state that my view of your arguments is At least that is often a way forward in face-to-face communication. Though one have to say it with an querying voice. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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 right way to pronounce Subversion, and one said: The difference in pronunciation is extremely subtle, and I applaud your effort in attempting this via email. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
[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 multi-line before-strings an important feature? before-strings is an important feature. It is true that multi-line before-strings are not often used. But we should make such a feature work correctly in all cases, not just most cases. Chong, I suggest you install the patch (the one you feel most comfortable about), make a new pretest, and let's get on with the release. I did that. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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 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 are almost unthinkable at this stage, given the long pretest -- unless, that is, they were caused by unsafe changes we did very recently, on one of the occasions we failed to exercise will power and resist the temptation of fixing ``one more bug''. 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 Popper, if your answer is ``nothing will change my mind'', then this is a religious type of argument that we should just stop, because it has no hope of any agreement whatsoever. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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 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 convince you, since you lack a significant experience of having to decide what needs to be fixed before the release and what's after it. Of course experience is good. Did I ever say something else? Or why did you say the above? I said that in the hope that you will respect our experience and the grey hair that came with it. If you please separate my opinion from my arguments it will be much nicer. It is fundamentally human to interpret the arguments to understand the opinions of your opponent, and then try to deal with those opinions. I don't know how to discuss an issue without trying to understand what you think. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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 are almost unthinkable at this stage, given the long pretest -- unless, that is, they were caused by unsafe changes we did very recently, on one of the occasions we failed to exercise will power and resist the temptation of fixing ``one more bug''. 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 Popper, if your answer is ``nothing will change my mind'', then this is a religious type of argument that we should just stop, because it has no hope of any agreement whatsoever. That is a good question. I am of course also worried about stability. We can unfortunately not only use logical thinking, the problem is too complex for that. So we are arguing about how to look upon the different arguments. I agree that a managerial/economical view is good to use as a tool for deciding. And there must be a decision at the end. Just fixing the bug is not enough for this kind of bug. My guess is that so far we do not differ very much, or? A note: What makes me a bit upset is more that I get the feeling that you think the bug is unimportant though I have said that I do have a real use case where it will show up. Note that I do not say that you actually think so, it is perhaps more my feelings. Anyway those feelings are noticeable in my replies. This is part of the difficulties with arguing now. Probably I disturb you in a similar manner. I think that from both sides this is unintentional, but it is worth noting when we try to solve this. I have tried to explain in similar situations before that I always try to look at the problem at different levels. When you ask for what arguments will convince me this is key. If you want to convince me the best you can do is try to argument on all the different levels of the problem. Maybe you think that you have done so by referring to the experts on this code for their opinion? The difficulty I have with this is that the actual arguments on the details gets hidden. I can not argue at all then since I am trying to estimate the stability by looking at the details. That said I must point out that I can not say anything for sure about the stability. I give my arguments, hope for feedback from the experts. The may very well kill my arguments, no problems, but I do have some arguments that I think may be worth listening too. I feel very much better if the arguments are killed than if they are never looked upon. (This is kind of human I think.) Killed by some sound logic of course. I have tried to list my argumenting below (except the one above). If you want to you can comment on it. I do not know if it matters now, but to frame the situation I think we can state something like this: - We all want a release. I think we may feel a little bit weary. - There is/was a bug in cursor positionining that affects multiline 'before-string, 'after-string or 'display properties in characters or overlays. - This bug is perhaps not seen very often. - I have however a use case were it will be seen. - A bug in cursor positioning is confusing and can lead a user to suspect that something is terribly wrong (and indeed that is often a plausible thinking when the cursor is in the wrong position). I have got a milder reaction of this kind - the user thought something was wrong in my code, not in Emacs. - The display code is complex, very complex. - There is/was a bug now, which may indicate that it is fragile too (in the sense that one should be very careful and thoughtful when changing it). - We see some consequences of this bug, but there may be more, even instability. - We have not seen any instability for 2 years however with the bug. - As far as I remember we did not see any instability either with the old bug (for how many years? 1-2?) that unfortunately was cured in such a way that it created this new bug. - The fix (that Chong installed a version of) is in a sense a middle way between the two bugs above. This does not prove it does not cause instability, but it may be seen as an indication (which I prefer to see it as). - The fix is rather local and as far as I can see it only affects multi-line 'before-string, 'after-string and 'display. That makes my worries for stability less. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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 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 convince you, since you lack a significant experience of having to decide what needs to be fixed before the release and what's after it. Of course experience is good. Did I ever say something else? Or why did you say the above? I said that in the hope that you will respect our experience and the grey hair that came with it. Ah, I always learned that grey hair was caused by children. If you please separate my opinion from my arguments it will be much nicer. It is fundamentally human to interpret the arguments to understand the opinions of your opponent, and then try to deal with those opinions. I don't know how to discuss an issue without trying to understand what you think. Yes, but since we differ please be careful. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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 *before* or *after* the display string should depend in most cases on the stickiness of the property (i.e. would insertion of a char at point insert it before or after the display string?), but AFAIK we still don't do that: we just choose one of the two arbitrarily (sometimes just because it's convenient or it seemed right in some circumstance, or because that's how it worked in earlier releases). So as a user, I expect the cursor movement to be a bit odd in the presence of display strings. 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. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 it. Maybe Kim's solution with an added test of if the
string has the 'display property will solve the problem for now.
I am unable to test this now, since I do not understand how to check
for the 'display property in cursor_row_p. If someone can tell that I
will test.
That is _not_ easy.
You have to record that during redisplay (by display_line in the glyph
row) if you need that information later.
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.
If this way works (my test works) then as I said before this seems
rather safe as far as the return value from cursor_row_p is concerned.
However I think the actual code I added in cursor_row_p must be checked
carefully and perhaps rewritten. I have tried to use the ideas from
set_cursor_from_row, but I may easily have misunderstood things. I am
not good at C and the code in xdisp.c is complicated.
Here is the patch:
Index: xdisp.c
===
RCS file: /sources/emacs/emacs/src/xdisp.c,v
retrieving revision 1.1146
diff -c -r1.1146 xdisp.c
*** xdisp.c 10 Apr 2007 15:57:25 - 1.1146
--- xdisp.c 15 Apr 2007 14:31:07 -
***
*** 15858,15865
string if the string starts in this row.
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row-end.string_pos) = 0)
! cursor_row_p = (row-continued_p
! || PT = MATRIX_ROW_START_CHARPOS (row));
else if (MATRIX_ROW_ENDS_IN_MIDDLE_OF_CHAR_P (row))
{
/* If the row ends in middle of a real character,
--- 15858,15880
string if the string starts in this row.
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row-end.string_pos) = 0)
! {
! /* Check for 'display property: */
! int end = row-end.pos.charpos;
! struct glyph *text_glyphs = row-glyphs[TEXT_AREA];
! struct glyph *end_glyph = text_glyphs + row-used[TEXT_AREA];
! struct glyph *glyph = end_glyph;
! int q2 = -1;
! while (-1 == q2 glyph text_glyphs) {
! int gend2 = -1;
! if (STRINGP (glyph-object))
! gend2 = string_buffer_position(w, glyph-object, end);
! if (gend2 0)
! q2 = Fget_char_property (make_number (gend2), Qdisplay,
Qnil);
! --glyph;
! }
! cursor_row_p = (row-continued_p || (q2 != -1) );
! }
else if (MATRIX_ROW_ENDS_IN_MIDDLE_OF_CHAR_P (row))
{
/* If the row ends in middle of a real character,
___
emacs-pretest-bug mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 patch.
My main concern with such an approach is that this will be slow for
long multi-line strings filling most of the window. In such a case,
we will basically scan over all glyphs every redisplay cycle. On the
other hand, maybe this situation need not bother us right now.
There are various problems with this patch:
1. Due to an off-by-one error, you start scanning from beyond the
end of the glyph row, which can cause a segfault.
2. You have a mixup between Lisp_Object and int in the return value
of Fget_char_property.
3. The call to get_char property is unnecessary, since
string_buffer_position checks only the display property.
I fixed up the patch; see below.
I still believe it's adviseable to hold off redisplay changes till
Emacs 22.2, but if RMS insists, I guess we might as well check it in
instead of continuing this thread.
*** emacs/src/xdisp.c.~1.1146.~ 2007-04-14 11:35:10.0 -0400
--- emacs/src/xdisp.c 2007-04-15 12:37:47.0 -0400
***
*** 15850,15865
struct glyph_row *row;
{
int cursor_row_p = 1;
! 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.
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row-end.string_pos) = 0)
! cursor_row_p = (row-continued_p
! || PT = MATRIX_ROW_START_CHARPOS (row));
else if (MATRIX_ROW_ENDS_IN_MIDDLE_OF_CHAR_P (row))
{
/* If the row ends in middle of a real character,
--- 15850,15886
struct glyph_row *row;
{
int cursor_row_p = 1;
+ int row_end_charpos = MATRIX_ROW_END_CHARPOS (row);
! if (PT == row_end_charpos)
{
! /* If the row ends with a newline from a string (other than a
!display string), we don't want the cursor there.
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row-end.string_pos) = 0)
! {
! if (row-continued_p)
! cursor_row_p = 1;
! else
! {
! /* Check for `display' property. */
! struct glyph *beg = row-glyphs[TEXT_AREA];
! struct glyph *end = beg + row-used[TEXT_AREA] - 1;
! struct glyph *glyph;
! Lisp_Object prop = Qnil;
!
! for (glyph = end;
! !STRINGP (glyph-object) glyph beg;
! --glyph)
! ;
!
! cursor_row_p =
! (STRINGP (glyph-object)
! (string_buffer_position (w, glyph-object,
!row_end_charpos)
! 0));
! }
! }
else if (MATRIX_ROW_ENDS_IN_MIDDLE_OF_CHAR_P (row))
{
/* If the row ends in middle of a real character,
___
emacs-pretest-bug mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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 multi-line before-strings cause real trouble? Is the display of multi-line before-strings an important feature? ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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. Thanks for the patch. Thanks for fixing it up. Sorry for not doing it myself, but I was in a hurry. My main concern with such an approach is that this will be slow for long multi-line strings filling most of the window. In such a case, we will basically scan over all glyphs every redisplay cycle. On the other hand, maybe this situation need not bother us right now. You mean multi-line 'display strings? Then there is something I misunderstand. I mean 1) Scanning starts from the end and stops as soon as STRINGP is true. 2) It is the glyph row that is scanned. Is that not just a line? There are various problems with this patch: 1. Due to an off-by-one error, you start scanning from beyond the end of the glyph row, which can cause a segfault. Now you see why I normally do not touch C code ;-) 2. You have a mixup between Lisp_Object and int in the return value of Fget_char_property. Ah, yes, I thought it was a pointer. 3. The call to get_char property is unnecessary, since string_buffer_position checks only the display property. Thanks, I forgot that. I still believe it's adviseable to hold off redisplay changes till Emacs 22.2, but if RMS insists, I guess we might as well check it in instead of continuing this thread. I would be glad if we included this. I have already got complaints about this bug from some testers of my code. I think it would be good if this code were tested with all libraries using 'display prop as soon as possible. My worst doubt about this code is that I am not sure whether the necessary information actually always is available when cursor_row_p is called, but it looks to me like it must be that. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 working on it. There were a substantial number of them. Could you resend just to me the message which explained the problem? ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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. 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 release. -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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 that causes real trouble is a serious bug. While such bugs create a well-understood motivation for fixing them, we should always weigh that against the possibility of introducing new and exciting bugs into an already very stable code base, and delaying an already long overdue release. When such a risk is real (as in this case, since we are talking about a change in the guts of a general purpose display code), we should, as a counter-balance, estimate the risk of someone tripping on the original bug. If that latter risk is low (as it is in this case, as evidenced by the 2-year period passed since the commit of the buggy code), we should seriously consider leaving the bug alone until after the release. 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. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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] http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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 indisputably wrong and that causes real trouble is a serious bug. While such bugs create a well-understood motivation for fixing them, we should always weigh that against the possibility of introducing new and exciting bugs into an already very stable code base, and delaying an already long overdue release. When such a risk is real (as in this case, since we are talking about a change in the guts of a general purpose display code), we should, as a counter-balance, estimate the risk of someone tripping on the original bug. If that latter risk is low (as it is in this case, as evidenced by the 2-year period passed since the commit of the buggy code), we should seriously consider leaving the bug alone until after the release. I think this analysis could be a big deal deeper and less general. I think that would help to create a more meaningful discussion if we want that. 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. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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 release. Yes, I've never seen this `bug', but there must be a real danger that I will see one caused by the fix, as Kim says, after the release. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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 inconvenienced by this bug (and how often do you need an overlay at the start of the buffer?) while probably thousands want to see a release, and thousands more want to see Unicode added to Emacs, I just find the whole thing absurd. Some things are worth dying for, but I don't this is one of them. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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, neither am I ignoring Richard's advice here. And I have listened to Chong. If you read my messages carefully you will see why I do not think this is dangerous to fix the way I have suggested. This is what I wrote to Kim some hours ago (who if I understand correctly is suspecting that a slightly different way to fix it is better in the long run): The advantage of this way (my fix) is that it is rather safe. In essence it just switches the value or-ed with row-continued_p between that your a little bit unfortunate patch gave (ie t) and the previous value (ie nil). Both these values have been tested for quite a while so it does not look as there can much stability problems. Given that you appear to be the only one to have been inconvenienced by this bug (and how often do you need an overlay at the start of the buffer?) while probably thousands want to see a release, and thousands more want to see Unicode added to Emacs, I just find the whole thing absurd. Some things are worth dying for, but I don't this is one of them. 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, this makes me frustrated too, but I have tried my best not to delay the release. I believe the fix I sent today and that Chong turned into something more well written does what is needed. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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 that code inside and out routinely makes mistakes when changing it (as the bug you've found proves). Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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 not say so of course. I suggested reading my arguments. Is not that a better level of discussion? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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 knowledgeable about it either. OTOH, it seems that people who really knows it inside and out is unconvinced that changing it now is safe. Excuse me if I trust their opinion. Is not that a better level of discussion? I'd suggest as a better level of discussion if you presupposed that people who disagrees with your arguments *perhaps* does so for reasons other than not having read them... Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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 you're not very knowledgeable about it either. OTOH, it seems that people who really knows it inside and out is unconvinced that changing it now is safe. Excuse me if I trust their opinion. Ok, that is fine, but see below. Is not that a better level of discussion? I'd suggest as a better level of discussion if you presupposed that people who disagrees with your arguments *perhaps* does so for reasons other than not having read them... Ok, sorry. Then what arguments are actually convincing to you? For sure I found it troublesome to change that code now. There is however no other way to fix the bug. I know that both Kim and Chong hesitate to do the changes now. My argument is not that I do not trust them. I try to look at the actual changes and estimate the chances that it can go wrong. Then I try to get their feedback on this because I know that they know the code better from both a present and a historical point of view. Chong has given concrete feedback to the list to the fix I sent. Kim has not done so yet and I do not know if he will give feedback on that level. You are of course free to take any standpoint you want, but I think it would be nice and useful if you tried to keep it on the level I suggest above. If you just want to say that you do not want that change to be made now that is also ok. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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 meaningful discussion if we want that. You don't need to be ``deep'' to recognize a general principle and behave in accordance with it. And no ``meaningful discussion'' is ever needed to agree that 2 + 2 = 4. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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 it in another two years. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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 convince you, since you lack a significant experience of having to decide what needs to be fixed before the release and what's after it. For sure I found it troublesome to change that code now. There is however no other way to fix the bug. We do not intend to forget about the bug. We just want to fix it _after_ the release that's all. I hope you understand that, no matter how hard we work, there will be always bugs in the released Emacs. Leaving this one in just means there's one more. I know that both Kim and Chong hesitate to do the changes now. My argument is not that I do not trust them. I try to look at the actual changes and estimate the chances that it can go wrong. This estimation on the one hand, and the estimated seriousness of the bug on the other, is the fundamental issue. If you cannot see how the former is much larger than the latter, then we have no real basis for a reasonable discussion. Then I try to get their feedback on this because I know that they know the code better from both a present and a historical point of view. Chong has given concrete feedback to the list to the fix I sent. Kim has not done so yet and I do not know if he will give feedback on that level. That's because everyone else but you look at this issue at a fundamentally different level. You look at the details, but no amount of details will ever lead you to the bigger picture--that we need to release soon, and that Emacs is ready for that. You are of course free to take any standpoint you want, but I think it would be nice and useful if you tried to keep it on the level I suggest above. You cannot force your opponents in the argument to reply only to your arguments and not take the discussion to a higher level. The main issue here is of a managerial character, it's not about the specifics of the proposed solutions to the bug. I hope you do understand that there are principles, not only facts and details, do you? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
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 true that multi-line before-strings are not often used. But we should make such a feature work correctly in all cases, not just most cases. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 continue this talk. To figure out what this conditional is, one must first get to the bottom of the failure. If you explain the failure mode to me, I will try to figure out a safe fix. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 figure out what this conditional is, one must first get to the bottom of the failure. If you explain the failure mode to me, I will try to figure out a safe fix. I already explained twice what the problem is, and why it's better to postphone the fix. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 figure out how? To figure out what this conditional is, one must first get to the bottom of the failure. If you explain the failure mode to me, I will try to figure out a safe fix. I already explained twice what the problem is, and why it's better to postphone the fix. I took the sketchial patch Chong sent, inserted a lot of dump messages and played with it to try to understand what is happening. The patch looks bigger than it actually is. I mean much of it just adds another parameter to string_buffer_pos and that is rather harmless from a stability point of view. I think I see several small bugs, most related to the 'display property, but not all: 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 press down arrow. 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 property (which is the correct behavior I believe). This seems to be a bug in another part than the ones Chong tried to cover with his patch sketch. C) Even when moving with left arrow the cursor stops at the wrong position. It stops after the 'display part. (This behavior is correct for 'before-string and 'after-string, but not for 'display strings.) D) When the cursor is at the second 'display area of Kim's example set_cursor_from_row gets called over and over again. It does not matter how that row was entered AFAICS. Can others reproduce the bug in B? If so I believe this is the most serious one. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 property (which is the correct behavior I believe). This seems to be a bug in another part than the ones Chong tried to cover with his patch sketch. Can others reproduce the bug in B? If so I believe this is the most serious one. I reverted the changes to keyboard.c in Chongs patch sketch. That cured this problem. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 press down arrow. Whatever size the buffer have when point is at the end of buffer and I press left arrow then set_cursor_from_row has PT=14 and when I press down arrow PT=1. In other circusomstances PT seems to be what I expect (ie ==(point)). Could not this be a problem for the cursor position routines? ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 'display property will solve the problem for now. I am unable to test this now, since I do not understand how to check for the 'display property in cursor_row_p. If someone can tell that I will test. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 solution with an added test of if the string has the 'display property will solve the problem for now. I am unable to test this now, since I do not understand how to check for the 'display property in cursor_row_p. If someone can tell that I will test. That is _not_ easy. You have to record that during redisplay (by display_line in the glyph row) if you need that information later. -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
[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 cursor places it on the 'A'.
Without my change, moving the cursor places it on the 'y'.
So my change may be incorrect - but it _does_ solve a real problem.
I think the following approach may work.
It reverts your cursor_row_p change, and deals with overlays
containing display properties by modifying adjust_point_for_property
so that one is never at the start of such an overlay (the behavior for
display text properties is left unchanged). It doesn't deal with the
other issue I raised (i.e., the apparently false assumption in the way
set_cursor_from_row uses string_buffer_position). However, dealing
with the opens up another can of worms, and the current patch seems
sufficient to provide good behavior for all cases I've tried.
Of course, redisplay can lead to some pretty subtle bugs. It's still
debatable whether we want to make such a change at this stage.
*** emacs/src/xdisp.c.~1.1146.~ 2007-04-14 16:57:50.0 -0400
--- emacs/src/xdisp.c 2007-04-14 19:03:17.0 -0400
***
*** 15854,15865
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.
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row-end.string_pos) = 0)
! cursor_row_p = (row-continued_p
! || PT = MATRIX_ROW_START_CHARPOS (row));
else if (MATRIX_ROW_ENDS_IN_MIDDLE_OF_CHAR_P (row))
{
/* If the row ends in middle of a real character,
--- 15854,15863
if (PT == MATRIX_ROW_END_CHARPOS (row))
{
/* If the row ends with a newline from a string, we don't want
!the cursor there.
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row-end.string_pos) = 0)
! cursor_row_p = row-continued_p;
else if (MATRIX_ROW_ENDS_IN_MIDDLE_OF_CHAR_P (row))
{
/* If the row ends in middle of a real character,
*** emacs/src/keyboard.c.~1.899.~ 2007-04-14 16:26:52.0 -0400
--- emacs/src/keyboard.c2007-04-14 19:22:33.0 -0400
***
*** 2006,2027
}
check_composition = 0;
if (check_display
! PT BEGV PT ZV
!NILP (val = get_char_property_and_overlay
(make_number (PT), Qdisplay, Qnil, overlay))
! display_prop_intangible_p (val)
! (!OVERLAYP (overlay)
! ? get_property_and_range (PT, Qdisplay, val, beg, end, Qnil)
! : (beg = OVERLAY_POSITION (OVERLAY_START (overlay)),
!end = OVERLAY_POSITION (OVERLAY_END (overlay
! (beg PT /* end PT - It's always the case. */
! || (beg = PT STRINGP (val) SCHARS (val) == 0)))
! {
! xassert (end PT);
! SET_PT (PT last_pt
! ? (STRINGP (val) SCHARS (val) == 0 ? beg - 1 : beg)
! : end);
! check_composition = check_invisible = 1;
}
check_display = 0;
if (check_invisible PT BEGV PT ZV)
--- 2006,2041
}
check_composition = 0;
if (check_display
! PT = BEGV PT ZV
!NILP (val = get_char_property_and_overlay
(make_number (PT), Qdisplay, Qnil, overlay))
! display_prop_intangible_p (val))
! {
! if (OVERLAYP (overlay))
! {
! beg = OVERLAY_POSITION (OVERLAY_START (overlay));
! end = OVERLAY_POSITION (OVERLAY_END (overlay));
! if (beg = PT)
! {
! SET_PT (PT last_pt
! ? (beg BEGV) ? beg - 1 : end
! : end);
! check_composition = check_invisible = 1;
! }
! }
! else if (PT BEGV)
! {
! get_property_and_range (PT, Qdisplay, val, beg, end, Qnil);
! xassert (end PT);
! if ((beg PT)
! || (beg == PT STRINGP (val) SCHARS (val) == 0))
! {
! SET_PT (PT last_pt
! ? (STRINGP (val) SCHARS (val) == 0 ? beg - 1 : beg)
! : end);
! check_composition = check_invisible = 1;
! }
! }
}
check_display = 0;
if (check_invisible PT BEGV PT ZV)
___
emacs-pretest-bug mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 it. Maybe Kim's solution with an added test of if the string has the 'display property will solve the problem for now. I am unable to test this now, since I do not understand how to check for the 'display property in cursor_row_p. If someone can tell that I will test. That is _not_ easy. You have to record that during redisplay (by display_line in the glyph row) if you need that information later. But does not the code in set_cursor_from_row test for 'display in strings? Or is that another situation? But I see now set_cursor_from_row just calls pos = XINT (Fnext_single_char_property_change (make_number (pos), Qdisplay, Qnil, limit)); Can't that approach be used? glyph_row has a pointer to the position in the buffer through the field display_pos start, where display_pos has a text_pos field. And text_pos has a charpos field, which I assume is the position in the buffer. I am thinking about this solution since it seems rather safe to me. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 - combining before and after strings as well as compositions, so I really feel bad about touching this now. If you make a change that only takes action in the bug case, you can be sure you are not breaking any other case. Pardon me, but that's nonsense. How can I be sure that the change only takes action in the bug case ? How can I be sure that _any_ change in redisplay will not have unexpected side-effects ... in my experience, most first attempt redisplay changes aimed at fixing corner-case bugs have unexpected side-effects. Redisplay is just so damn complicated that I would never use the word sure in that context. -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 it's a rather big change, and likely to cause
problems, whereas the problem it corrects is not commonly encountered
(cursor positioning in multi-line overlay before/after-strings).
So I'd like to delay this till after Emacs 22.1. WDYT?
*** emacs/src/keyboard.c.~1.899.~ 2007-04-04 13:05:31.0 -0400
--- emacs/src/keyboard.c2007-04-13 14:04:15.0 -0400
***
*** 2010,2021
!NILP (val = get_char_property_and_overlay
(make_number (PT), Qdisplay, Qnil, overlay))
display_prop_intangible_p (val)
! (!OVERLAYP (overlay)
! ? get_property_and_range (PT, Qdisplay, val, beg, end, Qnil)
! : (beg = OVERLAY_POSITION (OVERLAY_START (overlay)),
!end = OVERLAY_POSITION (OVERLAY_END (overlay
! (beg PT /* end PT - It's always the case. */
! || (beg = PT STRINGP (val) SCHARS (val) == 0)))
{
xassert (end PT);
SET_PT (PT last_pt
--- 2010,2022
!NILP (val = get_char_property_and_overlay
(make_number (PT), Qdisplay, Qnil, overlay))
display_prop_intangible_p (val)
! (OVERLAYP (overlay)
! ? (beg = OVERLAY_POSITION (OVERLAY_START (overlay)),
!end = OVERLAY_POSITION (OVERLAY_END (overlay)),
!beg = PT)
! : (get_property_and_range (PT, Qdisplay, val, beg, end, Qnil),
!(beg PT
! || (beg = PT STRINGP (val) SCHARS (val) == 0)
{
xassert (end PT);
SET_PT (PT last_pt
*** emacs/src/dispextern.h.~1.225.~ 2007-01-21 13:34:43.0 -0500
--- emacs/src/dispextern.h 2007-04-13 13:42:58.0 -0400
***
*** 2636,2642
struct glyph_row *row_containing_pos P_ ((struct window *, int,
struct glyph_row *,
struct glyph_row *, int));
! int string_buffer_position P_ ((struct window *, Lisp_Object, int));
int line_bottom_y P_ ((struct it *));
int display_prop_intangible_p P_ ((Lisp_Object));
void resize_echo_area_exactly P_ ((void));
--- 2636,2642
struct glyph_row *row_containing_pos P_ ((struct window *, int,
struct glyph_row *,
struct glyph_row *, int));
! int string_buffer_position P_ ((struct window *, Lisp_Object, int,
Lisp_Object *));
int line_bottom_y P_ ((struct it *));
int display_prop_intangible_p P_ ((Lisp_Object));
void resize_echo_area_exactly P_ ((void));
*** emacs/src/xdisp.c.~1.1146.~ 2007-04-12 16:23:44.0 -0400
--- emacs/src/xdisp.c 2007-04-13 14:09:22.0 -0400
***
*** 4425,4434
called asynchronously from note_mouse_highlight. */
int
! string_buffer_position (w, string, around_charpos)
struct window *w;
Lisp_Object string;
int around_charpos;
{
Lisp_Object limit, prop, pos;
const int MAX_DISTANCE = 1000;
--- 4425,4435
called asynchronously from note_mouse_highlight. */
int
! string_buffer_position (w, string, around_charpos, overlay)
struct window *w;
Lisp_Object string;
int around_charpos;
+ Lisp_Object *overlay;
{
Lisp_Object limit, prop, pos;
const int MAX_DISTANCE = 1000;
***
*** 4438,
limit = make_number (min (XINT (pos) + MAX_DISTANCE, ZV));
while (!found !EQ (pos, limit))
{
! prop = Fget_char_property (pos, Qdisplay, Qnil);
if (!NILP (prop) display_prop_string_p (prop, string))
found = 1;
else
--- 4439,4445
limit = make_number (min (XINT (pos) + MAX_DISTANCE, ZV));
while (!found !EQ (pos, limit))
{
! prop = get_char_property_and_overlay (pos, Qdisplay, Qnil, overlay);
if (!NILP (prop) display_prop_string_p (prop, string))
found = 1;
else
***
*** 4451,4457
limit = make_number (max (XINT (pos) - MAX_DISTANCE, BEGV));
while (!found !EQ (pos, limit))
{
! prop = Fget_char_property (pos, Qdisplay, Qnil);
if (!NILP (prop) display_prop_string_p (prop, string))
found = 1;
else
--- 4452,4458
limit = make_number (max (XINT (pos) - MAX_DISTANCE, BEGV));
while (!found !EQ (pos, limit))
{
! prop = get_char_property_and_overlay (pos, Qdisplay, Qnil, overlay);
if (!NILP (prop) display_prop_string_p (prop, string))
found = 1;
else
***
***
Re: Display problems with 'before-string in overlay
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 patch fails with the following reject (xdisp.c.rej): Sorry if I wasted someonce time. There were no problems applying the patch, I just applied it to the wrong tree. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 tests for that case. Show what that conditional is ... then we can continue this talk. -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 grave bug. How do you know? This just looks so strange so it could well be a grave bug. How do I know what? that it's not grave? But I just explained that! To me it looks more like using a 'before-string of the kind I am using is uncommon. But maybe that is what you mean, that is not grave because it is uncommon. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 one noticed this since July 2005, it's hardly a grave bug. How do you know? This just looks so strange so it could well be a grave bug. How do I know what? that it's not grave? But I just explained that! To me it looks more like using a 'before-string of the kind I am using is uncommon. But maybe that is what you mean, that is not grave because it is uncommon. 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. -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 fix a bug, and it
did fix _that_ bug.
Now you have found a different bug in the same code, and you propose
a different way to fix _your_ bug.
Indeed your code does look like it could fix the problem - but it
definitely changes the semantics of the test, so there may very well
be other corner casee which are broken by _your_ code.
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.
Besides, the ++row seems dangrous to me. Would row+1 do the same?
Index: xdisp.c
===
RCS file: /cvsroot/emacs/emacs/src/xdisp.c,v
retrieving revision 1.1146
diff -c -r1.1146 xdisp.c
*** xdisp.c 10 Apr 2007 15:57:25 - 1.1146
--- xdisp.c 12 Apr 2007 00:40:36 -
***
*** 15859,15865
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row-end.string_pos) = 0)
cursor_row_p = (row-continued_p
! || PT = MATRIX_ROW_START_CHARPOS (row));
else if (MATRIX_ROW_ENDS_IN_MIDDLE_OF_CHAR_P (row))
{
/* If the row ends in middle of a real character,
--- 15859,15865
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row-end.string_pos) = 0)
cursor_row_p = (row-continued_p
! || PT MATRIX_ROW_START_CHARPOS (++row));
else if (MATRIX_ROW_ENDS_IN_MIDDLE_OF_CHAR_P (row))
{
/* If the row ends in middle of a real character,
--
Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk
___
emacs-pretest-bug mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
[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 after strings as well as compositions, so I really feel bad about touching this now. Besides, the ++row seems dangrous to me. Would row+1 do the same? Note: You must check that the next row is a valid row. And decide what to do if not? -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 to was installed to fix a bug, and it
did fix _that_ bug.
The code before my change looked like this:
if (PT == MATRIX_ROW_END_CHARPOS (row))
{
if (CHARPOS (row-end.string_pos) = 0)
cursor_row_p = (row-continued_p
|| PT = MATRIX_ROW_START_CHARPOS (row));
I thought it was useless because it the first test with PT seems to
imply that the second test with PT must be true. I did not look into the
structures and how they are used, only the names of the macros and the
definition of them.
Do you say that the second test actually could fail? I believed it was
perhaps a mis-paste or something.
Now you have found a different bug in the same code, and you propose
a different way to fix _your_ bug.
Indeed your code does look like it could fix the problem - but it
definitely changes the semantics of the test, so there may very well
be other corner casee which are broken by _your_ code.
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.
If you think that the test actually does something I can try.
Besides, the ++row seems dangrous to me. Would row+1 do the same?
Sorry, yes, that is better and my first test now implies it works.
This is the bug I want to have fixed (since it is very visible), but
there are other bugs there too. The first one is for the record, perhaps
you care about the second:
1) In some situations the cursor can still stop at the end of the first
row in the 'before-string. But I have only seen it once and I am not
sure how to reproduce it. (It does not happen when the overlay is at 1-1
or at least I have not seen it then.) Does this imply that some other
test in cursor_row_p may be wrong?
2) If you shrink the window so that the 'before-string fills from top to
bottom the first char after it disappears from the screen. Not extremely
serious in itself, but perhaps easy to fix (and it might also point to
other troubles, of course). To reproduce this eval the code below (same
as before):
(defvar temp-ovl nil)
(defun temp-toggle-ovl()
(interactive)
(if temp-ovl
(progn
(delete-overlay temp-ovl)
(setq temp-ovl nil))
(setq temp-ovl (make-overlay 1 1))
(let ((s A string\nwith several rows\nthat should be at top\n))
(put-text-property 0 (length s)
'face (list (cons 'background-color
yellow))
s)
(overlay-put temp-ovl 'before-string s
The create a new buffer with two rows:
First char may disappear.
But second line is ok.
Do
M-x temp-toggle-ovl
go to char 1 and then shrink the window vertically. When the number of
lines gets down to the height of the 'before-string the char F
disappears. Or the cursor may move to the first line of the 'before-string.
___
emacs-pretest-bug mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 have to rethink after coding. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
[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 http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-06/msg00342.html However, your fix appears to have been unrelated to that original bug report: http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-07/msg00246.html From: Kim F. Storm Subject: Re: Overlays disappearing during line-by-line scrolling Date: Wed, 13 Jul 2005 12:35:42 +0200 I have installed some changes to fix this and other problems related to line-move around such multi-line overlay strings. The changes touches on some tricky low-level move_it_... functions so I may have broken other things... * I also fixed problems with positioning the cursor on (first char of) * such multi-line strings. Finally, I fixed problems related to vertical-motion not moving when point is on an image. The ChangeLog entry says: Row is ok if cursor is at newline from string, but string starts on this line (so we always position cursor at start of string). 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 setting cursor_row_p unconditionally, since PT == MATRIX_ROW_END_CHARPOS (row) implies PT = MATRIX_ROW_START_CHARPOS (row). To actually do what the comments and ChangeLog say we want to do, we would have to scan backward in the glyph row for the beginning of the string, which would be significantly more complicated than the current code. For the Emacs 22 release, maybe we should simply revert this change to cursor_row_p = row-continued_p; It does not cause the original 2005 bug report to reappear, and it doesn't seem to affect anything else as far as I can tell. WDYT? ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 setting cursor_row_p unconditionally, since PT == MATRIX_ROW_END_CHARPOS (row) implies PT = MATRIX_ROW_START_CHARPOS (row). Looking at it again I wonder why my test change did not do that too ... ;-) To actually do what the comments and ChangeLog say we want to do, we would have to scan backward in the glyph row for the beginning of the string, which would be significantly more complicated than the current code. For the Emacs 22 release, maybe we should simply revert this change to cursor_row_p = row-continued_p; It does not cause the original 2005 bug report to reappear, and it doesn't seem to affect anything else as far as I can tell. WDYT? Reverting as you propose seems to at least cure the problem I saw. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 pointing out that it's setting cursor_row_p unconditionally, since PT == MATRIX_ROW_END_CHARPOS (row) implies PT = MATRIX_ROW_START_CHARPOS (row). To actually do what the comments and ChangeLog say we want to do, we would have to scan backward in the glyph row for the beginning of the string, which would be significantly more complicated than the current code. For the Emacs 22 release, maybe we should simply revert this change to cursor_row_p = row-continued_p; It does not cause the original 2005 bug report to reappear, and it doesn't seem to affect anything else as far as I can tell. WDYT? 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 'display Ax\nyB)) (goto-char (point-max))) With my change, moving the cursor places it on the 'A'. Without my change, moving the cursor places it on the 'y'. So my change may be incorrect - but it _does_ solve a real problem. -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 not the time to try to fix that. This could be a corner case. If so, you could fix it, and things would surely be better even if maybe not perfect. So please try. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
[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 'display Ax\nyB))
(goto-char (point-max)))
With my change, moving the cursor places it on the 'A'.
Without my change, moving the cursor places it on the 'y'.
So my change may be incorrect - but it _does_ solve a real problem.
OK, now I see the problem.
I believe the underlying fault is not in cursor_row_p, but in
set_cursor_from_row, on xdisp.c:11948:
pos = string_buffer_position (w, string, string_before_pos);
/* If STRING is from overlay, LAST_POS == 0. We skip such glyphs
because we always put cursor after overlay strings. */
while (pos == 0 glyph stop)
{
string = glyph-object;
The assumption made in the comment is not correct:
string_buffer_position returns non-zero values for overlay strings
with the `display' property. In xdisp.c:4446:
prop = Fget_char_property (pos, Qdisplay, Qnil);
if (!NILP (prop) display_prop_string_p (prop, string))
found = 1;
This suggests that the way to fix this is to change
string_buffer_position to do what that says. 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.
Thus, I think this issue should be left alone for the Emacs 22.1. It
is easy to work around the affected corner case, by using text
properties or a display property rather an overlay with a
before-string. After 22.1, I can take a look at fixing this along the
lines discussed above.
___
emacs-pretest-bug mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 overlay with a before-string. After 22.1, I can take a look at fixing this along the lines discussed above. Thank you. -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 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 grave bug. How do you know? This just looks so strange so it could well be a grave bug. How do I know what? that it's not grave? But I just explained that! To me it looks more like using a 'before-string of the kind I am using is uncommon. But maybe that is what you mean, that is not grave because it is uncommon. A feature that no one used in almost 2 years is uncommon, yes. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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)))
(overlay-put ov 'display Ax\nyB))
(goto-char (point-max)))
With my change, moving the cursor places it on the 'A'.
Without my change, moving the cursor places it on the 'y'.
So my change may be incorrect - but it _does_ solve a real problem.
OK, now I see the problem.
I believe the underlying fault is not in cursor_row_p, but in
set_cursor_from_row, on xdisp.c:11948:
pos = string_buffer_position (w, string, string_before_pos);
/* If STRING is from overlay, LAST_POS == 0. We skip such glyphs
because we always put cursor after overlay strings. */
while (pos == 0 glyph stop)
{
string = glyph-object;
The assumption made in the comment is not correct:
string_buffer_position returns non-zero values for overlay strings
with the `display' property. In xdisp.c:4446:
prop = Fget_char_property (pos, Qdisplay, Qnil);
if (!NILP (prop) display_prop_string_p (prop, string))
found = 1;
This suggests that the way to fix this is to change
string_buffer_position to do what that says. 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.
I tested another way that perhaps is in line with Kim's original intent.
Since I do not know this code I had to guess put I put it here so you
can comment:
static int
cursor_row_p (w, row)
struct window *w;
struct glyph_row *row;
{
int cursor_row_p = 1;
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.
If the row is continued it doesn't end in a newline. */
fprintf (stderr, cont=%d, start.string_pos=%d, %d, end=%d, %d\n,
row-continued_p,
CHARPOS (row-start.string_pos),
row-start.pos.charpos,
CHARPOS (row-end.string_pos),
row-end.pos.charpos);
if (CHARPOS (row-end.string_pos) = 0)
cursor_row_p = (row-continued_p
||
(
/* If an overlay string starts on this glyph
line, then put the cursor here, but only
if not on the first buffer line and there
are no characters there. */
((CHARPOS (row-start.string_pos)) == -1)
((CHARPOS (row-end.string_pos)) -1)
(row-start.pos.charpos 1)
));
else if (MATRIX_ROW_ENDS_IN_MIDDLE_OF_CHAR_P (row))
{
/* If the row ends in middle of a real character,
and the line is continued, we want the cursor here.
That's because MATRIX_ROW_END_CHARPOS would equal
PT if PT is before the character. */
if (!row-ends_in_ellipsis_p)
cursor_row_p = row-continued_p;
else
/* If the row ends in an ellipsis, then
MATRIX_ROW_END_CHARPOS will equal point after the invisible text.
We want that position to be displayed after the ellipsis. */
cursor_row_p = 0;
}
/* If the row ends at ZV, display the cursor at the end of that
row instead of at the start of the row below. */
else if (row-ends_at_zv_p)
cursor_row_p = 1;
else
cursor_row_p = 0;
}
return cursor_row_p;
}
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.
Thus, I think this issue should be left alone for the Emacs 22.1. It
is easy to work around the affected corner case, by using text
properties or a display property rather an overlay with a
before-string. After 22.1, I can take a look at fixing this along the
lines discussed above.
Could you please tell me how then? I want to display text at the top of
a buffer, but I do not want to change the users text in the buffer.
___
emacs-pretest-bug mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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. The only thing one has to do is to go to the first character in a buffer and then press left arrow. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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. */ if (CHARPOS (row-end.string_pos) = 0) cursor_row_p = (row-continued_p || ( /* If an overlay string starts on this glyph line, then put the cursor here, but only if not on the first buffer line and there are no characters there. */ ((CHARPOS (row-start.string_pos)) == -1) ((CHARPOS (row-end.string_pos)) -1) (row-start.pos.charpos 1) )); This does not solve the underlying problem, because the unexpected cursor position can occur even if the affected overlay is not on the first line. 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. As you can see, tweaking redisplay can have rather non-trivial effects. Could you please tell me how then? I want to display text at the top of a buffer, but I do not want to change the users text in the buffer. Why not just use a header line? ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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. This was wrong. The looping occurs without my changes. The only thing one has to do is to go to the first character in a buffer and then press left arrow. 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. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 doesn't end in a newline. */ if (CHARPOS (row-end.string_pos) = 0) cursor_row_p = (row-continued_p || ( /* If an overlay string starts on this glyph line, then put the cursor here, but only if not on the first buffer line and there are no characters there. */ ((CHARPOS (row-start.string_pos)) == -1) ((CHARPOS (row-end.string_pos)) -1) (row-start.pos.charpos 1) )); This does not solve the underlying problem, because the unexpected cursor position can occur even if the affected overlay is not on the first line. 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. 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. As you can see, tweaking redisplay can have rather non-trivial effects. Yes, I really believe it can, but I was wrong in this case. The problem is there without my changes. A new small bug. Could you please tell me how then? I want to display text at the top of a buffer, but I do not want to change the users text in the buffer. Why not just use a header line? Because I need several lines and I think it is rather necessary that they move together with the buffer contents to save screen estate. I want to put this at the top of the buffer to make it easier for users to understand what is happening. This is part of nXhtml where I try to adopt James Clark's nxml-mode for editing of XHTML files and also files that are not full XHTML, like php, jsp etc. The framework from nxml-mode parses the XML code in the buffer and gives the user the possibility to use completion of tags, attributes and values in accordance with the DTD. Now in the case of php this headers may not be there in the buffer (since they may instead be created dynamically) so I give the framework a starting state instead. To show the user the starting state I want to (optionally) show these lines in the buffer. Even with this feedback it may be difficult to understand what is happening, but hopefully with it users will learn. So at the top of the buffer I am displaying something like this with the help of an overlay and 'before-string: ?xml version=1.0 encoding=iso-8859-1? !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; html xmlns=http://www.w3.org/1999/xhtml; head titleDummy/title /head body ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 press left arrow. This was wrong. The looping occurs without my changes. The only thing one has to do is to go to the first character in a buffer and then press left arrow. 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 -Q. For me a continues output from the frpintf statements starts immediately, something like the below. It stops if I enter some text and continues if I go to the beginning of the buffer and then press left arrow again. cont=0, start.string_pos=-1, 1, end=-1, 67 cont=0, start.string_pos=-1, 1, end=-1, 67 cont=0, start.string_pos=-1, 1, end=-1, 1 cont=0, start.string_pos=-1, 1, end=-1, 67 cont=0, start.string_pos=-1, 1, end=-1, 1 cont=0, start.string_pos=-1, 1, end=-1, 67 cont=0, start.string_pos=-1, 1, end=-1, 67 cont=0, start.string_pos=-1, 1, end=-1, 67 cont=0, start.string_pos=-1, 1, end=-1, 67 cont=0, start.string_pos=-1, 1, end=-1, 67 cont=0, start.string_pos=-1, 1, end=-1, 20 cont=0, start.string_pos=-1, 1, end=-1, 1 cont=0, start.string_pos=-1, 1, end=-1, 20 cont=0, start.string_pos=-1, 1, end=-1, 20 cont=0, start.string_pos=-1, 1, end=-1, 20 cont=0, start.string_pos=-1, 1, end=-1, 20 ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 -Q. For me a continues output from the frpintf statements starts immediately, something like the below. It does not loop infinitely, at least for me. The messages stop as soon as Emacs finishes starting up, as expected. It stops if I enter some text and continues if I go to the beginning of the buffer and then press left arrow again. I can't reproduce this. You probably left some of your code in xdisp.c. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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, the unexpected cursor position can occur even if the affected overlay is not on the first line, so there's no point introducing a kludge to handle the case where it is on the first line. It is better to wait for Emacs 22.2 to fix it for real. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 start with emacs -Q. For me a continues output from the frpintf statements starts immediately, something like the below. It does not loop infinitely, at least for me. The messages stop as soon as Emacs finishes starting up, as expected. It stops if I enter some text and continues if I go to the beginning of the buffer and then press left arrow again. I can't reproduce this. You probably left some of your code in xdisp.c. Yes, you are right. it actually stops if you wait a little longer than I did. But it takes 80-100 turns before it does that. And it starts again if you press left or right arrow. And it stops if you press up or down arrow. Something strange perhaps, but nothing to worry about. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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)))
(overlay-put ov 'display Ax\nyB))
(goto-char (point-max)))
With my change, moving the cursor places it on the 'A'.
Without my change, moving the cursor places it on the 'y'.
So my change may be incorrect - but it _does_ solve a real problem.
OK, now I see the problem.
I believe the underlying fault is not in cursor_row_p, but in
set_cursor_from_row, on xdisp.c:11948:
pos = string_buffer_position (w, string, string_before_pos);
/* If STRING is from overlay, LAST_POS == 0. We skip such glyphs
because we always put cursor after overlay strings. */
while (pos == 0 glyph stop)
{
string = glyph-object;
The assumption made in the comment is not correct:
string_buffer_position returns non-zero values for overlay strings
with the `display' property. In xdisp.c:4446:
prop = Fget_char_property (pos, Qdisplay, Qnil);
if (!NILP (prop) display_prop_string_p (prop, string))
found = 1;
This suggests that the way to fix this is to change
string_buffer_position to do what that says.
I tested with !display_prop_string_p at the two places in
string_buffer_position where it occurs. That does the correct thing in
my case, but not in Kim's example AFAICS.
In Kim's example the cursor stops after the 'display part when moving
char by char from left or right. It stays on that position for an extra
left or right arrow.
Checking if the string is from 'display at the correct position in
set_cursor_from_row could perhaps cure the problem. There is a test now
for Qdisplay, but it looks like this test might be disabled by the while
loop right above it which skips all overlays.
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 note_mouse_highlight.
___
emacs-pretest-bug mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 note_mouse_highlight. In the past, we've had point-is-completely-stuck bugs originating from the former code, and crash bugs from the latter. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 as compositions, so I really feel bad about touching this now. If you make a change that only takes action in the bug case, you can be sure you are not breaking any other case. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 buffer. When (point) is 1 I want the cursor to be displayed after the 'before-string. And as a pessimist I fear that it might be displayed before the 'before-string. However none of these alternatives happen. Instead the cursor is displayed at the end of the first line of the 'before-string. To reproduce the problem eval this code and go to the beginning of the buffer: (defvar temp-ovl nil) (defun temp-toggle-ovl() (interactive) (if temp-ovl (progn (delete-overlay temp-ovl) (setq temp-ovl nil)) (setq temp-ovl (make-overlay 1 1)) (let ((s A string\nwith several rows\nthat should be at top\n) (put-text-property 0 (length s) 'face (list (cons 'background-color yellow)) s) (overlay-put temp-ovl 'before-string s I have attached an image display the cursor at point 1. In GNU Emacs 22.0.97.1 (i386-mingw-nt5.1.2600) of 2007-04-09 Could I get some feedback on this please? I know now that the problem exists also on GNU/Linux. It looks to me like it could be easy to fix, but I do not know the code involved for displaying the cursor, 'before-string etc. I would really like this bug to be fixed before the release. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 'before-string.
[Modified test function]:
(defun foo ()
(interactive)
(let ((o (make-overlay 1 1))
(s (propertize A string\nwith several rows\nat top\n
'face 'highlight)))
(overlay-put o 'before-string s)))
This buglet appears to be due to the following change:
2005-07-13 Kim F. Storm [EMAIL PROTECTED]
* xdisp.c (cursor_row_p): Row is ok if cursor is at newline
from string, but string starts on this line (so we always
position cursor at start of string).
The relevant code is at xdisp.c:15861:
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.
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row-end.string_pos) = 0)
cursor_row_p = (row-continued_p
|| PT = MATRIX_ROW_START_CHARPOS (row));
Changing this last line to `cursor_row_p = row-continued_p;', as it
was before, eliminates the bug. I haven't thought about how to fix
this, though.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 with a
before-string property to do this... the cursor is displayed at the
end of the first line of the 'before-string.
[Modified test function]:
(defun foo ()
(interactive)
(let ((o (make-overlay 1 1))
(s (propertize A string\nwith several rows\nat top\n
'face 'highlight)))
(overlay-put o 'before-string s)))
This buglet appears to be due to the following change:
2005-07-13 Kim F. Storm [EMAIL PROTECTED]
* xdisp.c (cursor_row_p): Row is ok if cursor is at newline
from string, but string starts on this line (so we always
position cursor at start of string).
The relevant code is at xdisp.c:15861:
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.
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row-end.string_pos) = 0)
cursor_row_p = (row-continued_p
|| PT = MATRIX_ROW_START_CHARPOS (row));
Changing this last line to `cursor_row_p = row-continued_p;', as it
was before, eliminates the bug. I haven't thought about how to fix
this, though.
FWIW, I wouldn't touch this so close to the release: if no one noticed
this since July 2005, it's hardly a grave bug.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 at point 1 with a
before-string property to do this... the cursor is displayed at the
end of the first line of the 'before-string.
[Modified test function]:
(defun foo ()
(interactive)
(let ((o (make-overlay 1 1))
(s (propertize A string\nwith several rows\nat top\n
'face 'highlight)))
(overlay-put o 'before-string s)))
This buglet appears to be due to the following change:
2005-07-13 Kim F. Storm [EMAIL PROTECTED]
* xdisp.c (cursor_row_p): Row is ok if cursor is at newline
from string, but string starts on this line (so we always
position cursor at start of string).
The relevant code is at xdisp.c:15861:
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.
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row-end.string_pos) = 0)
cursor_row_p = (row-continued_p
|| PT = MATRIX_ROW_START_CHARPOS (row));
Changing this last line to `cursor_row_p = row-continued_p;', as it
was before, eliminates the bug. I haven't thought about how to fix
this, though.
FWIW, I wouldn't touch this so close to the release: if no one noticed
this since July 2005, it's hardly a grave bug.
How do you know? This just looks so strange so it could well be a grave bug.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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.
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row-end.string_pos) = 0)
cursor_row_p = (row-continued_p
|| PT = MATRIX_ROW_START_CHARPOS (row));
Changing this last line to `cursor_row_p = row-continued_p;', as it
was before, eliminates the bug. I haven't thought about how to fix
this, though.
FWIW, I wouldn't touch this so close to the release: if no one noticed
this since July 2005, it's hardly a grave bug.
How do you know? This just looks so strange so it could well be a
grave bug.
Its only effect is that if a before-string spans multiple lines then
the cursor ends up being displayed on the end of the first line. It
does not have any further implications, such as crashing Emacs or
corrupting data.
As for whether or not to change the code, I guess it's up to KFS.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 this row.
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row-end.string_pos) = 0)
cursor_row_p = (row-continued_p
|| PT = MATRIX_ROW_START_CHARPOS (row));
Changing this last line to `cursor_row_p = row-continued_p;', as it
was before, eliminates the bug. I haven't thought about how to fix
this, though.
FWIW, I wouldn't touch this so close to the release: if no one noticed
this since July 2005, it's hardly a grave bug.
How do you know? This just looks so strange so it could well be a
grave bug.
Its only effect is that if a before-string spans multiple lines then
the cursor ends up being displayed on the end of the first line. It
does not have any further implications, such as crashing Emacs or
corrupting data.
If that is the case then it is perhaps also easy and not dangerous to
fix it?
As for whether or not to change the code, I guess it's up to KFS.
Yes, I looked at the code but decided it takes me too long time at the
moment. Kim, is this easy for you?
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 problem with it. IMO, this is not the time to try to fix that. -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 someone finds a problem with it. IMO, this is not the time to try to fix that. Maybe not, but is not this more about positioning the cursor? The characters are displayed correctly. Moving to char = 2 works correctly. But moving to char = 1 fails. Looks like it could be a corner case to me, ie something that perhaps could be fixed without general impact. BTW I wonder if I did not complain about this two years ago too? But at that time I worked against a different solution since I wanted to get something that worked then. This time I think I need this change to get things working. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 one bug ... and two years later someone finds a problem with it. IMO, this is not the time to try to fix that. Maybe not, but is not this more about positioning the cursor? The characters are displayed correctly. Moving to char = 2 works correctly. But moving to char = 1 fails. Looks like it could be a corner case to me, ie something that perhaps could be fixed without general impact. BTW I wonder if I did not complain about this two years ago too? But at that time I worked against a different solution since I wanted to get something that worked then. This time I think I need this change to get things working. 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. I therefore compared using 'before-string with using (put-text-property 1 (point) 'intangible t) The cursor moves quite differently in those cases. Is there an intangible property missing internally on line endings in 'before-string? (A wild guess of course, but the best I can do at the moment.) BTW I also noticed that using 'before-string like I did here also influences undo intervals. Quite strange. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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. That is not the display code. Looking at the code Chong mentioned instead. BTW I also noticed that using 'before-string like I did here also influences undo intervals. Quite strange. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
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 this row.
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row-end.string_pos) = 0)
cursor_row_p = (row-continued_p
|| PT = MATRIX_ROW_START_CHARPOS (row));
Changing this last line to `cursor_row_p = row-continued_p;', as it
was before, eliminates the bug. I haven't thought about how to fix
this, though.
FWIW, I wouldn't touch this so close to the release: if no one noticed
this since July 2005, it's hardly a grave bug.
How do you know? This just looks so strange so it could well be a
grave bug.
Its only effect is that if a before-string spans multiple lines then
the cursor ends up being displayed on the end of the first line. It
does not have any further implications, such as crashing Emacs or
corrupting data.
As for whether or not to change the code, I guess it's up to KFS.
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?
Index: xdisp.c
===
RCS file: /cvsroot/emacs/emacs/src/xdisp.c,v
retrieving revision 1.1146
diff -c -r1.1146 xdisp.c
*** xdisp.c 10 Apr 2007 15:57:25 - 1.1146
--- xdisp.c 12 Apr 2007 00:40:36 -
***
*** 15859,15865
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row-end.string_pos) = 0)
cursor_row_p = (row-continued_p
! || PT = MATRIX_ROW_START_CHARPOS (row));
else if (MATRIX_ROW_ENDS_IN_MIDDLE_OF_CHAR_P (row))
{
/* If the row ends in middle of a real character,
--- 15859,15865
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row-end.string_pos) = 0)
cursor_row_p = (row-continued_p
! || PT MATRIX_ROW_START_CHARPOS (++row));
else if (MATRIX_ROW_ENDS_IN_MIDDLE_OF_CHAR_P (row))
{
/* If the row ends in middle of a real character,
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
