Jason Rumney | 1 Jan 02:20 2009
Picon

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.

Jason Rumney | 1 Jan 02:23 2009
Picon

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?

Lennart Borgman | 1 Jan 03:45 2009
Picon

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)))))

Jason Rumney | 1 Jan 03:55 2009
Picon

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.

Lennart Borgman | 1 Jan 03:57 2009
Picon

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. ;-)

anhnmncb | 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)

Chong Yidong | 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?

Juanma Barranquero | 1 Jan 05:38 2009
Picon

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)

Drew Adams | 1 Jan 06:44 2009
Picon

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)

Stephen J. Turnbull | 1 Jan 09:33 2009
Picon

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