Enlarging text while having line numbers enabled covers the view of the numbers?
I've enabled line numbers globally by adding (global-linum-mode t) to init.el.
Zooming in on text using the C-x C-+ keybinding results in the behavior seen below, which is not satisfactory.
What can I do to fix this? Are their working alternatives?
I don't see this problem, using library zoom-frm.el (see also Emacs Wiki page Set Fonts).
But vanilla Emacs clearly has another bug, in that enlarging the text by scaling enlarges the horizontal space used for the line numbers (good), but shrinking the text then does not shrink that space used for line numbers (bad). I've just now filed Emacs bug #24164 for this.
In Notepad++, you can press Alt-LeftMouseClick-Drag to select a rectangular region.
How do I do this in emacs (windows) ?
I tried the methods in http://www.emacswiki.org/emacs/RectangleCommands but
my selection happens as a regular region instead of rectangular shape:
http://i.stack.imgur.com/tBMBN.png
I also tried enabling/disabling cua mode.
In Emacs 24.4 and greater, C-x SPC is bound to rectangle-mark-mode which selects a rectangle visually.
http://emacsredux.com/blog/2014/01/01/a-peek-at-emacs-24-dot-4-rectangular-selection/ describes this in greater detail.
One more fun one to add to the list.
If you're using evil-mode (ie, the Vim emulation layer), you can use evil-visual-block (default binding of C-v) to select a rectangle visually.
In Emacs, whether a command affects a continuous piece of text or a rectangle depends on the command, not on what the selection looks like.
I'm not aware of any way to make the selection appear as a rectangle on the screen (but see this answer), but if you use any of the rectangle commands listed in the page you linked to, such as C-x r k or C-x r t, you'll see that they operate on the rectangle defined by the beginning and the end of the selection, despite the fact that the selection looks like a regular region.
You use rectangle commands by placing the mark at one corner of the rectangle and point at the opposite corner. Even though the region will be displayed as normal, the rectangle commands will act on the rectangle delimited by point and mark. CUA mode doesn't affect this.
You just have to use your imagination :)
Enter rectangle mark mode with C-x SPC
Shrink or grow region by (This is going to select a rectangle):
2.1. Do C-n or C-p to expand the cursor to the next or previous lines respectively.
2.2. You can now play with text selection by doing C-f, C-b, M-f, M-b, etc.
This selected rectangle region can be used to perform some actions like
kill : C-x r k
delete: C-x r d
yank: C-x r y (paste last killed rectangle at cursor position)
If you want to see the rectangular selection, use CUA rectangles instead. Enable it with
(cua-selection-mode t)
Then use M-RET to start the selection, move the cursor to change it (you can also hit RET to move the cursor to different corners), C-? to get a list of commands to operate on the rectangle. M-RET with the selection active cancels the selection, as does C-g.
CUA selection mode does not enable the rest of CUA, so C-x, C-c, C-v, etc. will not change.
You can do the same thing with the mouse if you so wish. While not as specific as doing it via keyboard where you can select characters that don't exist following the end of the line for example it will fulfill most use cases.
(defun mouse-start-rectangle (start-event)
(interactive "e")
(deactivate-mark)
(mouse-set-point start-event)
(rectangle-mark-mode +1)
(let ((drag-event))
(track-mouse
(while (progn
(setq drag-event (read-event))
(mouse-movement-p drag-event))
(mouse-set-point drag-event)))))
(global-set-key (kbd "M-<down-mouse-1>") #'mouse-start-rectangle)
Found this here: https://emacs.stackexchange.com/a/7261
Most rectangle commands are accessed via the C-x r prefix (shared
with the "register" commands). See the
Rectangles manual section
here
for a description of all the special kill, yank, delete, number, replace,
etc. commands, which you'll need to do anything useful with your rectangles.
The only non-prefixed rectangle command is the initiator C-x SPC
(rectangle-mark-mode), but that's easy enough to remember, being a
lot like the very common C-SPC (set-mark-command).
It looks like in recent Emacs versions, the selected region is working
well to show exactly what's selected.
(I recommend
helm-descbinds or
guide-key to complete your
C-x r command prefixes, as well as any others.)
In addition to what others have mentioned, including about highlighting shown as a rectangle by rectangle-mark-mode and cua-rectangle-mark-mode, library Mode-Line Position (modeline-posn.el) provides the following feature for use with rectangle commands: It shows the length and width of the rectangle in the mode line, as part of size-indication-mode.
Normally, size-indication-mode shows only the buffer size and the current relative position in the buffer. With library modeline-posn.el what you see is different when the region is active:
For a rectangle command that reads input, you see the number of rectangle rows and columns (e.g. 21 rows, 16 cols)
Otherwise, the region size.
You can customize how this information appears (option modelinepos-style). By default, the active region size is shown as the number of characters and the number of lines in the region (e.g. 473 ch, 3 l).
The face used for the mode-line indication of an active region (including rectangle) is face region, so it looks the same as the region.
An additional feature draws your attention further to the mode-line region indication when a command that acts on the active region or changes its behavior when the region is active reads input. This just uses a different face, which by default is face region but with a red overline and underline.
Finally, Boolean option modelinepos-empty-region-flag determines whether an empty active region is indicated in the mode line, to attract your attention (you might not otherwise notice that you are acting on an empty region). E.g., you see (highlighted using face region): 0 ch, 0 l.
When I start a rectangular selection (C-x SPS), firstly, a thin line appears at the side of the rectangle which shifts lines to the right.
Is there a way to make rectangular selection seamless?
The thin line is put "on purpose" to visually show where is the empty rectangle. We could make it optional (in which case the 0-width rectangles would simply not be displayed). Please use M-x report-emacs-bug since that's where this discussion should take place.
Update
This problem disappeared after upgrading from Mountain Lion to Mavericks, while also updating Emacs from 23.4 to 24.3.
End-update
With a .emacs file containing
(set-foreground-color "white")
(set-background-color "black")
(setq mouse-wheel-scroll-amount '(1 ((shift) . 1) ((control) . nil)))
(setq mouse-wheel-progressive-speed nil)
as I scroll up or down with the reduced step, I see the strange patterns
Magnifying one of the patterns reveals
This problem has been present in Emacs 22, 23, and now 24 for several versions of OSX—up to and including Mountain Lion. Is it a known rendering bug? Is there a fix?
Neither the suggestion to modify fringes nor linum works for me. Where else can I look?
If I use the default white background and black foreground, these lines either do not appear or are imperceptible (to me).
What is most pesky about this problem is that redrawing (C-l) does not result in clean text.
The problem is related to the interaction between OS X's LCD Font Smoothing algorithm and the algorithm that emacs uses to implement scrolling.
The figure below shows font smoothing turned off (left) and on (right). You will find this setting in System Preferences \ general. In both cases I scrolled the program by one line. When OS X draws the "#" with font smoothing turned on, it does not only use the pixels dedicated to the "#" but also uses the blue pixels of the adjacent (blank) character.
When emacs scrolls, it only modifies the characters that it believes need to be modified. If the character is blank and will remain blank after scrolling, it does not modify it. This optimization remains valid in 2013. In other words, testing that two characters are blank is still cheaper than drawing one character. But this optimization is hardly necessary today, and it results in the buggy display.
If the hypothesis above holds, the sequel question becomes whether one can turn off the optimization. Is it possible to ask emacs to redraw the full screen at each scroll or to at least redraw characters that remain blank if they were adjacent to a non-blank character.
One could of course simply turn off font smoothing. The magnified image may even suggest that the non-smoothed image is better. In practice, when the fonts appear in their natural (unmagnified) size, smoothing makes the characters far more legible, eliminating the need to use larger fonts.
The pattern on either side of "c();" in the image below is consistent with the bug. OS X uses blue pixels on the left side and red/tan pixels on the right (possibly this is related to the RGB pattern on the display). The vertical lines left over when scrolling are either blue or red/tan/brick, depending on whether they have dropped out of the left or right side of scrolled characters.
Update
The problem is now solved in this nightly. The magnified c(); produced by Emacs 24.3.50.1 shows that the font smoothing remains identical to that produced by Emacs 24.3.1. But the output is not identical. There is at least one extra horizontal line of pixels between each two lines of text.
I don't know if this can easily be done with Emacs (read below for my hack in case there's no easy way to do this) so...
How can I add one pixel of vertical-spacing between each line under Emacs?
I know that screen real estate is precious but I'm using a "custom" font (ProggyFont) and, under IntelliJ IDEA, I can modify the vertical spacing to something that I like.
Under Emacs, however, I find the text hard to read because the pixels from one line are too close from the pixel of another line, so I'd like to add one "one pixel" empty vertical line between every line. Can this be done simply?
If there's no "simple way", how do I take a "x by y" bitmap font and turn it into a "x by (y+1)" bitmap font? I don't mind using a font editor: been there, done that. But I don't know exactly everything that would be involved.
Check out the line-spacing variable, e.g.
(setq line-spacing 0.2)
From the docs:
Additional space to put between lines when displaying a buffer.
The space is measured in pixels, and put below lines on window systems.
If value is a floating point number, it specifies the spacing relative
to the default frame line height. A value of nil means add no extra space.