Well... I have run into similar problems for some utilities I wrote and
what I did is either filtering the BOM silently (ie skipping it) or, if
the file has to be written again, set a flag so I know that it had a BOM
in the first place and write it back with BOM (for inhouse stuff, I
don't care and just save everything w/o BOM).
From: Mitchell <m.att.foicica.com>
Date: Mon, 27 Aug 2018 08:54:10 -0400 (EDT)
Subj: Re: [code] v strange find/replace behaviour
> 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.
-- You are subscribed to code.att.foicica.com. To change subscription settings, send an e-mail to code+help.att.foicica.com. To unsubscribe, send an e-mail to code+unsubscribe.att.foicica.com.Received on Mon 27 Aug 2018 - 08:59:43 EDT
This archive was generated by hypermail 2.2.0 : Tue 28 Aug 2018 - 06:27:47 EDT