I have a bold line, followed by a line starting with a period. man thinks that the . is the start of a command... is there a way to "escape" it?
.B bold words
./something
The ./something is a command to type in a terminal, not a man macro. I want man to display it.
Things I've tried: ../something \./something
According to the GNU Troff manual, you should put \& in front of a period that should not be interpreted as the beginning of a command, i.e.
.B bold words
\&./something
Related
I have a legacy system that only accepts Windows \r\n and I want to edit a file in VS Code that has just \n to have \r\n.
I'm trying to use a Regex replace:
But this puts literal \r in instead of the whitespace char.
I've tried putting a newline in the replacement using SHIFT+ENTER:
But this just puts in \n.
How do I change the line feed chars used and save the file in VS Code?
There's the text "LF" in the bottom bar on the right, click on it and select "CRLF". Or press Ctrl+Shift+P and enter Change End of Line Sequence.
No idea why your approach doesn't work. Nor does \x0D or \15 get recognized. I'd call it a bug.
For multiple files, on Linux, I'd do it outside of the editor, e.g., with
find somedir -name '*.someext' -exec perl -pi -e 's/\n/\r\n/' {} +
Just press Ctrl+H and select regex replace. Then start input:
Find what: ^\n
Replace with: \r\n
You can try this one
In the local searchbox (Ctrl + F) you can insert newlines by pressing Ctrl + Enter.
https://www.graef.io/find-and-replace-with-a-newline-in-visual-studio-code/
Visual Studio Code provides an option to Select End of Line Sequence in its taskbar on bottom right:
When clicked, it'll provide an option to choose between CRLF (Carriage return and Line feed: Windows default) and LF (Line feed alone: Linux supported):
Make sure to save the file once the EOL sequence is changed.
The commands M-a (backward-sentence) and M-e (forward-sentence) move to the beginning and end of the current sentence, respectively. I would like to end a sentence if there is a newline. So, I would like emacs to treat the following text as two lines (even though there are no periods). With the default config, emacs treats it as a single sentence.
This is line one
This is line two
Why do I need this?
I use visual-line-mode. So my sentences never contain a newline character. I am using the sentence hilight mode which relies on emacs "sentence end". This creates problem in cases where there are no periods. For example program source listing. (The whole program is treated as a single line by emacs.)
Adding \n to the end of the regexp for sentence-end should accomplish the goal you seek -- it is done by adding a delimiter that looks like this \\| and then the \n.
Here is the default regexp for sentence-highlight-mode:
(setq sentence-end "[^.].[.?!]+\\([]\"')}]*\\|<[^>]+>\\)\\($\\| $\\|\t\\| \\)[ \t\n]*")
Here is the revised regexp for sentence-highlight-mode:
(setq sentence-end "[^.].[.?!]+\\([]\"')}]*\\|<[^>]+>\\)\\($\\| $\\|\t\\| \\)[ \t\n]*\\|\n")
This is odd. I have defined the following prompt in zsh:
local user_host='%{$terminfo[bold]$fg[green]%}%n # %m%{$reset_color%}'
local current_dir='%{$terminfo[bold]$fg[blue]%} %~%{$reset_color%}'
local git_branch='$(git_prompt_info)%{$reset_color%}'
local return_code="%(?..%{$fg[red]%}%? ↵%{$reset_color%})"
PROMPT="╭─${user_host} %D{[%a, %b %d %I:%M:%S]} ${current_dir} ${git_branch}
╰─%B$%b "
RPS1="${return_code}"
It works great on gnome-terminal as well as in an ansi-term terminal in Emacs (M-x ansi-term) - see the example below:
However, it does not work well under multi-term in Emacs as you can see below:
I thought multi-term would be capable of interpreting the same set of escape characters that a terminal like gnome-terminal or ansi-term does. Why is it not interpreting the escape characters returned by git-prompt_info and others correctly?
I have also tried:
M-x set-terminal-coding-system and setting it to utf-8-unix
TERM=eterm-color within the multi-term terminal, or before calling Emacs, etc.
TERM= within the multi-term terminal, or before calling Emacs, etc.
Removing any export TERM from my .zshrc
Update (January 29, 2014):
The best solution so far seems to be to do the following:
TERM=xterm-256color
but causes another problem that I have reported here: Passing escape sequences to shells within ansi-term in Emacs.
Why is it not interpreting the escape characters returned by
git-prompt_info and others correctly?
The answer is most likely that multi-term just isn't prepared to accept those escape sequences, in that format, for whatever reason. This may be a configuration issue, bug, or intentional. Setting the mode to accept colors, i.e. TERM=xterm-256color, improves the situation because it then accepts color escape sequences similar to the standard format used among terminal emulators, e.g.:
RED='\033[0;31m'
NC='\033[0m' # No Color
echo "I ${RED}love${NC} Stack Overflow\n" # this output IS NOT interpreting the escapes
echo -e "I ${RED}love${NC} Stack Overflow\n" # this output IS interpreting them
code borrowed from here
the salient part is the [0;31m for color, which is referenced in the linked thread in "Update 2" of your other question, asking why lines are printed out that begin with 4m which is part of this color escape sequence.
Here is more info, with a relevant excerpt:
Thus it is your terminal emulator that understands colors. Your
terminal emulator understands that \033[0;36m is cyan, but another
terminal emulator might use an entirely different set of characters
for cyan (though no sane terminal emulator would flaunt the standard
and do this). This is the reason for tput. When you run tput setaf
6, tput is going to look up your terminal's escape codes for the
color 6 (cyan), and output that escape code.
I suspect, in your other question, the reason that alt+b and alt+f aren't working in your other question is due to the terminal width count being off because of improper interpretation of these escape sequences which are supposed to be non-printing or zero-width. I haven't messed with multi-term a lot but the solution may involve using tput or similar to allow it to properly understand the escape sequences.
Possible relevant troubleshooting info
I have a .txt file named COPYING which is edited on windows.
It contains Windows-style line breaks :
$ file COPYING
COPYING: ASCII English text, with CRLF line terminators
I tried to convert it to Unix style using dos2unix. Below is the output :
$ dos2unix COPYING
dos2unix: Skipping binary file COPYING
I was surprised to find that the dos2unix program reports it as a binary file. Then using some other editor (not Emacs) I found that the file contains a control character. I am interested in finding all the invisible characters in the file using Emacs.
By googling, I have found the following solution which uses tr :
tr -cd '\11\12\40-\176' < file_name
How can I do the same in an Emacs way? I tried the Hexl mode. The Hexl mode shows text and their corresponding ASCII values in a single buffer which is great. How do I find the characters which have ASCII values other than 11-12, 40-176 (i.e tab, space, and visible characters)? I tried to create a regular expression for that search, but it is quite complicated.
To see invisible characters, you can try whitespace-mode. Spaces and tabs will be displayed with a symbol in a different face. If the coding system is automatically being detected as dos (showing (DOS) on the status bar), carriage returns at the end of a line will be hidden as well. Run revert-buffer-with-coding-system to switch it to Unix or binary (e.g. C-x RET r unix) and they'll always show up as ^M. The binary coding system will display any non-ASCII characters as control characters as well.
Emacs won't hide any character by default. Press Ctrl+Meta+%, or Esc then Ctrl+% if the former is too hard on your fingers, or M-x replace-regexp RET if you prefer. Then, for the regular expression, enter
[^#-^H^K-^_^?]
However, where I wrote ^H, type Ctrl+Q then Ctrl+H, to enter a “control-H” character literally, and similarly for the others. You can press Ctrl+Q then Ctrl+Space for ^#, and usually Ctrl+Q then Backspace for ^?. Replace all occurrences of this regular expression by the empty string.
Since you have the file open in Emacs, you can change its line endings while you're at it. Press C-x RET f (Ctrl+X Return F) and enter us-ascii-unix as the new desired encoding for the file.
Check out M-x set-buffer-file-coding-system. From the documentation:
(set-buffer-file-coding-system CODING-SYSTEM &optional FORCE NOMODIFY)
Set the file coding-system of the current buffer to CODING-SYSTEM.
This means that when you save the buffer, it will be converted
according to CODING-SYSTEM. For a list of possible values of
CODING-SYSTEM, use M-x list-coding-systems.
So, going from DOS to UNIX, M-x set-buffer-file-coding-system unix.
In GNU screen, I want to change the default command binding to Alt-s (by tweaking .screenrc) instead of the default C-a, the reason is I use emacs hence GNU screen binds the C-a key, sending "C-a" to the emacs becomes tedious (as #Nils said, to send "C-a" I should type "C-a a"), as well as "C-a" in bash shell, and I could change the escape to C- but some of them are already mapped in emacs and other combinations are not as easy as ALT-s . If anyone has already done a ALT key mapping, please do let me know.
It is possible to work around :escape command limitations using registers and :bindkey command. Just put this in .screenrc:
# reset escape key to the default
escape ^Aa
# auxiliary register
register S ^A
# Alt + x produces ^A and acts as an escape key
bindkey "^[x" process S
## Alt + space produces ^A and acts as an escape key
# bindkey "^[ " process S
See http://adb.cba.pl/gnu-screen-tips-page-my.html#howto-alt-key-as-escape
From my reading of man screen it seems like the only meta character that screen can use for the command binding is CTRL:
escape xy
Set the command character to x and the character generating a literal
command character (by triggering the "meta" command) to y (similar to
the -e option). Each argument is either a single character, a two-character
sequence of the form "^x" (meaning "C-x"), a backslash followed by an octal
number (specifying the ASCII code of the character), or a backslash followed
by a second character, such as "\^" or "\\". The default is "^Aa".
If there is some mapping that you don't use in emacs, even if it's inconvenient, like C-|, then you could use your terminal input manager to remap ALT-X to that, letting you use the ALT binding instead. That would be a little hackish though.
I'm an Emacs and screen user as well. Although I rarely use Emacs in a terminal -- and as such in a screen session -- I didn't want to give up C-a for the shell either (which uses Emacs key bindings). My solution was to use C-j as the prefix key for screen, which I was willing to sacrifice. In Emacs programming modes it is bound to (newline-and-indent) which I bound to RET as well, so I really don't miss it.
By the way: I know this is an advise rather than an answer, but I felt this would be valuable enough to post nevertheless.
To make Alt+X the default prefix for commands and free C-a, add the following lines to .screenrc:
escape ^||
bindkey "^[x" command
As a side effect C-| will be command prefix too. If you need this keys to be free too, then fix "escape ^||" accordingly.
Screen doesn't have any shorthand syntax for alt bindings, but you can give it the octal code directly. For instance on my machine, Alt-x has the hex code F8, or 370 octal, so putting
escape \370x
in my screenrc changed the escape code to alt-X
Tested and works with screen 4.00.03 on Linux.
You may have to change the escape, since I think this may depend on things like your language and codeset, etc: how I found out what my escape code was was to type
$ echo -n ^QM-x | perl -ne 'printf "%lo\n", ord($_)'
^Q is the quoted-insert command for readline (it inserts what you type directly without trying to interpret it) and M-x was a literal Alt-X.
Fellow emacs user here.
The best solution I've found is a ~/.screenrc file with the following:
# C-a :source .screenrc
escape ^gg
Live updated here: https://gist.github.com/1058111
See also: http://ubuntuforums.org/showthread.php?t=498675
Something I have had for years in my .screenrc:
escape ^Zz
which is now hardwired in muscle memory for me.
Somehow I ended up having to share a screen with someone else's config, and now I keep stopping processes all the time (bash ^Z)... Not funny...