1 Jan 02:20 2009

### Re: mode line eol char indication

```Drew Adams wrote:
> * The non-"nontrivial" eol convention, represented by `:', is
>   presumably what is meant by "usually", that is, a newline char.
>   But a newline eol is also sometimes represented by `(Unix)'.
>   Why?  And why is this called "nontrivial" - why is it more
>   nontrivial and more usual than the other possibilities?
>

In Emacs 20, only the single character indications were used, but people
found them confusing. But the full word indications are too long for
many people, so now we use the single character when the newline format
is native for the platform Emacs is running on, and the full word when
it is non-native - this change occurred in 21.1 IIRC. Unix line ends are
non-trivial because they are what Emacs uses internally - no conversion
is required. They are more usual for users of GNU based platforms
because GNU is based on unix conventions.

> Why `:'?  Why `\' (is there some relation to the DOS directory
> separator?)?  Why `/'?
>
.
Originally : was was based on the unix PATH separator, and \ on the DOS
directory separator. / was made the Mac indicator because like the DOS
separator, it is not straight up and down, but it leans a different
direction than DOS. I think at some point during 20.1 pretest, we had /
for Unix and : for Mac, until someone pointed out that : was less
noticeable, so that should indicate the trivial Unix line-end.

```
1 Jan 02:23 2009

### Re: Expand dir name with \ when on windows.

```anhnmncb wrote:
> On 2008-12-25, anhnmncb wrote:
>
>> Is there a varible that control the expanding behivior when on windows?
>> I find that *shell* sometimes does strange thing when cd dir with /, the
>> shell prompt is still the old dir, but actually I have changed to the new
>> dir. With \, no strange happens.
>>

Have you tried changing the value of comint-completion-addsuffix?

```
1 Jan 03:45 2009

### Change major mode for nxml-mode

```I have had this comment for long in nXhtml and nearly forgot about it.
Does someone know if this is fixed (in some way) now?

;; This should be run in `change-major-mode-hook'."
;; Should be part of nxml.el IMO
(defun nxml-change-mode ()
;; Remove overlays used by nxml-mode.
(save-excursion
(save-restriction
(widen)
(rng-validate-mode -1)
(let ((inhibit-read-only t)
(buffer-undo-list t)
(modified (buffer-modified-p)))
(nxml-with-invisible-motion
(remove-text-properties (point-min) (point-max) '(face nil)))
(set-buffer-modified-p modified)))))

```
1 Jan 03:55 2009

### Re: Change major mode for nxml-mode

```Lennart Borgman wrote:
> I have had this comment for long in nXhtml and nearly forgot about it.
> Does someone know if this is fixed (in some way) now?
>

2008-04-09  Lennart Borgman  <lennart.borgman <at> gmail.com>

* nxml/nxml-mode.el (nxml-cleanup): New function.
(nxml-mode): Add it to change-major-mode-hook.

```
1 Jan 03:57 2009

### Re: Change major mode for nxml-mode

```On Thu, Jan 1, 2009 at 3:55 AM, Jason Rumney <jasonr <at> gnu.org> wrote:
> Lennart Borgman wrote:
>>
>> I have had this comment for long in nXhtml and nearly forgot about it.
>> Does someone know if this is fixed (in some way) now?
>>
>
> 2008-04-09  Lennart Borgman  <lennart.borgman <at> gmail.com>
>
>   * nxml/nxml-mode.el (nxml-cleanup): New function.
>   (nxml-mode): Add it to change-major-mode-hook.

Ehum, thanks. Sorry.

Now I remember why I kept this function. For Emacs 22 users. Maybe I
will learn to put a note on such things.

```
1 Jan 04:36 2009

### Re: Expand dir name with \ when on windows.

```On 2009-01-01, Jason Rumney wrote:
> anhnmncb wrote:
>> On 2008-12-25, anhnmncb wrote:
>>
>>> Is there a varible that control the expanding behivior when on windows?
>>> I find that *shell* sometimes does strange thing when cd dir with /, the
>>> shell prompt is still the old dir, but actually I have changed to the new
>>> dir. With \, no strange happens.
>>>
>
> Have you tried changing the value of comint-completion-addsuffix?

I have tried (setq comint-completion-addsuffix '("\\" . " "))
Then

shell> cd ..\foo<tab>

you will find that emacs changes it to

shell> cd ../foo\

the result I want is

shell > cd ..\foo\.

--

--
Regards,
anhnmncb

```
(Continue reading)

1 Jan 04:47 2009

### Re: 23.0.60; end-of-sentence and non-breaking space

```From bug#1726 and bug#1727:

> forward-sentence does not treat non-breaking space as a space for
> purposes of sentence ends.
...
> When I type C-x = at a non-breaking space, it tells me that it
> has code 160, hex a0.  But when I execute (insert "\xa0"),
> it inserts something that displays as `\240' and for which C-x =
> displays this:
>
>    Char:   (4194208, #o17777640, #x3fffa0, raw-byte) point=198 of 211
>    (93%) column=5
>
> Is that a bug?  It seems quite confusing to me.

ISTR that there was an extended discussion about classifying
non-breaking spaces on this list a while back.  But I can't find it now.
Does anyone remember the details?

```
1 Jan 05:38 2009

### Re: Optimized gcc 4.3.0 build on Windows returns 0 secs for all time values of system-process-attributes

```On Wed, Dec 31, 2008 at 20:12, Eli Zaretskii <eliz <at> gnu.org> wrote:

> It works for me with GCC 3.4.2 and MinGW 3.14:

Optimized or unoptimized build?

> Could you please step into process_times and ltime (or add printf's if
> stepping doesn't work), and see what is going wrong and where?

Stepping isn't much helpful because most variables are optimized away.

As for printf, I'm not sure what's wrong, but

long double x = 3.5;
printf ("f = %Lf\n", x);
printf ("g = %Lg\n", x);

=>

f = -26815615859885194000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000.000000
g = -2.68156e+154

(Not just with gcc 4.3.0, I get the same result with 3.4.5.)

Am I missing something obvious?

I tried rewriting w32.c:process_time to do time computations by using
ULARGE_INTEGER (see attached patch), as the Platform SDK recommends,
and it works fine. Why it is implemented with long doubles?
```
(Continue reading)

1 Jan 06:44 2009

### RE: mode line eol char indication

```> > * The non-"nontrivial" eol convention, represented by `:', is
> >   presumably what is meant by "usually", that is, a newline char.
> >   But a newline eol is also sometimes represented by `(Unix)'.
> >   Why?  And why is this called "nontrivial" - why is it more
> >   nontrivial and more usual than the other possibilities?

I meant "trivial", sorry. The doc claims that line endings other than newline
are nontrivial.

> In Emacs 20, only the single character indications were used,
> but people found them confusing. But the full word indications
> are too long for many people, so now we use the single
> character when the newline format is native for the platform
> Emacs is running on, and the full word when it is non-native -
> this change occurred in 21.1 IIRC. Unix line ends are
> non-trivial

(I think you too meant "trivial" here, for UNIX.)

> because they are what Emacs uses internally - no conversion
> is required.

What's trivial for the implementation shouldn't be behind characterizing this
line ending to the user as more trivial. Why would a user care which is easier
to implement?

> They are more usual for users of GNU based platforms
> because GNU is based on unix conventions.

Yes, and less usual for users of other platforms. But who cares?
```
(Continue reading)

1 Jan 09:33 2009

### RE: mode line eol char indication

```Drew Adams writes:

> What's trivial for the implementation shouldn't be behind
> characterizing this line ending to the user as more trivial. Why
> would a user care which is easier to implement?

Because the trivial line endings never get screwed up.  Nontrivial
line endings cause no end of pain (eg, inappropriate conversion of
line endings causes 100% of the lines of a text file to differ from
its previous revision, and irrecoverable data corruption in binary
files (ie, where CR and LF have semantics other than "line ending").

> If we're trying to indicate the _line ending characters_, then lets just say
> what they are: C-j, C-m, or C-j C-m.

Those are commands.  Users almost *never* use those as self-inserting
characters.  ^J, LF, NL, \n, OK (my preference is LF), but not C-j,
please.

```

Gmane