Is there a way to position a value on the the right end of the modeline?
From my understanding currently the modeline "pushes" its values farther right if the values increase in size. I would prefer it if some values would start on the right side and expand into the middle.
I have tried solutions like powerline, but they seem rather distracting and more complicated in setup to display the same amount of informatioon as the standard modeline.
Here is one way to do it. The trick is to add spaces until the end of the line minus the place needed to display your text (extracted from powerline code on the emacs wiki):
(defun mode-line-fill (face reserve)
"Return empty space using FACE and leaving RESERVE space on the right."
(unless reserve
(setq reserve 20))
(when (and window-system (eq 'right (get-scroll-bar-mode)))
(setq reserve (- reserve 3)))
(propertize " "
'display `((space :align-to (- (+ right right-fringe right-margin) ,reserve)))
'face face))
;; Set the modeline to tell me the filename, hostname, etc..
(setq-default mode-line-format (list
" "
mode-line-mule-info
'mode-line-modified
"- "
'mode-line-buffer-identification
" (%l, %c) "
'mode-line-modes
" -- "
`(vc-mode vc-mode)
;; Fill until the end of line but 10 characters
(mode-line-fill 'mode-line 10)
"Some text"
)
)
As far as I'm aware, that isn't possible to do through straightforward customization of the ordinary mode line. You can modify the mode-line-format variable to alter its appearance and contents to some degree, but as far as built-in constructs for text alignment are concerned, I'm fairly certain that you're limited to controlling the width of mode line components via either padding or truncation. It might be feasible to employ some clever hackery within the mode-line-format variable (using the (:eval ...) and/or (list ...) forms) to achieve the desired result, however. You could consult the Emacs Lisp Reference Manual page on the mode-line-format variable for details. Beyond that, you'd have to use some third-party packages.
Related
I am trying to set the line height of text in an Emacs buffer so there is space above and below the letters. From the documentation, I infer that the line-height text property may help me to accomplish this.
There is also a line-spacing variable which I can set like (setq-default line-spacing 0.25). This kind of works, except it does not produce space before text, only after it. I don’t like the way this looks when using modes like show-paren-mode, since it “dips” down:
Undesired current behavior (“hanging”)
Desired behavior mockup (vertically-centered)
I'd like to vertically-center the text.
I have discovered that I can temporarily get the effect I want with the following code:
(add-text-properties (point-min) (point-max)
'(line-spacing 0.25 line-height 1.25))
However, in some modes the properties go away in regions where I start typing. How do I make that top and bottom spacing the default? (Hooks won't work.)
Update
TLDR: I've succumbed to the fact that you can't really reliably achieve this natively with Emacs. You need to patch the font itself to include extra spacing. So, I created this script to take care of that.
Old/Incomplete Answer
TLDR: Add this somewhere in init file:
;; Set the padding between lines
(defvar line-padding 3)
(defun add-line-padding ()
"Add extra padding between lines"
; remove padding overlays if they already exist
(let ((overlays (overlays-at (point-min))))
(while overlays
(let ((overlay (car overlays)))
(if (overlay-get overlay 'is-padding-overlay)
(delete-overlay overlay)))
(setq overlays (cdr overlays))))
; add a new padding overlay
(let ((padding-overlay (make-overlay (point-min) (point-max))))
(overlay-put padding-overlay 'is-padding-overlay t)
(overlay-put padding-overlay 'line-spacing (* .1 line-padding))
(overlay-put padding-overlay 'line-height (+ 1 (* .1 line-padding))))
(setq mark-active nil))
(add-hook 'buffer-list-update-hook 'add-line-padding)
Increase or decrease the line-padding value to your liking.
This answer pretty much just summarizes the information in the above question, answer, and comments, so I suggest reading those first.
I use an overlay instead of text properties because it behaves more nicely when adding new text to the buffer (especially via copy/paste).
The buffer-list-update-hook is used as a means of identifying when a new buffer has been created and thus would need to have the overlay applied.
For performance reasons, to not continuously add overlays, the existing padding overlay is deleted if it aleady existed.
As the doc says, line-height is a text (or an overlay) property. It is not a variable.
Try (setq-default line-spacing 20).
line-spacing is a frame parameter or a buffer-local variable. Its value can be an integer number of pixels or a floating-point number specifying spacing relative to the frame's default line height. The doc says nothing about giving it a list value, such as (32 64).
And if you are using Emacs in terminal mode then none of this applies. As the doc says about that:
On text terminals, the line spacing cannot be altered.
Try "Help => More Manuals => Emacs Lisp Reference" and from there type i text properties RET. This will hopefully clarify the situation. As for your specific request, I don't think there's a simple way to get what you want right now. You might like to M-x report-emacs-bug about the display appearence of the paren-highlighting.
I'd like to display a few lines at the top of the buffer, but not as part of the actual buffer text, just for display.
Specifically, I'd like to display a Git timeline (not yet released, sorry), like this automatically when I open a file, so I can easily see any recent activity:
P DP D D
T=F=S=S=M=T=W=T=F=S=S=M=T=W=T=F=S=S=M==T==W==T==F==S==S==M==T==W==T==F==S==S==M=
11 18 25 2 9
(Single chars are first initials of people with commits on those days. There will be a legend below as well)
It sounds like I want something like the header line, but for the buffer. Is there anything like that?
One idea I had was to use an overlay at the start of the buffer and put my text there, but I'm not at all sure this is "the right thing" or a completely inappropriate / unsuitable use of this.
I tried, and got it working, using an overlay of the char at (point-min), with the text-property of 'before-string and the string literal above (with newlines and a trailing newline). Here's a proof of concept:
(defun test/add-overlay ()
(interactive)
(setq test/timeline-overlay (make-overlay (point-min) (+ (point-min) 1)))
(overlay-put test/timeline-overlay 'timeline-panel t)
(overlay-put test/timeline-overlay 'before-string
(propertize " P DP D D \nT=F=S=S=M=T=W=T=F=S=S=M=T=W=T=F=S=S=M==T==W==T==F==S==S==M==T==W==T==F==S==S==M=\n 11 18 25 2 9
" 'face 'font-lock-comment-face))
)
(defun test/remove-overlay ()
(interactive)
(remove-overlays (point-min) (point-max) 'timeline-panel t)
)
This does seem to work quite fine, but I'm not sure if it might conflict with something else.
Is this the way to go, or are the more suitable user interface constructs in Emacs to do what I want?
If you can reduce it to a single line, then use header-line-format -- it's local in every buffer. Just set the variable for the buffer you want. See the Emacs sources for examples, e.g., ruler-mode.el.
You seem to have dismissed using a header line, saying that you want something "for the buffer". I don't understand why you think header-line-format does not give you what you want (except that it is one line only).
Yes, if you want display-only text placed at a particular location in the buffer, then an overlay with some after-string or before-string is the way to go.
this is my first question, so apologies for breaking any rules.
I've just started writing some functions in elisp to help me navigate certain types of text files more efficiently. To make these accessible, I've added some buttons to the tool-bar. As it's now becoming busy, I'd like to either: 1) move some of these additional buttons to a second line; or 2) instantiate a second tool-bar that could be placed somewhere else in the frame (either under the existing tool-bar, or perhaps vertically along the side where the scrollbar is).
I've searched high and low but am unable to find an existing example of this and, as I don't yet really know what I'm doing, I wonder if somebody has a code snippet from which I might start to hack a solution together.
Many thanks in advance.
System: CentOS 5/6, emacs for linux 23.1
Edit:
Thanks for the comment, William. Here's a simple example representing what my tool-bar code might do:
;
; functions used by the toolbar
;
;
(defun copy-paste-whole-line ()
"copies and pastes the whole of the current into a new line underneath"
(interactive)
(beginning-of-line)
(set-mark (point))
(end-of-line)
(setq temp (buffer-substring (region-beginning) (region-end)))
(message " copying: %s" temp )
(newline)
(insert temp))
;
;
; population of the toolbar:
;
;
(when (find-image '((:type xpm :file "copy_paste_line.xpm")))
(unless tool-bar-mode (tool-bar-mode 1))
; (setq tool-bar-map (make-sparse-keymap)) ; <- uncomment this line to have only this button present
(tool-bar-add-item
"copy_paste_line"
'copy-paste-whole-line
'copy-paste-whole-line
:help "copies and pastes the whole of the current line into a new line underneath"))
so, as you can see (actually, I'm not allowed to post images until I have 10 reputation points, so you won't be able to see), the code adds an extra button to the end of the existing tool-bar buttons. I believe this to be a reasonable way to achieve this, but I'm not an experienced elisp programmer, so if you think it's poorly written, please comment - I'd like to understand why... :)
If I only had 1 button, it would be ok like that, however, I have multiple buttons. I would, thus, like to add them to a second instance of a similar tool-bar (or, perhaps a vertical one placed where the scrollbars are).
Thanks again for any input.
Frame parameter tool-bar-lines is supposed to control this. You can, for instance, customize option default-frames-alist if you want to change the number of tool-bar rows to 2 or 3 everywhere. Or you can do this on a mode-by-mode or frame-by-frame basis. You can, for instance, use M-: (set-frame-parameter nil 'tool-bar-lines 3).
Depending on your platform (and toolkit), the behavior might be variable. See the Elisp manual, node Layout Parameters and node Tool Bars.
I believe you are out of luck. It seems to me that (at least on ubuntu and cygwin) only one row of buttons in the tool-bar is supported.
Here is what I have tried without luck on both systems:
(progn
(set-frame-parameter nil 'tool-bar-lines 3)
(loop for i from 1 upto 20 do
(setcdr tool-bar-map (cons (cadr tool-bar-map) (cdr tool-bar-map)))))
The following picture shows what I get:
The other buttons appear in a pull-down menu if you click on the little triangle at the right end of the toolbar:
You can restore the old tool-bar with the following commands:
(progn
(setq tool-bar-map (make-sparse-keymap))
(tool-bar-setup))
Finally, I have 3 rows of buttons. This is possible with emacs-w32:
So it is the gtk+ / nextstep problem.
I'm using Emacs 24.2 with a line-wrapping activated.
When I read log files of various simulations which contain messages like: "Error: ...some message...", I perform an incremental search: C-s error RET, C-s, C-s...
I find it very annoying that the highlighted result of the search (the word Error) is displayed at the bottom of the screen, and all the additional wrapped lines can't be seen:
I'd like to add modifications which ensure that the whole line of text will be displayed in the buffer, like this:
I found this question concerning re-centering of the search results. It seems that I could use the same defadvice statements for the search functions, but rather than re-centering the line I need just scroll the screen down by the number of wrapped parts.
How to do this?
You can use the solution on the question you reference, but changing recenter-top-bottom by this highly untested function:
(defun scroll-if-truncated()
(scroll-up
(/ (- (save-excursion
(end-of-line) (point))
(save-excursion
(beginning-of-line) (point)))
(window-body-width))))
After playing a bit with the code according to #juanleon's advice, I ended up with this:
;; Execute after each update in isearch-mode
(setq isearch-update-post-hook 'show-whole-line)
(defun show-whole-line ()
"Scroll such that the whole line (which contains the point) will be visible."
;; If it is the top part which is truncated
(if (not (pos-visible-in-window-p (line-beginning-position)))
(let
((amount
;; the required number of lines to scroll
(ceiling (/
(- (window-start)
(line-beginning-position))
(float (window-body-width))))))
;; don't scroll at all if the search result will be scrolled out
(if (< amount (/
(- (window-end)
(point) )
(float (window-body-width))))
(scroll-down amount)))
;; Else
(if (not (pos-visible-in-window-p (line-end-position)))
(let
((amount
(min
;; the required number of lines to scroll
(ceiling (/
(-
(line-end-position)
(window-end (selected-window) t))
(float (window-body-width))) )
;; however not to scroll out the first line
(/ (- (line-beginning-position) (window-start)) (window-body-width)))))
(scroll-up amount)))))
Few explanations:
Setting defadvice for isearch-forward is not enough - this function is not called again when you add chars to the search string. After a quick review of isearch.el.gz package I decided to advice to isearch-update function. This also eliminates the need of adding a separate advice for isearch-repeat-forward and etc. Later I noticed that there is a predefined hook in isearch-update, therefore no need for defadvice here.
show-whole-line function checks whether the beginning of the current line is visible. If not, it scrolls-down to show the beginning of the line, unless this scrolling will result in hiding the search match itself.
If the beginning of the line is visible, show-whole-line checks whether the end of the line is also visible. If not, it scrolls-up to show the end of the line, unless this scrolling will result in hiding the beginning of the line. I prefer to be able to see the beginning of the line.
This function and a hook work pretty well, but there is one annoying thing about it: the function is called when you initially press C-s (before you typed in any search string). This means that if the point is at a line which has its beginning or end out of the window, a simple invocation of C-s will result in scrolling in some manner.
While not critical at all, I'll be glad to hear suggestions how to remove the above side effect.
You should be able to get the behavior you want using variables scroll-conservatively and scroll-margin, in particular the latter.
I use GNU EMACS on multiple monitors from a Windoze PC via VNC.
(Currently 5 - 4 big, 1 the small monitor on my tablet PC. Two vertical 1200x1920, two horizontal 1920x1200, plus the small.)
The way I am currently doing this is to run a separate VNC on each monitor. I then open a single emacs, and use make-frame-other-display to open emacs' frames in the other VNC window.
To make things more complicated - I run the VNCs on an up-to-date Ubuntu system, but I run the emacs on a quite out of date machine where the rest of the build tools live. I.e. the VNC displays are not local to the same machine as emacs.
Rather than xhost+, I open an xterm in each of the VNCs, and ssh to the machine running emacs. This creates DISPLAYS of the form localhost:16.0. I then use make-frame-on-display using these localhost DISPLAYs.
This gets confusing.
It helps if I leave an "echo $DISPLAY" in the xterm windows. Or chamnge the xterm's title.
I'd like to similarly change the EMACS' frames' titles, to reflect what each frame things is its current DISPLAY. But doing
(defvar frame-title-specific-ag "emacs"
"title element from frame-title-format that is specific to a particular emacs instance; andy glew")
(setq frame-title-format
(list
"frame=%F "
(format "%s" frame-title-specific-ag)
" " 'system-name
" DISPLAY="
(getenv "DISPLAY")
" %b"
" " (format "pid:%d" (emacs-pid))
" user:"(user-login-name))
)
only gets the DISPLAY variable for the entire emacs.
Q: is there a way to find out the display associated with any particular frame?
To get the display name for the current frame, use
(frame-parameter nil 'display)
or replace nil with a specific frame to get the name of its display instead of the current one. For example, use this to show the display in the title:
(setq frame-title-format
'("DISPLAY=" (:eval (frame-parameter nil 'display))))
Note that it is important that this form is completely quoted, so the list that is used has an :eval which tells Emacs to run the code whenever it renders a frame title. Without that, you might be tempted to write something like:
(setq frame-title-format
(list "DISPLAY=" (frame-parameter nil 'display)))
but this doesn't work. The problem is that the function call happens immediately when this form is evaluated, and the result is a list holding a particular string, which is the name of whatever frame was in effect this evaluation happened, and the string will not change magically.
Eli Barzilay pointed us to
(frame-parameter nil 'display)
which is 90% of the way there.
The following puts the display associated with the currently selected frame in its frame title.
(setq frame-title-format
'(
"DISPLAY="
(:eval (frame-parameter nil 'display))
)
)
Glew: This puts the display of the currently selected frame, at the time the frame is created
(e.g. via make-frame-on-display) in the
title. Since this may be a different frame, in a completely different
display, it is not always what is wanted.
The unquoted, un-:eval'ed, form, puts the display of the currently selected frame,
at the time the setq is evaluated, in the title. This is even less of what is wanted.
Here is what I ended up with:
I set the default frame-title-format as above. But I do bnot really use it because I
hook the following:
(defun ag-set-frame-title (frame)
"set frame-title to glew preference, optional arg FRAME / default nil (currently selected frame)"
(interactive)
;; TBD: make-variable-frame-local is deprecated in more recent versions of emacs
;; than the antiquated version at my work. use modify-frame-parameters instead
(let (x)
(setq x
(concat
(or frame-title-specific-ag "emacs")
" " system-name
" DISPLAY=" (frame-parameter frame 'display)
" " (format "pid:%d" (emacs-pid))
" user:" (user-login-name)
;;" " (buffer-name)
)
)
(modify-frame-parameters frame (list (cons 'title x)))
)
)
;; TBD: this old emacs does not have modern hooks
(setq after-make-frame-functions '(ag-set-frame-title))
For good measure:
(defun ag-fix-frame-titles ()
"run ag-set-frame-title on frame-lits"
(interactive)
(mapc 'ag-set-frame-title (frame-list))
)
(ag-fix-frame-titles)
NOTE: per comment string it is possible that the fix described here is only needed on an old version of emacs, such as 21.4.1. #EliBarzilay says not needed on whatever version of emacs he is using.
Subtract points all you want, folks. Truth.