BUG: indenting lisp code marks buffer as dirty when it shouldn't

BUG: indenting lisp code marks buffer as dirty when it shouldn't

[Karl Chen]

This bug exists in Emacs 21.2 as well as CVS HEAD 2002-11-23.

Synopsis:

  emacs -q

  C-space

  insert  "t ;; blah\n"          [ in scratch or any lisp buffer ]

  M-: (buffer-modified-tick)

  C-M-\                          [ or M-x indent-region ]

  M-: (buffer-modified-tick)


The buffer is not modified.  Thus the two `buffer-modified-tick's should
report the same value, but they don't. another way to test this is to save the
buffer before `indent-region', and see that `indent-region' makes the buffer
dirty, even though it ahsn't actually changed.

Emacs seems to be trying to move the ";;" to the same indentation level as
the rest of the code (which in this case would be the first column since
we're at top level), but there's text "blocking" it (the "t" in this case).

Pressing TAB on the "t ;; comment" line works fine (oesn't tick the buffer
modification).

Putting a double-semicolon comment after a line of code probably doesn't
follow GNU lisp coding style (I didn't write this myself anyway), but taht
shouldn't cause incorrect behavior when trying to indent it.

-- 
Karl Chen / quarl@quarl.org

Re: BUG: indenting lisp code marks buffer as dirty when it shouldn't

[Karl Chen]

The same also happens when you do M-; (comment-dwim) on such a line

-- 
Karl Chen / quarl@quarl.org

Re: BUG: indenting lisp code marks buffer as dirty when it shouldn't

[Kai Großjohann]

Karl Chen <quarl@hkn.eecs.berkeley.edu> writes:

> The buffer is not modified.  Thus the two `buffer-modified-tick's should
> report the same value, but they don't. another way to test this is to save the
> buffer before `indent-region', and see that `indent-region' makes the buffer
> dirty, even though it ahsn't actually changed.

M-q has the same problem, but is it really _that_ important?

It took me 7 years of using Emacs to notice the M-q problem...

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: BUG: indenting lisp code marks buffer as dirty when it shouldn't

[Francesco Potorti`]

>> buffer before `indent-region', and see that `indent-region' makes the buffer
>> dirty, even though it ahsn't actually changed.
>
>M-q has the same problem, but is it really _that_ important?

I has always annoyed me, but not enough to try and debug it...

Re: BUG: indenting lisp code marks buffer as dirty when it shouldn't

[Richard Stallman]

    The buffer is not modified.  Thus the two `buffer-modified-tick's should
    report the same value, but they don't. another way to test this is to save the
    buffer before `indent-region', and see that `indent-region' makes the buffer
    dirty, even though it ahsn't actually changed.

It is not a bug to mark the buffer modified in this case.
However, it would be a nice touch to avoid doing so.

If someone wants to work on it, please go ahead.

Re: BUG: indenting lisp code marks buffer as dirty when it shouldn't

[Stefan Monnier]

> This bug exists in Emacs 21.2 as well as CVS HEAD 2002-11-23.

as well as in Emacs-20.7.

> Synopsis:
> 
>   emacs -q
> 
>   C-space
> 
>   insert  "t ;; blah\n"          [ in scratch or any lisp buffer ]

Does it really ?  That's odd.  It doesn't for me.  The reason why it doesn't
is that the ;; is inside a string, so it doesn't try to reindent it
(Emacs-20.7 behaves as you describe because I doesn't pay attention to the
string quotes).
But the problem would appear if you removed the quotes, because the
reindentation would try to reindent the comment and that code is not
careful to modify the text "only if needed".  I'll see how hard it
would be to fix it.


	Stefan

Re: BUG: indenting lisp code marks buffer as dirty when it shouldn't

[Karl Chen]

    Stefan> Does it really ?  That's odd.  It doesn't for me.  The reason why it doesn't
    Stefan> is that the ;; is inside a string, so it doesn't try to reindent it
    Stefan> (Emacs-20.7 behaves as you describe because I doesn't pay attention to the
    Stefan> string quotes).
    Stefan> But the problem would appear if you removed the quotes, because the
    Stefan> reindentation would try to reindent the comment and that code is not
    Stefan> careful to modify the text "only if needed".  I'll see how hard it
    Stefan> would be to fix it.

sorry - that's what I meant, insert the text without the quotes. I quoted it
in the bug report because the spaces typed are important.

-- 
Karl Chen / quarl@quarl.org