mark perl-indent-level and cperl-indent-level as safe ?
I have run into some code that was setting perl-indent-level and cperl-indent-level as local variables. Should I mark them as safe? Other modes do the same for similar variables. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mark perl-indent-level and cperl-indent-level as safe ?
I have run into some code that was setting perl-indent-level and cperl-indent-level as local variables. Should I mark them as safe? Other modes do the same for similar variables. Yes, please, 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
Oh, good, I am delaying the Unicode release! I did not think of that. Sorry, I could not really resist. I can understand your frustration, Your replies show that you don't even begin to understand. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
On 4/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: Then what arguments are actually convincing to you? At this point in time, just days short of the intented release? Either the bug crashes Emacs, or it does cause trouble for some really major package, or it is very common and/or confusing for many users. If you just want to say that you do not want that change to be made now that is also ok. Is not that I don't want, and what I want is largely irrelevant. Is that IMO you have not justified it enough in the urgency scale, release-wise. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
Eli Zaretskii wrote: Date: Mon, 16 Apr 2007 03:14:13 +0200 From: Lennart Borgman (gmail) [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org Then what arguments are actually convincing to you? Did you ever managed release of some software product, Lennart? Because if you didn't, then there's really no way we could convince you, since you lack a significant experience of having to decide what needs to be fixed before the release and what's after it. Of course experience is good. Did I ever say something else? Or why did you say the above? I know that both Kim and Chong hesitate to do the changes now. My argument is not that I do not trust them. I try to look at the actual changes and estimate the chances that it can go wrong. This estimation on the one hand, and the estimated seriousness of the bug on the other, is the fundamental issue. We are getting closer to a serious discussion, thanks. If you cannot see how the former is much larger than the latter, then we have no real basis for a reasonable discussion. And now you are leaving it again. That's because everyone else but you look at this issue at a fundamentally different level. You look at the details, but no amount of details will ever lead you to the bigger picture--that we need to release soon, and that Emacs is ready for that. And now you have left it totally. Instead of asking me you say that I am thinking in a certain way. If you discuss that way you will always win a discussion. If you please separate my opinion from my arguments it will be much nicer. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
On 4/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: We are getting closer to a serious discussion, thanks. Because you're the arbiter of when a discussion is serious enough? Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
Juanma Barranquero wrote: On 4/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: We are getting closer to a serious discussion, thanks. Because you're the arbiter of when a discussion is serious enough? Yes, I do have an opinion about that. Disrespect is not one of the things I respect. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
On 4/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: Yes, I do have an opinion about that. Disrespect is not one of the things I respect. Disrespect is often in the eye of the beholder. I certainly have no trouble detecting disrespect in some of your messages, but I'm sure you'll disagree. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
Juanma Barranquero wrote: On 4/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: Yes, I do have an opinion about that. Disrespect is not one of the things I respect. Disrespect is often in the eye of the beholder. I certainly have no trouble detecting disrespect in some of your messages, but I'm sure you'll disagree. It has not been my intent. I do get a bit upset by some type of answers and you are right, it is then in the eye of the beholder. I can understand if Eli feel a bit hurt. He took long time to write a long answer and I just pointed to some a little bit weaker points in the answer. So, Eli, there I missed your point and I apologize for that. I try to have respect for that more economic reasoning that you are using, but I often fail there. (On the other hand I often try to tell people that I learned one thing from that kind of reasoning and that is that you sometimes have to take a decision without having all the knowledge of the details that you wish you had.) And I often prefer to keep my own opinion even under strong pressure. It is unusual, but it is not out of disrespect. Though those things are close in a way it is still possible to distinguish them. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
Lennart Borgman (gmail) [EMAIL PROTECTED] writes: It has not been my intent. I do get a bit upset by some type of answers and you are right, it is then in the eye of the beholder. I can understand if Eli feel a bit hurt. He took long time to write a long answer and I just pointed to some a little bit weaker points in the answer. IMO, there are _no weak points_ in Eli's message. In one sentence: All software have bugs, so to ever make a release, someone must decide when enough is enough. Sadly RMS does not see it that way either ... so we'll probably never see a release, no matter how close we get to one (unless of course, people stop reporting bugs in the pretests, even when they find one). I try to have respect for that more economic reasoning that you are using, Eli talked about management - not economics. -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
On 4/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: I try to have respect for that more economic reasoning that you are using, but I often fail there. Economic reasoning is a good way to see it. Your defense of fixing the bug doesn't seem very convincing, on an (informal, I'm no economist) cost-benefit analysis :) And I often prefer to keep my own opinion even under strong pressure. It is unusual, but it is not out of disrespect. I was not offended, but saying to your opponent I suggested reading my arguments is not keep[ing your] own opinion, for example. I point it out merely to show that it is easy to cross the line without being aware. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
Richard Stallman [EMAIL PROTECTED] writes: Does drawing cursor in the wrong position on multi-line before-strings cause real trouble? Yes. Whenever the cursor is in the wrong position, that is real trouble. Is the display of multi-line before-strings an important feature? before-strings is an important feature. It is true that multi-line before-strings are not often used. But we should make such a feature work correctly in all cases, not just most cases. Chong, I suggest you install the patch (the one you feel most comfortable about), make a new pretest, and let's get on with the release. -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
[EMAIL PROTECTED] (Kim F. Storm) writes: Lennart Borgman (gmail) [EMAIL PROTECTED] writes: It has not been my intent. I do get a bit upset by some type of answers and you are right, it is then in the eye of the beholder. I can understand if Eli feel a bit hurt. He took long time to write a long answer and I just pointed to some a little bit weaker points in the answer. IMO, there are _no weak points_ in Eli's message. In one sentence: All software have bugs, so to ever make a release, someone must decide when enough is enough. Sadly RMS does not see it that way either ... so we'll probably never see a release, no matter how close we get to one (unless of course, people stop reporting bugs in the pretests, even when they find one). I will not be surprised at all if we will see after the release a flood of problem reports currently held back by a large release pain threshold. -- David Kastrup ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
David Kastrup wrote: I will not be surprised at all if we will see after the release a flood of problem reports currently held back by a large release pain threshold. Uhm. At least I have tried to avoid reporting some bugs now just because it seems useless. We all want a release I guess. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
Juanma Barranquero wrote: I was not offended, but saying to your opponent I suggested reading my arguments is not keep[ing your] own opinion, for example. I point it out merely to show that it is easy to cross the line without being aware. Oh, yes it is easy. And I know you have told me about this one before, but in some situations it is easy to forget. The only way avoiding this is probably beeing very carefully when one is commenting on the opponents view. Perhaps it works in this kind of communication to clearly state that my view of your arguments is At least that is often a way forward in face-to-face communication. Though one have to say it with an querying voice. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
On 4/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: At least that is often a way forward in face-to-face communication. Though one have to say it with an querying voice. Couldn't help but remember this quote from the Subversion developers' list. Several guys were talking about the right way to pronounce Subversion, and one said: The difference in pronunciation is extremely subtle, and I applaud your effort in attempting this via email. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
[EMAIL PROTECTED] (Kim F. Storm) writes: Richard Stallman [EMAIL PROTECTED] writes: Does drawing cursor in the wrong position on multi-line before-strings cause real trouble? Yes. Whenever the cursor is in the wrong position, that is real trouble. Is the display of multi-line before-strings an important feature? before-strings is an important feature. It is true that multi-line before-strings are not often used. But we should make such a feature work correctly in all cases, not just most cases. Chong, I suggest you install the patch (the one you feel most comfortable about), make a new pretest, and let's get on with the release. I did that. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mark perl-indent-level and cperl-indent-level as safe ?
I have run into some code that was setting perl-indent-level and cperl-indent-level as local variables. Should I mark them as safe? Please mark them as safe for numeric values. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mark perl-indent-level and cperl-indent-level as safe ?
Richard Stallman [EMAIL PROTECTED] writes: I have run into some code that was setting perl-indent-level and cperl-indent-level as local variables. Should I mark them as safe? Please mark them as safe for numeric values. Done. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display margin errors on a tty
Richard Stallman [EMAIL PROTECTED] writes: It forces a glyph matrix reallocation after each call to enlarge_window. The slowdown will be undetectable since redisplay is so fast on text terminals anyway. I think this is a good solution, if it works. It is simple, and it is safe. And the slowdown is insignificant compared with everything else that is going on when you change window sizes. However, KFS wrote No, the problem seems to come up as long as there is a window with a marginal area in use. Does that mean your fix doesn't actually solve the problem? It papers over it. An optimization in dispnew.c gets screwed up when display margins are present for terminal display. I just checked in a patch that basically disables the optimization when we are in that situation. So it's not *really* solving the problem. But it's a lot safer, and AFAICT it completely prevents the problem from appearing. So we can probably live with it for now. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
Date: Mon, 16 Apr 2007 09:57:44 +0200 From: Juanma Barranquero [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org On 4/16/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: Then what arguments are actually convincing to you? At this point in time, just days short of the intented release? Either the bug crashes Emacs, or it does cause trouble for some really major package, or it is very common and/or confusing for many users. And such bugs are almost unthinkable at this stage, given the long pretest -- unless, that is, they were caused by unsafe changes we did very recently, on one of the occasions we failed to exercise will power and resist the temptation of fixing ``one more bug''. But let me turn the table around, Lennart, and ask you: what arguments will actually convince _you_ to change your mind on this? Following Karl Popper, if your answer is ``nothing will change my mind'', then this is a religious type of argument that we should just stop, because it has no hope of any agreement whatsoever. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
Date: Mon, 16 Apr 2007 10:38:14 +0200 From: Lennart Borgman (gmail) [EMAIL PROTECTED] CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org Eli Zaretskii wrote: Date: Mon, 16 Apr 2007 03:14:13 +0200 From: Lennart Borgman (gmail) [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org Then what arguments are actually convincing to you? Did you ever managed release of some software product, Lennart? Because if you didn't, then there's really no way we could convince you, since you lack a significant experience of having to decide what needs to be fixed before the release and what's after it. Of course experience is good. Did I ever say something else? Or why did you say the above? I said that in the hope that you will respect our experience and the grey hair that came with it. If you please separate my opinion from my arguments it will be much nicer. It is fundamentally human to interpret the arguments to understand the opinions of your opponent, and then try to deal with those opinions. I don't know how to discuss an issue without trying to understand what you think. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
Eli Zaretskii wrote: Then what arguments are actually convincing to you? At this point in time, just days short of the intented release? Either the bug crashes Emacs, or it does cause trouble for some really major package, or it is very common and/or confusing for many users. And such bugs are almost unthinkable at this stage, given the long pretest -- unless, that is, they were caused by unsafe changes we did very recently, on one of the occasions we failed to exercise will power and resist the temptation of fixing ``one more bug''. But let me turn the table around, Lennart, and ask you: what arguments will actually convince _you_ to change your mind on this? Following Karl Popper, if your answer is ``nothing will change my mind'', then this is a religious type of argument that we should just stop, because it has no hope of any agreement whatsoever. That is a good question. I am of course also worried about stability. We can unfortunately not only use logical thinking, the problem is too complex for that. So we are arguing about how to look upon the different arguments. I agree that a managerial/economical view is good to use as a tool for deciding. And there must be a decision at the end. Just fixing the bug is not enough for this kind of bug. My guess is that so far we do not differ very much, or? A note: What makes me a bit upset is more that I get the feeling that you think the bug is unimportant though I have said that I do have a real use case where it will show up. Note that I do not say that you actually think so, it is perhaps more my feelings. Anyway those feelings are noticeable in my replies. This is part of the difficulties with arguing now. Probably I disturb you in a similar manner. I think that from both sides this is unintentional, but it is worth noting when we try to solve this. I have tried to explain in similar situations before that I always try to look at the problem at different levels. When you ask for what arguments will convince me this is key. If you want to convince me the best you can do is try to argument on all the different levels of the problem. Maybe you think that you have done so by referring to the experts on this code for their opinion? The difficulty I have with this is that the actual arguments on the details gets hidden. I can not argue at all then since I am trying to estimate the stability by looking at the details. That said I must point out that I can not say anything for sure about the stability. I give my arguments, hope for feedback from the experts. The may very well kill my arguments, no problems, but I do have some arguments that I think may be worth listening too. I feel very much better if the arguments are killed than if they are never looked upon. (This is kind of human I think.) Killed by some sound logic of course. I have tried to list my argumenting below (except the one above). If you want to you can comment on it. I do not know if it matters now, but to frame the situation I think we can state something like this: - We all want a release. I think we may feel a little bit weary. - There is/was a bug in cursor positionining that affects multiline 'before-string, 'after-string or 'display properties in characters or overlays. - This bug is perhaps not seen very often. - I have however a use case were it will be seen. - A bug in cursor positioning is confusing and can lead a user to suspect that something is terribly wrong (and indeed that is often a plausible thinking when the cursor is in the wrong position). I have got a milder reaction of this kind - the user thought something was wrong in my code, not in Emacs. - The display code is complex, very complex. - There is/was a bug now, which may indicate that it is fragile too (in the sense that one should be very careful and thoughtful when changing it). - We see some consequences of this bug, but there may be more, even instability. - We have not seen any instability for 2 years however with the bug. - As far as I remember we did not see any instability either with the old bug (for how many years? 1-2?) that unfortunately was cured in such a way that it created this new bug. - The fix (that Chong installed a version of) is in a sense a middle way between the two bugs above. This does not prove it does not cause instability, but it may be seen as an indication (which I prefer to see it as). - The fix is rather local and as far as I can see it only affects multi-line 'before-string, 'after-string and 'display. That makes my worries for stability less. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
Eli Zaretskii wrote: Date: Mon, 16 Apr 2007 10:38:14 +0200 From: Lennart Borgman (gmail) [EMAIL PROTECTED] CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org Eli Zaretskii wrote: Date: Mon, 16 Apr 2007 03:14:13 +0200 From: Lennart Borgman (gmail) [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org Then what arguments are actually convincing to you? Did you ever managed release of some software product, Lennart? Because if you didn't, then there's really no way we could convince you, since you lack a significant experience of having to decide what needs to be fixed before the release and what's after it. Of course experience is good. Did I ever say something else? Or why did you say the above? I said that in the hope that you will respect our experience and the grey hair that came with it. Ah, I always learned that grey hair was caused by children. If you please separate my opinion from my arguments it will be much nicer. It is fundamentally human to interpret the arguments to understand the opinions of your opponent, and then try to deal with those opinions. I don't know how to discuss an issue without trying to understand what you think. Yes, but since we differ please be careful. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display margin errors on a tty
It papers over it. An optimization in dispnew.c gets screwed up when display margins are present for terminal display. I just checked in a patch that basically disables the optimization when we are in that situation. So it's not *really* solving the problem. But it's a lot safer, and AFAICT it completely prevents the problem from appearing. So we can probably live with it for now. It looks good to me. Thanks. -- 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
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
expand-file-name leaves /../ in expansions at times
I have no idea if this is a bug or not, but sometimes `expand-file-name' returns a path with /../ at the beginning of it. Below are a few simple examples. It looks like it might have to do with whether there is an even or odd number of ../ - with an odd amount it seems to return the correct path, but not with even numbers - and it does the opposite when there's a / at the beginning of the path to expand. (expand-file-name ../home/ /) /../home/ (expand-file-name /../home/ /usr/) /../home/ (expand-file-name /../../home/ /usr/) /home/ (expand-file-name ../../../../../home/ /usr/) /home/ (expand-file-name ../../../../../../home/ /usr/) /../home/ (expand-file-name /home/../../../usr/ /usr/) /usr/ (expand-file-name /home/../../usr/ /usr/) /../usr/ (expand-file-name /home/../..//../../usr/ /usr/) /../usr/ (expand-file-name /home/..//../../usr/ /usr/) /usr/ In GNU Emacs 22.0.97.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2007-04-14 on spargel Windowing system distributor `The XFree86 Project, Inc', version 11.0.4030 configured using `configure '--prefix=/usr/local/emacs-cvs/2007-04-14' '--program-suffix=-cvs'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.ISO_8859-1 locale-coding-system: iso-8859-1 default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: left left left left left left left C-j C-e return return ( e x escape / escape / SPC / h o m e / backspace backspace backspace backspace backspace . . / h o m e / S-SPC / u s r / ) C-j up up C-e left left left left left left left left left left left left left left left left left left h o m e / right right right C-d C-d C-d C-d u s r C-e C-j up up C-e left left left left left left left left left left left left left left . . / C-e C-j up up up up up up up up up C-e left left left left left left left left left left left left left left left left left left left left left left left left left left left left left left / C-e C-j up up right right right right right right right right right right right right right right right right right right right C-d down down down down down down down down down right right right right right right right right right right right right right left . . / C-e C-j up up C-SPC C-e M-w down down S-insert left left left left left left left left left left left left left left left left left C-d C-d C-e left left left left left left left left left left left left left left C-e C-j up up right right right right right right right right right right right right right right right right right right right right right right right right right right right right right right right right left C-d C-e C-j escape x r e o p tab backspace backspace p o tab r tab return Recent messages: (emacs-cvs -Q) For information about the GNU Project and its goals, type C-h C-p. Mark set [2 times] Loading dabbrev...done Mark set [2 times] Making completion list... Loading help-mode...done Loading emacsbug... Loading regexp-opt...done Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: expand-file-name leaves /../ in expansions at times
Diane Murray [EMAIL PROTECTED] writes: I have no idea if this is a bug or not, but sometimes `expand-file-name' returns a path with /../ at the beginning of it. Below are a few simple examples. C-h f expand-file-name RET expand-file-name is a built-in function in `C source code'. (expand-file-name name optional default-directory) Convert filename name to absolute, and canonicalize it. Second arg default-directory is directory to start with if name is relative (does not start with slash); if default-directory is nil or missing, the current buffer's value of `default-directory' is used. All your examples are consistent with this behavior. The important thing is that DEFAULT-DIRECTORY is only consulted if the filename is relative. Also, note that (/../ == /). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: C-u C-SPC: doc string and behavior if mark = point
Split the run-on sentence that starts With no prefix at ; also. That was not a run-on sentence. A semicolon is the correct way to join two independent clauses in one sentence. A run-on sentence is what results from using a comma for this. ___ 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: C-u C-SPC: doc string and behavior if mark = point
Split the run-on sentence that starts With no prefix at ; also. That was not a run-on sentence. A semicolon is the correct way to join two independent clauses in one sentence. A run-on sentence is what results from using a comma for this. 1. It was just a suggestion. 2. I should have said long sentence, not run-on sentence. It's a judgment call whether a sentence should be split for readability. 3. A run-on sentence results from joining independent clauses (or sentences) without using any punctuation for the join. 4. Independent clauses joined using a comma, and without a conjunction, form a comma splice, not a run-on sentence. A semicolon should be used to join independent clauses (as you indicated), or the sentence should be split. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
