This is my PS1 variable for the terminal:
PS1='\n\e[1;36m┌[\w]\n┤\n└\]\e[1;00m[\u#\h][\$]'[\$?]'\]\e[0m\] '
When I type a long string like "xxxxxxxxxxxxxxxxxxxxxxxxxxx(cursor)" and press the up arrow to look for and "old typed string", this occurs to me:
xxxxxxxxxold typed string(cursor)
The terminal delete only part por the "xxxxxxxxxxxxxxxxxxxxxxxxxxx" typed string. how could i correct this behavior? Thanks
Related
I have a text file that contains some basic passwords and some variants of those basic passwords. They are typed out together like this:
qwerty, qwerty1
password, password1
default, default 1
123, 12345, 123456
I am trying to take these values and split them, storing them in a tuple and then print out the values as 'Password' and then any variants, but I am getting a syntax error on the print BIF? (I am aware this will not print out the password '123456', I am just trying to solve the syntax error first.)
for each_line in passwords:
(passwd, passwd_variant) = each_line.split(',',1)
print(f'Password: {passwd}, Variant {passwd_variant}')
SyntaxError: invalid syntax
normally if I was writing a script, in the editor I would put print on a new line, however a new line in IDLE simply executes the code above it. is there a shortcut or something to do a carriage return and write the print statement on a new line and if so, is that the cause of the syntax error and why?
Cheers
EDIT: I would like my output to be this
Finally discovered that you need to hit Enter after the for in statement, this will then take you to a new line inside for in statement. Was up all night trying to work it out, maybe my fresh brain helped this morning.
I've removed and added a few times now the following line to ~/.tmux.conf:
set -ga terminal-overrides ',xterm*:smcup#:rmcup#'
Which according to the person who provided it does the following:
to fool the multiplexers into thinking that the terminal has no "alternate screen" mode (such as that used by pico, mutt, etc). This is accomplished by setting termcap commands for the session.
The 'xterm*' part of the command should be set to whatever your terminal-emulator is declared as.
The end result is that the overflow ends up in the terminal's scrollback buffer instead of disappearing. Of course, since this is one static buffer, things will get messy as you switch between screen or tmux windows, but this is handy for quickly flicking up to see the output of an ls command or the such.
I don't quite understand the bolded section (emphasis added), but guess this is the source of what I'm seeing. It's causing some weird sort of unicode overspill upon exiting tmux.
Pasted as plaintext this text won't show up, but the symbol [001B]112 appears alongside the usual [exited]:
]112[exited]
(FWIW I think it has pasted in that line, but isn't displaying)
I followed this advice ("Use terminal scrollbar with tmux"), and while it does work, this is just ugly/annoying to see that upon exiting. Can anyone advise how to fix or avoid the output message?
Offhand, I would get the unwanted "message" is some hard-coded application (or script) which is helpfully resetting the xterm dynamic text cursor color. See XTerm Control Sequences in the description of Operating System Controls:
The dynamic colors can also be reset to their default
(resource) values:
...
Ps = 1 1 2 -> Reset text cursor color.
So... somewhere there is some script doing the equivalent of
echo -n -e '\e]112\a
The results probably depend most on what particular terminal emulator you are using. Both screen and tmux filter out escape sequences that their developers did not care to implement, and pass through those that the terminal "should" handle.
Just take a look at sentence you provided: "The 'xterm*' part of the command should be set to whatever your terminal-emulator is declared as."
In my case, the $TERM has value xterm-256color and the corresponding line in ~/.tmux.conf looks like:
set -g terminal-overrides "xterm-color256:smcup#:rmcup#"
I'm trying to do a fancy-shmancy tweak in my Tiny Core Linux command line. I decorated my PS1 like this:
http://i.stack.imgur.com/iEBx2.jpg
But here is what I get in most cases:
http://i.stack.imgur.com/FN4dv.png
If I press Tab or Up\Down to scroll history it prints new PS1 strings on top of previous. On the other hand when I press Enter to run a command it prints a new line and it's all OK.
I'm running the Almquist shell (ash, not bash).
Can I implement the next algorithm:
1. If the last key pressed was Enter, then... (do nothing)
2. Else if the last key pressed was another key, then... (position the text pointer one line up to redraw the previous PS1.)
I would implement this right inside the PS1 definition. But how can I get the last key pressed before some action (when the PS1 is printed) using only ash variables and commands?
Here's what happens. I'm using Vim + LaTeX-Suite to edit TeX files in Vim. This could be in the Terminal or in MacVim.
I happily
Insert lots of $\LaTeX \commands$ etc. I love using the $\backslash$.
TeX works great. No problem.
Then I go and open up a .R file in the same window (different tab). R-Plugin for Vim uses the <Leader> key (mapped to \ as per usual) to execute commands, e.g. I type \sa to send the selection to R and execute and move the window down. Life is nice.
Problem: even though while editing an R file, Vim is nice enough not to bug me in insert mode when I type \, for some reason when I switch back to the tab to edit the TeX file, then type \ in insert mode, it moves the cursor left of the \ and pauses as though waiting for the rest of the command, before then re-moving to the right of the \ and moving on as I type.
Below shows what happens just from typing \ in insert mode; obviously I could reproduce this by moving the cursor to the left with the arrow keys, but that's not how this happened--the cursor just moves left for a split second as though waiting for the R command to finish being input.
So: how can I stop the annoying behavior in the TeX file insert mode, without sacrificing other functionality? Note, (a) I don't expect mapping <Leader> to a different key to help since then that key will just have the same left-cursor-move problem in TeX; (b), I like the leader as \ anyway so I don't want to change it.
Put this line in your vimrc (requires Vim-R-plugin >= 0.9.9.2):
let g:vimrplugin_insert_mode_cmds = 0
If the problem persists, you can do the following in Normal mode to know what are the keyboard shortcuts in Insert mode:
:imap
I'm using Emacs 24 on Windows to write some R code. Up until about 30 minutes ago, whenever I would write a new function, ESS would automatically indent the lines following the function declaration and pressing the tab key on a new blank line would jump me to the appropriately indented starting position inside the declaration.
EG:
foo <- function() {
first line started here
second line here. .etc
}
Now, it is hard wrapping everything to the left, and not responding by automatically indenting after the function declaration or when I hit the tab key.
foo <- function() {
first line
second line
}
I've googled, but my google-fu is failing me on this. Anyone know how to restore default tab behavior to ESS in Emacs?
just for the record. Whenever such things happens, select the whole buffer C-x h and press C-M-\ to indent the whole region. This will show unambiguously the syntax error.
Try to add a space after "#".
I don't think ESS-mode handles # as a comment unless you have space after it.
I just came across the same problem you describe.
None of the above seemed to work, but I narrowed it down to using a carriage return and then an open parenthesis inside a string, like so:
### indent ( <tab> ) working fine up to here
s1 <- "string
(then this in brackets)"
### now indent does nothing!
The fact that it's balanced later doesn't help. I think EMACS reads this as opening a new expression/ block in spite of the fact that it occurs in a quoted string. This seems to apply also to expression openers { and [. It only seems to happen when the 'open expression' symbol appears at the start of the line...
In my case the string was part of a plot label, so the solution was to use \n instead.