Re: [code][textadept] Dirty buffers

From: Mitchell <>
Date: Sun, 10 Nov 2013 22:51:41 -0500 (EST)


On Fri, 8 Nov 2013, Richard Philips wrote:

> Hi,
> I find it is very easy for a buffer in Textadept to become dirty :-)
> e.g.:
> - executing `io.set_buffer_encoding('UTF-8')` with CTRL+E in a buffer which
> uses already UTF-8 makes the buffer dirty.
> (same thing with the other encodings)
> [snip]
> Especially the first example is cumbersome: if you create a new language
> module which should be in a specific encoding, say 'ISO-8859-1'.
> and you put in your module: `io.set_buffer_encoding('ISO-8859-1')` then every
> time you open a file of that type in textadept, its buffer becomes dirty.
> Looking at the code in file_io.lua:
> [snip]
> can be replaced with:
> function io.set_buffer_encoding(encoding)
> ... [snip] ...
> local text, text2 = buffer:get_text()
> text2 = text:iconv(buffer.encoding, 'UTF-8')
> text2 = text2:iconv(encoding, buffer.encoding)
> text2 = text2:iconv('UTF-8', encoding)
> if text2 ~= text then

You are comparing the UTF-8 representation of text in the original
encoding with a UTF-8 representation of the same text in the new encoding.
I'm no expert on encodings, but shouldn't the comparison always be true?
(unless the conversion failed)

By that logic, one could argue that an encoding change should not dirty a
buffer, but if the output bytes differ (which I believe they would), the
buffer should be marked dirty. I think we can improve on this, but I'm not
comfortable enough with encodings and prefer not to risk marking a buffer
as not dirty when it in fact is. I welcome any additional input on this.

A workaround for your case with the language module setting file encodings
might be to just go ahead and call `buffer:set_save_point()` to reset the
dirty status if you know your buffers aren't dirty.


You are subscribed to
To change subscription settings, send an e-mail to
To unsubscribe, send an e-mail to
Received on Sun 10 Nov 2013 - 22:51:41 EST

This archive was generated by hypermail 2.2.0 : Mon 11 Nov 2013 - 06:26:27 EST