[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
Contents
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
documentation:
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.
- insert-file-contents and format-decode,
martin rudalics <=
- Re: insert-file-contents and format-decode, Richard Stallman, 2007/06/08
- Re: insert-file-contents and format-decode, martin rudalics, 2007/06/17
- Re: insert-file-contents and format-decode, Richard Stallman, 2007/06/18
- Re: insert-file-contents and format-decode, martin rudalics, 2007/06/19
- Re: insert-file-contents and format-decode, Richard Stallman, 2007/06/23
- Re: insert-file-contents and format-decode, Richard Stallman, 2007/06/23
- Re: insert-file-contents and format-decode, martin rudalics, 2007/06/24
- Re: insert-file-contents and format-decode, Richard Stallman, 2007/06/25
- Re: insert-file-contents and format-decode, martin rudalics, 2007/06/26
- Re: insert-file-contents and format-decode, Richard Stallman, 2007/06/26