I have to use Textpad in my environment. To treat a file (on a regular basis) it is necessary to make +/- 20 replacements, some of them regex, some of them not. For most of the replacements I have defined macros (for each replacement one macro, i. e. 1:1). It is possible to "concat" macros or put replacements "in a sequence"? If it is possible: Would this sequence break, if one replacement does not find matching patters (off course, it should not break).
I'm not sure how you would "concat" them aside from recording each macro together (unless you know how to concat the files)... but as your question is about "would it work"... then I'd say yes but you would have to ensure each marco started in the right place.
I'd recommend each macro started and ended with something like Ctrl+Home to ensure a consistent starting / ending place
Related
One of the useful features of ess-mode (Emacs speaks statistics) is to automatically replace the underscore _ with the assignment operator <-. Lately, I have been using a lot of pipes (written as %>%) and it would be great to not have to type three characters for each pipe.
Is it possible to define a custom key binding for the pipe, similar to the one converting _ into ->?
The simplest solution is to just bind a key to insert a string:
(define-key ess-mode-map (kbd "|") "%>%")
You can still insert | with C-q |. I'm not sure about the map's name; you'll almost certainly want to limit the key binding to ess-mode.
Check out yasnippet. You can use it to define something like "if this sequence of characters is followed by this key (which you can define to whatever you like), then replace them with this other sequence of characters and leave the cursor in this place". There's more to yasnippet than this, but there's plenty of documentation online and even already made recipes similar to the example I gave above that you can try, like yasnippet-ess-mode, for example.
Alternatively, you can also try abbrev-mode and see if that works for you.
I, for one, like yasnippet better, since you can also specify where to leave the cursor after the expansion, but abbrev-mode seems to be easier to set up. As always in Emacs world, try multiple solutions, don't settle for the first one you put your hands on. What works best for others might not work for you, and vice-versa.
I work with knitr() and I wish to transform inline Latex commands like "\label" and "\ref", depending on the output target (Latex or HTML).
In order to do that, I need to (programmatically) generate valid R strings that correctly represent the backslash: for example "\label" should become "\\label". The goal would be to replace all backslashes in a text fragment with double-backslashes.
but it seems that I cannot even read these strings, let alone process them: if I define:
okstr <- function(str) "do something"
then when I call
okstr("\label")
I directly get an error "unrecognized escape sequence"
(of course, as \l is faultly)
So my question is : does anybody know a way to read strings (in R), without using the escaping mechanism ?
Yes, I know I could do it manually, but that's the point: I need to do it programmatically.
There are many questions that are close to this one, and I have spent some time browsing, but I have found none that yields a workable solution for this.
Best regards.
Inside R code, you need to adhere to R’s syntactic conventions. And since \ in strings is used as an escape character, it needs to form a valid escape sequence (and \l isn’t a valid escape sequence in R).
There is simply no way around this.
But if you are reading the string from elsewhere, e.g. using readLines, scan or any of the other file reading functions, you are already getting the correct string, and no handling is necessary.
Alternatively, if you absolutely want to write LaTeX-like commands in literal strings inside R, just use a different character for \; for instance, +. Just make sure that your function correctly handles it everywhere, and that you keep a way of getting a literal + back. Here’s a suggestion:
okstr("+label{1 ++ 2}")
The implementation of okstr then needs to replace single + by \, and double ++ by + (making the above result in \label{1 + 2}). But consider in which order this needs to happen, and how you’d like to treat more complex cases; for instance, what should the following yield: okstr("1 +++label")?
The GNU project has a standard for how command line arguments should look like. However, there is no description for what to do, when an option has multiple arguments. Is there a convention for a special character to separate those arguments?
Example:
--longOption="firstArg;secondArg" -s first;second
In my case, I need to be able to specify one option multiple times, which results in creating an object multiple times with different parameters.
This must be possible:
--longOption="allArgs;for;firstObject" --longOption="args;for;second"
I guess I would also need a way to escape that separation character somehow...
Standard common-lisp defines many reader macros such as ( and ) for grouping, ' for quote, " for string quotation, | for symbol quotation, # for dispatch macro, etc. Now I want to disable them all and use my own ones, and I have to call set-macro-character one by one to disable them all and then define my own ones.
I have found that there's one way to restore all reader macros to standard ones by calling (setf *readtable* (copy-readtable nil)), but is there a way to set them to empty(i.e., all the characters are treated as normal letters and numbers)?
I don't think there's a way. The expectation is that you're just making incremental modifications to the Lisp reader, not trying to replace it wholesale. It's not really designed to be used that way, because you can't define everything as a macro -- most of the constituent characters are associated with built-in behaviors that can't be defined as reader macros.
It seems that the output are the same when I echoed it.
I also tested other commands such as open, but the results from both are the same.
In traditional sh-style pattern matching, * matches zero or more characters in a component of the file name, so there is no difference between *, **, and ***, either on its own or as part of a larger pattern.
However, there are globbing syntaxes that assign a distinct meaning to **. Pattern matching implemented by the Z shell, for example, expands x/**/y to all file names beginning with x/ and ending in /y regardless of how many directories are in between, thus matching all of x/y, x/subdir/y, x/subdir1/subdir2/y, etc. This syntax was later implemented by bash, although only enabled when the globstar configuration option is set by the user.