In Ultraedit macros, the following works, and finds the content of the clipboard as expected:
Find "^c"
but the following does not:
Find RegExp "^c"
How can i use the contents of the clipboard in a Find RegExp macro?
Usage of ^c (clipboard content) and ^s (selected text) in search and replace explains briefly how to use ^c and ^s in a regular expression find/replace.
^s and ^c can be used only in non regular expression or in UltraEdit regular expression finds/replaces. When used in an UltraEdit regular expression find/replace, the selected text respectively contents of the clipboard is interpreted as UltraEdit regular expression string.
Selected text and clipboard contents cannot be referenced within a Unix or Perl regular expression find/replace. There is no workaround solution for this limitation for UltraEdit macros.
Such tasks are nowadays done with using an UltraEdit script instead of an UltraEdit macro as a script supports string variables and access of selected text and contents of clipboard. Therefore it is possible to build the search/replace string in an UltraEdit script first in a string variable and then run the regular expression find/replace with the value of the string variable.
There are many examples of scripts using a dynamically modified search and/or replace string during script execution in the UltraEdit Scripts forum.
Related
I have a markdown document that I convert to PDF via pandoc's latex engine. I'm trying to render an n with a tilde over it, as in "niño", with markdown like the following:
ni\~{n}o
...but this just gets rendered in the PDF as "ni~no" -- i.e. the tilde gets interpreted literally. I've also tried escaping the backslash (ni\\~{n}o), surrounding everything in brackets (ni{\~{n}}o), and basically what I think is every possible combination of escaping characters in this sequence, but nothing works. It also fails even when the sequence is on its own (i.e. \~{n}).
But, other similar sequences that are based on letters rather than symbols work just fine (e.g. Otter\r{a} gets rendered correctly to "Otterå"). Pandoc is specifically failing to handle the tilde (or maybe more generally non-letter-based latex character sequences -- I haven't tested others).
The command I'm using to build the pdf is pandoc file.md -o file.pdf. I've also tried specifying -f markdown+raw_tex, but it still fails (nor should I need to, since the \r{a} works without it, and I think raw_tex is enabled by default anyway).
Any thoughts? I know I can use xetex to just enter these characters directly, but that's not really a satisfying solution...
Besides using the ñ character directly (which apparently works in native Pandoc because it's magic!), an alternative is to create a simple LaTeX \newcommand for forcing native TeX interpretation.
\newcommand{\tex}[1]{#1}
ni\tex{\~n}o
Thanks to John McFarlane for introducing me to this clever workaround!
I got a script that is no longer supported and I'm looking for a way to change the value of a variable in it... The script is encrypted (loadstring/bytecode/something like that) e.g.: loadstring('\27\76\117\97\81\0\1\4\4\4\8\0\')
I can find what I want to change (through notepad after I compile the script), but if I try to change the value, the script won't work, if I change and try to recompile it still won't work: "luac: Testing09.lua: unexpected end in precompiled chunk" ...
Any ideas? I did something like that with a program long a go using ollydbg but I can't use it with lua scripts... I'm kinda lost here, doing some Googling for quite a while couldn't find a way... Any ideas?
It is easy to change a string in a Lua bytecode. You just have to adjust the length of the string after you change it. The length comes before the string. It probably takes four or eight bytes just before the string, depending on whether you have a 32-bit or 64-bit platform. The length is stored in the endianness of the machine where the bytecode was generated. Note that strings include a trailing '\0' and this counts in the length.
Perhaps it is easier to just copy some bytes directly. Write this file
return "this is the new string you want"
Generate bytecode from it with luac and look at an dump of luac.out and locate the string and its length. Copy those bytes to the original file.
I don't know whether notepad handles binary data. if it doesn't, you'll need an hex editor to do this.
Another solution is to write a Lua program that reads the bytecode as a strings, generate bytecode for return "this is the new string you want", perform the change in the original bytecode using string operations and write it back to file.
You can also try my bytecode inspector library lbci, which allows you to change constants in functions. You'd load the bytecode (but not execute it), and use setconstant after locating the constant that has the string you want to change.
In all, there is some fun to be had here...
HI I need to include a french text in vb script with special characters - REJETÉE.
When I add text, it appears as REJETÉE. How do I include the following?
I can use either : É or É. but it shows exceptions.
Visual basic in itself does only support ASCII characters. The 'É' is an ANSI character, thus unsupported.If you are writing to a text file, you may want to print the direct ANSI value of the character. If you now use a text editor that uses ANSI encoding, you will see the 'É' correctly.
Also, maybe the following will work as a debug output, you will have to try thou:
Debug.Print chr$(200)
You should get the 'È' character when writing the value 200. As I said, i don't know if this works in the debug printer, but when writing to text files it will work.
In a .fs file a newline is denoted by \r\n, but in the F# Interactive window it is \n.
In a problem I'm currently trying to solve, the length of a multiple line literal string matters. So a problem arises when I am testing code in the F# Interactive window, because the length of the string is different from in normal execution.
I hope there is an option to change the newline 'character' in F# Interactive to \r\n, but I can't find it. Does anyone know where I can achieve this, or some other workaround?
You can use conditional compilation to handle this:
#if INTERACTIVE
text.Replace("\n", System.Environment.NewLine)
#endif
I don't know of a way to change it in fsi. Another option would be to remove, or normalize, the newlines regardless of the execution environment. If the exact length is that important, it might be good to do anyway.
EDIT
If the newlines are only there for readability, you can end each line with a backslash. The backslash, newline, and leading whitespace on the following line are removed at compile time.
let text = "a\
b"
printfn "%s" text //"ab"
This works the same in VS and FSI. I'm assuming you're sending bits of code to FSI via Alt+Enter or Alt+'.
How can I find all lines in Delphi source code using GExperts grep search which contain a string literal instead of a resource string, except those lines which are marked as 'do not translate'?
Example:
this line should match
ShowMessage('Fatal error! Save all data and restart the application');
this line should not match
FieldByName('End Date').Clear; // do not translate
(Asking specifically about GExpert as it has a limited grep implementation afaik)
Regular Expressions cannot be negated in general.
Since you want to negate a portion of the search, this comes as close as I could get it within the RegEx boundaries that GExpers Grep Search understands:
\'.*\'.*[^n][^o][^t][^ ][^t][^r][^a][^n][^s][^l][^a][^t][^e]$
Edit: Forgot the end-of-line $ marker, as GExperts Grep Search cannot do without.
blokhead explains why you cannot negate in general.
This Visual Studio Quick Search uses the tilde for negation, but the GExperts Grep Search cannot.
The grep command-line search has the -v (reverse) option to negate a complete search (but not a partial search).
A perfect manual negation gets complicated very rapidly.
--jeroen