Richard Stallman <[EMAIL PROTECTED]> writes:
> Maybe this would work ?
>
> (if (input-pending-p)
> (forward-line 1)
> (vertical-motion 1))
>
> It is incorrect for a cursor motion function to depend on whether
> input is pending.
Agreed. I think it would be reas
1995-03-09 Richard Stallman <[EMAIL PROTECTED]>
* simple.el (line-move-ignore-invisible): New variable.
(line-move): If that var is set, use vertical-motion.
Skip any extra invis chars beyond where vertical-motion stops.
So it seems like you o
The last time I looked, this thread was about Emacs not being fast
enough to update the display.
It was about typing C-u 2500 C-n. Anyway, I think I have
more or less fixed the problem with my last change to
line-move-1.
___
Emacs-devel mailin
Maybe this would work ?
(if (input-pending-p)
(forward-line 1)
(vertical-motion 1))
It is incorrect for a cursor motion function to depend on whether
input is pending.
___
Emacs-devel mailing list
Emacs-devel@g
"Eli Zaretskii" <[EMAIL PROTECTED]> writes:
> Maybe it was, I just am not sure. Richard said "C-n is very slow"
> and gave an example of invoking C-n with a large numeric argument.
> The example would cause only one redisplay: at the end of movement,
> regardless of the rate input is coming in.
> And I was trying to say that AFAIK currently there's no reliable way
> of deferring fontifications until just before the screen is redrawn.
> What you suggest will perhaps work in the single example given by
> Richard (and even then it requires some changes in the C code),
Maybe this would work
"Eli Zaretskii" <[EMAIL PROTECTED]> writes:
>> From: [EMAIL PROTECTED] (Kim F. Storm)
>> Date: Wed, 27 Apr 2005 10:59:39 +0200
>> Cc: [EMAIL PROTECTED], emacs-devel@gnu.org
>>
>> The code has used vertical-motion since CVS revision 1.1 (Dec. 1991),
>> and I don't see anything relevant in the olde
> Cc: emacs-devel@gnu.org
> From: David Kastrup <[EMAIL PROTECTED]>
> Date: Wed, 27 Apr 2005 13:32:11 +0200
>
> >> We are talking about the situation where the input is coming in faster
> >> than Emacs can process it.
> >
> > See, we don't really know that. Whether this is true or not,
> > depend
"Eli Zaretskii" <[EMAIL PROTECTED]> writes:
>> Cc: emacs-devel@gnu.org
>> From: David Kastrup <[EMAIL PROTECTED]>
>> Date: Wed, 27 Apr 2005 11:43:01 +0200
>>
>> We are talking about the situation where the input is coming in faster
>> than Emacs can process it.
>
> See, we don't really know that.
> Cc: emacs-devel@gnu.org
> From: David Kastrup <[EMAIL PROTECTED]>
> Date: Wed, 27 Apr 2005 11:43:01 +0200
>
> We are talking about the situation where the input is coming in faster
> than Emacs can process it.
See, we don't really know that. Whether this is true or not, depends
on several unkn
> From: [EMAIL PROTECTED] (Kim F. Storm)
> Date: Wed, 27 Apr 2005 10:59:39 +0200
> Cc: [EMAIL PROTECTED], emacs-devel@gnu.org
>
> The code has used vertical-motion since CVS revision 1.1 (Dec. 1991),
> and I don't see anything relevant in the older ChangeLogs, so who knows?
"cvs annotate" tells m
"Eli Zaretskii" <[EMAIL PROTECTED]> writes:
>> Cc: emacs-devel@gnu.org
>> From: David Kastrup <[EMAIL PROTECTED]>
>> Date: Wed, 27 Apr 2005 00:57:05 +0200
>>
>> Without looking at the code, it would be my guess that it would
>> currently run immediately after redisplay, whereas my suggestion for
> From: Richard Stallman <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED], emacs-devel@gnu.org
> Date: Tue, 26 Apr 2005 18:56:25 -0400
>
> One way to do that is to set jit-lock-defer-time.
>
> Are you suggesting this as a change in the defaults?
> I'm not interested in this as a workaround for me
> Cc: emacs-devel@gnu.org
> From: David Kastrup <[EMAIL PROTECTED]>
> Date: Wed, 27 Apr 2005 00:57:05 +0200
>
> Without looking at the code, it would be my guess that it would
> currently run immediately after redisplay, whereas my suggestion for
> jit-lock-defer-time=0 semantics would be that it
Richard Stallman <[EMAIL PROTECTED]> writes:
> I found a way to change line-move-1 not to use vertical-motion
> in simple cases. I think it should work, but I don't understand
> the reason why the code uses vertical-motion.
>
> Can anyone add a comment to explain why?
The code has used vertical-
"Eli Zaretskii" <[EMAIL PROTECTED]> writes:
>> Cc: [EMAIL PROTECTED], emacs-devel@gnu.org
>> From: David Kastrup <[EMAIL PROTECTED]>
>> Date: Tue, 26 Apr 2005 23:38:11 +0200
>>
>> > I think jit-lock-defer-time _is_ the way to avoid the slowness if
>> > you are willing to see the text unfontified
So for its correct behavior, it is mandatory to do the font locking.
The only exception to that would be if the user would have specified
that it is ok to work with unfontified text.
You are right. I will change it back.
One way to do that is to set jit-lock-defer-time.
Are you
> Cc: [EMAIL PROTECTED], emacs-devel@gnu.org
> From: David Kastrup <[EMAIL PROTECTED]>
> Date: Tue, 26 Apr 2005 23:38:11 +0200
>
> > I think jit-lock-defer-time _is_ the way to avoid the slowness if
> > you are willing to see the text unfontified for a fraction of a
> > second.
>
> I think that a
"Eli Zaretskii" <[EMAIL PROTECTED]> writes:
>> From: Richard Stallman <[EMAIL PROTECTED]>
>> CC: emacs-devel@gnu.org
>> Date: Tue, 26 Apr 2005 06:05:41 -0400
>>
>> > It turns out that vertical-motion was fontifying all the text that
>> > it moved over. That seems to be easy to fix.
>>
>
> From: Richard Stallman <[EMAIL PROTECTED]>
> CC: emacs-devel@gnu.org
> Date: Tue, 26 Apr 2005 06:05:41 -0400
>
> > It turns out that vertical-motion was fontifying all the text that
> > it moved over. That seems to be easy to fix.
>
> Did you try my suggestion of customizing jit-lo
Richard Stallman <[EMAIL PROTECTED]> writes:
> > It turns out that vertical-motion was fontifying all the text that
> > it moved over. That seems to be easy to fix.
>
> Did you try my suggestion of customizing jit-lock-defer-time?
>
> No, because I want to fix this, not work around it
> It turns out that vertical-motion was fontifying all the text that
> it moved over. That seems to be easy to fix.
Did you try my suggestion of customizing jit-lock-defer-time?
No, because I want to fix this, not work around it. vertical-motion
is a cursor motion function. It shou
> From: Richard Stallman <[EMAIL PROTECTED]>
> CC: emacs-devel@gnu.org
> Date: Sun, 24 Apr 2005 17:23:07 -0400
>
> It turns out that vertical-motion was fontifying all the text that
> it moved over. That seems to be easy to fix.
Did you try my suggestion of customizing jit-lock-defer-time? I th
JIT lock is optimized for C-v and similar methods that page
by large chunks of text rather than by one line.
I am not sure what that means, in concrete terms of Lisp program
actions. I'm also not sure what you mean by "make text visible".
It turns out that vertical-motion was fontifyin
> From: Richard Stallman <[EMAIL PROTECTED]>
> Date: Sat, 23 Apr 2005 12:16:35 -0400
>
> With Font-Lock mode enabled, starting from the beginning of a large
> file (such as fileio.c), C-n with a large argument (I tried C-u 2536
> C-n) took many seconds. I think it was fontifying all the text
> th
With Font-Lock mode enabled, starting from the beginning of a large
file (such as fileio.c), C-n with a large argument (I tried C-u 2536
C-n) took many seconds. I think it was fontifying all the text
that it moved across.
Can this be avoided? I don't think C-n ought to need to fontify
all that t
26 matches
Mail list logo
