Is it possible to get xed to stop parsing escape codes in copy/paste?

Questions about applications and software
Forum rules
Before you post please read how to get help
Level 1
Level 1
Posts: 43
Joined: Sun Jun 19, 2016 11:56 pm

Is it possible to get xed to stop parsing escape codes in copy/paste?

Postby Ascaris » Thu Nov 09, 2017 1:20 pm


Tried searching for this, but the forum won't let me search for "xed" since it only has three letters... that's kind of an odd restriction, isn't it?

I am trying to edit a Mozilla Thunderbird prefs.js file in xed. Specifically, I am attempting to copy and replace pathnames embedded within the document from their Windows version to their Linux equivalent. The Windows paths within one part of the document are of the form "C:\\\\users\\\\account\\\\appdata..." It appears to be two levels of encoding the backslashes as escaped backslashes (represented as \\).

Well, when I try to copy the entire path and paste it into the search box, xed claims "No matches found," even though I just copied it out of the very same document ten seconds prior.

It is parsing the double-slashes as escape codes to represent a slash, so it thinks I am searching for "C:\\users\\account\\appdata..." It does this while continuing to display the correct as-entered string in the search field. What is displayed is not what it is actually searching for. In other words, it is parsing the double slashes not at the paste event, but at the start of the search event.

I didn't ask it to transform what I typed (or pasted) into the box into something else before performing the search. I would like it to look for exactly what is in the box, as a literal string. Can this be done with a hidden setting somewhere, or is it a bug, or is searching for something other than what is in the search box somehow an intended effect?


Changing the file to .txt before editing didn't change the behavior. It prevented the js highlighting of the syntax, but the transformation of \\ to \ continued.

Edit: Just installed Pluma from the repo, and it doesn't exhibit the unwanted behavior, even with the "Parse escape sequences" box checked. Perhaps this is a bug introduced when the search function was moved from a floating dialog to the bottom of the window?
Main PC: Mint 18 Cinnamon & Windows 8.1/ Asus P8P67 Deluxe/i5-2500k @ 4.7Ghz
Laptop: Mint 18 Cinnamon & Windows 8.1/ Asus F8Sn w/GTX220 & C2D T7800 @ 2.6Ghz

Return to “Software & Applications”