[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

insert-file-contents and format-decode

From: martin rudalics
Subject: insert-file-contents and format-decode
Date: Wed, 06 Jun 2007 16:06:23 +0200
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

To reproduce:

Open etc/enriched.doc, insert at buffer start the text


and do M-x revert-buffer.  Admire the guts of enriched.doc.

To explain:

The third element of `format-alist' is a regexp with the following

REGEXP  is a regular expression to match against the beginning of the file;
        it should match only files in that format. ...

The regexp for enriched mode is "Content-[Tt]ype:[ \t]*text/enriched".
When reverting the buffer `insert-file-contents' attempts to preserve
"markers pointing to the unchanged parts" and thus not change "Content"
but insert "-[Tt]ype:[ \t]*text/enriched ...." after it.  The subsequent
matching step in `format-decode' fails because `point' is in between
"Content" and "-[Tt]ype:[ \t]*text/enriched" due to

      /* Set point before the inserted characters.  */
      SET_PT_BOTH (temp, same_at_start);

Apparently, the marker preserving optimization was written without
paying attention to `format-decode'.

To fix:

The call to `format-decode' in

      insval = call3 (Qformat_decode,
                      Qnil, make_number (inserted), visit);

should be performed with `point' at the original position and `inserted'
equalling the number of characters that would have been inserted without
the optimization.  After the call `point' may be restored to the
optimized position iff insval == inserted, that is, format-decode has
not modified the length of the "inserted" text (this might still fail in
pathological cases where format-decode removes and adds the same number
of characters but we shouldn't be too concerned about that).

Maybe someone familiar with the optimizations in `insert-file-contents'
could give it a try?

To consider:

The example given above is contrived.  The bug will become annoying when
you wrap the regexp in a comment to avoid, for example, a compiler
error.  In that case, any "real" comment at the beginning of the file
may trigger the bug.

FWIW, the `after-insert-file-functions' call

      insval = call1 (XCAR (p), make_number (inserted));

should be fixed in a similar manner.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]