From: Eli Zaretskii <eliz@gnu.org>
To: David Engster <deng@randomsample.de>
Cc: 18856@debbugs.gnu.org
Subject: bug#18856: 24.4; *grep* output buffer not getting fontified when jit-lock-defer-time is used
Date: Tue, 28 Oct 2014 18:36:56 +0200 [thread overview]
Message-ID: <83fve82lsn.fsf@gnu.org> (raw)
In-Reply-To: <87a94h2tpf.fsf@engster.org>
> From: David Engster <deng@randomsample.de>
> Date: Mon, 27 Oct 2014 20:33:48 +0100
>
> Recipe:
>
> * emacs -Q
>
> * M-x set-variable RET jit-lock-defer-time RET 0.05 RET
>
> * Call M-x rgrep and search for some string in some directory
>
> You should be able to see that the *grep* buffer capturing grep's output
> is not getting fontified until you hit a key. I would expect that it
> gets fontified automatically when new output arrives.
First, my crystal ball says you omitted something from this recipe,
because if I strictly follow these steps, I cannot even see the
matches produced by Grep, because the shell command inserted by rgrep
into the *grep* buffer is longer than the visible portion of the
window displaying the buffer. Moreover, rgrep doesn't seem to obey
grep-scroll-output (which will soon be a separate bug report), so you
cannot see the output.
Nevertheless, the problem does exist. I used the following recipe to
reproduce it:
emacs -Q
M-x set-variable RET jit-lock-defer-time RET 0.05 RET
M-: (setq-default grep-scroll-output t) RET
M-x grep RET <type a suitable Grep command arguments here> RET
Here's what I saw while digging into this problem:
. It looks like the idleness state is not reset when we receive input
from a subprocess. At least, what I see is that
jit-lock-deferred-fontify is called only once, prior to any input
is received from Grep, and never called again, until you press a
key or send some other input event Emacs's way.
I can overcome this problem if I add a call to
internal-timer-start-idle at the end of compilation-handle-exit.
Not sure this is TRT, though. If not, what else?
. But even after the call to internal-timer-start-idle is made when
Grep exits, and jit-lock-deferred-fontify _is_ called, there's no
fontification. Why? because input-pending-p, called by sit-for,
returns non-nil, and we don't call redisplay. This happens to me
on MS-Windows in a GUI session only. If I put a breakpoint in
readable_events, here:
static bool
readable_events (int flags)
{
if (flags & READABLE_EVENTS_DO_TIMERS_NOW)
timer_check ();
/* If the buffer contains only FOCUS_IN_EVENT events, and
READABLE_EVENTS_FILTER_EVENTS is set, report it as empty. */
if (kbd_fetch_ptr != kbd_store_ptr)
{
if (flags & (READABLE_EVENTS_FILTER_EVENTS
#ifdef USE_TOOLKIT_SCROLL_BARS
| READABLE_EVENTS_IGNORE_SQUEEZABLES
#endif
))
{
struct input_event *event;
event = ((kbd_fetch_ptr < kbd_buffer + KBD_BUFFER_SIZE)
? kbd_fetch_ptr
: kbd_buffer);
do
{
if (!( <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
#ifdef USE_TOOLKIT_SCROLL_BARS
(flags & READABLE_EVENTS_FILTER_EVENTS) &&
#endif
event->kind == FOCUS_IN_EVENT)
#ifdef USE_TOOLKIT_SCROLL_BARS
&& !((flags & READABLE_EVENTS_IGNORE_SQUEEZABLES)
&& (event->kind == SCROLL_BAR_CLICK_EVENT
|| event->kind == HORIZONTAL_SCROLL_BAR_CLICK_EVENT)
&& event->part == scroll_bar_handle
&& event->modifiers == 0)
#endif
)
return 1;
event++;
then I see a single event, BUFFER_SWITCH_EVENT, being reported.
Should input-pending-p ignore such events?
Finally, if I disable blink-cursor-mode, the problem with
input-pending-p doesn't happen, and the only change that is needed to
fix this is a call to internal-timer-start-idle mentioned above.
next prev parent reply other threads:[~2014-10-28 16:36 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-27 19:33 bug#18856: 24.4; *grep* output buffer not getting fontified when jit-lock-defer-time is used David Engster
2014-10-28 16:36 ` Eli Zaretskii [this message]
2014-10-28 17:38 ` Stefan Monnier
2014-10-29 15:01 ` Eli Zaretskii
2014-10-29 22:23 ` Stefan Monnier
2014-11-01 14:24 ` Eli Zaretskii
2014-10-28 17:09 ` Stefan Monnier
2014-10-28 17:53 ` Eli Zaretskii
2014-10-28 19:01 ` Stefan Monnier
2014-10-28 19:26 ` Eli Zaretskii
2014-10-29 4:06 ` Stefan Monnier
2014-10-29 14:16 ` Eli Zaretskii
2014-10-29 22:16 ` Stefan Monnier
2014-10-30 3:39 ` Eli Zaretskii
2014-10-30 4:10 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83fve82lsn.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=18856@debbugs.gnu.org \
--cc=deng@randomsample.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.