emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: as the accident occued... long lines in emacs buffers.


From: alin
Subject: Re: as the accident occued... long lines in emacs buffers.
Date: Fri, 13 Nov 2015 21:01:26 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: David Kastrup <address@hidden>
>> Date: Fri, 13 Nov 2015 17:40:02 +0100
>> Cc: John Wiegley <address@hidden>, Brandon Invergo <address@hidden>,
>>      address@hidden
>> 
>> > I'll settle for "as fast as one would expect given its behavior on short
>> > lines".
>> 
>> Though purportedly this should have been somewhat addressed by
>> 
>> cache-long-scans is a variable defined in ‘C source code’.
>> Its value is t
>
> No, this variable is unrelated.  It only helps when Emacs looks for a
> newline.  By contrast, redisplay slowness with long lines has almost
> nothing to do with searching a buffer for newlines, its main cause is
> that to move to the next visual line the display engine must
> completely traverse the current line.

Anyway.  Emacs does not work well.  This is a fact that I see many times
when I open shell-processes.

I have the full plan in my mind to execute it.  And all the needed
experience and background.

I cannot work alone.  I need somebody to discuss with him/her and help
me read what I am doing and what's next step.  As this is a a complex
problem and I do not want to lose the time working.  This would be
painful to think to.

I think I will be available to do this in the months
Mars-Avr-May-June-July-Au. If somebody around Paris want to involve in
this, please answer me in the mean time.

If not, I will be available for this task after July 2018 or sporadic.
I think it will take 7-8 week-ends to execute it.  It will be lot of
work.





Alin.



-- 
No GNUs is bad news.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]