I use the default terminal.app
I use cmd+d command to split panes so I can look at the part of the code while using another command.
This annoying bug comes up when de-splitting the panes.
What it does is that it basically reduces the vertical length of the terminal, so that after de-split, terminal is not filling my screen vertically.
Is there any solution to this?
Any true solution is going to have to depend on a bug fix. But this works for me:
Set the window default size in Preferences/Profiles/Window.
Assign a shortcut key to Window/Return to Default Size.
You could also use the inspector that you get with Shell -> Show Inspector.
Related
While I am typing on a specific line in workspace, the text present in the particular line's font is getting increased ! And it gets to regular size as soon as I stop typing.
I also upgraded to XCode 8.2 still the same issue occurs.
FYI:
I have also tried the following code to reset the XCode default settings, but still no use.
defaults delete com.apple.dt.Xcode
Solution:
This happens when you change font size for one particular element but the other editor's elements are using the previous/default font size.
If you want to change the font size either press cmd + or in preferences -> Fonts and Colors choose your theme and in the right pane select all the elements (press cmd a) and then change the font size.
See this SO answer
I had a similar problem but I am not sure is exactly the same.
Did you try to change this settings?
Xcode preferences > Fonts & Colors Your chosen theme will have a
"current line" option just under the font. Can't remember exactly but
I think you can find something there.
I can't get emacs to scroll horizontally!
To replicate the problem:
Open the *scratch* buffer.
Write a long line.
Make the long line exceed the window width with M-xtoggle-truncate-lines. The left hand text (column 0) will now be off the left of the window.
Try M-xscroll-left or its shortcut C-x < to scroll left.
Type y to enable the disabled commands.
NOTHING HAPPENS!
I also tried C-a to go to the beginning of the line.
I also tried M-xtoggle-horizontal-scroll-bar but got the error message "Horizontal scroll bars aren't implemented yet".
There seems to be no way to scroll horizontally!
I need this because I have many wide CSV files to read.
I'm using the latest prelude on emacs 24.5 on Windows 10.
I filed an issue on the prelude project in case it is a genuine bug and could be fixed there.
You seem not to understand how horizontal scrolling works. It's not intuitive, that's why the command is disabled by default.
When I press C-x< at the end of the long line, the line disappears to the left. When I press C-x> there, nothing happens.
Pressing C-x< at the beginning of the long line, though, shows the second part of the long line.
Consider using visual-line-mode or even the csv-mode instead.
There is new a feature in Emacs 26. You can customize mwheel-tilt-scroll-p and use mouse to scroll.
M-x customize group RET mouse
Then set mwheel-tilt-scroll-p to t
No need to handroll it yourself. This is provided out of the box in emacs 27, and it probably was available for longer:
This feature is off by default; the variable mouse-wheel-tilt-scroll turns it on, if you customize it to a non-nil value.
(setq mouse-wheel-tilt-scroll t)
Sounds like xemacs have horizontal scroll in a 'natural' way.
As far as I can see it there is a [Options] button in the menubar, when clicking on it there is a [Frame Appearance] sub menu and there, there are 2 button []scrollbars, [] Truncate Lines
When these 2 buttons are checked in, long line are truncated and scrolling is smooth.
May be xemacs is non standard though.
I use it, I find it easy to cut/paste even rectangular areas, selection is faster and more precise to me that what I could achieve with keyboard meta-ctrl-shift stroke alone.
Cheers
Phi
I
Can anyone suggest:
Why does it higlight like this? I don't seem to do anything to activate it:
How to disable it?
This is old, but I ran into the same problem and just figured out an easy fix.
From the file menu: Language > N > Normal Text
I'm not sure if this is the same issue as mine, but I wanted to keep the language setting enabled but remove the highlighting.
I did this by going to Settings --> Preferences --> Highlghting
Removed the Enable check mark for Highlight Matching Tags.
1) Go to settings -> Style Configurator.
2) Select the language that Notepad++ has chosen, usually based on filename extension. You can also change this manually under the Language menu setting.
3) Go through the Styles until you find the style that applied the highlighting. You can tell because the Background colour will match the highlighted color.
4) Change Background colour to white.
I do not have an answer for your first question
For your second question do the following steps
Inside Notepad++ press ctrl A( select all)
Right click for context menu.
select Remove style and click on Clear all Styles
This will clear all the highlights.
FYI. You may also see this sort of behavior when using a vertical edge in background mode. Switching to line mode will eliminate the highlighting of lines that run over the set character count for the vertical edge.
I have following content layout on a page:
Then text is entered into input box, keyboard appears and 1. Fixed header is shited up:
How can I make area 1. Fixed header really fixed, so it's not moved by keyboard?
Update 1: solution #1, however I find it rather cumbersome and complex to implement. If there any other ways I will be happy to see them.
Kindly go through this example we have to do some manual works as this issue is because of the default property of keyboard in wp7
http://sorokoletov.com/2011/08/windows-phone-70-handling-text-entry-screens/
Using Terminal.app on OS X 10.5, often you see the commands get garbled when you do a reverse-search with Bash. Is there some kind of termcap or perhaps a bash shopt command that can fix this? It is very annoying.
Steps to reproduce: Open Terminal.app, reverse-search to a longish command. Hit <ctrl>-E once you've found the command. The cursor goes to the end of the line, but the display doesn't update.
I'm guessing this is some kind of problem with the readline library on OS X. It's more of a problem with updating the cursor position after a search than anything else. Basically, ctrl-a and ctrl-e tend to break the search output.
os x terminal failure image http://involution.com/images/osxterminal.png
In the above, the first part of the command should be displayed, and the cursor should be at the end of the line, but it isn't. You literally can't see what you're editing when this happens.
I was able to set my TERM to xterm instead of xterm-color and it solves the problem. (export TERM=xterm).
You may want to look at this post.
bash-prompt-in-os-x-terminal-broken
I had the same problem and it had to do with the PS1 variable. Let me know if this helps.
If the prompt has colors, then this is an acknowledged bug.
See bug report msg#00019.
I've encountered this bug, and while I don't know how to solve it, you can work around it by pressing <down><up>
Not sure whether this is the problem here, but a very common cause of a messed up screen in bash (with any terminal emulator, not just Terminal.app) is the window being resized.
Bash will read the window size when it starts up, and then assume it hasn't changed. When the window is resized a signal will be sent to whatever app is currently reading from the console. If this isn't bash (because you're running a text editor at the time, perhaps), then bash won't know about it.
Solution in this case is to resize the window again so that bash gets the signal and notices the new size.
I can't reproduce this, hitting either Ctrl+E, Ctrl+A or the arrow keys updates the command line correctly. Are you running 10.5.4? Is it perhaps a bug in earlier versions?
In worst case, you could launch the X server (somewhere under utilities) and launch a real xterm.