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
> 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 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 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: 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: 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
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
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
> 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
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
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
> 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
> 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
[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
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
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
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
[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
On 4/16/07, Kim F. Storm <[EMAIL PROTECTED]> wrote: IMO, there are _no weak points_ in Eli's message. Agreed. 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). Now that's a good idea :) Eli talked about management - not economics. Management is also economics. The Wikipedia entry for "cost-benefit analysis" says: "a formal discipline used to help appraise, or assess, the case for a project or proposal, which itself is a process known as project appraisal" It sounds like project management to me. 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
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
"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
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
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: 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: 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
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: 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
> 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
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
> 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
> 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: 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
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
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: 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: 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
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
> 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: 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. We use Emacs differently. Is not that part of the fun? At least I have switched to Emacs for the reason that it is flexible and possible to do a lot of things in Emacs. The fun of avoiding having to learn a lot of new-soon-to-be-old things. In other words: I have seen this 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
> > 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
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
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
> 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
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
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 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
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
"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
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
Display problems with `before-string' in overlay
> I think redisplay bugs are serious bugs. As you say yourself, what someone _think_ is not a useful argument. That is true, but you are the one that has to convince me, not vice versa. 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. ___ 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. I tested this way, but everything just gets very weird after some of the "Lisp_Object q_display" lines have been executed. I guess I am breaking something very fundamental. Could someone of you explain what? 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. */ if (CHARPOS (row->end.string_pos) >= 0) { int start = row->start.pos.charpos; int end = row->end.pos.charpos; //Lisp_Object q_display = get_char_property_and_overlay (end, Qdisplay, Qnil, 0); Lisp_Object q_display = Fget_char_property (end, Qdisplay, Qnil); //fprintf (stderr, "> cursor_row_p.start=%d, end=%d, nil(q_display)=%d\n", start, end, NILP(q_display)); cursor_row_p = row->continued_p; } ___ 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
[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 lis
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
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) 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
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
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
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
> 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: > 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
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
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
Chong Yidong wrote: 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? Great. I will test this and I guess I do not have to say I want it now. I can of course not say I understand the code, but I will try to look at it anyway. BTW when I made a brief try to understand the code I noticed the text property Qcomposition. That is missing from (info "(elisp) Special Properties"). Should it not be there? Or is it something internal only? 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): *** *** 11933,11952 Lisp_Object string; struct glyph *stop = glyph; int pos; limit = make_number (pt_old + 1); glyph = string_start; x = string_start_x; string = glyph->object; ! 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; SKIP_GLYPHS (glyph, stop, x, EQ (glyph->object, string)); if (glyph < stop) ! pos = string_buffer_position (w, glyph->object, string_before_pos); } while (glyph < stop) --- 11934,11955 Lisp_Object string; struct glyph *stop = glyph; int pos; + Lisp_Object overlay = Qnil; limit = make_number (pt_old + 1); glyph = string_start; x = string_start_x; string = glyph->object; ! pos = string_buffer_position (w, string, string_before_pos, &overlay); ! /* If STRING is from overlay, skip its glyphs because we always !put cursor after overlay strings. */ ! while ((pos == 0 || !NILP (overlay)) && glyph < stop) { string = glyph->object; SKIP_GLYPHS (glyph, stop, x, EQ (glyph->object, string)); if (glyph < stop) ! pos = string_buffer_position (w, glyph->object, ! string_before_pos, &overlay); } while (glyph < stop) *** *** 15858,15869 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, --- 15861,15870 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-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))
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: > > 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
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
> 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
"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
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
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
"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
"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
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
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: http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd";> http://www.w3.org/1999/xhtml";> Dummy ___ 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
"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) 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
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
> 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 <[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
[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
> 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
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
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
[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
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
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
[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
"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
"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
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
> Date: Wed, 11 Apr 2007 22:48:34 +0200 > From: "Lennart Borgman (gmail)" <[EMAIL PROTECTED]> > CC: Chong Yidong <[EMAIL PROTECTED]>, emacs-pretest-bug@gnu.org, > [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! ___ 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
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
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
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)" <[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