I copied a few lines from somewhere into my .screenrc to give me an informative hardstatus line:
# An alternative hardstatus to display a bar at the bottom listing the
# windownames and highlighting the current windowname in blue. (This is only
# enabled if there is no hardstatus setting for your terminal)
hardstatus alwayslastline "%{.bW}%-w%{.rW}%n %t%{-}%+w %=%{..G} %H %{..Y} %m/%d %C%a "
As per the screen documentation, the 'blinking' color modifier is B. Yet the hardstatus line has NO B's anywhere... and it still blinks! It's driving me nuts. I've looked at other screenrc's, asked coworkers, removed tokens left and right from this status line, but nothing will stop it blinking.
How can I get the nice red-on-blue status line, without blinking? Any help would be appreciated.
I happened to find this phenomena.
It's a typical compound display question. In my enviornment, I use screen hardstatus config similar to yours, and use Xshell as terminal tool. I use linux in Xshell, this phenomena occurs. If I change to xterm, it disappears definitely.
So, try to change your Xshell config.
Related
The other day I mis-clicked on and mis-dragged something probably and then the left "side bar" of the editor window got wider than normal.
Since this happened by mis-clicking and dragging, I don't know how to reset it back to the normal width. It simply doesn't respond when I try to click and drag the borderline. Didn't find anything related in Settings either.
It's not possible to change the gutter width at the moment. It adjusts itself automatically when needed (e.g. there is a gutter icon for override method and a breakpoint on the same line).
Looking at your screenshot, the width is actually standard. It needs some extra space to allow you setting breakpoints without accidentally clicking the line number.
You could submit a feature request/usability problem to https://youtrack.jetbrains.com/issues/IDEA, but to me, it seems fine.
But since you say it was different the other day and then something happened and it became wider, you could try starting PyCharm with default settings by renaming/removing configuration folder. Here is the article on how to find it.
Go to Settings -> Editor -> General -> Gutter Icon and uncheck the Show gutter icons.
But you should be careful: this action will hide information about recursive calls, override methods etc...
By default Terminal.app has a keybinding for ⌘+↑ that scrolls the screen back to (and briefly highlights) the previous command prompt. (This seems to be independent of shell although I've only tried a couple. I'm using bash.)
I'm trying to get similar behavior in iTerm2, but I haven't found a mapping that does that. None of the search terms I've tried in iTerm2's list of key mappings suggest anything like this function. The iTerm2 mapping preset called Terminal.app Compatibility causes ⌘+↑ to scroll through previous commands, the same way ↑ does, rather than the window scrolling back to the lines on which previous commands were input.
Based on this answer to a similar question, I looked through the output of bind -p and see entries "\e[A": previous-history and "\e[B": next-history, but these seem to be describing the scrolling through previously-entered commands rather than scrolling through the entire terminal window output to the prompt at which the command was input. These are the only bind -p entries that refer to up or down arrows (if my assumption is correct that [A refers to the up arrow, which I determined with xxd -psd as suggested in this answer.
Is this behavior in Terminal.app the result of a key binding? Or, how would I determine whether it is or not? And is there a way to get iTerm2 to duplicate this behavior?
Have you tried
fn + CMD + UpArrow ?
Only an ersatz for Terminal.app "going up one prompt at a time” behavior, but maybe helpful as it makes iTerm2 do a Full Page Up consistently across my custom profiles and various key map preferences.
With shell integration installed, iTerm2 creates a "mark" at each prompt, and the default shortcut for moving to the previous mark is ⌘+⇧+↑.
PHPStorm has a vertical line on what they call the "right margin" which is set by default to 120 characters or columns...
Given that PSR standards state There MUST NOT be a hard limit on line length; the soft limit MUST be 120 characters; lines SHOULD be 80 characters or less., it'd be nice if I could get another visual indicator at the 80 character mark...
I'm well aware that it says what line/column you're on in the status bar, but I typically hide most panels (status bar included) while coding.
Therefore, is there a way (feature or plugin) that would allow me to add a 2nd vertical line to indicate the 80th column?
It is not currently possible .. and no plugin comes into my mind.
https://youtrack.jetbrains.com/issue/IDEA-99875 -- star/vote/comment to get notified on progress.
P.S. Considering that this is rather PHP/Python specific (other languages do not care about this) .. I would not expect JB to have it implemented in nearest future...
I suggest the following workaround, it works for me on PhpStorm 9.0:
Open Settings page (usually Ctrl+Alt+S), go to Plugins -> Browse Repositories
Find and install BackgroundImage plugin
Restart IDE, it may output an error, something like "unknown protocol d" - don't worry, go forth
Make an image with height=1px, and width=(desired width of additional margin). Give it, say, white background and paint one rightmost pixel to say, black. I took a screenshot of an editor and cropped it in PS, to avoid annoying search and adjustment of the image width. Every change of background image requires to restart PhpStorm.
Open Settings again, goto Other settings -> BackgroundImage
Set Enabled checkbox, browse your created image, and check the FileSystem radio button
Restart IDE again and change the margin and you will get two margins
The image is left-aligned, so when you resize an editor on x-axis (move the splitter between Editor and Project View or File System View, etc.), the margin will remain truthy.
Some side-effects - it appears also on console window, event log, perhaps somewhere else.
If the plugin doesn't work, check out this page (there said that most JetBrains plugins should work on all products on IntelliJ Platform, and some workaround if they does not): http://www.jetbrains.org/intellij/sdk/docs/basics/getting_started/plugin_compatibility.html
ADDED: Doesn't work with scaling an editor (Ctrl + MouseWheel) - the scale of the image (fake margin), remains the same and the margin becomes not truthy.
In the latest PHPStorm, this is now possible. This would be PHPStorm 2017.3. The instructions on the ticket mentioned in the accepted answer explains it quite well:
Will be available in the next EAP build. You can set it up at
Settings|Editor|Code Style|Visual guides for all languages or on
"Wrapping and Braces" tab for a specific language ("Other" tab for
XML/HTML). You can change the visual indent guide color at
Settings|Editor|Color Scheme|General|Guides|Visual guides. Please
submit separate reports if you find any problems.
I personally found the setting in Settings|Editor|Code Style|PHP|Wrapping and Braces|Visual guides. It should be there for every language.
Given the following byobu (with tmux backend) status bar, how can the window activity notification colors be adjusted? Since they are currently the same as the "active" window, it is difficult to tell the difference.
Sure! You can set it like this, in your ~/.byobu/.tmux.conf:
set -g window-status-activity-bg red
For a complete list of color options, refer to tmux.1 and specifically its OPTIONS section
Full disclosure: I am the author and maintainer of Byobu.
On my new Ubuntu system, I start a screen session and edit a file in vim or view it in less. After I quit, the screen doesn't redraw itself, but simply scrolls up to show a command line under all the stuff I was just viewing in vim or less.
How can I change this so that quitting vim will return me to the screen the way it was before I invoked vim?
screen's altscreen (alternate screen) feature is turned off by default.
Add this to your .screenrc:
altscreen on
See: http://www.gnu.org/software/screen/manual/screen.html#Redisplay
This is caused by your termcap for screen being incomplete. (This seems to be a really common problem.) Vim doesn't know the sequence for restoring the screen, so it just leaves it like it was.
You can work around this problem by setting vim's term option (or the TERM environment variable before you start vim) to a terminal that's "screen compatible", like xterm. eg:
TERM=xterm vim
or (in vim):
:set term=xterm
You can set the t_ti and t_te options in vim to the right codes. See :help xterm-screens in vim for more details.