From Newsgroup: alt.os.linux

PSA: Clipboard differences between Chromium & Firefox across platforms

I do a lot of research as I generally invest at least an hour or two into
many of my Usenet opening posts, where I currently employ a thousand-line Windows Notepad++ macro that beautifully cleans up non-ASCII garbage copied from both Firefox and Chromium web output, where, only with Chromium pastes into Notepad++ was the selection mechanism (i.e., Ctrl+A) inoperative.
Newsgroups: alt.comp.os.windows-10,alt.comp.os.windows-11,alt.comp.microsoft.windows
Subject: PSA: HTML fragment mode interaction between Chromium, Clipboard & Notepad++
Date: Tue, 10 Feb 2026 07:17:37 -0500
Message-ID: <10mf7l0$dbf$1@nnrp.usenet.blueworldhosting.com>

After much effort, I was able to resolve the problem in one programmed
stroke (as all my solutions are one-tap solutions) but what I wanted to
remind those on the Firefox newsgroup is WHY only Chromium. Not Firefox.

It goes under a bunch of names when I researched it, but they're the same.
1. The HTML Fragment Clipboard Format issue
2. The StartHTML offset bug
3. The Windows HTML Clipboard Format quirk
4. The Chromium HTML clipboard serialization problem
5. The multi-format clipboard mismatch issue
etc.

The HTML Fragment issue showed up for me on Windows when pasting into
Notepad++ from Chromium, but the underlying cause applies to all platforms because it apparently comes from how Chromium generates clipboard data,,
which is DIFFERENT from how Firefox does the same copy/paste tasks.

Even as Firefox uses a different and more conservative clipboard path, the problem seemed almost random because the editor is intimately involved.

The important point is that not all editors behave the same way when they receive multiple clipboard formats. Some editors request only plain text
from clipboard pastes, while some request HTML Format, and some request
both and then choose one based on the editor's own internal rules.

On Windows, Notepad++ requests the plain text stream, but the presence of
the HTML Fragment block can influence how the plain text stream is
generated or parsed.

Other editors on other platforms may ignore the HTML Fragment block or
may sanitize the plain text stream differently. This means the issue is
not tied to one editor. It depends on how each editor interacts with the clipboard and how it handles the plain text stream when HTML Format is
also present.

Unfortunately for me, Chromium always emits HTML Format, so any editor on
any platform that does not expect it or that parses the plain text stream
in a strict way can show the odd behavior which tripped up my one-tap Unicode-to-ASCII conversion solutions. Copying from Firefox avoids this
because FF apparently emits HTML Format only when needed, so the plain text stream is simpler and more predictable across editors and platforms.

That's why I didn't see this problem when I used Firefox for my researched copy/pasting. Only a paste from Chromium browsers broke the Control+A key
press (which also broke the left-mouse-sweep selection workaround).

Specifically, since I edit in GVim but I convert Unicode-to-ASCII in
Notepad, this HTML Fragment issue showed up for me on Windows when pasting
into Notepad++, where NOTHING VISIBLE could be found for a land mine.

The land mine being invisible is important to note because I originally
went down character set and invisible character rat holes, but Notepad++'s
hex editor showed absolutely nothing there causing the problem.

It's an invisible land mine.

I'm writing this PSA to help others because the underlying cause applies to
all platforms (and some editors) because it comes from the design of the Chromium clipboard pipeline, not only from Notepad++ or Windows alone.

To delve a bit deeper into the cause of this invisible land mine,
apparently Chromium always places multiple formats on the clipboard when we copy from a web page. This includes plain text, HTML Format, and several internal formats. The HTML Format block follows a Microsoft specification
that uses StartHTML, EndHTML, StartFragment, and EndFragment offsets to
mark the visible part of the selection.

While I have not tested the other platforms, apparently Chromium does this
on all platforms because its selection code comes from the WebKit and Blink model, which treats every selection as a range of DOM nodes that can be serialized into both plain text and HTML.

Firefox takes a different approach.

Mozilla's clipboard pipeline was apparently built around the Gecko editor
and it only emits HTML Format when the selection contains markup that
Firefox considers meaningful. In many cases Firefox emits only plain text. Perhaps this is why pasting from Firefox did not trigger the same behavior
that I saw when pasting from Chromium based browsers.

The practical effect for users on all common consumer operating systems is
that Chromium produces HTML fragments far more often than Firefox does,
even when the user sees no visible formatting.

On Windows this can expose quirks in applications that do not expect
HTML Format or that handle the plain text stream differently when HTML
is also present. On Linux and macOS the details differ, but the general
pattern is the same because the behavior comes from Chromium, not from
the operating system.

This PSA is only a heads up. Firefox is not at fault here. It simply
uses a more conservative clipboard serializer. Chromium uses a richer
one. If you ever see odd paste behavior in a text editor, the difference
in clipboard formats may be the reason, which is why I wrote this up.

Had I known about this months ago, I wouldn't have had this problem that I
had to add an extra step of adding a blank line in every Chromium paste,
but I didn't have to add that blank line in every Firefox paste.

Adding a blank line, to me, is anathema, because it's an extra step.
I hate extra steps. I grew up in DEC/VAX/PDP11 days and I learned early on
when burning the 2Kbit EEPROMs for Motorola MC68701 micro controllers by
hex (not assembly, but hex) that everything can be halved in steps.

Unlike quantum physics though, I stop when I get it to be one step.

In short, the invisible land mine I hit came from the way Chromium
generates clipboard data differently than Firefox does.

Chromium places multiple formats on the clipboard on all platforms, not
only on Windows.

This behavior is part of the Chromium clipboard design itself.

The exact formats differ by operating system because each OS has
its own clipboard API, but the pattern is the same.

Chromium always serializes the selection into plain text, HTML Format, and several internal formats. On Windows this shows up as CF_UNICODETEXT and
HTML Format with StartHTML and StartFragment offsets. On macOS it shows up
as NSPasteboard types for plain text and HTML. On Linux it shows up as
multiple MIME types on the X11 or Wayland clipboard.

The important point is that Chromium always provides HTML along with plain text, while Firefox provides HTML only when needed. This is why the issue
can appear on any platform that uses Chromium and any editor that reacts to
the presence of HTML on the clipboard.

The invisible land mine issue I had to solve yesterday comes from the
design of the Chromium clipboard pipeline, and any editor that handles the plain text stream in a strict way can be tripped up by the extra HTML
Fragment data that Chromium always provides.

I hope this PSA saves you looking in all the wrong places when the solution
was as simple as automatically adding & deleting a space at the very
beginning of my thousand-line Notepad++ macro to normalize pasted text.

If this edifies you, then the time invested in writing it was worthwhile.
--
Had I known how it works, I would have written up a tutorial instead since
I'm a rare breed of person who delights in edifying everyone around me.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On 2026-02-12 21:26, Maria Sophia wrote:

PSA: Clipboard differences between Chromium & Firefox across platforms

I do a lot of research as I generally invest at least an hour or two into many of my Usenet opening posts, where I currently employ a thousand-line Windows Notepad++ macro that beautifully cleans up non-ASCII garbage copied from both Firefox and Chromium web output, where, only with Chromium pastes into Notepad++ was the selection mechanism (i.e., Ctrl+A) inoperative.

How do you propose we test this in Linux? There is no notepad++.

...
--
Cheers,
Carlos E.R.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Carlos E. R. wrote:

On 2026-02-12 21:26, Maria Sophia wrote:

PSA: Clipboard differences between Chromium & Firefox across platforms

I do a lot of research as I generally invest at least an hour or two into
many of my Usenet opening posts, where I currently employ a thousand-line
Windows Notepad++ macro that beautifully cleans up non-ASCII garbage
copied
from both Firefox and Chromium web output, where, only with Chromium
pastes
into Notepad++ was the selection mechanism (i.e., Ctrl+A) inoperative.

How do you propose we test this in Linux? There is no notepad++.

...

Wine?
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On 2026-02-13 12:19, R Daneel Olivaw wrote:

Carlos E. R. wrote:

On 2026-02-12 21:26, Maria Sophia wrote:

PSA: Clipboard differences between Chromium & Firefox across platforms

I do a lot of research as I generally invest at least an hour or
two into many of my Usenet opening posts, where I currently
employ a thousand- line Windows Notepad++ macro that beautifully
cleans up non-ASCII garbage copied from both Firefox and
Chromium web output, where, only with Chromium pastes into
Notepad++ was the selection mechanism (i.e., Ctrl+A) inoperative.

How do you propose we test this in Linux? There is no notepad++.

...

Wine?

Not going to happen. I have many nice editors native to Linux, no reason
to use a foreign editor.

If Arlen says that this may be an issue outside of Windows, he must have
in mind that we test with some native editor. Name which, name what
webpage to test with and paste from.
--
Cheers,
Carlos E.R.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On Fri, 2/13/2026 6:32 AM, Carlos E. R. wrote:

On 2026-02-13 12:19, R Daneel Olivaw wrote:

Carlos E. R. wrote:

On 2026-02-12 21:26, Maria Sophia wrote:

PSA: Clipboard differences between Chromium & Firefox across platforms >>>>
I do a lot of research as I generally invest at least an hour or
two into many of my Usenet opening posts, where I currently
employ a thousand- line Windows Notepad++ macro that beautifully
cleans up non-ASCII garbage copied from both Firefox and
Chromium web output, where, only with Chromium pastes into
Notepad++ was the selection mechanism (i.e., Ctrl+A) inoperative.

How do you propose we test this in Linux? There is no notepad++.

...

Wine?

Not going to happen. I have many nice editors native to Linux, no reason to use a foreign editor.

If Arlen says that this may be an issue outside of Windows, he must have in mind that we test with some native editor. Name which, name what webpage to test with and paste from.

Now, most of the time, Google doesn't give me these,
so this was unexpected :-) All I had done is asked
for "notepad++ for linux" and it trotted this out.

AI Overview
Notepad++ is not natively available for Linux, but it can be run efficiently using the Snap package manager (via Wine) or through alternatives that mimic its functionality.
The most direct method is installing the Snap package , which provides a functional version
of the application.

Key Methods to Use Notepad++ on Linux:

Snap Package (Recommended): This is the easiest, most stable method that
bundles Wine to run the Windows app seamlessly.

Command: . <=== AI flubs it snap search notepad-plus-plus
snap install notepad-plus-plus (uses wine-platform-runtime-core22)
Wine: For advanced users, you can manually install Wine and use it to run the installer.

Popular Native Linux Alternatives:

If a native application is preferred over a Wine-based one, consider these alternatives:

Notepad Next: A re-implementation of Notepad++ designed for Linux.
Notepadqq: A close, native clone of Notepad++.
Kate or Geany: Highly polished native editors.
Sublime Text: A powerful, fast, cross-platform alternative.

Using the Snap package is generally recommended because it provides a pre-configured Wine environment.

*******

[Picture] Use "Download Original" to exit the advertising-heavy page

https://i.postimg.cc/mkZJG76Q/notepad-plus-plus.png

That's it running. Can't do anything there, until "the updates are finished".

Paul
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Carlos E. R. wrote:

On 2026-02-12 21:26, Maria Sophia wrote:

PSA: Clipboard differences between Chromium & Firefox across platforms

I do a lot of research as I generally invest at least an hour or two into
many of my Usenet opening posts, where I currently employ a thousand-line
Windows Notepad++ macro that beautifully cleans up non-ASCII garbage copied >> from both Firefox and Chromium web output, where, only with Chromium pastes >> into Notepad++ was the selection mechanism (i.e., Ctrl+A) inoperative.

How do you propose we test this in Linux? There is no notepad++.

Not at all. Just forget it. ;-)
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On 2026-02-13, R Daneel Olivaw <Danni@hyperspace.vogon.gov.invalid> wrote:

Carlos E. R. wrote:

On 2026-02-12 21:26, Maria Sophia wrote:

PSA: Clipboard differences between Chromium & Firefox across platforms

I do a lot of research as I generally invest at least an hour or two into >>> many of my Usenet opening posts, where I currently employ a thousand-line >>> Windows Notepad++ macro that beautifully cleans up non-ASCII garbage
copied
from both Firefox and Chromium web output, where, only with Chromium
pastes
into Notepad++ was the selection mechanism (i.e., Ctrl+A) inoperative.

How do you propose we test this in Linux? There is no notepad++.

...

Wine?

Youy mean it can be done if we get drunk?
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Jim Jackson wrote:

On 2026-02-13, R Daneel Olivaw <Danni@hyperspace.vogon.gov.invalid> wrote:

Carlos E. R. wrote:

On 2026-02-12 21:26, Maria Sophia wrote:

PSA: Clipboard differences between Chromium & Firefox across platforms >>>>
I do a lot of research as I generally invest at least an hour or two into >>>> many of my Usenet opening posts, where I currently employ a thousand-line >>>> Windows Notepad++ macro that beautifully cleans up non-ASCII garbage
copied
from both Firefox and Chromium web output, where, only with Chromium
pastes
into Notepad++ was the selection mechanism (i.e., Ctrl+A) inoperative.

How do you propose we test this in Linux? There is no notepad++.

...

Wine?

Youy mean it can be done if we get drunk?

https://www.winehq.org/
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Carlos E. R. wrote:

I do a lot of research as I generally invest at least an hour or two into
many of my Usenet opening posts, where I currently employ a thousand-line
Windows Notepad++ macro that beautifully cleans up non-ASCII garbage copied >> from both Firefox and Chromium web output, where, only with Chromium pastes >> into Notepad++ was the selection mechanism (i.e., Ctrl+A) inoperative.

How do you propose we test this in Linux? There is no notepad++.

Hi Carlos,

Thanks for asking, where I'll propose a test for Linux later, but first I
need you to understand that the problem exists across all platforms
(AFAIK).

Reacting to a perceived incredularity on your part, I simply ask (a bit snarkily in jest so as to bring the conversation back to where it belongs),
are we really prepared to claim that Linux users, who are those same people
who have approximately seventeen text editors installed before breakfast,
have never once copied any text from Firefox or Chromium and pasted it into
vi, vim, GVim, Kate, gedit, or any of the other editors that have existed
since the Pleistocene?

Because the absence of native Notepad++ on Linux doesn't magically prevent clipboard testing. The clipboard exists. Chromium exists. Firefox exists. Editors exist.

The only missing ingredient would be the willingness to actually try it.

If the question is whether the Chromium HTML-Fragment/StartHTML clipboard
quirk shows up on Linux, the answer depends entirely on whether the editor
in question reacts to the presence of HTML on the clipboard.

Some may. Some may not. That's the whole point of the PSA!

To warn others that the behavior comes from the browser's clipboard serialization, not from Windows, Notepad++, or any single platform.

So yes, of course this can be tested on Linux. It always could.

The prerequisite is acknowledging that "Notepad++ doesn't run on Linux" is
not the airtight argument all the follow on posters seem to believe.
--
When people throw obstacles into the path of testing, it means that they
never understood the premise in the first place, as it can be tested.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Carlos E. R. wrote:

I do a lot of research as I generally invest at least an hour or two into
many of my Usenet opening posts, where I currently employ a thousand-line
Windows Notepad++ macro that beautifully cleans up non-ASCII garbage copied >> from both Firefox and Chromium web output, where, only with Chromium pastes >> into Notepad++ was the selection mechanism (i.e., Ctrl+A) inoperative.

How do you propose we test this in Linux? There is no notepad++.

Hi Carlos,

Thanks for asking, where I'll propose a test for Linux later, but first I
need you to understand that the problem exists across all platforms
(AFAIK).

Reacting to a perceived incredularity on your part, I simply ask (a bit snarkily in jest so as to bring the conversation back to where it belongs),
are we really prepared to claim that Linux users, who are those same people
who have approximately seventeen text editors installed before breakfast,
have never once copied any text from Firefox or Chromium and pasted it into
vi, vim, GVim, Kate, gedit, or any of the other editors that have existed
since the Pleistocene?

Because the absence of native Notepad++ on Linux doesn't magically prevent clipboard testing. The clipboard exists. Chromium exists. Firefox exists. Editors exist.

The only missing ingredient would be the willingness to actually try it.

If the question is whether the Chromium HTML-Fragment/StartHTML clipboard
quirk shows up on Linux, the answer depends entirely on whether the editor
in question reacts to the presence of HTML on the clipboard.

Some may. Some may not. That's the whole point of the PSA!

To warn others that the behavior comes from the browser's clipboard serialization, not from Windows, Notepad++, or any single platform.

So yes, of course this can be tested on Linux. It always could.

The prerequisite is acknowledging that "Notepad++ doesn't run on Linux" is
not the airtight argument all the follow on posters seem to believe.
--
When people throw obstacles into the path of testing, it means that they
never understood the premise in the first place, as it can be tested.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

R Daneel Olivaw wrote:

Jim Jackson wrote:

On 2026-02-13, R Daneel Olivaw <Danni@hyperspace.vogon.gov.invalid> wrote: >>> Carlos E. R. wrote:

On 2026-02-12 21:26, Maria Sophia wrote:

PSA: Clipboard differences between Chromium & Firefox across platforms >>>>>
I do a lot of research as I generally invest at least an hour or two into >>>>> many of my Usenet opening posts, where I currently employ a thousand-line >>>>> Windows Notepad++ macro that beautifully cleans up non-ASCII garbage >>>>> copied
from both Firefox and Chromium web output, where, only with Chromium >>>>> pastes
into Notepad++ was the selection mechanism (i.e., Ctrl+A) inoperative. >>>>

How do you propose we test this in Linux? There is no notepad++.

...

Wine?

Youy mean it can be done if we get drunk?

https://www.winehq.org/

Wine and Notepad++ are red herrings for the Linux newsgroup, but the
problem is the same so I apologize if I didn't make the main point clear.

Linux itself does not define how the clipboard works. The clipboard
behavior depends on the display system in use, which is either X11 or
Wayland on most desktops.

Chromium and Firefox both sit on top of that display system. They each
have their own clipboard pipeline, which decides what formats to put on
the clipboard when we copy from a web page.

The key point is that Chromium always puts multiple formats on the
clipboard, including HTML, while Firefox is more conservative and often
puts only plain text. That design difference exists on all platforms,
including Linux.

When we copy from Chromium, on any platform, it typically offers several formats at once, such as
1. text/plain
2. text/html
3. text/html fragment or internal HTML types
4. sometimes image types
5. sometimes internal or custom MIME types

This pattern is the same idea on Windows, macOS, Linux on X11, and Linux
on Wayland. The exact API calls differ, but the design is the same.

Chromium always serializes the selection as plain text and as HTML, even
when the user does not see obvious formatting.

That is the source of the invisible land mine the PSA describes in the OP.

The HTML fragment is present even when we think we are copying only simple text.

Since this is a Mozilla group, let's contrast with how Firefox behaves.

Firefox uses a more conservative clipboard pipeline than Chromium.
Thank God.

Firefox tends to emit plain text only, unless the selection actually
contains markup that Firefox considers meaningful.

So I agree with you that in many cases, copying from Firefox produces only
a plain text clipboard entry. That makes the plain text stream simpler and
more predictable for editors on all platforms, not just Windows.

This is why I did not see the same problem when copying from Firefox.
The HTML fragment was simply not there most of the time.

On X11, the clipboard is implemented using the X11 selection model.

1. The application that owns the selection keeps the data.
2. When another application pastes, it asks the owner for data in a
specific format.
3. The owner responds with data in that format, if it supports it.

Chromium on X11 advertises multiple MIME types, such as text plain and
text html. Different Linux/Windows/macOS editors make different choices
about which format to request.

Some editors request only text plain. Some request text html first.
Some request both, then apply their own rules to decide which one to use.

Because Chromium always offers HTML as well as plain text, an editor on
X11 can end up using the HTML based representation, or can parse the
plain text differently because HTML is also present. That can trigger
odd behavior, even though nothing visible appears in the pasted text.

So on X11, the same Chromium design can cause different symptoms in
different editors, depending on how they negotiate clipboard formats.

By way of conrast, Wayland uses a more structured clipboard protocol.

1. Applications explicitly declare which MIME types they offer.
2. The compositor mediates clipboard access.
3. Only the active paste target can request clipboard data.

Chromium on Wayland still offers multiple formats, including text plain
and text html. Editors on Wayland still choose which format to request.

The stricter protocol can avoid some of the older X11 quirks, but it
does not change the basic fact that Chromium always provides HTML along
with plain text.

Any editor that prefers HTML on any platform, or that treats plain text differently when HTML is present, can still show this surprising behavior.

So the same invisible land mine can exist on Wayland, although the exact symptoms may differ from X11.

The point of the OP is that this issue is not a Windows-only problem

Certainly I have observed the issue on Windows with Notepad++, where
Control+A stopped working after pasting from Chromium. The root
cause, however, is not specific to Windows nor to Notepad++.

The root cause is that Chromium always places multiple formats on the clipboard, including HTML fragments, while Firefox often does not.

That's the whole point of this PSA.

Any editor on any platform that reacts badly to the presence of HTML, or
that parses the plain text stream in a strict way when HTML is also
present, can be tripped up.

On Linux, we do not need Notepad++ to see this.

We can see similar effects in other editors, for example GVim, Kate, or
various GTK or Qt based editors, depending on how they choose clipboard
formats and how they parse the plain text stream when HTML is also present.

So to answer your question keeping on topic for this PSA warning...

1. Chromium always offers HTML plus plain text on all platforms.
2. Firefox often offers only plain text, unless HTML is clearly needed.
3. X11 uses an older, flexible selection model, so editor behavior can
vary widely.
4. Wayland uses a newer, stricter protocol, but editors still choose
which MIME type to request.

The design difference between Chromium and Firefox is the main reason
for the invisible land mine. X11 and Wayland mainly change how that
difference shows up in practice, not whether it exists.

This was not intended to be a Linux-only PSA but a practical takeaway for
Linux users is if we see strange paste behavior in a Linux editor,
especially when copying from Chromium based browsers, it is reasonable to suspect that the editor may be reacting to multiple clipboard formats, not
just to plain text.

Just knowing this can be a possibility is like a TSB for a mechanic.

This newsgroup is involved because copying the same content from Firefox
can be a useful comparison test, because Firefox often omits HTML when it
is not needed.

If the problem disappears when copying from Firefox, that supports the idea that the extra HTML fragment from Chromium is involved.

In summary, the answer to your question is the same pattern I saw on
Windows & the same underlying design applies on Linux, both on X11 and on Waylan (as far as I am aware).
--
Had I known how it works, I would have written up a tutorial instead since
I'm a rare breed of person who delights in edifying everyone around me.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Frank Miller wrote:

Carlos E. R. wrote:

On 2026-02-12 21:26, Maria Sophia wrote:

PSA: Clipboard differences between Chromium & Firefox across platforms

I do a lot of research as I generally invest at least an hour or two into >>> many of my Usenet opening posts, where I currently employ a thousand-line >>> Windows Notepad++ macro that beautifully cleans up non-ASCII garbage copied >>> from both Firefox and Chromium web output, where, only with Chromium pastes >>> into Notepad++ was the selection mechanism (i.e., Ctrl+A) inoperative.

How do you propose we test this in Linux? There is no notepad++.

Not at all. Just forget it. ;-)

I had thought the data in the PSA was clear, but apparently it was not.

That's my mistake for not explaining why all operating systems are affected (AFAICT) since we do not need Notepad++ at all to reproduce underlying
browser design on Linux as the browser-to-clipboard-to-editor behavior
being described is not Windows-specific. All platforms deal with it.

The problem is a mix of operating system quirks (clipboard specific), and
the differences between how browsers and editors work with copy & paste.

As far as I'm aware, but I could be wrong, Chromium's multi-format
clipboard serialization (plain text + HTML + internal formats) happens on
all platforms, including Linux under both X11 and Wayland.

Hence the Chromium vs. Firefox clipboard behavior I saw on Windows, AFAIK,
does carry over to Linux, but X11 and Wayland handle clipboards very differently, so the effects of Chromium's multi-format clipboard can vary depending on which display system the user is running and which editor.

Let me work on a test protocol for Linux since I no longer dual boot even
as I see a grub screen every day when I boot my Windows-only old desktop.
--
My PC used to be Windows:Redhat, then Windows:Centos, then Windows:Ubuntu
but now it's just Windows because I've long ago ported over my Linux tools.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Paul wrote:

On Fri, 2/13/2026 6:32 AM, Carlos E. R. wrote:

On 2026-02-13 12:19, R Daneel Olivaw wrote:

Carlos E. R. wrote:

On 2026-02-12 21:26, Maria Sophia wrote:

PSA: Clipboard differences between Chromium & Firefox across platforms >>>>>
I do a lot of research as I generally invest at least an hour or
two into many of my Usenet opening posts, where I currently
employ a thousand- line Windows Notepad++ macro that beautifully
cleans up non-ASCII garbage copied from both Firefox and
Chromium web output, where, only with Chromium pastes into
Notepad++ was the selection mechanism (i.e., Ctrl+A) inoperative.

How do you propose we test this in Linux? There is no notepad++.

Now, most of the time, Google doesn't give me these,
so this was unexpected :-) All I had done is asked
for "notepad++ for linux" and it trotted this out.

AI Overview
Notepad++ is not natively available for Linux, but it can be run efficiently using the Snap package manager (via Wine) or through alternatives that mimic its functionality.
The most direct method is installing the Snap package , which provides a functional version
of the application.

Hi Paul,

Thanks for always being helpful and kind, as I strive to emulate you.
The problem, as far as I am aware, is not tied to Windows or Notepad++.

I apologize if I wasn't clear in the original post of this PSA that I
believe the problem lies in the underlying design which prevails in all operating systems, particularly when contrasting Firefox with Chromium.

It comes from how Chromium and Firefox generate clipboard data, and that behavior is the same on Linux, macOS and Windows as far as I'm aware.

Hence, the editor only exposes the issue.
The editor does not create it.

On Linux, the clipboard is handled by the display protocol. That means
X11 or Wayland. Chromium, Firefox and every other graphical program talk
to the clipboard through whichever protocol the desktop is using.

1. On X11, the clipboard is based on selection ownership.
The program that owns the selection must stay alive, and the
clipboard contents are provided on demand when another program
requests a specific MIME type.

2. On Wayland, the clipboard is more structured. Programs advertise the
MIME types they can provide, and the compositor mediates access.

In both cases, Chromium always advertises multiple MIME types, including text/plain and text/html. The contrast I'm trying to help explain to this newsgroup is that Firefox often advertises only text/plain unless
the selection contains real markup.

That difference is the root cause of the odd behavior I saw on Windows.

Some Linux editors prefer text/html when it is available. Others ignore
it and take only text/plain. When an editor chooses the HTML version,
even if the visible text looks identical, the internal buffer can contain fragment markers or offsets that affect selection, cursor movement or
macro behavior.

That is the same class of invisible land mine that showed up in Notepad++
on Windows.

Below is a simple Linux testing sequence that might reproduce the issue.

1. Install xclip if needed.
sudo apt-get install xclip

2. In Chromium, copy a paragraph of plain looking text from any web page.

3. Inspect the clipboard targets.
xclip -selection clipboard -t TARGETS -o

We should see text/html and text/plain among the entries.

4. Inspect the HTML version.
xclip -selection clipboard -t text/html -o

We should see HTML markup even if the selection looked plain.

5. Inspect the plain text version.
xclip -selection clipboard -t text/plain -o

6. Repeat steps 2 through 5 using Firefox instead of Chromium.
Note that Firefox often omits text/html for simple selections.

7. Paste the Chromium sourced text into several editors:
A. gedit
B. Kate
C. GVim
D. Geany

Then test:
a. Ctrl+A
b. Mouse sweep selection
c. Any macro or command that assumes a clean plain text buffer

If an editor behaves oddly only when the source is Chromium, that
confirms the HTML fragment is influencing the paste.

8. Paste the Firefox sourced text into the same editors and repeat the
same tests. If the odd behavior disappears, that isolates the cause.

This sequence is intended to show that the issue is not about Notepad++ or Windows. It is about Chromium always providing HTML fragments that Firefox
does not produce, and about editors that change behavior when HTML is
present on the clipboard even when the user sees only plain text.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On Fri, 2/13/2026 1:37 PM, Maria Sophia wrote:

Paul wrote:

On Fri, 2/13/2026 6:32 AM, Carlos E. R. wrote:

On 2026-02-13 12:19, R Daneel Olivaw wrote:

Carlos E. R. wrote:

On 2026-02-12 21:26, Maria Sophia wrote:

PSA: Clipboard differences between Chromium & Firefox across platforms >>>>>>
I do a lot of research as I generally invest at least an hour or
two into many of my Usenet opening posts, where I currently
employ a thousand- line Windows Notepad++ macro that beautifully
cleans up non-ASCII garbage copied from both Firefox and
Chromium web output, where, only with Chromium pastes into
Notepad++ was the selection mechanism (i.e., Ctrl+A) inoperative.

How do you propose we test this in Linux? There is no notepad++.

Now, most of the time, Google doesn't give me these,
so this was unexpected :-) All I had done is asked
for "notepad++ for linux" and it trotted this out.

AI Overview
Notepad++ is not natively available for Linux, but it can be run efficiently >> using the Snap package manager (via Wine) or through alternatives that mimic its functionality.
The most direct method is installing the Snap package , which provides a functional version
of the application.

Hi Paul,

Thanks for always being helpful and kind, as I strive to emulate you.
The problem, as far as I am aware, is not tied to Windows or Notepad++.

I apologize if I wasn't clear in the original post of this PSA that I
believe the problem lies in the underlying design which prevails in all operating systems, particularly when contrasting Firefox with Chromium.

It comes from how Chromium and Firefox generate clipboard data, and that behavior is the same on Linux, macOS and Windows as far as I'm aware.

Hence, the editor only exposes the issue.
The editor does not create it.

On Linux, the clipboard is handled by the display protocol. That means
X11 or Wayland. Chromium, Firefox and every other graphical program talk
to the clipboard through whichever protocol the desktop is using.

1. On X11, the clipboard is based on selection ownership. -a The program that owns the selection must stay alive, and the -a clipboard contents are provided on demand when another program -a requests a specific MIME type.

2. On Wayland, the clipboard is more structured. Programs advertise the
-a MIME types they can provide, and the compositor mediates access.

In both cases, Chromium always advertises multiple MIME types, including text/plain and text/html. The contrast I'm trying to help explain to this newsgroup is that Firefox often advertises only text/plain unless
the selection contains real markup.
That difference is the root cause of the odd behavior I saw on Windows.

Some Linux editors prefer text/html when it is available. Others ignore
it and take only text/plain. When an editor chooses the HTML version,
even if the visible text looks identical, the internal buffer can contain fragment markers or offsets that affect selection, cursor movement or
macro behavior.
That is the same class of invisible land mine that showed up in Notepad++
on Windows.

Below is a simple Linux testing sequence that might reproduce the issue.

1. Install xclip if needed.
-a sudo apt-get install xclip

2. In Chromium, copy a paragraph of plain looking text from any web page.

3. Inspect the clipboard targets.
-a xclip -selection clipboard -t TARGETS -o

-a We should see text/html and text/plain among the entries.

4. Inspect the HTML version.
-a xclip -selection clipboard -t text/html -o

-a We should see HTML markup even if the selection looked plain.

5. Inspect the plain text version.
-a xclip -selection clipboard -t text/plain -o

6. Repeat steps 2 through 5 using Firefox instead of Chromium.
-a Note that Firefox often omits text/html for simple selections.

7. Paste the Chromium sourced text into several editors:
-a A. gedit
-a B. Kate
-a C. GVim
-a D. Geany

-a Then test:
-a a. Ctrl+A
-a b. Mouse sweep selection
-a c. Any macro or command that assumes a clean plain text buffer

-a If an editor behaves oddly only when the source is Chromium, that
-a confirms the HTML fragment is influencing the paste.

8. Paste the Firefox sourced text into the same editors and repeat the
-a same tests. If the odd behavior disappears, that isolates the cause.

This sequence is intended to show that the issue is not about Notepad++ or Windows. It is about Chromium always providing HTML fragments that Firefox does not produce, and about editors that change behavior when HTML is
present on the clipboard even when the user sees only plain text.

When I got Chromium installed, and I used the "clipboard" SNAP,
it was claiming only a text buffer was on the clipboard. As
near as I can determine. And my one sentence, copied OK into Notepad++
under WINE.

Linux has a pile of clipboard tools, and for the most part,
they are not forensic in nature, and you can't really be sure
they are showing the multiple clipboard entries that might or should
be there.

My only contribution here, is showing that there is "some" amount of cross-platform, but not really enough for any "proof" type posts.
I got as far as being able to list what one tool claimed was
on the clipboard, and it didn't break when I pasted into a
WINE-supported application. That's going through a few "torturous paths"
as you can imagine. That's a hell of a lot more complexity than when we
were using clipboard managers on UNIX.

Paul

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Maria Sophia <mariasophia@comprehension.com> wrote:

Hi Paul,

Thanks for always being helpful and kind, as I strive to emulate you.

[...]

Even to the extent of using the same unusual newsreader, Maria!
I'm sure Paul is very flattered; I do hope it doesn't turn his head.
--
\|/
(((-))) - Mr +n!on, NPC

When we shake the ketchup bottle
At first none comes and then a lot'll.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On 2026-02-13 19:37, Maria Sophia wrote:

Paul wrote:

On Fri, 2/13/2026 6:32 AM, Carlos E. R. wrote:

On 2026-02-13 12:19, R Daneel Olivaw wrote:

Carlos E. R. wrote:

On 2026-02-12 21:26, Maria Sophia wrote:

PSA: Clipboard differences between Chromium & Firefox across
platforms

I do a lot of research as I generally invest at least an hour or
two into many of my Usenet opening posts, where I currently
employ a thousand- line Windows Notepad++ macro that beautifully
cleans up non-ASCII garbage copied from both Firefox and
Chromium web output, where, only with Chromium pastes into
Notepad++ was the selection mechanism (i.e., Ctrl+A) inoperative.

How do you propose we test this in Linux? There is no notepad++.

Now, most of the time, Google doesn't give me these,
so this was unexpected :-) All I had done is asked
for "notepad++ for linux" and it trotted this out.

AI Overview
Notepad++ is not natively available for Linux, but it can be run
efficiently
using the Snap package manager (via Wine) or through alternatives that
mimic its functionality.
The most direct method is installing the Snap package , which provides
a functional version
of the application.

Hi Paul,

Thanks for always being helpful and kind, as I strive to emulate you.
The problem, as far as I am aware, is not tied to Windows or Notepad++.

I apologize if I wasn't clear in the original post of this PSA that I
believe the problem lies in the underlying design which prevails in all operating systems, particularly when contrasting Firefox with Chromium.

It comes from how Chromium and Firefox generate clipboard data, and that behavior is the same on Linux, macOS and Windows as far as I'm aware.

Hence, the editor only exposes the issue.
The editor does not create it.

On Linux, the clipboard is handled by the display protocol. That means
X11 or Wayland. Chromium, Firefox and every other graphical program talk
to the clipboard through whichever protocol the desktop is using.

I will not do this procedure you describe, way too complex an long.

I opened the wikipedia page on Chrome. If that one is not suitable, you
post the exact page to try with. I use ^A to select and copy paste all
to Kate. It just works, but the result is useless, obviously. ^A in Kate
also works.

Pasting it all in owrite almost works. I mean, graphics and formatting
is copied almost correctly. Areas with several columns fail.

If this is not what you intended, write a *short* test procedure.
--
Cheers,
Carlos E.R.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On 2026-02-13 19:12, Maria Sophia wrote:

Carlos E. R. wrote:

I do a lot of research as I generally invest at least an hour or
two into many of my Usenet opening posts, where I currently
employ a thousand- line Windows Notepad++ macro that beautifully
cleans up non-ASCII garbage copied from both Firefox and
Chromium web output, where, only with Chromium pastes into
Notepad++ was the selection mechanism (i.e., Ctrl+A) inoperative.

How do you propose we test this in Linux? There is no notepad++.

Hi Carlos,

Thanks for asking, where I'll propose a test for Linux later, but first I need you to understand that the problem exists across all platforms
(AFAIK).

Reacting to a perceived incredularity on your part, I simply ask (a bit snarkily in jest so as to bring the conversation back to where it belongs), are we really prepared to claim that Linux users, who are those same people who have approximately seventeen text editors installed before breakfast, have never once copied any text from Firefox or Chromium and pasted it into vi, vim, GVim, Kate, gedit, or any of the other editors that have existed since the Pleistocene?

I copy paste rich text from Firefox into editors without problems. I do
not use Chrome, but I have it installed.

Because the absence of native Notepad++ on Linux doesn't magically prevent clipboard testing. The clipboard exists. Chromium exists. Firefox exists. Editors exist.
The only missing ingredient would be the willingness to actually try it.

If the question is whether the Chromium HTML-Fragment/StartHTML clipboard quirk shows up on Linux, the answer depends entirely on whether the editor
in question reacts to the presence of HTML on the clipboard.
Some may. Some may not. That's the whole point of the PSA!

To warn others that the behavior comes from the browser's clipboard serialization, not from Windows, Notepad++, or any single platform.

So yes, of course this can be tested on Linux. It always could.
The prerequisite is acknowledging that "Notepad++ doesn't run on Linux" is not the airtight argument all the follow on posters seem to believe.

I pasted an entire web page from Chrome into Kate and LO Write, with no perceived problems.
--
Cheers,
Carlos E.R.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Carlos E. R. wrote:

I will not do this procedure you describe, way too complex an long.

I opened the wikipedia page on Chrome. If that one is not suitable, you
post the exact page to try with. I use ^A to select and copy paste all
to Kate. It just works, but the result is useless, obviously. ^A in Kate also works.

Pasting it all in owrite almost works. I mean, graphics and formatting
is copied almost correctly. Areas with several columns fail.

If this is not what you intended, write a *short* test procedure.

Hi Carlos,

Thanks for testing the warning PSA and for explaining what you tried.

I was very careful in the original post to not claim the problem is
"caused" by the editor, as the editor is simply the last item in the chain.

Let me clarify something, because I think we may be talking past each other
a bit. My original point wasn't that the editor (Kate, Notepad++, owrite,
etc.) causes the issue. The editor is simply where the problem becomes
visible. The underlying issue starts earlier in the chain, specifically
with how the Chromium and Firefox browsers copy the HTML fragment.

That's why I emphasized the browser differences (Firefox vs. Chromium) and
why the operating system or editor isn't the root of the problem. The
editor just reacts to whatever HTML fragment the browser provides.

The problem exists on any operating system where Chromium & Firefox are.

Your helpful test with Kate and owrite is useful, but it doesn't change the core issue that Firefox and Chromium generate different clipboard HTML, and that's what leads to the inconsistent results when pasting.

If the procedure I described felt too long, I can absolutely provide a
shorter, more direct test case. Here's a minimal version of the test...

1. Open the specific page or snippet in Firefox.
2. Select only the defined section (not the whole page).
3. Paste into any editor that supports HTML fragments.
4. Repeat the same steps in Chromium and compare.

This isolates the browser behavior without involving the editor as a
variable.

If you want an even smaller snippet or a different page, I can provide that
too as goal of this PSA is simply to warn others of this pernicious issue.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Carlos E. R. wrote:

On 2026-02-13 19:12, Maria Sophia wrote:

Carlos E. R. wrote:

I do a lot of research as I generally invest at least an hour or
two into many of my Usenet opening posts, where I currently
employ a thousand- line Windows Notepad++ macro that beautifully
cleans up non-ASCII garbage copied from both Firefox and
Chromium web output, where, only with Chromium pastes into
Notepad++ was the selection mechanism (i.e., Ctrl+A) inoperative.

How do you propose we test this in Linux? There is no notepad++.

Hi Carlos,

Thanks for asking, where I'll propose a test for Linux later, but first I
need you to understand that the problem exists across all platforms
(AFAIK).

Reacting to a perceived incredularity on your part, I simply ask (a bit
snarkily in jest so as to bring the conversation back to where it belongs), >> are we really prepared to claim that Linux users, who are those same people >> who have approximately seventeen text editors installed before breakfast,
have never once copied any text from Firefox or Chromium and pasted it into >> vi, vim, GVim, Kate, gedit, or any of the other editors that have existed
since the Pleistocene?

I copy paste rich text from Firefox into editors without problems. I do
not use Chrome, but I have it installed.

Because the absence of native Notepad++ on Linux doesn't magically prevent >> clipboard testing. The clipboard exists. Chromium exists. Firefox exists.
Editors exist.
The only missing ingredient would be the willingness to actually try it.

If the question is whether the Chromium HTML-Fragment/StartHTML clipboard
quirk shows up on Linux, the answer depends entirely on whether the editor >> in question reacts to the presence of HTML on the clipboard.
Some may. Some may not. That's the whole point of the PSA!

To warn others that the behavior comes from the browser's clipboard
serialization, not from Windows, Notepad++, or any single platform.

So yes, of course this can be tested on Linux. It always could.
The prerequisite is acknowledging that "Notepad++ doesn't run on Linux" is >> not the airtight argument all the follow on posters seem to believe.

I pasted an entire web page from Chrome into Kate and LO Write, with no perceived problems.

Hi Carlos,

Thanks for testing this on your side. Your results in Kate and LO Write
are useful because they show that not every Linux editor reacts the same
way to the clipboard formats that Chromium provides. That is exactly the pattern I was trying to highlight in the PSA but I did a bad job of it.

I apologize for not being clear in the original post that this issue is due
to the way the browser interacts wth the clipboard with the editor only
being the last item in the chain, so results vary depending on $EDITOR.

The point of this PSA is about browsers, and the clipboard, and, eventually
the $EDITOR but it's not that every $EDITOR will show the fragment problem.

Given this is a set of operating system and Firefox newsgroups, the point
is that Chromium always places HTML on the clipboard along with plain text, while Firefox often provides only plain text on all consumer platforms.

Some $EDITORS ignore the HTML, some prefer it, and some change behavior
when both formats are present. I don't know the list of who does what.

I was just warning people that the problem exists (on all platforms).

It bit me. Bad. I couldn't for the life of me figure out at first why only Chromium pastes killed the "Control+A" selection while FF pastes did not.

Especially since the editor's hex mode shows absolutely nothing about it.

Your tests confirm that Kate and LO Write handle the Chromium clipboard
in a way that avoids the issue. That is good information for the group.
It also helps narrow down which editors might react differently.

Since you run Linux every day, your input is valuable here. You can help
the team by checking one small thing that keeps the test simple.

Here is a short test that keeps things simple.
1. Copy a short plain-looking paragraph in Firefox.
2. Paste it into any editor you prefer.
3. Press Control+A and confirm that full selection works.
4. Repeat the same steps using Chromium.
5. Compare only the behavior of the editor, not the formatting.

This keeps the test short and avoids long procedures, and it lets us see whether the difference between Firefox and Chromium shows up in your own
Linux setup.

If both behave the same, that tells us the editor is choosing plain text.
If they differ, that suggests the editor is reacting to the HTML fragment
that Chromium always provides. This is the PSA that I'm warning folks of.

Note that Control+A is not a Windows feature.
It is an editor feature.
On Linux:
a. Kate supports Control+A
b. LO Write supports Control+A
c. GVim supports Control+A
But many terminal editors do not.

So the key point is that while Control+A works on Linux, the behavior after
a Chromium paste can differ depending on how the editor interprets the clipboard formats.

Thanks again for checking this.
Your Linux results help complete the picture for everyone.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On 2026-02-13 14:42, Paul wrote:

On Fri, 2/13/2026 6:32 AM, Carlos E. R. wrote:

On 2026-02-13 12:19, R Daneel Olivaw wrote:

Carlos E. R. wrote:

On 2026-02-12 21:26, Maria Sophia wrote:

PSA: Clipboard differences between Chromium & Firefox across platforms >>>>>
I do a lot of research as I generally invest at least an hour or
two into many of my Usenet opening posts, where I currently
employ a thousand- line Windows Notepad++ macro that beautifully
cleans up non-ASCII garbage copied from both Firefox and
Chromium web output, where, only with Chromium pastes into
Notepad++ was the selection mechanism (i.e., Ctrl+A) inoperative.

How do you propose we test this in Linux? There is no notepad++.

...

Wine?

Not going to happen. I have many nice editors native to Linux, no reason to use a foreign editor.

If Arlen says that this may be an issue outside of Windows, he must have in mind that we test with some native editor. Name which, name what webpage to test with and paste from.

Now, most of the time, Google doesn't give me these,
so this was unexpected :-) All I had done is asked
for "notepad++ for linux" and it trotted this out.

AI Overview
Notepad++ is not natively available for Linux, but it can be run efficiently using the Snap package manager (via Wine) or through alternatives that mimic its functionality.
The most direct method is installing the Snap package , which provides a functional version
of the application.

Key Methods to Use Notepad++ on Linux:

Snap Package (Recommended): This is the easiest, most stable method that
bundles Wine to run the Windows app seamlessly.

I understand this is a sort of package that bundles both wine and
Notepad++? Thus the size will be huge, on disk and on RAM.

Command: . <=== AI flubs it snap search notepad-plus-plus
snap install notepad-plus-plus (uses wine-platform-runtime-core22)
Wine: For advanced users, you can manually install Wine and use it to run the installer.

Popular Native Linux Alternatives:

If a native application is preferred over a Wine-based one, consider these alternatives:

Notepad Next: A re-implementation of Notepad++ designed for Linux.
Notepadqq: A close, native clone of Notepad++.
Kate or Geany: Highly polished native editors.
Sublime Text: A powerful, fast, cross-platform alternative.

Cross platforms alternatives are something to consider, if one is to
learn a new editor.

Using the Snap package is generally recommended because it provides a pre-configured Wine environment.

*******

[Picture] Use "Download Original" to exit the advertising-heavy page

https://i.postimg.cc/mkZJG76Q/notepad-plus-plus.png

That's it running. Can't do anything there, until "the updates are finished".

Paul

--
Cheers,
Carlos E.R.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Maria Sophia <mariasophia@comprehension.com> wrote:

Mr +n!on wrote:

Even to the extent of using the same unusual newsreader, Maria!
I'm sure Paul is very flattered; I do hope it doesn't turn his head.

I've been very public who I am so Paul is extremely well aware who I am
as I've been posting extremely helpful tutorials for decades on Usenet.

All very laudable, I'm sure.

I'm particularly interested in Usenet Newsreaders; would you please
tell me more about yours? I've never heard of it before.


[the remainder of your interesting post left for context]

I haven't changed who I am in decades of posting scores of articles daily. However, I admire Paul (and others like Andy & Zaidy & Herbert, et al).

While I'm one of a kind, I don't have the social skills that they have.

Like they do though, I know the million things about "stuff" that most
people only know a half dozen of, where privacy is one of those things.

Most people know about six of the million things I know about privacy.

Where header privacy is one of those things, just as much as never reading from the same nntp server that wee post to is another one of those things.

People who least understand privacy deprecate it out of ignorance, where
Paul has always been understanding that the gift is in the article body.

The whole point of every thread is to add value to our tribal knowledge.
That was and is the point of this thread. To warn others with this PSA.

Those who claimed "notepad++ doesn't exsist on Linux" didn't read what was written in the original post, or, if they did, they didn't understand it.

That's my problem I guess, in that I wasn't descriptive enough.
For that I apologize since Notepad++ has nothing to do with the issue.

The editor didn't create the issue.
The editor just reacted to it.

Chromium (and to some extent, Firefox) creates the issue (so to speak).
I was just being kind and helpful, where I admire that Paul always is.

I know who is kind and helpful, and who isn't, where Paul has always been very helpful when adding value, even with a nice twist of added sarcasm.

Paul has a way of responding to the trolls who can never add any value,
which is why they troll, with far more kind-hearted aplomb than I can.

I respect Paul's acumen and his ability to add value in every post.
As for my newsreader, I wrote it on Solaris decades ago and ported it to Windows probably a decade or so ago, so all the header lines are bogus.

Just as the wrapping paper isn't the gift of the package inside, most
people who don't understand the thread topic seem to think the pretty wrapping paper which encloses the gift, 'is' the gift. It's not.

The value of any Usenet post is not in the headers, but in the body.

My value for Usenet is not in a collection of tens of thousands of headers over the years, but in the posting of hundreds if not thousands of articles that add value to the tribal knowledge of each particular newsgroup.

The value I'm striving to add in this thread is a kind-hearted helpful word to the wise that what tripped me up with invisible HTML could trip you up.

--
\|/
(((-))) - Mr +n!on, NPC

When we shake the ketchup bottle
At first none comes and then a lot'll.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On 2026-02-13 22:01, Maria Sophia wrote:

Carlos E. R. wrote:

On 2026-02-13 19:12, Maria Sophia wrote:

Carlos E. R. wrote:

...

Your tests confirm that Kate and LO Write handle the Chromium clipboard
in a way that avoids the issue. That is good information for the group.
It also helps narrow down which editors might react differently.

Since you run Linux every day, your input is valuable here. You can help
the team by checking one small thing that keeps the test simple.

Here is a short test that keeps things simple. 1. Copy a short plain- looking paragraph in Firefox. 2. Paste it into any editor you prefer. 3. Press Control+A and confirm that full selection works. 4. Repeat the
same steps using Chromium. 5. Compare only the behavior of the editor,
not the formatting.

Yes, I pasted into Kate, from both browsers, and ctrl-A works fine.

This keeps the test short and avoids long procedures, and it lets us see whether the difference between Firefox and Chromium shows up in your own Linux setup.

If both behave the same, that tells us the editor is choosing plain text.
If they differ, that suggests the editor is reacting to the HTML fragment that Chromium always provides. This is the PSA that I'm warning folks of.

Kate is a plain text editor, so it chooses the plain text part. LO lets
me choose (with shift-^V)

Note that Control+A is not a Windows feature. It is an editor feature.
On Linux:
a. Kate supports Control+A
b. LO Write supports Control+A
c. GVim supports Control+A
But many terminal editors do not.

So the key point is that while Control+A works on Linux, the behavior after
a Chromium paste can differ depending on how the editor interprets the clipboard formats.

Thanks again for checking this. Your Linux results help complete the
picture for everyone.

--
Cheers,
Carlos E.R.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On 2026-02-13 20:13:22 +0000, Carlos E. R. said:

On 2026-02-13 19:12, Maria Sophia wrote:

Carlos E. R. wrote:

I do a lot of research as I generally invest at least an hour or
two into many of my Usenet opening posts, where I currently
employ a thousand- line Windows Notepad++ macro that beautifully
cleans up non-ASCII garbage copied from both Firefox and
Chromium web output, where, only with Chromium pastes into
Notepad++ was the selection mechanism (i.e., Ctrl+A) inoperative.

How do you propose we test this in Linux? There is no notepad++.

Hi Carlos,

Thanks for asking, where I'll propose a test for Linux later, but first I
need you to understand that the problem exists across all platforms
(AFAIK).

Reacting to a perceived incredularity on your part, I simply ask (a bit
snarkily in jest so as to bring the conversation back to where it belongs), >> are we really prepared to claim that Linux users, who are those same people >> who have approximately seventeen text editors installed before breakfast,
have never once copied any text from Firefox or Chromium and pasted it into >> vi, vim, GVim, Kate, gedit, or any of the other editors that have existed
since the Pleistocene?

I copy paste rich text from Firefox into editors without problems. I do
not use Chrome, but I have it installed.

I have noticed a couple of small differences when using MacOS 10.13 /
High Sierra versions of old Safari and current Firefox:

1. Copying a link from a webpage.
In Safari and then pasting it into any text-based app (TextEdit,
Usenet messages, etc.), all you get is the on-page text of the
link, not the actual http web link itself. Using Firefox pastes
the http web link.

2. When copying text from a webpage with an embedded YouTube video.
In Safari, pasting the text into a text-based app give the HTML
code for the video with the video's web address. Using Firefox
just results in some error text about JavaScript where the video
should be.

I only ever use Chrome for the very very occasional websites that won't
work in Safari or Firefox - usually awful Government-based ones where
they still think everybody uses Windoze - so never bothered to see what
that does in these two cases.

Because the absence of native Notepad++ on Linux doesn't magically prevent >> clipboard testing. The clipboard exists. Chromium exists. Firefox exists.
Editors exist.
The only missing ingredient would be the willingness to actually try it.

If the question is whether the Chromium HTML-Fragment/StartHTML clipboard
quirk shows up on Linux, the answer depends entirely on whether the editor >> in question reacts to the presence of HTML on the clipboard.
Some may. Some may not. That's the whole point of the PSA!

To warn others that the behavior comes from the browser's clipboard
serialization, not from Windows, Notepad++, or any single platform.

So yes, of course this can be tested on Linux. It always could.
The prerequisite is acknowledging that "Notepad++ doesn't run on Linux" is >> not the airtight argument all the follow on posters seem to believe.

I pasted an entire web page from Chrome into Kate and LO Write, with no perceived problems.

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On 2026-02-13 22:31, Your Name wrote:

On 2026-02-13 20:13:22 +0000, Carlos E. R. said:

On 2026-02-13 19:12, Maria Sophia wrote:

Carlos E. R. wrote:

...

I copy paste rich text from Firefox into editors without problems. I
do not use Chrome, but I have it installed.

I have noticed a couple of small differences when using MacOS 10.13 /
High Sierra versions of old Safari and current Firefox:

1.-a Copying a link from a webpage.
-a-a In Safari and then pasting it into any text-based app (TextEdit,
-a-a Usenet messages, etc.), all you get is the on-page text of the
-a-a link, not the actual http web link itself. Using Firefox pastes
-a-a the http web link.

Which means that the conversion to plain text is done by the web
browser, and both do differently.

When I paste a text including a link into Thunderbird mail editor in
html mode, I get a working link if read in a complying html mail client. However, the sent mail contains two parts, one in html rich text, and
one plain text. The text part contains both the name of the link and the
URL inside parenthesis.

2.-a When copying text from a webpage with an embedded YouTube video.
-a-a In Safari, pasting the text into a text-based app give the HTML
-a-a code for the video with the video's web address. Using Firefox
-a-a just results in some error text about JavaScript where the video
-a-a should be.

I only ever use Chrome for the very very occasional websites that won't
work in Safari or Firefox - usually awful Government-based ones where
they still think everybody uses Windoze - so never bothered to see what
that does in these two cases.

Heh, here most government sites try to be "accessible", so they work in
FF. Specially tax sites: they make easy to pay. ;-)

Yesterday I had to renew the certificate used in FFx to identify and do
taxes, or identify to the health site and get a printout of my
medicines. The site included instructions and software for Windows,
Linux, Apple. And Android, I think.

The problems are with some commercial sites.
--
Cheers,
Carlos E.R.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Mr +n!on wrote:

I'm particularly interested in Usenet Newsreaders; would you please
tell me more about yours? I've never heard of it before.

Well, assuming (and hoping) that you're not the "sn!pe" troll, the
fundamental point of writing my own newsreader was simply two major privacy/usability goals because I happen to know a lot about both.
a. Full control of my privacy, and,
b. Full control of the $EDITOR (which, for me, is gVim)

Of the million things I do for usability and privacy, most people only know about six of them, but there are very many layers to my usability/privacy.

People who deprecate it are simply saying that they don't understand it.
And I don't expect them to understand usability or privacy, where, for example, almost everything I do is a single step on any platform I use.

And, I do astonishing things for privacy that most people couldn't think of
if you gave them a million years to ponder it, e.g., my Android contacts sqlite database is empty and yet I can do everything everyone else does.
Newsgroups: comp.mobile.android
Subject: FOSS Contacts app with privacy for backup & restore offline
Date: Thu, 5 Feb 2026 18:47:39 -0500
Message-ID: <10m3a6r$2mc6$1@nnrp.usenet.blueworldhosting.com>

The difference is I have privacy doing it, and they don't.
(note most "think" they have privacy but they don't understand privacy)
Newsgroups: comp.mobile.android
Subject: How many apps on your phone have contacts read permission?
Date: Tue, 10 Feb 2026 16:51:26 -0500
Message-ID: <10mg98t$pig$1@nnrp.usenet.blueworldhosting.com>

Note people in those threads "think" their contacts are safe, but they
don't even know what apps are reading them and what they do with them.

As I said, privacy is a million things, of which most people know only six.
For example, only the most respectful people have an empty contacts db.

And nobody who cares about privacy has a mothership account on their device. Nobody ever logs into anything using their real email either, if they care about privacy, so they have ways of obfuscating the origin.

My goals are always privacy and usability, where I probably maintain the
most organized computer hierarchy you've ever seen in your entire life.
<https://i.postimg.cc/fW38dhsX/android-windows-menus.jpg>

Privacy and usability are everything, to me.
Of the million things I do for both, most people can only do about six.

Given those two goals, my Usenet reader is just telnet tied to stunnel tied
to a bunch of ugly scripts and dictionaries which randomize the time zones periodically and randomize the headers at least once a year based on dictionaries culled off of Usenet over the years, so it's nothing special.

My stunnel entry, for example, for Wolfgang's server (which I think you are using) is below, but I have a section for every nntp server I've used.
[EternalSept]
client = yes
accept = 127.0.0.1:55503
connect = news.eternal-september.org:563
verifyChain = yes
CAfile = ca-certs.pem
checkHost = news.eternal-september.org
OCSPaia = yes

The use model is that everything shows up to me in gVim such that I don't
even know whom I'm responding to (as I never see *any* headers) as all I
see is the attribute in my gVim session, which is why sometimes I confuse Carlos with Chris, given they both seem to post similarly in my experience.

Likewise, Andy and Carlos and others have noticed that I don't do any character recognition, which, in the past, has caused them issues, so I've worked closely with them in the past few months to standardize the headers
by always adding these lines (previously my scripts tried to guess them):
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Because I don't use a "real" newsreader, there is no check that the
newsgroup line is correct since I have to type that manually when creating
a post, and sometimes others have noticed typos in my "Newsgroups" line.

But that's due to human error as my system isn't hardened against typos
in the newsgroup line like most "real" newsreaders would be hardened to.

Back to the point of this thread, I've recently hardened my use model
against Unicode creeping in, as most of my Usenet posts are extremely well researched as I came from the finest schools in the country and worked with the most technical companies on the planet in Silicon Valley, including
being on call for the windowless brick buildings around the world, most notably at Fort Meade back in the 90s but also in Israel & elsewhere.

It's important to note that of the million things I know about privacy,
most people only know six, so they consider anyone who does anything for privacy must be doing so for nefarious reasons, even as they can never
point out a single nefarious thing that the people do.

It's against Occam's Razor but most people are simply illogical since they don't take every fact into account when coming up with their conclusions.

The less they know about privacy, the more they claim that anyone who cares about privacy must be doing so because they're murdering little children.

The fact they don't murder the children doesn't stop them from deprecating that people who know privacy do a million things to maintain that privacy.

But back to the topic at hand, where I have a Notepad++ macro which I will append to this post so that you can understand how I ran into this issue.

Bear in mind that I correlate research from a wide variety of sources,
which I learned when I earned my PhD back east in one of the finest schools
in the country, so I needed this Notepad++ macro to normalize all the text, even as my editor is gVim (as Notepad++ is simply my normalizing process).

Since everything should be a single step, I control+c from a browser, and I hit the "n" command in my taskbar to bring up Notepad (via the
fantastically efficient Windows registry "App Paths" key) and then I
Control+V the clipboard into Notepad++ where I control+B the fixed text
back into the Windows Clipboard for pasting into gVim for further editing.

Notice I could skip the "n" step by leaving the Notepad++ window open (as
I'm all about eliminating every step) but in a Notepad Macro, apparently Scintilla won't let me kill the notepad session (although there's a key sequence for that but it's another step and I abhor extra steps).

Anyway, here's the Notepad++ macro that fixes the HTML fragment issues.
Notice it uses a clever trick of adding and deleting a space to do it.

<?xml version="1.0" encoding="UTF-8" ?>
<!-- C:\app\editor\txt\N++\shortcuts.xml for Windows Notepad++ (N++) -->
<!-- Automatically cleans fragments, converts to ASCII & copies to clipbrd -->
<!-- Use model: Control+V (paste) & Control+B (run the macro) -->
<!-- v3p9 20260211 N++ was not running the macro in the order shown -->
<!-- But it turned out any error causes an OLDER version to run. -->
<!-- Worse, when that happens, N++ overwrites this file -->
<!-- Worse, N++ is executing macro actions in a different order -->
<!-- than they appear in the XML so a total rewrite is needed in v4p0 -->
<!-- v3p8 20260211 U+2060 is driving me nuts so it's the first block now -->
<!-- v3p7 20260211 moved U+2060 up because it's the most disruptive -->
<!-- v3p6 20260211 U+2009 & U+200B not being converted properly -->
<!-- v3p5 20260211 fixed U+200B failing when U+200B is between ' & s -->
<!-- A 2nd pass was duplicated after apostrophe normalization rules -->
<!-- v3p4 20260211 added U+275E (heavy double quote right) -->
<!-- v3p3 20260211 added U+2009 (thin space) -->
<!-- v3p2 20260211 added seven new conversions after running testcases -->
<!-- U+02BE (modifier letter right half ring) -->
<!-- U+02BF (modifier letter left half ring) -->
<!-- U+201E (double low-9 quote) -->
<!-- U+201F (double high-reversed-9 quote) -->
<!-- U+275D (heavy double quote left) -->
<!-- U+275E (heavy double quote right) -->
<!-- U+2015 (horizontal bar) -->
<!-- U+2009 (thin space) -->
<!-- v3p1 20260211 reorganized into a dozen distinct categories -->
<!-- (1) control characters: U+000F U+0001 -->
<!-- (2) dashes & minus signs: U+2010 U+2011 U+2012 U+2212 -->
<!-- (3) zero-width characters: U+200C U+200B U+200D U+FEFF U+2060 -->
<!-- (4) special spaces: U+00A0 U+2007 U+202F U+200A U+2008 U+2006 -->
<!-- (5) apostrophe-like characters:
U+0F0C U+2018 U+2019 U+2032 U+02BC U+02B9 U+02C8 U+02EE
U+201B U+02CB U+A78C U+FF07 -->
<!-- (6) combining marks (remove after apostrophes):
U+0351 U+0307 U+0331 U+0335 U+0336 U+0337 U+0338 -->
<!-- (7) double-quote normalization: U+201C U+201D -->
<!-- (8) dash-like & ellipsis & HTML entities:
U+2026 &#151; U+2014 U+2013 &zwnj; -->
<!-- (9) bullets, math symbols, diacritics:
U+2022 U+8722 U+011F U+2009 U+00E1 U+0161 U+011B -->
<!-- (10) miscellaneous symbols:
U+2713 ASCII hyphen ` U+2192 U+00B0 U+00A9 U+2122 U+00AE -->
<!-- (11) invisible operators:
U+00AD U+2061 U+2062 U+2063 U+2064 U+180E -->
<!-- (12) line separators: U+2028 U+2029 U+0085 -->
<!-- v3p0 20260211 added combining marks U+0351 U+0307 U+0331 -->
<!-- v3p1 20260211 added apostrophe-like characters U+201B U+02CB -->
<!-- v2p9 20260211 moved U+2060 to be above apostrophe-related blocks -->
<!-- v2p8 20260211 fixed Chromium CF_HTML paste control+A anomaly -->
<!-- v2p7 20260211 added U+02EE modifier letter double apostrophe rule -->
<!-- v2p6 20260211 fixed U+02C8 modifier letter vertical line) rule -->
<!-- v2p5 20260211 fixed U+02B9 (modifier letter prime) rule -->
<!-- v2p4 20260211 removed one of two U+000F blocks -->
<!-- v2p3 20260211 removed two (duplicate) 1700 lines in U+0161 -->
<!-- v2p2 20260211 fixed all zero-width blocks to replace with nothing -->
<!-- v2p1 20260211 fixed BOM to replace with nothing -->
<!-- v2p0 20260210 cleaned (emptied out) closing sections of the file -->
<!-- v1p9 20260210 ported old shortcuts.xml to improve coverage -->
<!-- Cleans Chromium pasted text & normalizes Unicode to ASCII -->
<!-- Use model: paste (using control+v) & fix (using control+b) -->
<!-- The macro should 1st break CF_HTML fragment mode (so Ctrl+A works) -->
<!-- and then run the Unicode-to-ASCII cleanup on all the pasted text -->
<!-- cutting (control+x) the result back into the Windows clipboard -->
<!-- thereby leaving the N++ GUI empty & ready for the next paste-->

<!--
To break Scintilla's CF_HTML fragment mode, we need to make any edit.
We can insert a space & then delete that space, for example.
-->

<!-- Scintilla engine command meanings:
1700 = begin a new search/replace operation
1601 = set the search string (the Unicode character to find)
1625 = clear the replacement buffer
1602 = set the replacement string (ASCII equivalent)
1702 = execute Replace All
1701 = end this search/replace block
2001 = SCI_REPLACESEL (inserts a space)
2326 = SCI_DELETEBACK (deletes the space)
2013 = SCI_SELECTALL (selects everything)
2177 = SCI_CUT (cut all)
41001 = IDM_FILE_EXIT (close)
-->

<!-- When you paste from a Chromium-based app, the clipboard contains:
CF_UNICODETEXT (plain text) & CF_HTML (HTML fragment)
And sometimes CF_RTF where N++ prefers CF_HTML if available.

v2p0 fixes a N++ selection issue caused by CF_HTML pastes.
"HTML Paste Mode" prevents the "Control+A" from working.
"HTML paste mode" inserts HTML fragment as plain text
where Ctrl+A is disabled until the buffer is "normalized"
(until the first edit that breaks the fragment state)
-->

<!-- Below is garbage that N++ adds to shortcuts.xml -->
<NotepadPlus>
<InternalCommands>
<Shortcut id="43009" Ctrl="no" Alt="no" Shift="no" Key="0" />
</InternalCommands>
<Macros>
<!-- Above is garbage that N++ adds to shortcuts.xml -->

<!-- ASCII "control+b" Cleanup Macro -->
<Macro name="ASCII" Ctrl="yes" Alt="no" Shift="no" Key="66">

<!-- Begin Scintilla HTML-paste workaround top portion -->
<!-- Break Chromium CF_HTML fragment mode by adding & deleting a space-->
<Action type="0" message="2001" wParam="32" lParam="0" sParam="" />
<Action type="0" message="2326" wParam="0" lParam="0" sParam="" />
<!-- Select all text before running cleanup -->
<Action type="0" message="2013" wParam="0" lParam="0" sParam="" />
<!-- End Scintilla HTML-paste workaround top portion -->

<!-- BEGIN CONVERSION BLOCKS -->

<!-- U+2060 is driving me nuts so I'm making it the 1st block -->
<!-- U+2060 must be placed above the apostrophe-related blocks -->
<!-- Otherwise apostrophe block may skip over it -->
<!-- U+2060 is disruptive as it must be placed above zero-width too -->
<!-- Replace U+2060 (WORD JOINER) with nothing -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x2060;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- #1. CONTROL CHARACTERS (remove first) -->
<!-- Replace U+000F (SHIFT-OUT control character) with nothing -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x000F;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+0001 (SOH control character) with nothing -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x0001;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- #2. DASHES & MINUS SIGNS (safest to remove early) -->
<!-- Replace U+2010 (HYPHEN) with ASCII "-" -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x2010;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="-" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2011 (NON-BREAKING HYPHEN) with ASCII hyphen "-" -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x2011;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="-" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2012 (FIGURE DASH) with ASCII "-" -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x2012;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="-" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2212 (MINUS SIGN) with ASCII "-" -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x2212;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="-" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- #3. ZERO-WIDTH CHARACTERS (must be BEFORE apostrophes) -->

<!-- Replace U+200C (ZERO WIDTH NON-JOINER) with "" (nothing) -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x200C;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+200B (ZERO WIDTH SPACE) with nothing -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x200B;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+200D (ZERO WIDTH JOINER) with nothing -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x200D;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+FEFF (BOM) with nothing -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#xFEFF;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- #4. SPECIAL SPACES (convert to ASCII space) -->
<!-- Replace U+00A0 (NO-BREAK SPACE) with ASCII space -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x00A0;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam=" " />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2007 (FIGURE SPACE) with ASCII space -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x2007;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam=" " />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+202F (NARROW NO-BREAK SPACE) with ASCII space -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x202F;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam=" " />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+200A (HAIR SPACE) with ASCII space -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x200A;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam=" " />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2008 (PUNCTUATION SPACE) with ASCII space -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x2008;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam=" " />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2006 (SIX-PER-EM SPACE) with ASCII space -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x2006;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam=" " />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- #5. APOSTROPHE-LIKE CHARACTERS -->
<!-- Replace U+0F0C (TIBETAN MARK DELIMITER) with ASCII apostrophe "'" -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x0F0C;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="&apos;" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2018 (LEFT SINGLE QUOTE) with ASCII apostrophe "'" -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x2018;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="&apos;" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2019 (RIGHT SINGLE QUOTATION) with ASCII apostrophe "'" -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x2019;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="&apos;" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2032 (PRIME) with ASCII apostrophe -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x2032;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="&apos;" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+02BC (MODIFIER LETTER APOSTROPHE) with ASCII apostrophe -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x02BC;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="&apos;" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+02B9 (MODIFIER LETTER PRIME) with ASCII apostrophe "'" -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x02B9;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="&apos;" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+02C8 (MODIFIER LETTER VERTICAL) with ASCII apostrophe "'" -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x02C8;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="&apos;" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+02EE (MODIFIER DOUBLE APOSTROPHE) with ASCII apostrophe "'" -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x02EE;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="&apos;" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- U+201B (SINGLE HIGH-REVERSED-9 QUOTATION MARK) with apostrophe "'" -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x201B;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="&apos;" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+02CB (MODIFIER LETTER GRAVE ACCENT) with ASCII apostrophe "'" -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x02CB;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="&apos;" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- This is is a duplication which is after the apostrophes -->
<!-- When U+200B appears between two characters that were already replaced -->
<!-- the first pass fails to remove it, so I added this duplicate -->
<!-- Remove U+200B (ZERO-WIDTH SPACE) second pass -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x200B;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- #6. COMBINING MARKS (remove only after apostrophes are done) -->
<!-- Remove U+0351 (COMBINING RIGHT HALF RING ABOVE) -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x0351;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Remove U+0307 (COMBINING DOT ABOVE) -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x0307;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Remove U+0331 (COMBINING MACRON BELOW) -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x0331;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />


<!-- #7. DOUBLE-QUOTE NORMALIZATION -->
<!-- Replace U+201C (LEFT DOUBLE QUOTE) with ASCII double quote " -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x201C;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam='&quot;' />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+201D (RIGHT DOUBLE QUOTE) with ASCII double quote -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x201D;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam='&quot;' />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- #8. ELLIPSIS, EM DASH, EN DASH, HTML ENTITIES -->
<!-- Replace U+2026 (HORIZONTAL ELLIPSIS) with ASCII "..." -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x2026;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="..." />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace literal &#151; (HTML entity for EM DASH) with ASCII "-" -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&amp;#151;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="-" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2014 (EM DASH) with ASCII "-" -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x2014;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="-" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2013 (EN DASH) with ASCII "-" -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x2013;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="-" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace literal &zwnj; (ZERO WIDTH NON-JOINER entity) with ASCII "-" -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&zwnj;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="-" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- #9. BULLETS, MATH SYMBOLS, LETTERS WITH DIACRITICS -->
<!-- Replace U+2022 (BULLET) with ASCII "*" -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x2022;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="&#x002A;" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+8722 (MATHEMATICAL MINUS variant) with ASCII "&" -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x8722;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="&amp;" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+011F (LATIN SMALL G WITH BREVE) with ASCII "g" -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x11f;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="g" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+00E1 (LATIN SMALL A WITH ACUTE) with ASCII "a" -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#xe1;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="a" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+0161 (LATIN SMALL S WITH CARON) with ASCII "s" -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x161;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="s" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+011B (LATIN SMALL E WITH CARON) with ASCII "e" -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x11b;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="e" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- #10. MISCELLANEOUS SYMBOLS -->
<!-- Replace U+2713 (CHECK MARK) with ASCII space -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x2713;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam=" " />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace ASCII hyphen "-" with ASCII hyphen "-" (normalize) -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="-" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="-" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace backtick with ASCII single quote -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="`" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="&apos;" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace Unicode Arrow (U+2192) with ASCII dash greaterthan -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x2192;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="->" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace degree symbol with deg -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x00B0;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="deg" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace copyright symbol U??? with (C) -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x00A9;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="(C)" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace Trademark (U+2122) with (TM) -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x2122;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="(TM)" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace Registered (U+00AE) with (R) -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x00AE;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="(R)" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />


<!-- #11. INVISIBLE OPERATORS (remove) -->
<!-- Replace U+00AD (SOFT HYPHEN) with "" (remove completely) -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x00AD;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2061 (FUNCTION APPLICATION) with "" -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x2061;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2062 (INVISIBLE TIMES) with "" -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x2062;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2063 (INVISIBLE SEPARATOR) with "" -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x2063;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2064 (INVISIBLE PLUS) with "" -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x2064;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+180E (MONGOLIAN VOWEL SEPARATOR) with "" -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x180E;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- #12. LINE SEPARATORS -->
<!-- Replace U+2028 (LINE SEPARATOR) with ASCII newline -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x2028;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam=" " />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2029 (PARAGRAPH SEPARATOR) with ASCII newline -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x2029;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam=" " />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+0085 (NEXT LINE / NEL) with ASCII newline -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x0085;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam=" " />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+A78C (LATIN SMALL LETTER SALTILLO) with ASCII apostrophe "'" -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#xA78C;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="&apos;" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+FF07 (FULLWIDTH APOSTROPHE) with ASCII apostrophe "'" -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#xFF07;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="&apos;" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Remove U+0335 (COMBINING SHORT STROKE OVERLAY) -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x0335;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Remove U+0336 (COMBINING LONG STROKE OVERLAY) -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x0336;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Remove U+0337 (COMBINING SHORT SOLIDUS OVERLAY) -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x0337;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Remove U+0338 (COMBINING LONG SOLIDUS OVERLAY) -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x0338;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2043 (HYPHEN BULLET) with ASCII "-" -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x2043;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="-" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+02BE (MODIFIER LETTER RIGHT HALF RING) w/ ASCII apostrophe -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x02BE;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="&apos;" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+02BF (MODIFIER LETTER LEFT HALF RING) w/ ASCII apostrophe -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x02BF;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="&apos;" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+201E (DOUBLE LOW-9 QUOTATION MARK) w/ ASCII double quote -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x201E;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="&quot;" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+201F (DOUBLE HIGH-REVERSED-9 QUOTATION MARK) w/ dquote -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x201F;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="&quot;" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+275D (HEAVY DOUBLE QUOTATION MARK ORNAMENT LEFT) w/ dquote -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x275D;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="&quot;" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+275E (HEAVY DOUBLE QUOTATION MARK ORNAMENT RIGHT) w/ dquote -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x275E;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="&quot;" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2015 (HORIZONTAL BAR) with ASCII hyphen -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x2015;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="-" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2009 (THIN SPACE) with ASCII space -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x2009;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam=" " />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2009 (THIN SPACE) with ASCII space -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x2009;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam=" " />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- END OF CONVERSION BLOCKS -->

<!-- Begin Scintilla HTML-paste workaround bottom portion -->
<!-- Select all cleaned text -->
<Action type="0" message="2013" wParam="0" lParam="0" sParam="" />

<!-- Cut cleaned text to Windows clipboard -->
<Action type="0" message="2177" wParam="0" lParam="0" sParam="" />
<!-- End Scintilla HTML-paste workaround bottom portion -->

<!-- Close N++ -->
<Action type="2" message="41001" wParam="0" lParam="0" sParam="" />

<!-- N++ will save shortcuts.xml automatically as it
rewrites the file whenever shortcuts/macros/plugins change.
Some sections are required so empty sections will be recreated.
-->

</Macro>
</Macros>
<UserDefinedCommands>
</UserDefinedCommands>

<PluginCommands />
<ScintillaKeys />

</NotepadPlus>
--
If something takes ten steps, you drop it in half, & half again, & then in half again, until everything you do on any computing device is one step.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Carlos E. R. wrote:

Cross platforms alternatives are something to consider, if one is to
learn a new editor.

That's the beauty of vi since we learned it decades ago and our fingers
know it better than our mind does at this point, and it works on all
platforms (yes, even on Android although the "escape" part is a PITA).

For me, I only use Notepad++ to normalize web page copies from various
sources so that the punctuation is consistent, as I don't edit with it.

If I was a kid starting out today though, I probably wouldn't pick vi.
But, I'll go to my grave using vi since it's what I learned decades ago.

Note: I've tested every free Android text editor ever suggested on the
Android newsgroup and decided early on that vi was not a keeper at all. :)
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Maria Sophia <mariasophia@comprehension.com> wrote:

Mr +n!on wrote:

I'm particularly interested in Usenet Newsreaders; would you please
tell me more about yours? I've never heard of it before.

Well, assuming (and hoping) that you're not the "sn!pe" troll, the fundamental point of writing my own newsreader was simply two major privacy/usability goals because I happen to know a lot about both.
a. Full control of my privacy, and,
b. Full control of the $EDITOR (which, for me, is gVim)

Of the million things I do for usability and privacy, most people only know about six of them, but there are very many layers to my usability/privacy.

There's a lot to digest in your explanation! Thank you, I've left it
below for context. Apologies for rewrapping long lines, my 'reader
insisted.

I'm curious to know how it is that Paul happens to use the same 'reader
as you do; I haven't seen seen Ratcatcher/2.0.0.25 (Windows/20130802)
used elsewhere before.

People who deprecate it are simply saying that they don't understand it.
And I don't expect them to understand usability or privacy, where, for example, almost everything I do is a single step on any platform I use.

And, I do astonishing things for privacy that most people couldn't think of if you gave them a million years to ponder it, e.g., my Android contacts sqlite database is empty and yet I can do everything everyone else does.
Newsgroups: comp.mobile.android
Subject: FOSS Contacts app with privacy for backup & restore offline
Date: Thu, 5 Feb 2026 18:47:39 -0500
Message-ID: <10m3a6r$2mc6$1@nnrp.usenet.blueworldhosting.com>

The difference is I have privacy doing it, and they don't.
(note most "think" they have privacy but they don't understand privacy)
Newsgroups: comp.mobile.android
Subject: How many apps on your phone have contacts read permission?
Date: Tue, 10 Feb 2026 16:51:26 -0500
Message-ID: <10mg98t$pig$1@nnrp.usenet.blueworldhosting.com>

Note people in those threads "think" their contacts are safe, but they
don't even know what apps are reading them and what they do with them.

As I said, privacy is a million things, of which most people know only six. For example, only the most respectful people have an empty contacts db.

And nobody who cares about privacy has a mothership account on their device. Nobody ever logs into anything using their real email either, if they care about privacy, so they have ways of obfuscating the origin.

My goals are always privacy and usability, where I probably maintain the
most organized computer hierarchy you've ever seen in your entire life.
<https://i.postimg.cc/fW38dhsX/android-windows-menus.jpg>

Privacy and usability are everything, to me.
Of the million things I do for both, most people can only do about six.

Given those two goals, my Usenet reader is just telnet tied to stunnel tied to a bunch of ugly scripts and dictionaries which randomize the time zones periodically and randomize the headers at least once a year based on dictionaries culled off of Usenet over the years, so it's nothing special.

My stunnel entry, for example, for Wolfgang's server (which I think you are using) is below, but I have a section for every nntp server I've used.
[EternalSept]
client = yes
accept = 127.0.0.1:55503
connect = news.eternal-september.org:563
verifyChain = yes
CAfile = ca-certs.pem
checkHost = news.eternal-september.org
OCSPaia = yes

The use model is that everything shows up to me in gVim such that I don't even know whom I'm responding to (as I never see *any* headers) as all I
see is the attribute in my gVim session, which is why sometimes I confuse Carlos with Chris, given they both seem to post similarly in my experience.

Likewise, Andy and Carlos and others have noticed that I don't do any character recognition, which, in the past, has caused them issues, so I've worked closely with them in the past few months to standardize the headers
by always adding these lines (previously my scripts tried to guess them):
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Because I don't use a "real" newsreader, there is no check that the newsgroup line is correct since I have to type that manually when creating
a post, and sometimes others have noticed typos in my "Newsgroups" line.

But that's due to human error as my system isn't hardened against typos
in the newsgroup line like most "real" newsreaders would be hardened to.

Back to the point of this thread, I've recently hardened my use model
against Unicode creeping in, as most of my Usenet posts are extremely well researched as I came from the finest schools in the country and worked with the most technical companies on the planet in Silicon Valley, including
being on call for the windowless brick buildings around the world, most notably at Fort Meade back in the 90s but also in Israel & elsewhere.

It's important to note that of the million things I know about privacy,
most people only know six, so they consider anyone who does anything for privacy must be doing so for nefarious reasons, even as they can never
point out a single nefarious thing that the people do.

It's against Occam's Razor but most people are simply illogical since they don't take every fact into account when coming up with their conclusions.

The less they know about privacy, the more they claim that anyone who cares about privacy must be doing so because they're murdering little children.

The fact they don't murder the children doesn't stop them from deprecating that people who know privacy do a million things to maintain that privacy.

But back to the topic at hand, where I have a Notepad++ macro which I will append to this post so that you can understand how I ran into this issue.

Bear in mind that I correlate research from a wide variety of sources,
which I learned when I earned my PhD back east in one of the finest schools in the country, so I needed this Notepad++ macro to normalize all the text, even as my editor is gVim (as Notepad++ is simply my normalizing process).

Since everything should be a single step, I control+c from a browser, and I hit the "n" command in my taskbar to bring up Notepad (via the
fantastically efficient Windows registry "App Paths" key) and then I Control+V the clipboard into Notepad++ where I control+B the fixed text
back into the Windows Clipboard for pasting into gVim for further editing.

Notice I could skip the "n" step by leaving the Notepad++ window open (as
I'm all about eliminating every step) but in a Notepad Macro, apparently Scintilla won't let me kill the notepad session (although there's a key sequence for that but it's another step and I abhor extra steps).

Anyway, here's the Notepad++ macro that fixes the HTML fragment issues. Notice it uses a clever trick of adding and deleting a space to do it.

<?xml version="1.0" encoding="UTF-8" ?> <!--
C:\app\editor\txt\N++\shortcuts.xml for Windows Notepad++ (N++) --> <!--
Automatically cleans fragments, converts to ASCII & copies to clipbrd
--> <!-- Use model: Control+V (paste) & Control+B (run the macro) -->
<!-- v3p9 20260211 N++ was not running the macro in the order shown -->
<!-- But it turned out any error causes an OLDER version to run. -->
<!-- Worse, when that happens, N++ overwrites this file --> <!--
Worse, N++ is executing macro actions in a different order --> <!--
than they appear in the XML so a total rewrite is needed in v4p0 -->
<!-- v3p8 20260211 U+2060 is driving me nuts so it's the first block now
--> <!-- v3p7 20260211 moved U+2060 up because it's the most disruptive
--> <!-- v3p6 20260211 U+2009 & U+200B not being converted properly -->
<!-- v3p5 20260211 fixed U+200B failing when U+200B is between ' & s -->
<!-- A 2nd pass was duplicated after apostrophe normalization rules
--> <!-- v3p4 20260211 added U+275E (heavy double quote right) --> <!--
v3p3 20260211 added U+2009 (thin space) --> <!-- v3p2 20260211 added
seven new conversions after running testcases --> <!-- U+02BE
(modifier letter right half ring) --> <!-- U+02BF (modifier letter
left half ring) --> <!-- U+201E (double low-9 quote) --> <!-- U+201F
(double high-reversed-9 quote) --> <!-- U+275D (heavy double quote
left) --> <!-- U+275E (heavy double quote right) --> <!-- U+2015
(horizontal bar) --> <!-- U+2009 (thin space) --> <!-- v3p1 20260211
reorganized into a dozen distinct categories --> <!-- (1) control
characters: U+000F U+0001 --> <!-- (2) dashes & minus signs: U+2010
U+2011 U+2012 U+2212 --> <!-- (3) zero-width characters: U+200C U+200B
U+200D U+FEFF U+2060 --> <!-- (4) special spaces: U+00A0 U+2007 U+202F
U+200A U+2008 U+2006 --> <!-- (5) apostrophe-like characters: U+0F0C
U+2018 U+2019 U+2032 U+02BC U+02B9 U+02C8 U+02EE U+201B U+02CB U+A78C
U+FF07 --> <!-- (6) combining marks (remove after apostrophes): U+0351
U+0307 U+0331 U+0335 U+0336 U+0337 U+0338 --> <!-- (7) double-quote
normalization: U+201C U+201D --> <!-- (8) dash-like & ellipsis & HTML
entities: U+2026 &#151; U+2014 U+2013 &zwnj; --> <!-- (9) bullets, math
symbols, diacritics: U+2022 U+8722 U+011F U+2009 U+00E1 U+0161 U+011B
--> <!-- (10) miscellaneous symbols: U+2713 ASCII hyphen ` U+2192 U+00B0
U+00A9 U+2122 U+00AE --> <!-- (11) invisible operators: U+00AD U+2061
U+2062 U+2063 U+2064 U+180E --> <!-- (12) line separators: U+2028 U+2029
U+0085 --> <!-- v3p0 20260211 added combining marks U+0351 U+0307 U+0331
--> <!-- v3p1 20260211 added apostrophe-like characters U+201B U+02CB
--> <!-- v2p9 20260211 moved U+2060 to be above apostrophe-related
blocks --> <!-- v2p8 20260211 fixed Chromium CF_HTML paste control+A
anomaly --> <!-- v2p7 20260211 added U+02EE modifier letter double
apostrophe rule --> <!-- v2p6 20260211 fixed U+02C8 modifier letter
vertical line) rule --> <!-- v2p5 20260211 fixed U+02B9 (modifier letter
prime) rule --> <!-- v2p4 20260211 removed one of two U+000F blocks -->
<!-- v2p3 20260211 removed two (duplicate) 1700 lines in U+0161 --> <!--
v2p2 20260211 fixed all zero-width blocks to replace with nothing -->
<!-- v2p1 20260211 fixed BOM to replace with nothing --> <!-- v2p0
20260210 cleaned (emptied out) closing sections of the file --> <!--
v1p9 20260210 ported old shortcuts.xml to improve coverage --> <!--
Cleans Chromium pasted text & normalizes Unicode to ASCII --> <!-- Use
model: paste (using control+v) & fix (using control+b) --> <!-- The
macro should 1st break CF_HTML fragment mode (so Ctrl+A works) --> <!--
and then run the Unicode-to-ASCII cleanup on all the pasted text -->
<!-- cutting (control+x) the result back into the Windows clipboard -->
<!-- thereby leaving the N++ GUI empty & ready for the next paste-->

<!-- To break Scintilla's CF_HTML fragment mode, we need to make any
edit. We can insert a space & then delete that space, for example. -->

<!-- Scintilla engine command meanings: 1700 = begin a new
search/replace operation 1601 = set the search string (the Unicode
character to find) 1625 = clear the replacement buffer 1602 = set the
replacement string (ASCII equivalent) 1702 = execute Replace All 1701 =
end this search/replace block 2001 = SCI_REPLACESEL (inserts a space)
2326 = SCI_DELETEBACK (deletes the space) 2013 = SCI_SELECTALL (selects
everything) 2177 = SCI_CUT (cut all) 41001 = IDM_FILE_EXIT (close) -->

<!-- When you paste from a Chromium-based app, the clipboard contains:
CF_UNICODETEXT (plain text) & CF_HTML (HTML fragment) And sometimes
CF_RTF where N++ prefers CF_HTML if available.

v2p0 fixes a N++ selection issue caused by CF_HTML pastes. "HTML
Paste Mode" prevents the "Control+A" from working. "HTML paste mode"
inserts HTML fragment as plain text where Ctrl+A is disabled until the
buffer is "normalized" (until the first edit that breaks the fragment
state) -->

<!-- Below is garbage that N++ adds to shortcuts.xml --> <NotepadPlus>
<InternalCommands> <Shortcut id="43009" Ctrl="no" Alt="no" Shift="no"
Key="0" /> </InternalCommands> <Macros> <!-- Above is garbage that N++
adds to shortcuts.xml -->

<!-- ASCII "control+b" Cleanup Macro --> Macro name="ASCII" Ctrl="yes"
<Alt="no" Shift="no" Key="66">

<!-- Begin Scintilla HTML-paste workaround top portion --> !-- Break
<Chromium CF_HTML fragment mode by adding & deleting a space--> Action
<type="0" message="2001" wParam="32" lParam="0" sParam="" /> Action
<type="0" message="2326" wParam="0" lParam="0" sParam="" /> !-- Select
<all text before running cleanup --> Action type="0" message="2013"
<wParam="0" lParam="0" sParam="" /> !-- End Scintilla HTML-paste
<workaround top portion -->

<!-- BEGIN CONVERSION BLOCKS -->

<!-- U+2060 is driving me nuts so I'm making it the 1st block --> !--
<U+2060 must be placed above the apostrophe-related blocks --> !--
<Otherwise apostrophe block may skip over it --> !-- U+2060 is
<disruptive as it must be placed above zero-width too --> !-- Replace
<U+2060 (WORD JOINER) with nothing --> Action type="3" message="1700"
<wParam="0" lParam="0" sParam="" /> Action type="3" message="1601"
<wParam="0" lParam="0" sParam="&#x2060;" /> Action type="3"
<message="1625" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1602" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1702" wParam="0" lParam="768" sParam="" /> Action type="3"
<message="1701" wParam="0" lParam="1609" sParam="" />

<!-- #1. CONTROL CHARACTERS (remove first) --> !-- Replace U+000F
<(SHIFT-OUT control character) with nothing --> Action type="3"
<message="1700" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1601" wParam="0" lParam="0" sParam="&#x000F;" /> Action
<type="3" message="1625" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1602" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1702" wParam="0" lParam="768" sParam="" /> Action
<type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+0001 (SOH control character) with nothing --> Action
<type="3" message="1700" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1601" wParam="0" lParam="0" sParam="&#x0001;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- #2. DASHES & MINUS SIGNS (safest to remove early) --> !-- Replace
<U+2010 (HYPHEN) with ASCII "-" --> Action type="3" message="1700"
<wParam="0" lParam="0" sParam="" /> Action type="3" message="1601"
<wParam="0" lParam="0" sParam="&#x2010;" /> Action type="3"
<message="1625" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1602" wParam="0" lParam="0" sParam="-" /> Action type="3"
<message="1702" wParam="0" lParam="768" sParam="" /> Action type="3"
<message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2011 (NON-BREAKING HYPHEN) with ASCII hyphen "-" -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x2011;"
</> Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="-" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2012 (FIGURE DASH) with ASCII "-" --> Action type="3"
<message="1700" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1601" wParam="0" lParam="0" sParam="&#x2012;" /> Action
<type="3" message="1625" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1602" wParam="0" lParam="0" sParam="-" /> Action
<type="3" message="1702" wParam="0" lParam="768" sParam="" /> Action
<type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2212 (MINUS SIGN) with ASCII "-" --> Action type="3"
<message="1700" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1601" wParam="0" lParam="0" sParam="&#x2212;" /> Action
<type="3" message="1625" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1602" wParam="0" lParam="0" sParam="-" /> Action
<type="3" message="1702" wParam="0" lParam="768" sParam="" /> Action
<type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- #3. ZERO-WIDTH CHARACTERS (must be BEFORE apostrophes) -->

<!-- Replace U+200C (ZERO WIDTH NON-JOINER) with "" (nothing) --> Action
<type="3" message="1700" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1601" wParam="0" lParam="0" sParam="&#x200C;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+200B (ZERO WIDTH SPACE) with nothing --> Action type="3"
<message="1700" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1601" wParam="0" lParam="0" sParam="&#x200B;" /> Action
<type="3" message="1625" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1602" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1702" wParam="0" lParam="768" sParam="" /> Action
<type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+200D (ZERO WIDTH JOINER) with nothing --> Action type="3"
<message="1700" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1601" wParam="0" lParam="0" sParam="&#x200D;" /> Action
<type="3" message="1625" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1602" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1702" wParam="0" lParam="768" sParam="" /> Action
<type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+FEFF (BOM) with nothing --> Action type="3"
<message="1700" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1601" wParam="0" lParam="0" sParam="&#xFEFF;" /> Action
<type="3" message="1625" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1602" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1702" wParam="0" lParam="768" sParam="" /> Action
<type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- #4. SPECIAL SPACES (convert to ASCII space) --> !-- Replace U+00A0
<(NO-BREAK SPACE) with ASCII space --> Action type="3" message="1700"
<wParam="0" lParam="0" sParam="" /> Action type="3" message="1601"
<wParam="0" lParam="0" sParam="&#x00A0;" /> Action type="3"
<message="1625" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1602" wParam="0" lParam="0" sParam=" " /> Action type="3"
<message="1702" wParam="0" lParam="768" sParam="" /> Action type="3"
<message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2007 (FIGURE SPACE) with ASCII space --> Action type="3"
<message="1700" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1601" wParam="0" lParam="0" sParam="&#x2007;" /> Action
<type="3" message="1625" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1602" wParam="0" lParam="0" sParam=" " /> Action
<type="3" message="1702" wParam="0" lParam="768" sParam="" /> Action
<type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+202F (NARROW NO-BREAK SPACE) with ASCII space --> Action
<type="3" message="1700" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1601" wParam="0" lParam="0" sParam="&#x202F;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam=" " />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+200A (HAIR SPACE) with ASCII space --> Action type="3"
<message="1700" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1601" wParam="0" lParam="0" sParam="&#x200A;" /> Action
<type="3" message="1625" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1602" wParam="0" lParam="0" sParam=" " /> Action
<type="3" message="1702" wParam="0" lParam="768" sParam="" /> Action
<type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2008 (PUNCTUATION SPACE) with ASCII space --> Action
<type="3" message="1700" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1601" wParam="0" lParam="0" sParam="&#x2008;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam=" " />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2006 (SIX-PER-EM SPACE) with ASCII space --> Action
<type="3" message="1700" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1601" wParam="0" lParam="0" sParam="&#x2006;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam=" " />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- #5. APOSTROPHE-LIKE CHARACTERS --> !-- Replace U+0F0C (TIBETAN MARK
<DELIMITER) with ASCII apostrophe "'" --> Action type="3"
<message="1700" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1601" wParam="0" lParam="0" sParam="&#x0F0C;" /> Action
<type="3" message="1625" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1602" wParam="0" lParam="0" sParam="&apos;" /> Action
<type="3" message="1702" wParam="0" lParam="768" sParam="" /> Action
<type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2018 (LEFT SINGLE QUOTE) with ASCII apostrophe "'" -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x2018;"
</> Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="&apos;" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2019 (RIGHT SINGLE QUOTATION) with ASCII apostrophe "'"
<--> Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x2019;"
</> Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="&apos;" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2032 (PRIME) with ASCII apostrophe --> Action type="3"
<message="1700" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1601" wParam="0" lParam="0" sParam="&#x2032;" /> Action
<type="3" message="1625" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1602" wParam="0" lParam="0" sParam="&apos;" /> Action
<type="3" message="1702" wParam="0" lParam="768" sParam="" /> Action
<type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+02BC (MODIFIER LETTER APOSTROPHE) with ASCII apostrophe
<--> Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x02BC;"
</> Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="&apos;" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+02B9 (MODIFIER LETTER PRIME) with ASCII apostrophe "'"
<--> Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x02B9;"
</> Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="&apos;" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+02C8 (MODIFIER LETTER VERTICAL) with ASCII apostrophe "'"
<--> Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x02C8;"
</> Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="&apos;" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+02EE (MODIFIER DOUBLE APOSTROPHE) with ASCII apostrophe
<"'" --> Action type="3" message="1700" wParam="0" lParam="0" sParam=""
</> Action type="3" message="1601" wParam="0" lParam="0"
<sParam="&#x02EE;" /> Action type="3" message="1625" wParam="0"
<lParam="0" sParam="" /> Action type="3" message="1602" wParam="0"
<lParam="0" sParam="&apos;" /> Action type="3" message="1702" wParam="0"
<lParam="768" sParam="" /> Action type="3" message="1701" wParam="0"
<lParam="1609" sParam="" />

<!-- U+201B (SINGLE HIGH-REVERSED-9 QUOTATION MARK) with apostrophe "'"
<--> Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x201B;"
</> Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="&apos;" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+02CB (MODIFIER LETTER GRAVE ACCENT) with ASCII apostrophe
<"'" --> Action type="3" message="1700" wParam="0" lParam="0" sParam=""
</> Action type="3" message="1601" wParam="0" lParam="0"
<sParam="&#x02CB;" /> Action type="3" message="1625" wParam="0"
<lParam="0" sParam="" /> Action type="3" message="1602" wParam="0"
<lParam="0" sParam="&apos;" /> Action type="3" message="1702" wParam="0"
<lParam="768" sParam="" /> Action type="3" message="1701" wParam="0"
<lParam="1609" sParam="" />

<!-- This is is a duplication which is after the apostrophes --> !--
<When U+200B appears between two characters that were already replaced
<--> !-- the first pass fails to remove it, so I added this duplicate
<--> !-- Remove U+200B (ZERO-WIDTH SPACE) second pass --> Action
<type="3" message="1700" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1601" wParam="0" lParam="0" sParam="&#x200B;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- #6. COMBINING MARKS (remove only after apostrophes are done) -->
<!-- Remove U+0351 (COMBINING RIGHT HALF RING ABOVE) --> Action type="3"
<message="1700" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1601" wParam="0" lParam="0" sParam="&#x0351;" /> Action
<type="3" message="1625" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1602" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1702" wParam="0" lParam="768" sParam="" /> Action
<type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Remove U+0307 (COMBINING DOT ABOVE) --> Action type="3"
<message="1700" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1601" wParam="0" lParam="0" sParam="&#x0307;" /> Action
<type="3" message="1625" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1602" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1702" wParam="0" lParam="768" sParam="" /> Action
<type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Remove U+0331 (COMBINING MACRON BELOW) --> Action type="3"
<message="1700" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1601" wParam="0" lParam="0" sParam="&#x0331;" /> Action
<type="3" message="1625" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1602" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1702" wParam="0" lParam="768" sParam="" /> Action
<type="3" message="1701" wParam="0" lParam="1609" sParam="" />


<!-- #7. DOUBLE-QUOTE NORMALIZATION --> !-- Replace U+201C (LEFT DOUBLE
<QUOTE) with ASCII double quote " --> Action type="3" message="1700"
<wParam="0" lParam="0" sParam="" /> Action type="3" message="1601"
<wParam="0" lParam="0" sParam="&#x201C;" /> Action type="3"
<message="1625" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1602" wParam="0" lParam="0" sParam='&quot;' /> Action type="3"
<message="1702" wParam="0" lParam="768" sParam="" /> Action type="3"
<message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+201D (RIGHT DOUBLE QUOTE) with ASCII double quote -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x201D;"
</> Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam='&quot;' />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- #8. ELLIPSIS, EM DASH, EN DASH, HTML ENTITIES --> !-- Replace
<U+2026 (HORIZONTAL ELLIPSIS) with ASCII "..." --> Action type="3"
<message="1700" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1601" wParam="0" lParam="0" sParam="&#x2026;" /> Action
<type="3" message="1625" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1602" wParam="0" lParam="0" sParam="..." /> Action
<type="3" message="1702" wParam="0" lParam="768" sParam="" /> Action
<type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace literal &#151; (HTML entity for EM DASH) with ASCII "-" -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0"
<sParam="&amp;#151;" /> Action type="3" message="1625" wParam="0"
<lParam="0" sParam="" /> Action type="3" message="1602" wParam="0"
<lParam="0" sParam="-" /> Action type="3" message="1702" wParam="0"
<lParam="768" sParam="" /> Action type="3" message="1701" wParam="0"
<lParam="1609" sParam="" />

<!-- Replace U+2014 (EM DASH) with ASCII "-" --> Action type="3"
<message="1700" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1601" wParam="0" lParam="0" sParam="&#x2014;" /> Action
<type="3" message="1625" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1602" wParam="0" lParam="0" sParam="-" /> Action
<type="3" message="1702" wParam="0" lParam="768" sParam="" /> Action
<type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2013 (EN DASH) with ASCII "-" --> Action type="3"
<message="1700" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1601" wParam="0" lParam="0" sParam="&#x2013;" /> Action
<type="3" message="1625" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1602" wParam="0" lParam="0" sParam="-" /> Action
<type="3" message="1702" wParam="0" lParam="768" sParam="" /> Action
<type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace literal &zwnj; (ZERO WIDTH NON-JOINER entity) with ASCII
<"-" --> Action type="3" message="1700" wParam="0" lParam="0" sParam=""
</> Action type="3" message="1601" wParam="0" lParam="0" sParam="&zwnj;"
</> Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="-" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- #9. BULLETS, MATH SYMBOLS, LETTERS WITH DIACRITICS --> !-- Replace
<U+2022 (BULLET) with ASCII "*" --> Action type="3" message="1700"
<wParam="0" lParam="0" sParam="" /> Action type="3" message="1601"
<wParam="0" lParam="0" sParam="&#x2022;" /> Action type="3"
<message="1625" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1602" wParam="0" lParam="0" sParam="&#x002A;" /> Action
<type="3" message="1702" wParam="0" lParam="768" sParam="" /> Action
<type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+8722 (MATHEMATICAL MINUS variant) with ASCII "&" -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x8722;"
</> Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="&amp;" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+011F (LATIN SMALL G WITH BREVE) with ASCII "g" --> Action
<type="3" message="1700" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1601" wParam="0" lParam="0" sParam="&#x11f;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="g" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+00E1 (LATIN SMALL A WITH ACUTE) with ASCII "a" --> Action
<type="3" message="1700" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1601" wParam="0" lParam="0" sParam="&#xe1;" /> Action
<type="3" message="1625" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1602" wParam="0" lParam="0" sParam="a" /> Action
<type="3" message="1702" wParam="0" lParam="768" sParam="" /> Action
<type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+0161 (LATIN SMALL S WITH CARON) with ASCII "s" --> Action
<type="3" message="1700" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1601" wParam="0" lParam="0" sParam="&#x161;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="s" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+011B (LATIN SMALL E WITH CARON) with ASCII "e" --> Action
<type="3" message="1700" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1601" wParam="0" lParam="0" sParam="&#x11b;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="e" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- #10. MISCELLANEOUS SYMBOLS --> !-- Replace U+2713 (CHECK MARK) with
<ASCII space --> Action type="3" message="1700" wParam="0" lParam="0"
<sParam="" /> Action type="3" message="1601" wParam="0" lParam="0"
<sParam="&#x2713;" /> Action type="3" message="1625" wParam="0"
<lParam="0" sParam="" /> Action type="3" message="1602" wParam="0"
<lParam="0" sParam=" " /> Action type="3" message="1702" wParam="0"
<lParam="768" sParam="" /> Action type="3" message="1701" wParam="0"
<lParam="1609" sParam="" />

<!-- Replace ASCII hyphen "-" with ASCII hyphen "-" (normalize) -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="-" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="-" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace backtick with ASCII single quote --> Action type="3"
<message="1700" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1601" wParam="0" lParam="0" sParam="`" /> Action type="3"
<message="1625" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1602" wParam="0" lParam="0" sParam="&apos;" /> Action type="3"
<message="1702" wParam="0" lParam="768" sParam="" /> Action type="3"
<message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace Unicode Arrow (U+2192) with ASCII dash greaterthan -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x2192;"
</> Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="->" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace degree symbol with deg --> Action type="3" message="1700"
<wParam="0" lParam="0" sParam="" /> Action type="3" message="1601"
<wParam="0" lParam="0" sParam="&#x00B0;" /> Action type="3"
<message="1625" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1602" wParam="0" lParam="0" sParam="deg" /> Action type="3"
<message="1702" wParam="0" lParam="768" sParam="" /> Action type="3"
<message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace copyright symbol U??? with (C) --> Action type="3"
<message="1700" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1601" wParam="0" lParam="0" sParam="&#x00A9;" /> Action
<type="3" message="1625" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1602" wParam="0" lParam="0" sParam="(C)" /> Action
<type="3" message="1702" wParam="0" lParam="768" sParam="" /> Action
<type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace Trademark (U+2122) with (TM) --> Action type="3"
<message="1700" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1601" wParam="0" lParam="0" sParam="&#x2122;" /> Action
<type="3" message="1625" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1602" wParam="0" lParam="0" sParam="(TM)" /> Action
<type="3" message="1702" wParam="0" lParam="768" sParam="" /> Action
<type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace Registered (U+00AE) with (R) --> Action type="3"
<message="1700" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1601" wParam="0" lParam="0" sParam="&#x00AE;" /> Action
<type="3" message="1625" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1602" wParam="0" lParam="0" sParam="(R)" /> Action
<type="3" message="1702" wParam="0" lParam="768" sParam="" /> Action
<type="3" message="1701" wParam="0" lParam="1609" sParam="" />


<!-- #11. INVISIBLE OPERATORS (remove) --> !-- Replace U+00AD (SOFT
<HYPHEN) with "" (remove completely) --> Action type="3" message="1700"
<wParam="0" lParam="0" sParam="" /> Action type="3" message="1601"
<wParam="0" lParam="0" sParam="&#x00AD;" /> Action type="3"
<message="1625" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1602" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1702" wParam="0" lParam="768" sParam="" /> Action type="3"
<message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2061 (FUNCTION APPLICATION) with "" --> Action type="3"
<message="1700" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1601" wParam="0" lParam="0" sParam="&#x2061;" /> Action
<type="3" message="1625" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1602" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1702" wParam="0" lParam="768" sParam="" /> Action
<type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2062 (INVISIBLE TIMES) with "" --> Action type="3"
<message="1700" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1601" wParam="0" lParam="0" sParam="&#x2062;" /> Action
<type="3" message="1625" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1602" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1702" wParam="0" lParam="768" sParam="" /> Action
<type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2063 (INVISIBLE SEPARATOR) with "" --> Action type="3"
<message="1700" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1601" wParam="0" lParam="0" sParam="&#x2063;" /> Action
<type="3" message="1625" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1602" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1702" wParam="0" lParam="768" sParam="" /> Action
<type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2064 (INVISIBLE PLUS) with "" --> Action type="3"
<message="1700" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1601" wParam="0" lParam="0" sParam="&#x2064;" /> Action
<type="3" message="1625" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1602" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1702" wParam="0" lParam="768" sParam="" /> Action
<type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+180E (MONGOLIAN VOWEL SEPARATOR) with "" --> Action
<type="3" message="1700" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1601" wParam="0" lParam="0" sParam="&#x180E;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- #12. LINE SEPARATORS --> !-- Replace U+2028 (LINE SEPARATOR) with
<ASCII newline --> Action type="3" message="1700" wParam="0" lParam="0"
<sParam="" /> Action type="3" message="1601" wParam="0" lParam="0"
<sParam="&#x2028;" /> Action type="3" message="1625" wParam="0"
<lParam="0" sParam="" /> Action type="3" message="1602" wParam="0"
<lParam="0" sParam=" " /> Action type="3" message="1702" wParam="0"
<lParam="768" sParam="" /> Action type="3" message="1701" wParam="0"
<lParam="1609" sParam="" />

<!-- Replace U+2029 (PARAGRAPH SEPARATOR) with ASCII newline --> Action
<type="3" message="1700" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1601" wParam="0" lParam="0" sParam="&#x2029;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam=" " />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+0085 (NEXT LINE / NEL) with ASCII newline --> Action
<type="3" message="1700" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1601" wParam="0" lParam="0" sParam="&#x0085;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam=" " />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+A78C (LATIN SMALL LETTER SALTILLO) with ASCII apostrophe
<"'" --> Action type="3" message="1700" wParam="0" lParam="0" sParam=""
</> Action type="3" message="1601" wParam="0" lParam="0"
<sParam="&#xA78C;" /> Action type="3" message="1625" wParam="0"
<lParam="0" sParam="" /> Action type="3" message="1602" wParam="0"
<lParam="0" sParam="&apos;" /> Action type="3" message="1702" wParam="0"
<lParam="768" sParam="" /> Action type="3" message="1701" wParam="0"
<lParam="1609" sParam="" />

<!-- Replace U+FF07 (FULLWIDTH APOSTROPHE) with ASCII apostrophe "'" -->
<Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#xFF07;"
</> Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="&apos;" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Remove U+0335 (COMBINING SHORT STROKE OVERLAY) --> Action type="3"
<message="1700" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1601" wParam="0" lParam="0" sParam="&#x0335;" /> Action
<type="3" message="1625" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1602" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1702" wParam="0" lParam="768" sParam="" /> Action
<type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Remove U+0336 (COMBINING LONG STROKE OVERLAY) --> Action type="3"
<message="1700" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1601" wParam="0" lParam="0" sParam="&#x0336;" /> Action
<type="3" message="1625" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1602" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1702" wParam="0" lParam="768" sParam="" /> Action
<type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Remove U+0337 (COMBINING SHORT SOLIDUS OVERLAY) --> Action type="3"
<message="1700" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1601" wParam="0" lParam="0" sParam="&#x0337;" /> Action
<type="3" message="1625" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1602" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1702" wParam="0" lParam="768" sParam="" /> Action
<type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Remove U+0338 (COMBINING LONG SOLIDUS OVERLAY) --> Action type="3"
<message="1700" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1601" wParam="0" lParam="0" sParam="&#x0338;" /> Action
<type="3" message="1625" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1602" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1702" wParam="0" lParam="768" sParam="" /> Action
<type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2043 (HYPHEN BULLET) with ASCII "-" --> Action type="3"
<message="1700" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1601" wParam="0" lParam="0" sParam="&#x2043;" /> Action
<type="3" message="1625" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1602" wParam="0" lParam="0" sParam="-" /> Action
<type="3" message="1702" wParam="0" lParam="768" sParam="" /> Action
<type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+02BE (MODIFIER LETTER RIGHT HALF RING) w/ ASCII
<apostrophe --> Action type="3" message="1700" wParam="0" lParam="0"
<sParam="" /> Action type="3" message="1601" wParam="0" lParam="0"
<sParam="&#x02BE;" /> Action type="3" message="1625" wParam="0"
<lParam="0" sParam="" /> Action type="3" message="1602" wParam="0"
<lParam="0" sParam="&apos;" /> Action type="3" message="1702" wParam="0"
<lParam="768" sParam="" /> Action type="3" message="1701" wParam="0"
<lParam="1609" sParam="" />

<!-- Replace U+02BF (MODIFIER LETTER LEFT HALF RING) w/ ASCII apostrophe
<--> Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x02BF;"
</> Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="&apos;" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+201E (DOUBLE LOW-9 QUOTATION MARK) w/ ASCII double quote
<--> Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x201E;"
</> Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="&quot;" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+201F (DOUBLE HIGH-REVERSED-9 QUOTATION MARK) w/ dquote
<--> Action type="3" message="1700" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1601" wParam="0" lParam="0" sParam="&#x201F;"
</> Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="&quot;" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+275D (HEAVY DOUBLE QUOTATION MARK ORNAMENT LEFT) w/
<dquote --> Action type="3" message="1700" wParam="0" lParam="0"
<sParam="" /> Action type="3" message="1601" wParam="0" lParam="0"
<sParam="&#x275D;" /> Action type="3" message="1625" wParam="0"
<lParam="0" sParam="" /> Action type="3" message="1602" wParam="0"
<lParam="0" sParam="&quot;" /> Action type="3" message="1702" wParam="0"
<lParam="768" sParam="" /> Action type="3" message="1701" wParam="0"
<lParam="1609" sParam="" />

<!-- Replace U+275E (HEAVY DOUBLE QUOTATION MARK ORNAMENT RIGHT) w/
<dquote --> Action type="3" message="1700" wParam="0" lParam="0"
<sParam="" /> Action type="3" message="1601" wParam="0" lParam="0"
<sParam="&#x275E;" /> Action type="3" message="1625" wParam="0"
<lParam="0" sParam="" /> Action type="3" message="1602" wParam="0"
<lParam="0" sParam="&quot;" /> Action type="3" message="1702" wParam="0"
<lParam="768" sParam="" /> Action type="3" message="1701" wParam="0"
<lParam="1609" sParam="" />

<!-- Replace U+2015 (HORIZONTAL BAR) with ASCII hyphen --> Action
<type="3" message="1700" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1601" wParam="0" lParam="0" sParam="&#x2015;" />
<Action type="3" message="1625" wParam="0" lParam="0" sParam="" />
<Action type="3" message="1602" wParam="0" lParam="0" sParam="-" />
<Action type="3" message="1702" wParam="0" lParam="768" sParam="" />
<Action type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2009 (THIN SPACE) with ASCII space --> Action type="3"
<message="1700" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1601" wParam="0" lParam="0" sParam="&#x2009;" /> Action
<type="3" message="1625" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1602" wParam="0" lParam="0" sParam=" " /> Action
<type="3" message="1702" wParam="0" lParam="768" sParam="" /> Action
<type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- Replace U+2009 (THIN SPACE) with ASCII space --> Action type="3"
<message="1700" wParam="0" lParam="0" sParam="" /> Action type="3"
<message="1601" wParam="0" lParam="0" sParam="&#x2009;" /> Action
<type="3" message="1625" wParam="0" lParam="0" sParam="" /> Action
<type="3" message="1602" wParam="0" lParam="0" sParam=" " /> Action
<type="3" message="1702" wParam="0" lParam="768" sParam="" /> Action
<type="3" message="1701" wParam="0" lParam="1609" sParam="" />

<!-- END OF CONVERSION BLOCKS -->

<!-- Begin Scintilla HTML-paste workaround bottom portion --> !-- Select
<all cleaned text --> Action type="0" message="2013" wParam="0"
<lParam="0" sParam="" />

<!-- Cut cleaned text to Windows clipboard --> Action type="0"
<message="2177" wParam="0" lParam="0" sParam="" /> !-- End Scintilla
<HTML-paste workaround bottom portion -->

<!-- Close N++ --> Action type="2" message="41001" wParam="0" lParam="0"
<sParam="" />

<!-- N++ will save shortcuts.xml automatically as it rewrites the file
whenever shortcuts/macros/plugins change. Some sections are required so
empty sections will be recreated. -->

</Macro>
</Macros>
<UserDefinedCommands>
</UserDefinedCommands>

<PluginCommands />
<ScintillaKeys />

</NotepadPlus>

--
\|/
(((-))) - Mr +n!on, NPC

When we shake the ketchup bottle
At first none comes and then a lot'll.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On 2026-02-13 23:27, Mr |un!on wrote:

Maria Sophia <mariasophia@comprehension.com> wrote:

Mr |un!on wrote:

I'm particularly interested in Usenet Newsreaders; would you please
tell me more about yours? I've never heard of it before.

Well, assuming (and hoping) that you're not the "sn!pe" troll, the
fundamental point of writing my own newsreader was simply two major
privacy/usability goals because I happen to know a lot about both.
a. Full control of my privacy, and,
b. Full control of the $EDITOR (which, for me, is gVim)

Of the million things I do for usability and privacy, most people only know >> about six of them, but there are very many layers to my usability/privacy. >>

There's a lot to digest in your explanation! Thank you, I've left it
below for context.

Please don't.

Apologies for rewrapping long lines, my 'reader
insisted.

I'm curious to know how it is that Paul happens to use the same 'reader
as you do; I haven't seen seen Ratcatcher/2.0.0.25 (Windows/20130802)
used elsewhere before.

Because Arlen uses faked random headers in his posts. This was in his
reply somewhere. He is not using the same reader as Paul, he is using
scripts.
--
Cheers,
Carlos E.R.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Carlos E. R. <robin_listas@es.invalid> wrote:

There's a lot to digest in your explanation! Thank you, I've left it
below for context.

Please don't.

By all means; I left it only in case I was accused of subterfuge.

Apologies for rewrapping long lines, my 'reader
insisted.

I'm curious to know how it is that Paul happens to use the same 'reader
as you do; I haven't seen seen Ratcatcher/2.0.0.25 (Windows/20130802)
used elsewhere before.

Because Arlen uses faked random headers in his posts. This was in his
reply somewhere. He is not using the same reader as Paul, he is using scripts.

Noted, thank you. Arlen's reputation precedes him.
--
\|/
(((-))) - Mr +n!on, NPC

When we shake the ketchup bottle
At first none comes and then a lot'll.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On Thu, 12 Feb 2026 15:26:32 -0500, Maria Sophia wrote:

The HTML Fragment issue showed up for me on Windows when pasting
into Notepad++ from Chromium, but the underlying cause applies to
all platforms because it apparently comes from how Chromium
generates clipboard data,, which is DIFFERENT from how Firefox does
the same copy/paste tasks.

Even as Firefox uses a different and more conservative clipboard
path, the problem seemed almost random because the editor is
intimately involved.

Do you have a tool for inspecting the clipboard contents? In
particular, listing the different formats in which the clipboard
contents are being offered? That might shed more light on what exactly
is going on.

Here are some examples from my Linux system.

* Copying some text from Emacs:

ldo@theon:~> wl-paste -l
GTK_TEXT_BUFFER_CONTENTS
application/x-gtk-text-buffer-rich-text
text/plain;charset=utf-8
UTF8_STRING
COMPOUND_TEXT
TEXT
text/plain
STRING
text/plain;charset=utf-8
text/plain
SAVE_TARGETS

* Copying some text from a web page in Firefox:

ldo@theon:~> wl-paste -l
text/html
text/_moz_htmlcontext
text/_moz_htmlinfo
text/plain;charset=utf-8
UTF8_STRING
COMPOUND_TEXT
TEXT
text/plain
STRING
text/plain;charset=utf-8
text/plain
text/x-moz-url-priv
SAVE_TARGETS

* Copying the same text from the same web page in Chromium:

ldo@theon:~> wl-paste -l
chromium/x-source-url
text/html
STRING
TEXT
UTF8_STRING
text/plain
text/plain;charset=utf-8
chromium/x-internal-source-rfh-token
text/plain;charset=utf-8

* Copying the above text from KDE Konsole:

ldo@theon:~> wl-paste -l
text/plain
text/html
text/plain;charset=utf-8
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On Fri, 13 Feb 2026 16:01:16 -0500, Maria Sophia wrote:

Given this is a set of operating system and Firefox newsgroups, the point
is that Chromium always places HTML on the clipboard along with plain text, while Firefox often provides only plain text on all consumer platforms.

I wonder what you mean by rCLconsumer platformsrCY ... ?
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On Fri, 13 Feb 2026 17:17:53 -0000 (UTC), Jim Jackson wrote:

On 2026-02-13, R Daneel Olivaw <Danni@hyperspace.vogon.gov.invalid> wrote:

Wine?

Youy mean it can be done if we get drunk?

rCLWhatrCOs wrong with being drunk?rCY

rCLAsk a glass of water.rCY
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On Fri, 13 Feb 2026 13:37:15 -0500, Maria Sophia wrote:

The contrast I'm trying to help explain to this newsgroup is that
Firefox often advertises only text/plain unless the selection
contains real markup.

ldo@theon:~> cat test.txt
Hi there.
ldo@theon:~> firefox test.txt
[in Firefox, do Select All and Copy.]

[back in a terminal session:]
ldo@theon:~> wl-paste -l
text/html
text/_moz_htmlcontext
text/_moz_htmlinfo
text/plain;charset=utf-8
UTF8_STRING
COMPOUND_TEXT
TEXT
text/plain
STRING
text/plain;charset=utf-8
text/plain
text/x-moz-url-priv
SAVE_TARGETS

ldo@theon:~> wl-paste -t text/html
<meta http-equiv="content-type" content="text/html; charset=utf-8"><pre>Hi there.
</pre>

So ... nope.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On Fri, 2/13/2026 12:17 PM, Jim Jackson wrote:

On 2026-02-13, R Daneel Olivaw <Danni@hyperspace.vogon.gov.invalid> wrote:

Carlos E. R. wrote:

On 2026-02-12 21:26, Maria Sophia wrote:

PSA: Clipboard differences between Chromium & Firefox across platforms >>>>
I do a lot of research as I generally invest at least an hour or two into >>>> many of my Usenet opening posts, where I currently employ a thousand-line >>>> Windows Notepad++ macro that beautifully cleans up non-ASCII garbage
copied
from both Firefox and Chromium web output, where, only with Chromium
pastes
into Notepad++ was the selection mechanism (i.e., Ctrl+A) inoperative.

How do you propose we test this in Linux? There is no notepad++.

...

Wine?

Youy mean it can be done if we get drunk?

I don't think mixing WINE with Wine is a good
idea, as WINE constitutes "heavy machinery". But
in this particular case, all the ("SNAP") preparation was
done by someone sober. It's actually two wrongs
to make a thing, SNAP+WINE=Notepad++

Paul
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Carlos E. R. wrote:

faked random headers in his posts.
he is using scripts.
This was in his reply

Hi Carlos,

You're responding to the Snit-like Sn!pe, whom we all know well has an Alan Baker far-left-of-mount-stupid mentality, where what the troll is
attempting to do is correlate Paul's posts with mine (for his own reasons), where, since he doesn't understand anything, he thinks there value to be gleaned from the newsreader line in the headers (where I've obliged him).

Fundamentally, it appears he's accusing Paul of being me, or vice versa,
simply based on the fact we're both way over the top in knowledge &
kindness, which, I think, is a complement since Paul has far more knowledge than I will ever have and his social skills are better'n mine with when he deals with never-ending trolls from the likes of Snit, Sn!pe & Slootweg.

It's effort for me to plonk someone as it takes away from my goal of
learning from people and edifying others on this thread about clipboard differences on all platforms between the Mozilla and Chromium web browsers.

Suffice to say though that I've solved the problem to my satisfaction,
which allowed me to spend the time to join S!ipe with Snit & Alan Baker.

In decades of posting on Usenet, I've only had to plonk a handful of
posters, so rest assured I read everything you've ever posted to this ng.

I appreciate that you tested this HTML Fragment issue on Linux with your editors, where the problem mostly shows up with editors that are hyper-sensitive to the hidden HTML Fragment metadata Chromium includes.
-
I only plonk people who have shown themselves to be completely incapable
of ever adding value in any situation, any context, any time, anywhere.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Lawrence D'Oliveiro wrote:

Given this is a set of operating system and Firefox newsgroups, the point
is that Chromium always places HTML on the clipboard along with plain text, >> while Firefox often provides only plain text on all consumer platforms.

I wonder what you mean by "consumer platforms" ... ?

Hi Lawrence,

That's a fair-enough question for us to ponder... where I mostly had meant
the most common ecosystems owned by people like us that run FF & Chrome.

Such as Linux, Windows, macOS, Android, iOS/iPadOS.

Although, technically, neither Firefox nor Chromium actually run on iOS or iPadOS due to Apple's WebKit requirement, so they're really just paint-like meaningless skins over Safari's engine rather than true Gecko or Blink.

That's why iOS/iPadOS can never have the privacy of the real Tor browser.

To your point, though, since, for example, ChromeOS runs both Firefox & Chromium natively (Firefox through the Linux subsystem, Chromium as the
system browser), it probably should also qualify as a consumer platform as well.

And if we broaden the definition even slightly, we can add the various BSDs
and even Illumos/Solaris derivatives, all of which have working ports of Firefox and Chromium despite not being Linux at all.
--
If we think we understand something, we don't. But if we think we don't
quite yet understand something, then we're just beginning to understand it.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Lawrence DoOliveiro wrote:

Do you have a tool for inspecting the clipboard contents? In
particular, listing the different formats in which the clipboard
contents are being offered? That might shed more light on what exactly
is going on.

Here are some examples from my Linux system.

* Copying some text from Emacs:

ldo@theon:~> wl-paste -l
GTK_TEXT_BUFFER_CONTENTS
application/x-gtk-text-buffer-rich-text
text/plain;charset=utf-8
UTF8_STRING
COMPOUND_TEXT
TEXT
text/plain
STRING
text/plain;charset=utf-8
text/plain
SAVE_TARGETS

* Copying some text from a web page in Firefox:

ldo@theon:~> wl-paste -l
text/html
text/_moz_htmlcontext
text/_moz_htmlinfo
text/plain;charset=utf-8
UTF8_STRING
COMPOUND_TEXT
TEXT
text/plain
STRING
text/plain;charset=utf-8
text/plain
text/x-moz-url-priv
SAVE_TARGETS

* Copying the same text from the same web page in Chromium:

ldo@theon:~> wl-paste -l
chromium/x-source-url
text/html
STRING
TEXT
UTF8_STRING
text/plain
text/plain;charset=utf-8
chromium/x-internal-source-rfh-token
text/plain;charset=utf-8

* Copying the above text from KDE Konsole:

ldo@theon:~> wl-paste -l
text/plain
text/html
text/plain;charset=utf-8

Hi Lawrence,

Wow. That was excellent detective work you just did for the team!
Thanks for taking the time to run all those Linux-based wl-paste tests.

Of all who posted, only you, Carlos, and I have been testing this and
reporting back what we've found, all of which confirms the basic premise.

Each section of your output helps confirm the pattern I was trying to
describe in the PSA and your suggestion for me to do the same resonated.

Your Emacs example shows a plain-text-oriented application offering a
large set of classic X11 and GTK text targets. That is the baseline
case, nothing surprising there.

Your Firefox example shows exactly what we had expected. Firefox adds the _moz_htmlcontext and _moz_htmlinfo formats only when it believes the
selection contains meaningful structure. That matches what I intuitively
see on Windows, where Firefox emits HTML Format only when needed.

But I didn't have a clipboard inspector until I looked one up just now.
<https://www.nirsoft.net/utils/inside_clipboard.html>
<https://www.nirsoft.net/utils/insideclipboard.zip>
Name: insideclipboard.zip
Size: 42653 bytes (41 KiB)
SHA256: 13E71984F63C0C50E7710B92505D0B5BF422CA5214B61EAF51E02CB8A4B63B7E

Name: InsideClipboard.exe
Size: 37376 bytes (36 KiB)
SHA256: 89C7BF5136E5BC1572325197C97FEA33FBC9F106B04AA924BEB58B5A687D2DF7

InsideClipboard v1.30
This utility works on any version of Windows, from Win XP to Win 11.
"Each time that you copy something into the clipboard for pasting
it into another application, the copied data is saved into multiple
formats. The main clipboard application of Windows only display the
basic clipboard formats, like text and bitmaps, but doesn't display
the list of all formats that are stored in the clipboard.
InsideClipboard is a small utility that displays the binary content
of all formats that are currently stored in the clipboard, and allow
you to save the content of specific format into a binary file."

The pot of gold on the other end of the rainbow though was your Chromium example results where Chromium always emits text/html plus its own internal chromium/x-* formats, even when the selection looks like plain text.

That is the same behavior I ran into on Windows, where the HTML Fragment
block is always present and can influence how the plain text stream is
parsed by editors that do not expect it.

Your Konsole example shows a terminal that offers plain text first but
still includes text/html. That reinforces the assumption on my part that
the editor or application decides which format to request, and that the presence of HTML can change how the paste is interpreted.

All of your Linux results line up with what I saw on Windows. The
difference is not the platform, it is the clipboard formats that
Chromium places on the clipboard (which differ from what FF places).

I will try the NirSoft InsideClipboard tool tomorrow so I can see the
Windows formats directly, the same way your wl-paste -l output shows
them on Linux. If you have a simple test procedure you want me to run
with InsideClipboard, let me know and I will follow it exactly.

Otherwise, off the cuff, what I think I may try is this procedure
which keeps the variables controlled so we can compare results.

1. Open a plain-looking web page in Firefox.
2. Select a short block of visible text, no images.
3. Press Ctrl+C.
4. Open InsideClipboard and note every format listed.
5. Save the list or take a screenshot for reference.

6. Repeat the same steps in Chromium:
A. Same page.
B. Same text selection.
C. Press Ctrl+C.
D. Open NirSoft InsideClipboard and note the formats.

7. Compare the two lists. The key question is whether Chromium
always includes HTML Format and related offsets even when the
selection looks like plain text, and whether Firefox omits
HTML Format when it decides the selection has no structure.

8. If I want a third comparison, I can paste the same selection into
Notepad++ and then check InsideClipboard again. I think the formats
will disappear after the paste, which would confirm that the metadata
never enters the file buffer (which is why Notepad++ hex editor never
saw anything).

If I follow these steps tomorrow, maybe can line up the Windows results
with the wl-paste output you showed on Linux.

Thanks again for running the detailed tests which prove what we've
experienced the hard way, and for suggesting I see a clipboard inspector.

Do you think this test will suffice to sync up with your efforts?
--
There are two kinds of people on Usenet, one of which can add value.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Carlos E. R. wrote:

I don't have Chromium, I have Chrome.

Hi Carlos,

Just to be clear, as far as anyone has stated, any chromium-based browser
and any mozilla-based browser should show the respective attributes of this
PSA that Lawrence D'Oliveiro & you were testing for the team on Linux.

Lawrence kindly published his results in this post for others to benefit.
From: Lawrence DoOliveiro <ldo@nz.invalid>
Newsgroups: alt.comp.software.firefox,comp.sys.mac.system,alt.os.linux
Subject: Re: PSA: Clipboard differences between Chromium & Firefox across platforms
Date: Fri, 13 Feb 2026 23:17:22 -0000 (UTC)
Message-ID: <10mobe2$2nt13$1@dont-email.me>

From what I gather, he definitely confirmed this PSA in his Linux tests.
He used a command that shows every clipboard format currently stored.

He first kindly and very helpfully outlined this basic test:
---------------------------------
* Copying some text from Emacs:

ldo@theon:~> wl-paste -l
GTK_TEXT_BUFFER_CONTENTS
application/x-gtk-text-buffer-rich-text
text/plain;charset=utf-8
UTF8_STRING
COMPOUND_TEXT
TEXT
text/plain
STRING
text/plain;charset=utf-8
text/plain
SAVE_TARGETS
---------------------------------

For those not familiar with Linux (where I'm rusty myself),
1. Emacs is a text editor.
2. wl-paste -l means list all clipboard formats.
3. The long list of names are the formats Emacs puts on the clipboard.
4. They are all plain-text-related formats.
5. Nothing HTML related appears here.
This is his baseline case, showing what a plain text editor exports.

Then Lawrence kindly posted his next block.
---------------------------------
* Copying some text from a web page in Firefox:

ldo@theon:~> wl-paste -l
text/html
text/_moz_htmlcontext
text/_moz_htmlinfo
text/plain;charset=utf-8
UTF8_STRING
COMPOUND_TEXT
TEXT
text/plain
STRING
text/plain;charset=utf-8
text/plain
text/x-moz-url-priv
SAVE_TARGETS
---------------------------------

For those not familiar with Firefox browsers,
1. He copied text from Firefox.
2. Firefox now offers text/html,
which is the HTML version of the selection.
3. Firefox also adds two internal formats:
_moz_htmlcontext and _moz_htmlinfo.
4. These are Firefox specific metadata formats.
5. Firefox still includes plain text formats.
This matches the PSA as Firefox emits HTML only when
it thinks it is needed.

The next block is the pot of gold at the end of the rainbow!
---------------------------------
* Copying the same text from the same web page in Chromium:

ldo@theon:~> wl-paste -l
chromium/x-source-url
text/html
STRING
TEXT
UTF8_STRING
text/plain
text/plain;charset=utf-8
chromium/x-internal-source-rfh-token
text/plain;charset=utf-8
---------------------------------

For those not familiar with Chromium browsers,

1. He copied the same page & same text, but copied in Chromium.
2. Chromium always emits text/html, even if the selection looks plain.
3. Chromium also emits chromium/x-* internal formats.
These are Chromium specific metadata formats.
4. Chromium includes plain text formats too.
5. This is the behavior that caused my Windows issue as
Chromium always includes HTML

Then he added a KDE Konsole test.
---------------------------------
* Copying the above text from KDE Konsole:

ldo@theon:~> wl-paste -l
text/plain
text/html
text/plain;charset=utf-8
---------------------------------

For those not familiar with Linux consoles,
1. KDE Konsole is a terminal emulator.
2. It offers plain text first.
3. It still includes text/html.
Again, the editor decides which format to request.

I may be wrong but it seems that Lawrence's tests show that even terminals
may include HTML depending on the environment.
A. Emacs offers only plain text formats.
B. Firefox offers HTML only when it thinks the selection has structure.
C. Chromium always offers HTML plus internal formats.
His tests showed different applications expose different sets of formats.

The editor decides which format to use when pasting.
This matches the PSA exactly.

Do you think you might be able to reproduce his tests on your Linux box?
I'll try the same on my Windows box using the Nirsoft InsideClipboard tool.
<https://www.nirsoft.net/utils/inside_clipboard.html>
<https://www.nirsoft.net/utils/insideclipboard.zip>
--
On Usenet, good people help others out of their kindness & generosity.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Lawrence D'Oliveiro wrote:

On Fri, 13 Feb 2026 13:37:15 -0500, Maria Sophia wrote:

The contrast I'm trying to help explain to this newsgroup is that
Firefox often advertises only text/plain unless the selection
contains real markup.

ldo@theon:~> cat test.txt
Hi there.
ldo@theon:~> firefox test.txt
[in Firefox, do Select All and Copy.]

[back in a terminal session:]
ldo@theon:~> wl-paste -l
text/html
text/_moz_htmlcontext
text/_moz_htmlinfo
text/plain;charset=utf-8
UTF8_STRING
COMPOUND_TEXT
TEXT
text/plain
STRING
text/plain;charset=utf-8
text/plain
text/x-moz-url-priv
SAVE_TARGETS

ldo@theon:~> wl-paste -t text/html
<meta http-equiv="content-type" content="text/html; charset=utf-8"><pre>Hi there.
</pre>

So ... nope.

Hi Lawrence,

OMG! That's beautiful!

That changes one of my assumptions!

My brain is wired for Occam's Razor, but to be always 100% logically
correct, I needed to know what you just proved - which I had not known.

Until now!

Thank you for confirming that Chromium and Firefox both put text/html on
the clipboard (even as Chromiumos HTML flavor is apparently structured in a
way that confuses Notepad++, while Firefoxos is not).

Thanks!

That's a really helpful unexpected demonstration of what's going on with respect to the PSA's claims I made earlier.

I stand corrected. Both put text/html on the clipboard!
But differently so!

Thank you for confirming what is really happening with Firefox.

Your test above makes it abundantly clear that Firefox apparently *always* advertises a 'text/html' flavor on the clipboard, even when the selected content contains no markup at all.

In the plain-text case, Firefox just wraps the text in a minimal HTML
structure (a '<pre>' block plus a meta tag), so the presence of 'text/html' doesn't imply that the original selection had any real HTML in it.

Also useful in your output was to see the extra Mozilla-specific types ('text/_moz_htmlcontext', 'text/_moz_htmlinfo') showing up unexpectedly.

Given this PSA is discussing an oft-obscured gotcha, I appreciate you
running the experiment and sharing the results along with your other tests, which I have summarized below in the hopes you can check out my analysis.

It seems you first kindly & very helpfully outlined this basic test:
---------------------------------
* Copying some text from Emacs:
ldo@theon:~> wl-paste -l
GTK_TEXT_BUFFER_CONTENTS
application/x-gtk-text-buffer-rich-text
text/plain;charset=utf-8
UTF8_STRING
COMPOUND_TEXT
TEXT
text/plain
STRING
text/plain;charset=utf-8
text/plain
SAVE_TARGETS
---------------------------------

For those not familiar with Linux (where I'm rusty myself),
1. Emacs is a text editor.
2. wl-paste -l means list all clipboard formats.
3. The long list of names are the formats Emacs puts on the clipboard.
4. They are all plain-text-related formats.
5. Nothing HTML related appears here.
This is your baseline case, showing what a plain text editor exports.

Then you kindly posted your next block.
---------------------------------
* Copying some text from a web page in Firefox:
ldo@theon:~> wl-paste -l
text/html
text/_moz_htmlcontext
text/_moz_htmlinfo
text/plain;charset=utf-8
UTF8_STRING
COMPOUND_TEXT
TEXT
text/plain
STRING
text/plain;charset=utf-8
text/plain
text/x-moz-url-priv
SAVE_TARGETS
---------------------------------

For those not familiar with Firefox browsers,
1. You copied text from Firefox.
2. Firefox apparently always offers text/html,
which is the HTML version of the selection
that you reproduced which I hadn't thought was there!
3. Firefox also unexpectedly adds two internal formats:
_moz_htmlcontext and _moz_htmlinfo.
4. Apparently these are Firefox specific metadata formats.
5. Firefox still includes plain text formats.
This test clarifies one errant assumption in the PSA
since both Firefox & Chromium are adding the text/html,
only differently so.

The next block showed how Chromium did things in the same setup.
---------------------------------
* Copying the same text from the same web page in Chromium:
ldo@theon:~> wl-paste -l
chromium/x-source-url
text/html
STRING
TEXT
UTF8_STRING
text/plain
text/plain;charset=utf-8
chromium/x-internal-source-rfh-token
text/plain;charset=utf-8
---------------------------------

For those not familiar with Chromium browsers,
1. You copied the same page & same text, but copied in Chromium.
2. Chromium always emits text/html, even if the selection looks plain.
3. Chromium also emits chromium/x-* internal formats.
These are Chromium specific metadata formats.
4. Chromium includes plain text formats too.
5. This is the behavior that caused my Windows issue as
Chromium often includes HTML that screws up Notepad++ selection.

Then you kindly added a KDE Konsole sanity check.
---------------------------------
* Copying the above text from KDE Konsole:
ldo@theon:~> wl-paste -l
text/plain
text/html
text/plain;charset=utf-8
---------------------------------

For those not familiar with Linux consoles,
1. KDE Konsole is a terminal emulator.
2. It offers plain text first.
3. It still includes text/html.
Again, the editor decides which format to request.

Your generously run tests seem to show that even terminals
may include HTML depending on the environment.
A. Emacs offers only plain text formats.
B. Firefox offers HTML only when it thinks the selection has structure.
C. Chromium always offers HTML plus internal formats.
Different applications expose different sets of formats.

Is it true the editor decides which format to use when pasting?
I'll try to run tests on my Windows box using Nirsoft InsideClipboard.
<https://www.nirsoft.net/utils/inside_clipboard.html>
<https://www.nirsoft.net/utils/insideclipboard.zip>
--
On Usenet, good people help others out of their kindness & generosity.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On Sun, 15 Feb 2026 07:54:11 -0500, Paul wrote:
[snip]

There's no guarantee any clipboards softwares will
even agree on what is on the clipboard. Some of the
clipboard items could be automatic translations of
things submitted by the sourcing application. And
Wayland being a latecomer, of course it's going to have
to do weird shit, to get a name for itself.

Firefox supports all three serving options, as would a Chromium.

Wayland, Xwayland (temporary X11 option for older programs), Xorg (original X11 still available)

A person doing testing, has to find two clipboard managers (Wayland one, X11 one),

and, don't forget, X11 not only supports a "CLIPBOARD" selection, but also supports both "PRIMARY"
and "SECONDARY" selection (and even an arbitrary number of application specific selections).
Additionally, it offers 8 "cut buffers" (CUTBUFFER0 through CUTBUFFER7) for the same purposes.
(see https://x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html and related)

That means that, in testing in X11, the tester would have to test at least 11 different
"clipboard" combinations.

have three login options,
to do some tests. And even then, who knows whether the answer is based on hard reasons underneath.

--
Lew Pitcher
"In Skills We Trust"
Not LLM output - I'm just like this.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On 2026-02-15 13:54, Paul wrote:

On Sun, 2/15/2026 7:13 AM, Carlos E. R. wrote:

On 2026-02-15 07:52, Maria Sophia wrote:

Carlos E. R. wrote:

I can not run his command, anyway:

cer@Laicolasse:~> wl-paste
Failed to connect to a Wayland server
cer@Laicolasse:~> wl-paste --help
Usage:
-a-a-a-awl-paste [options]
Paste content from the Wayland clipboard.-a <===========

Options:
-a-a-a-a-n, --no-newline-a-a-a Do not append a newline character.
-a-a-a-a-l, --list-types-a-a-a Instead of pasting, list the offered types. >> -a-a-a-a-p, --primary-a-a-a-a-a-a-a Use the "primary" clipboard.
-a-a-a-a-w, --watch command-a-a-a Run a command each time the selection changes.
-a-a-a-a-t, --type mime/type-a-a-a Override the inferred MIME type for the content.
-a-a-a-a-s, --seat seat-name-a-a-a Pick the seat to work with.
-a-a-a-a-v, --version-a-a-a-a-a-a-a Display version info.
-a-a-a-a-h, --help-a-a-a-a-a-a-a Display this message.
Mandatory arguments to long options are mandatory for short options too.

See wl-clipboard(1) for more details.
cer@Laicolasse:~>

I use X, not wayland.

There's no guarantee any clipboards softwares will
even agree on what is on the clipboard. Some of the
clipboard items could be automatic translations of
things submitted by the sourcing application. And
Wayland being a latecomer, of course it's going to have
to do weird shit, to get a name for itself.

Firefox supports all three serving options, as would a Chromium.

Wayland, Xwayland (temporary X11 option for older programs), Xorg (original X11 still available)

A person doing testing, has to find two clipboard managers (Wayland one, X11 one), have three login options,
to do some tests. And even then, who knows whether the answer is based on hard reasons underneath.

I found several tools doing things with the clipboard. One letting you
access content from previous operations. But I did not see one listing
the contents of the clipboard.

Not being a Linux programmer, I'm not aware of the many clipboards you
or Lew mentions. I only know two types:

- An ancient method accessed solely with the mouse
- A newer method accessed via menu or shortcuts.

Different, but with some apps they mix.
--
Cheers,
Carlos E.R.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Carlos E. R. wrote:

Do you think you might be able to reproduce his tests on your Linux box?

I already tested and found no bug. I don't see what else you want to find out.

Hi Carlos,

I wish to thank you for your kind and helpful assistance, along that of
others like Lawrence who ran the definitive test procedure that I am only slowly beginning to understand the sheer brilliant elegance of.

Regarding ONLY your comment:
"I already tested and found no bug."
I don't think anyone suggested there was a bug, where we're all simply
openly and honestly discussing a, oh, shall we say, "quirk" in the system.

Regarding your honest and kind question of where else you can help out:
"I don't see what else you want to find out."
I think we have it all at this point, so there may be nothing more to do.

i. There is no bug.
ii. It's just the way it works.
iii. And, this PSA is posted to inform people what to watch out for.

If this "quirk" never bites you, then you never needed this PSA at all. However, it bit me because I solve every problem (if I can) that comes up.

And what "came up" was when I pasted Chromium text into Notepad, often I couldn't 'select' the text to convert it, which boggled my mind at first.

I looked for hidden characters, but there are none.
The text looks normal.

Take two notepad++ sessions, and look at them in a hex editor.
Neither looks different.

Yet one won't select (control+A).
The other will.

Huh?
WTF?

So it bit me bad.
Hours (and hours) of debugging.

As we all know now, the problem isn't the $EDITOR.
And, in a way, there is no "problem".

The problem is only if we run into this in the future, we will be armed
with the answer so we won't waste time tracking it down like I did.

Many thanks go to you, Carlos, Lawrence and Paul, all of whom openly and honestly discussed the technical issues to the best of their abilities.

All of you know far more than I do about this stuff, particularly on Linux,
so I think we formed an ad hoc well-honed team to validate the PSA with one VERY IMPORTANT correction given I was unaware of Lawrence's test in the OP.

Lawrence helpfully showed that both Firefox and Chromium do this.
It's just that Chromium does it differently.
--
On Usenet, wizened old men discuss topics of interest, where we each add
our own flavor of value so that the group, as a whole, benefits greatly.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Carlos E. R. wrote:

I found several tools doing things with the clipboard. One letting you access content from previous operations. But I did not see one listing
the contents of the clipboard.

Not being a Linux programmer, I'm not aware of the many clipboards you
or Lew mentions. I only know two types:

- An ancient method accessed solely with the mouse
- A newer method accessed via menu or shortcuts.

Different, but with some apps they mix.

Hi Carlos,

You're in good hands with Lew and Paul on the Linux side, since I haven't
used it as a daily drive since the Solaris/Redhat/Centos/Ubuntu days.

I think the issue you raised here is that Lawrence was running his tests
under Wayland, which is why his command was wl-paste -l. That tool only
works on Wayland, as you are aware, so it is expected that your system
prints "Failed to connect to a Wayland server" when you are running X11.

That does not mean you cannot reproduce the PSA on your Linux box.
It only means you need the X11 equivalent of wl-paste.

What's that?
Hell if I know.
I haven't had Linux as my daily drive for a long time now.

But, running a quick search on your behalf, it may be that
on X11, the closest equivalent may be xclip or xsel.

Apparently both can list the clipboard formats the same way
wl-paste does on Wayland.

For example, with xclip you can run:

xclip -selection clipboard -t TARGETS -o

That prints the list of offered clipboard formats under X11.
It seems, to me, to be the same idea as wl-paste -l, but
just for the X11 clipboard instead of the Wayland clipboard.

If you run that command after copying text from Firefox, then run it
again after copying the same text from Chrome, you should see the same
pattern that Lawrence showed (assuming the original copy had HTML).

What we learned, as a team, with the tests mostly done on Linux, was:
1. Firefox offers HTML only when it thinks the selection has structure.
2. Chromium based browsers always offer HTML plus their internal formats.
3. Plain text editors offer only plain text formats.

That is the core of the PSA. The platform does not matter. The browser
decides what formats to place on the clipboard, and the editor decides
which one to request when pasting.

So the only reason you could not reproduce Lawrence's exact command is
that you are on X11, not Wayland. If you use xclip or xsel instead, you
should be able to see the same differences he demonstrated. I think.
--
If we think we understand something, we don't. But if we think we don't
quite yet understand something, then we're just beginning to understand it.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Paul wrote:

A person doing testing, has to find two clipboard managers (Wayland one, X11 one), have three login options,
to do some tests. And even then, who knows whether the answer is based on hard reasons underneath.

I always agree with anyone who makes a logically sentient observation, as
Paul just did, where I think we don't need to test this PSA all that much.

The PSA was simply meant as a warning to think about IF it happens to you.
In the future.
With any browser.
On any platform.
Using any $EDITOR.
Or windowing system.

I wish I had known about this PSA before I had written it.
Knowing pitfalls helps us avoid them, or fix 'em or at least understand
them so that we can create a workaround (as I did with shortcuts.xml).

The simple solution would have taken seconds, instead of many hours.
Had I only known the solution is add a character & then delete it.

The PSA is simply just that.
A public service announcement.

I'd love to know stuff that's gonna happen to me BEFORE it happens!

An example is over the summer I had a total loss of hearing in an ear and I didn't take it seriously but only later found out it's like a heart attack.

Had I known it was a medical emergency, I would have called an ambulance.
But it didn't 'feel' like a medical emergency (even though it was).

After a month of living in a compression/decompression chamber as a result,
I wish someone had written a PSA for me to be more attentive to situations.
--
There are two kinds of people on Usenet, one of which can add value.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On 2026-02-15 20:49, Maria Sophia wrote:

Carlos E. R. wrote:

...

But, running a quick search on your behalf, it may be that on X11, the closest equivalent may be xclip or xsel.
Apparently both can list the clipboard formats the same way
wl-paste does on Wayland.

For example, with xclip you can run:

-a-a xclip -selection clipboard -t TARGETS -o

That prints the list of offered clipboard formats under X11. It seems,
to me, to be the same idea as wl-paste -l, but
just for the X11 clipboard instead of the Wayland clipboard.

If you run that command after copying text from Firefox, then run it
again after copying the same text from Chrome, you should see the same pattern that Lawrence showed (assuming the original copy had HTML).

Ok, that is easy to do.

Using the same selection as in my previous test.

Firefox:

cer@Laicolasse:~> xclip -selection clipboard -t TARGETS -o
TIMESTAMP
TARGETS
MULTIPLE
SAVE_TARGETS
text/html
text/_moz_htmlcontext
text/_moz_htmlinfo
UTF8_STRING
COMPOUND_TEXT
TEXT
STRING
text/plain;charset=utf-8
text/plain
text/x-moz-url-priv
cer@Laicolasse:~>

Chrome

cer@Laicolasse:~> xclip -selection clipboard -t TARGETS -o
TIMESTAMP
TARGETS
SAVE_TARGETS
MULTIPLE
STRING
TEXT
UTF8_STRING
text/plain;charset=utf-8
text/plain
text/html
chromium/x-internal-source-rfh-token
chromium/x-source-url
cer@Laicolasse:~>


...
--
Cheers,
Carlos E.R.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Thanks go to Lawrence for making me find a clipboard analyzer on Windows.
Tto my knowledge, in decades on these ngs, nobody ever has discussed them.

This is the one I used:'
InsideClipboard v1.30
Web site: https://www.nirsoft.net

For those in this thread who are not on Windows, there are certain Windows-specific oddities that may need to be explained in that output.

The "format" field is a numeric identifier that Windows uses internally to label a clipboard format.
Format ID 1 = CF_TEXT
Format ID 7 = CF_OEMTEXT
Format ID 13 = CF_UNICODETEXT
Format ID 16 = CF_LOCALE
These are built in Windows formats.
They exist on every Windows system.

Yet the important ones in this test were:
Format ID 49426 = HTML Format
Format ID 49661 = Chromium internal source RFH token
Format ID 49683 = Chromium internal source URL

For each of those, Chromium told Windows (taking one as an example):
"I want to register a clipboard format named HTML Format"
and Windows assigned it ID 49426.

Windows doesn't care what it's called.
Windows just assigns it an available number.

Why are the second set of numbers so big?
Because Windows built-in formats use up all the small numbers:
1, 7, 13, 16, etc.
While application-registered formats use available large numbers:
49426, 49661, 49683.

These indicate that Chromium placed multiple formats on the clipboard
HTML Format
Chromium internal source RFH token
Chromium internal source URL

But when your Notepad++ macro rewrote the clipboard, all of those formats disappeared.
A. This is why Ctrl+A started working again.
B. The shortcuts.xml CTRL+B macro removed the HTML Fragment land mine

This proves the PSA (at least the problematic Chromium portion of the PSA).
And it proves the single-step solution (on Windows).

Voila!
I love one-step automation!
--
If we think we understand something, we don't. But if we think we don't
quite yet understand something, then we're just beginning to understand it.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Maria Sophia wrote:

Each section of your output helps confirm the pattern I was trying to describe in the PSA and your suggestion for me to do the same resonated.

Lawrence and Paul and Carlos were way ahead of me all along, but,
I think I finally figured it out, where I'm usually the last to know. :)

This reminds me, in a small way, of how I felt when reading Einstein's 1916 book (later revised in the early 1920's, which lost copyright 100 years
later) in that every revelation reveals a new mystery to resolve next.

Keeping in mind the whole thing started when I pasted Chromium text into Notepad++ which caused Control+A to die, this is a short explanation.

Windows assigns every clipboard format a numeric ID, e.g., 1, 7, 13, 16.
CF_TEXT is the old ANSI text format.
CF_OEMTEXT is the old OEM codepage text format.
CF_UNICODETEXT is the modern Unicode text format.
CF_LOCALE tells Windows what language or locale the text came from
etc.

While NirSoft InsideClipboard shows those IDs, it turns out that Chromium registers its own formats by name, so Windows assigns those names whatever available (usually large) numbers it has, such as 49426 or 49683.

Notepad++ does not use most of those CF clipboard formats directly.
Notepad++ almost always just asks Windows only for CF_UNICODETEXT.

The important detail is that Windows uses the HTML Format entry to generate
the plain text that Notepad++ receives. That conversion step is where the invisible CTRL+A land mine comes from.

That means the presence of HTML Format changes how the plain
text is produced, even though Notepad++ never reads the HTML itself.

When the control+B shortcuts.xml macro rewrites the clipboard, it removes
HTML Format and all Chromium internal formats.

With only plain text formats left, Windows no longer has to convert from
HTML, so the plain text becomes clean and Ctrl+A works again.

But what exactly is causing Control+A to stop working in Notepad++?
The reason Ctrl+A dies is not that HTML is pasted into the file.

The problem actually happens earlier, inside Windows, when Windows converts
the HTML Format entry into CF_UNICODETEXT for Notepad++.

When Chromium puts HTML Format on the clipboard, Windows must run its HTML-to-text converter. That converter uses the StartHTML, EndHTML, StartFragment, and EndFragment offsets inside the HTML Fragment block.

If those offsets are wrong, or if the HTML fragment is malformed, the
converter can produce a CF_UNICODETEXT stream with hidden control
characters, mismatched boundaries, or an unexpected buffer length.

Notepad++ receives that CF_UNICODETEXT stream and loads it into its
internal Scintilla buffer. If the buffer contains an unexpected control sequence or a broken length field, Scintilla can fail to compute the
full document range.

Bingo!

When that happens, Ctrl+A does not select the whole buffer because
Scintilla thinks the document ends earlier than it actually does.

The Control+B macro fixes the issue because it wipes the clipboard and
replaces it with plain text only (among other things that it does).

With no HTML Format present, Windows does not run the HTML-to-text
converter again, so the CF_UNICODETEXT stream is finkally clean
and Scintilla can compute the correct document length.

Once the buffer is clean, Ctrl+A works again.
Whew!

Given this took me hours to debug & resolve, the whole point of this PSA is
to help the next person not have to do all the work that I just had to do!
--
"Everything should be made as simple as possible, but not simpler."
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Lawrence DoOliveiro wrote:

On Sun, 15 Feb 2026 17:13:16 -0500, Paul wrote:

If we're to have clipboard management, there should be
a way to tell exactly what the source program offered
and no more.

That is exactly how it works.

Speaking of "how it works", I'm not sure if it's a bug, or not, but what do
you think of this description I created below of how (I think) it works?

All that's left after fixing the issue was understanding what actually
went wrong in the first place (which killed the control+A in Notepad++).

It turns out that Windows does not convert the HTML Format entry into text until an application explicitly asks for a text format.

So the corruption happens at the moment Notepad++ requests CF_UNICODETEXT.

The sequence (as far as I can re-construct it) is...

1. With Ctrl+C, Chromium places several formats on the clipboard,
including HTML Format, CF_UNICODETEXT, and its internal metadata.

2. With Ctrl+V, Notepad++ asks Windows:
"Give me CF_UNICODETEXT."

3. Windows sees that HTML Format is available and may choose to generate
the CF_UNICODETEXT stream by converting the HTML fragment.

Kaboom!

4. That conversion step can produce a corrupted CF_UNICODETEXT stream.
The corruption is not visible text. Which is why I couldn't "see" it.
It is a bad length field or a hidden control character (apparently).

Is that a bug?
I don't know.

5. Scintilla loads that corrupted stream into its internal buffer.
But the buffer boundaries are now wrong, so Ctrl+A fails because
Scintilla thinks the document ends earlier than it actually does.

So why didn't I see it in the Notepad++ hex editor?

The HTML is never pasted into the file, so it can't be seen.
But it affects the text Windows hands to Notepad++ at paste time.

Well then, why does adding and deleting a character fix it?

Because the corruption lives only in Scintilla's internal buffer
structures, not in the visible text. When the macro inserts a space,
Scintilla is forced to rebuild its entire buffer. That rebuild wipes out
the corrupted boundary. Removing the space forces a second rebuild,
which simply restores the original content. The second rebuild is not
needed for the fix; it is only needed to undo the temporary change.

After that, the macro selects all and cuts the text. Cutting forces
Windows to create a brand new clipboard entry. This new clipboard entry contains only plain text formats, because Scintilla does not generate
HTML Format or any Chromium internal formats.

I don't know if this is a bug or not, as all I know, in the end, is...
1. The corrupted CF_UNICODETEXT stream from the original paste is gone.
2. The clipboard now contains only clean plain text.
3. Scintilla now has a clean buffer with correct boundaries.
4. Ctrl+A works again.

Woo hoo!

So the fix works because Windows created the problem when converting the
HTML fragment into text, which corrupted Scintilla's internal buffer.
Adding and removing a character forces Scintilla to rebuild its buffer,
and cutting the text forces Windows to rebuild the clipboard without
HTML Format. The corruption cannot survive those two rebuilds.

I think we explained it as simply as we could, but not simpler.
--
How wonderful that we have met with a paradox.
Now we have some hope of making progress.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

At Sun, 15 Feb 2026 21:01:50 -0500, Maria Sophia <mariasophia@comprehension.com> wrote:

Thanks go to Lawrence for making me find a clipboard analyzer on Windows.
Tto my knowledge, in decades on these ngs, nobody ever has discussed them.

This is the one I used:'
InsideClipboard v1.30
Web site: https://www.nirsoft.net

For those in this thread who are not on Windows, there are certain Windows-specific oddities that may need to be explained in that output.

The "format" field is a numeric identifier that Windows uses internally to label a clipboard format.
Format ID 1 = CF_TEXT
Format ID 7 = CF_OEMTEXT
Format ID 13 = CF_UNICODETEXT
Format ID 16 = CF_LOCALE
These are built in Windows formats.
They exist on every Windows system.

Yet the important ones in this test were:
Format ID 49426 = HTML Format
Format ID 49661 = Chromium internal source RFH token
Format ID 49683 = Chromium internal source URL

For each of those, Chromium told Windows (taking one as an example):
"I want to register a clipboard format named HTML Format"
and Windows assigned it ID 49426.

Windows doesn't care what it's called.
Windows just assigns it an available number.

Why are the second set of numbers so big?
Because Windows built-in formats use up all the small numbers:
1, 7, 13, 16, etc.
While application-registered formats use available large numbers:
49426, 49661, 49683.

These indicate that Chromium placed multiple formats on the clipboard
HTML Format
Chromium internal source RFH token
Chromium internal source URL

Did this unholy horrorshow of a plan come from Cutler and
VMS?

fu2: alt.os.linux
--
-v System76 Thelio Mega v1.1 x86_64 Mem: 258G
OS: Linux 6.18.10 D: Mint 22.3 DE: Xfce 4.18 (X11)
NVIDIA GeForce RTX 3090Ti (24G) (580.105.08)
"You have two choices for dinner: Take it or Leave it."
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Lawrence DoOliveiro wrote:

On Sun, 15 Feb 2026 21:58:46 -0500, Maria Sophia wrote:

Is that a bug?

Only happens under Windows?

Probably.

Hi Lawrence,

That's a good point because we got so wrapped up in proving that the
underlying mechanism were the same between the various platforms (although
the mac users only trolled us so I'm gonna remove them in the fup line)
that we forget that there is a real "issue" with the Control+A breaking.

It does seem to be a Windows corruption of Scintilla's internal indexing
tables when Windows hands Chromium data to Scintilla.
a. line boundaries
b. document length
c. byte offsets
d. character offset

But why doesn't it happen with Firefox?

The more confused I am, the more I learn, so I think it all comes down to
how each browser constructs its clipboard data diffferently.

Which, after all, is the SUBJECT line of this thread, as it's all about
Firefox versus Chromium, which are on "all common consumer platforms". :)

Back to Firefox, my tentative assessment is Chromium always puts a full
HTML Fragment block on the clipboard, complete with StartHTML, EndHTML, StartFragment, EndFragment offsets, and its own chromium/x-* metadata.

Yet Firefox does not.

Unfortunately, Windows uses that HTML Fragment to generate CF_UNICODETEXT.

If the HTML fragment or offsets are malformed, Windows produces a
corrupted CF_UNICODETEXT stream. That corrupted stream breaks Scintilla.

I can only assume Firefox's HTML fragment is simpler and hence Firefox's
HTML fragment does not trigger the buggy Windows conversion path.

What do you think of that hypothesis of why only Chromium, not Firefox?
--
This is getting more and more like Heisenberg's uncertainty principle.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

Carlos E. R. wrote:

Regarding ONLY your comment:
"I already tested and found no bug."
I don't think anyone suggested there was a bug, where we're all simply
openly and honestly discussing a, oh, shall we say, "quirk" in the system.

The problem you have with ctrl-A in Notepad++ after pasting html from Chrome.

Hi Carlos,

I'm gonna remove the mac folks in the fup because they've not participated
save to troll us, but after discussing this with Lawrence, and using
Occam's Razor to put all the data together, I don't think anyone has
suggested that graphical Linux editors have the same control+A disabling.

So I think I agree now that there may well be a bug in how Windows hands
the text from Chromium (but not from Firefox) to Scintilla/Notepad++.

In keeping with the original SUBJECT of this thread, where Firefox and
Chromium run on all common consumer platforms (well, not on iOS), my best
guess is that Firefox's HTML fragment is simpler and hence Firefox's
HTML fragment does not trigger the buggy Windows conversion path.

Who knows how many $EDITORs are affected...
--
How wonderful that we have met with a paradox.
Now we have some hope of making progress.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.os.linux

On Sun, 15 Feb 2026 21:58:46 -0500, Maria Sophia wrote:

Is that a bug?

Only happens under Windows?

Probably.
--- Synchronet 3.21b-Linux NewsLink 1.2