Re: [code] v strange find/replace behaviour

From: Mitchell <>
Date: Sun, 2 Sep 2018 22:10:58 -0400 (EDT)

Hi Thomas,

On Mon, 27 Aug 2018, Mitchell wrote:

> Hi Thomas,
> On Mon, 27 Aug 2018, Thomas Lauer wrote:
>> Hi Mitchell,
>> the file is in UTF-8 and TA correctly recognise and displays it as such
>> (that was my first hunch as well).
>> However (as these files came way back in the past from a Windows
>> machine), it does have a BOM. And it seems that indeed that BOM is not
>> removed but stays in the text (though not visible) and is copied with
>> the text I select. If I
>> a) start selecting in the second line or
>> b) hexedit the BOM away and retry in the first line
>> it all works.
>> So... although the BOM is not visible (on screen) it is still there and
>> can be copied!?
> Yes, it appears that Scintilla (Textadept's editing component) hides a BOM
> from view, but allows it to be silently copied. This seems undesirable, so
> I'll look into a fix.
> Sorry for the inconvenience.

I went through Textadept's history when it came to working with files and discovered that I removed explicit BOM handling a couple of years ago[1]. At the time I noted that "BOM use is legacy and discouraged". I still agree with that statement today and do not feel the need to put it back in. While it is a bit unfortunate that silent BOM copying can happen, it only occurs at the beginning of a file, and makes it unlikely to happen to others. (Sorry that you were in that minuscule pecent!) If you feel that you need it, you can always patch Textadept by reverting the aforementioned commit.



You are subscribed to
To change subscription settings, send an e-mail to
To unsubscribe, send an e-mail to
Received on Sun 02 Sep 2018 - 22:10:58 EDT

This archive was generated by hypermail 2.2.0 : Mon 03 Sep 2018 - 06:39:10 EDT