Emacs manipulate files with long-lines very slowly.

Emacs manipulate files with long-lines very slowly.

[Hongyi Zhao]

[-- Attachment #1: Type: text/plain, Size: 841 bytes --]

Dear Kenichi,

Now, I've a tex source file which is written on Microsoft Windows.  When I
open it with Emacs on my Ubuntu Linux, because the linefeed is different between
Windows and Linux/Unix, so the file will have very long lines in it.  Even I
use the *M-q* and *truncate long line* command, I find the Emacs is always
manipulate the file too slowly to tolerate.

But I can open it with gedit and edit it very quickly, is there any tricks
to solve the problem or some bugs in Emacs?

Attached is my tex file.
 
-- 
Hongyi Zhao <hongyi.zhao@gmail.com>
赵弘毅
--

题目:《春日即事》
作者:吕本中（１０８４－１１４５）
病起多情白日迟，强来庭下探花期。
雪消池馆初春后，人倚栏杆欲暮时。
乱蝶狂蜂俱有意，兔葵燕麦自无知。
池边垂柳腰支活，折尽长条为寄谁？

[-- Attachment #2: lone-line.tex.bz2 --]
[-- Type: application/octet-stream, Size: 8480 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Emacs manipulate files with long-lines very slowly.

[Miles Bader]

Hongyi Zhao <hongyi.zhao@gmail.com> writes:
> But I can open it with gedit and edit it very quickly, is there any tricks
> to solve the problem or some bugs in Emacs?

Is that really a windows file?  The lines are (mostly) separated with CR
(^M), which as far as I know is _not_ the windows line separator, but in
fact the old macintosh line separator.  Emacs normally handles such
files well, but in this case, there seem to be a few lines which use
newline instead of CR, so emacs thinks it isn't a macintosh file either.

I'd suggest just forcing it to use a consistent convention.

Try the following:

   (1) visit the file
   (2) force newlines to be written using CR:  C-x C-m f mac RET
   (3) save the file:  C-x C-s
   (4) kill the buffer:  C-x C-k RET
   (5) revisit the changed file

-Miles

-- 
"I distrust a research person who is always obviously busy on a task."
   --Robert Frosch, VP, GM Research

Re: Emacs manipulate files with long-lines very slowly.

[Hongyi Zhao]

> I'd suggest just forcing it to use a consistent convention.
> 
> Try the following:
> 
>    (1) visit the file
>    (2) force newlines to be written using CR:  C-x C-m f mac RET

But I can't input the C-x C-m, when stroking C-x C-m, the minibuffer will say:

==========
C-x RET-
==========

>    (3) save the file:  C-x C-s
>    (4) kill the buffer:  C-x C-k RET
>    (5) revisit the changed file

-- 
Hongyi Zhao <hongyi.zhao@gmail.com>
赵弘毅
--

题目:《山园小梅》
作者:林逋（９６７－１０２８）
众芳摇落独暄妍，占尽风情向小园。
疏影横斜水清浅，暗香浮动月黄昏。
霜禽欲下先偷眼，粉蝶如知合断魂。
幸有微吟可相狎，不须檀板共金尊。

Re: Emacs manipulate files with long-lines very slowly.

[Miles Bader]

Hongyi Zhao <hongyi.zhao@gmail.com> writes:
>> Try the following:
>> 
>>    (1) visit the file
>>    (2) force newlines to be written using CR:  C-x C-m f mac RET
>
> But I can't input the C-x C-m, when stroking C-x C-m, the minibuffer will say:

Notice that C-x C-m is followed by "f" -- the full command is:  C-x C-m f

-Miles
-- 
Any man who is a triangle, has thee right, when in Cartesian Space, to
have angles, which when summed, come to know more, nor no less, than
nine score degrees, should he so wish.  [TEMPLE OV THEE LEMUR]

Re: Emacs manipulate files with long-lines very slowly.

[Hongyi Zhao]

> >>    (1) visit the file
> >>    (2) force newlines to be written using CR:  C-x C-m f mac RET
> >
> > But I can't input the C-x C-m, when stroking C-x C-m, the minibuffer will say:
> 
> Notice that C-x C-m is followed by "f" -- the full command is:  C-x C-m f

I see, but this command is equivalent C-x RET f on my Operating System.

I do the following to solve this problem:

   (1) visit the file
   (2) force newlines to be written using CR:  C-x RET f mac RET
   (3) save the file:  C-x C-s
   (4) kill the buffer:  C-x k RET

Please notice, not the command you told me: C-x C-k RET, because if I use
this command, I'll meet the following message:

===============
No keyboard macro defined.  Create one? (y or n)
===============	

   (5) revisit the changed file

Why should these differences are exist?

-- 
Hongyi Zhao <hongyi.zhao@gmail.com>
赵弘毅
--

题目:《暑中杂咏》
作者:苏舜钦（１００８－１０４８）
嘉果浮沉酒半醺，床头书册乱纷纷。
北轩凉吹开疏竹，卧看青天行白云。

Re: Emacs manipulate files with long-lines very slowly.

[Miles Bader]

Hongyi Zhao <hongyi.zhao@gmail.com> writes:
>> Notice that C-x C-m is followed by "f" -- the full command is:  C-x C-m f
>
> I see, but this command is equivalent C-x RET f on my Operating System.

Yes, C-m and RET are different names for the same key.  You can type
either C-m or RET and it means the same thing.

> Please notice, not the command you told me: C-x C-k RET, because if I use
> this command, I'll meet the following message:

That's a typo on my part -- I mean:  C-x k RET

-Miles
-- 
It wasn't the Exxon Valdez captain's driving that caused the Alaskan oil spill.
It was yours.  [Greenpeace advertisement, New York Times, 25 February 1990]

Re: Emacs manipulate files with long-lines very slowly.

[Kenichi Handa]

In article <20061208101001.GA9251@localdomain>, Hongyi Zhao <hongyi.zhao@gmail.com> writes:

> > I'd suggest just forcing it to use a consistent convention.
> > 
> > Try the following:
> > 
> >    (1) visit the file
> >    (2) force newlines to be written using CR:  C-x C-m f mac RET

> But I can't input the C-x C-m, when stroking C-x C-m, the minibuffer will say:

> ==========
> C-x RET-
> ==========

C-m is echoed as RET.  So just go a head by typing the next `f'.

---
Kenichi Handa
handa@m17n.org

Re: Emacs manipulate files with long-lines very slowly.

[Richard Stallman]

    Now, I've a tex source file which is written on Microsoft Windows.  When I
    open it with Emacs on my Ubuntu Linux, 

Please do not call our operating system "Linux".  Ubuntu is an example
of a GNU/Linux system, basically GNU with Linux added.  Calling it
"Linux" is denying us the credit for our work.

					   because the linefeed is different between
    Windows and Linux/Unix,

Emacs is supposed to recognize different end-of-line data automatically
and convert.  If that doesn't happen in your case, but sounds like a bug.

Since you provided a test case, we will be able to debug it.  Thanks.