> 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 shou
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 mailin
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.
___
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'.
(
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
pa
> 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 *befor
> 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 saf
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@
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 ar
> 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
> 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
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
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.
__
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:/
[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 di
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 r
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 a
David Kastrup wrote:
I will not be surprised at all if we will see after the release a
flood of problem reports currently held back by a large release pain
threshold.
Uhm. At least I have tried to avoid reporting some bugs now just because
it seems useless. We all want a release I guess.
_
[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 t
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
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
> "import
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
e
"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 so
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 messag
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 dis
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 re
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-pr
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 r
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 c
29 matches
Mail list logo
