[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problem report #61
From: |
Stuart D. Herring |
Subject: |
Re: Problem report #61 |
Date: |
Wed, 12 Apr 2006 10:41:40 -0700 (PDT) |
User-agent: |
SquirrelMail/1.4.3a-11.EL3 |
> > 1870 if (current_buffer == prev_buffer
> > 1871 && last_point_position != PT
> > 1872 && NILP (Vdisable_point_adjustment)
> > 1873 && NILP (Vglobal_disable_point_adjustment)
> > 1874 && !already_adjusted)
> >
> > Event uninit_use: Using uninitialized value "prev_modiff"
> > Also see events: [var_decl]
> >
> > 1875 adjust_point_for_property (last_point_position, MODIFF
> !=
> > prev_modiff);
> > 1876
>
> This can only happen if last_point_position at entry to command_loop_1
> isn't equal to (point) at this point (ha) and read_key_sequence
> returns -1
> the first time through the loop (before already_adjusted is set).
> Maybe
> some nasty filter or timer could cause this? If so, should probably
> start
> with already_adjusted set to 1 so as to avoid random extra adjusts.
> If
> not, no bug.
>
> I think this cannot really fail, because if prev_modiff has not been set,
> then prev_buffer hasn't been set either, which means it is NULL,
> which means it does not equal current_buffer.
>
> But it is easy enough to initialize prev_modiff. I will.
That isn't the whole problem; already_adjusted is also uninitialized if
that code path is taken. However, prev_buffer is always NULL if the first
call to read_key_sequence returns -1 (which is the only way for either of
these variables to be uninitialized), so there's no bug at all. I didn't
catch that on the first reading; thanks.
Davis
--
This product is sold by volume, not by mass. If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.