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

[alin <as1789@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Fri, 13 Nov 2015 17:40:02 +0100
>> Cc: John Wiegley <jwiegley@gmail.com>, Brandon Invergo <brandon@invergo.net>,
>> 	emacs-devel@gnu.org
>> 
>> > 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.