I am giving a programming talk. Rather than use slides, I am presenting a sequence of incrementally longer programs, stored in filenames 0001.py, 0002.py, etc.
The code in each program introduces just one or a few lines of code as a modification to the preceding one.
I intend to present solely using emacs. I am familiar with ediff, but it would be a bit of a pain to use it live during a talk (as there are about 50 small programs, with one minute to introduce each increment).
Does there exist an emacs package that would allow me to split the window and to highlight what is actually different between (n).py and (n+1).py. (I'm using .py for concreteness, but hopefully the solution would work for any text file.)
I am asking here rather than on https://emacs.stackexchange.com because I will be happy with a solution using emacs, git, or any combination that I can string together to give a live demo, especially with the ability to modify the code live while answering questions.
Update
As phils suggests, M-x compare-windows almost solves this issue, but:
It would be nice if it works correctly regardless of the current position of the cursor in the two buffers.
It would be nice if all changes appear in one view, rather than iterating over the diffs. The point is to say "see, in the program on the right I've added just this line and that line, and look at all that that program can do compared to the previous one."
Update 2
In other words, how do I generate what is done manually in the HTML below to show the differences side-by-side?
.myflex {
display: flex;
flex-direction: row;
}
.before,
.after {
border: 1px solid black;
padding: 20px;
margin: 20px;
border-radius: 2px;
}
.pink {
background-color: pink;
}
.green {
background-color: PaleGreen;
}
<div class="myflex">
<div class="before">
<pre>
<span class='pink'>And so without particularly analyzing all the contiguous sections of a</span>
<span class='pink'>cone and of the ranks of an army, or the ranks and positions in any</span>
while the less their direct participation in the action itself, the more
they command and the fewer of them there are; rising in this way from
the lowest ranks to the man at the top, who takes the least direct share
in the action and directs his activity chiefly to commanding.
</pre>
</div>
<div class="after">
<pre>
<span class='green'>We see a law by which men, to take associated action, combine</span>
<span class='green'>in such relations that the more directly they participate in performing</span>
<span class='green'>the action the less they can command and the more numerous they are,</span>
while the less their direct participation in the action itself, the more
they command and the fewer of them there are; rising in this way from
the lowest ranks to the man at the top, who takes the least direct share
in the action and directs his activity chiefly to commanding.
</pre>
</div>
</div>
Sequel
(I'm only adding this sequel here because phils generously volunteered to answer more than I was initially asking for.)
Consider the program (in some imaginary language, stored in a .txt file):
hello
and consider that we insert a keyword that requires indentation:
repeat:
hello
Now when we show the two programs in split-window, it would be nice if the hi is not highlighted, despite that the two lines differ by indentation; only the repeat: is.
The idea is that we'd be adding some loop operator and do not wish the gaze of the listener to go to either the indentation or to the entire line, only to the operator.
In other words, when displaying the difference, we would ideally highlight the repeat line, but neither hello nor the indentation preceding it.
I suspect that some existing diff functionality can do this and so there'll be a better answer, but I've hacked the following together using compare-windows.
(defun my-compare-windows-complete (&optional ignore-whitespace)
"Highlight all differences between two windows.
With a prefix argument, do not highlight whitespace-only differences.
\(This does not prevent the highlighting of whitespace that is part of
a difference which includes non-whitespace characters.)
To remove the highlighting, use \\[compare-windows-dehighlight]."
(interactive "P")
(require 'cl-lib)
(require 'compare-w)
(compare-windows-dehighlight)
(let ((w1 (get-buffer-window))
(w2 (funcall compare-windows-get-window-function)))
(cl-letf ((w1p (window-point w1))
(w2p (window-point w2))
(compare-windows-highlight 'persistent)
((symbol-function 'compare-windows-dehighlight) #'ignore)
((symbol-function 'ding) (lambda () (error "done"))))
(with-selected-window w1
(goto-char (point-min)))
(with-selected-window w2
(goto-char (point-min)))
(ignore-errors
(while (compare-windows ignore-whitespace)))
;; Highlight any non-matching remainder in both buffers.
(let ((b1 (window-buffer w1))
(b2 (window-buffer w2))
(p1 (window-point w1))
(p2 (window-point w2))
(max1 (with-selected-window w1 (point-max)))
(max2 (with-selected-window w2 (point-max))))
(compare-windows-highlight p1 max1 b1 w1 p2 max2 b2 w2))
(set-window-point w1 w1p)
(set-window-point w2 w2p))))
You can use M-x compare-windows-dehighlight afterwards to remove the highlighting.
The faces used for highlighting are:
compare-windows-removed (inheriting from diff-removed)
compare-windows-added (inheriting from diff-added)
Related
What I mean is, if you have a tree, and you go to 1.2.1, I want to expand and collapse this without expanding the children (1.2.1.1 & 1.2.1.2).
In other words, normally I would have to press TAB three times, which shows the expanding of all subchildren. I just want a different key press to close the recently opened subtree.
Thanks! And hopefully I made myself clear!
EG
Possible it is, everything is possible in emacs if you go into defining lisp functions. However that eludes my knowledge.
What I can see from the available functionality is that you can't do that in a straightforward manner. See some relevant highlights from the help for the TAB key:
<tab> runs the command org-cycle.
(...)
- When point is at the beginning of a headline, rotate the subtree started
by this line through 3 different states (local cycling)
1. FOLDED: Only the main headline is shown.
2. CHILDREN: The main headline and the direct children are shown.
From this state, you can move to one of the children
and zoom in further.
3. SUBTREE: Show the entire subtree, including body text.
If there is no subtree, switch directly from CHILDREN to FOLDED.
(...)
- When there is a numeric prefix, go up to a heading with level ARG, do
a ‘show-subtree’ and return to the previous cursor position. If ARG
is negative, go up that many levels.
Full help see `C-h k TAB'.
You can also set VISIBILITY properties per buffer:
#+STARTUP: fold (or ‘overview’, this is equivalent)
#+STARTUP: nofold (or ‘showall’, this is equivalent)
#+STARTUP: content
#+STARTUP: showeverything
see: C-h v org-startup-folded.
Bottom line is: maybe the easiest is to just press TAB 3 times, unless you're skilled in lisp and are willing to make the changes,,,
This is what I came up with. It can be used repeatedly to fold up the chain.
(defun my/org-fold-this-heading ()
(interactive)
(org-back-to-heading)
(when (or
;; already folded
(outline-invisible-p (point-at-eol))
;; empty subtree
(let
((eoh (save-excursion (outline-end-of-heading) (point)))
(eos (save-excursion (org-end-of-subtree t t)
(when (bolp) (backward-char)) (point))))
(= eos eoh)))
;; move up a level before folding
(outline-up-heading 1))
(outline-hide-subtree))
(define-key org-mode-map (kbd "M-v") 'my/org-fold-this-heading)
I use emacs for my creative writing. To better analyze the structure of my sentences I would like to see my paragraphs displayed as consisting of one sentence per line. So I need a function that can take a normal auto-filled paragraph and do the following: 1) stretches all sentences into one line, and 2) put only one sentence per line.
Imagine I had written the following paragraph (lyrics from Suzanne Vega)
My name is Luka. I live on the second floor. I live upstairs from you. Yes I think you've seen me before. If you hear something late at night. Some kind of trouble. Some kind of fight.
With the function I want the paragraph would appear like this:
My name is Luka.
I live on the second floor.
I live upstairs from you.
Yes I think you've seen me before.
If you hear something late at night.
Some kind of trouble.
Some kind of fight.
Since I would like to do some of the writing when the sentences are displayed like this, the function should in addition to stretching out the sentences also turn off the autofill mode.
Ideally I would like a function that can toggle the display between auto-fill mode with all sentences wrapped, and this new mode with auto-fill turned off and all sentences stretched out.
Thanks in advance to all sort of suggestions or help to make such a function!
#Drew: Here is a text I am not able to split up with your code:
There are two ways to enable it: the first is with M-x visual-line-mode (for those with real menus, apparently Options->Line Wrapping in this Buffer->Word Wrap), which will give you a minor mode “wrap” in the mode line. As explained in C-h f visual-line-mode, one of the effects of this command is to subtly change the effect of commands that deal with “lines”: C-a, C-e no longer go to the end of the line (as in \n), but go to the end of the line (as in display line). M-a, M-e still work as they should. In addition, vertical split windows are guaranteed to not be truncated, and resize properly on changing width. Works wonderfully, especially if you have free form text that you’re keeping in version control (like a thesis in Latex) where hard-wrapping just doesn’t work out very well. It also makes vertical splitting much more useful, especially with huge windows. In my experience, it slows down redraw a little bit, but it’s worth it.
I guess something like this is what you're asking for.
(defun split-para-at-sentence-ends ()
"Split current paragraph into lines with one sentence each.
Then turn off `auto-fill-mode'."
(interactive)
(let ((mode major-mode))
(unwind-protect
(progn (text-mode)
(save-excursion
(let ((emacs-lisp-docstring-fill-column t)
(fill-column (point-max)))
(fill-paragraph))
(let ((bop (copy-marker (progn (backward-paragraph) (point))))
(eop (copy-marker (progn (forward-paragraph) (point)))))
(goto-char bop)
(while (< (point) eop)
(forward-sentence)
(forward-whitespace 1)
(unless (>= (point) eop)
(delete-horizontal-space)
(insert "\n"))))))
(funcall mode)))
(auto-fill-mode -1))
(define-minor-mode split-para-mode
"Toggle between a filled paragraph and one split into sentences."
nil nil nil
(if (not split-para-mode)
(split-para-at-sentence-ends)
(auto-fill-mode 1)
(fill-paragraph)))
(global-set-key "\C-o" 'split-para-mode) ; Or some other key.
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.
Modes: I'm using linum for line numbers, the package linum-relative for relative line numbers. If it matters, I am also using visual-line-mode. These are flexible.
Currently, a single line (i.e. text without a newline) is numbered as only one line, regardless of how many times it is wrapped. I am wondering if there is a way to change the numbering to respect these wraps. So, for example,
263 This is all in
a single line
without newlines
might become:
263 This is all in
264 a single line
265 without newlines
and, in relative mode:
0 This is all in
a single line
without newlines
might become:
-1 This is all in
0 a single line
1 without newlines
I really only want the change in relative mode, but would not mind if it spills over into absolute mode.
A toggled change that works on both would be most useful - that way, the user can specifically select when, or with which modes, to turn it off or on.
If the goal is navigation, I suggest a similar solution via the popular ace-jump-mode.
If the goal is just persistent line numbering, you might consider longlines-mode instead of visual-line-mode (but I would avoid this, personally).
ace-jump # GitHub
https://github.com/winterTTr/ace-jump-mode
Demo:
http://dl.dropboxusercontent.com/u/3254819/AceJumpModeDemo/AceJumpDemo.htm
With it, you can jump to any line with as little as two keypresses.
In addition to lines, you can jump to the start of any word; there's also individual character-level jump precision. If desired, it can be configured to restrict jumps to the current window/buffer, or across all windows in the current frame, and even multi-frames.
It doesn't, however, recognize wrapped lines as jump-able locations. Again, you might consider longlines-mode as a fix for this if it is really important to you, but as I understand, it's considered hack'ish and deprecated in favor of visual-line-mode. Though, with longlines-mode, the lines are renumbered exactly as you want in your first example.
I'm assuming the goal is navigation, and as such, I think you'll find with just a little practice that word-based jumping or even jumping via incremental search to be a superior solution.
Update
Here's a simple solution to trick ace-jump to scan within N lines using emacs narrowing features; perhaps others can improve upon it. You could also do something similar for word and line modes.
(defun brian-ace-jump-to-char-within-N-lines (&optional n)
(interactive "p")
(let* ((N (or n 0))
(query-char (read-char "Query Char:"))
(start (save-excursion
(forward-line (- N))
(point)))
(stop (save-excursion
(forward-line (1+ N))
(point))))
(unwind-protect
(condition-case err
(progn
(narrow-to-region start stop)
(ace-jump-char-mode query-char))
(error
(message (error-message-string err))))
(widen))))
I'm using auto-complete-mode which I think is totally fantastic. I'm also a big fan of linum-mode but I've got a very irritating issue when the two are used together, especially when I'm working in a new buffer (or a buffer with very few lines).
Basically the buffer is 'x' lines long but when auto-complete kicks in it "adds" lines to the buffer, so linum-mode keeps switching, for example, between displaying line numbers on one column or two columns, depending on whether auto-complete is suggesting a completion or not.
So you type a sentence and you see your buffer's content frantically shifting from left to right at every keypress. It is really annoying.
I take it the solution involves configuring the linum-format variable but I don't know how.
Ideally it would be great if my linum-format was:
dynamic
right-aligned
considering there are 'y' more lines to the buffer than what the buffer actually has
My rationale being that auto-complete shall not suggest more than 'y' suggestion and that, hence, the two shall start playing nicely together.
For example, if 'y' is set to 20 and my buffer has 75 lines, then linum should use two columns: because no matter where I am auto-complete shall not make the buffer 'bigger' than 99 lines.
On the contrary, if 'y' is still set to 20 and my buffer has 95 lines, then linum should use three columns because otherwise if I'm near the end of the buffer and auto-complete kicks in my buffer shall start "wobbling" left and right when I type.
I'd rather not hardcode "3 columns wide" for linum.
I guess using "dynamic but always at least two columns" would somehow fix most annoyances but still something as I described would be great.
P.S: I realize that my 'fix' would imply that linum would always display on at least two columns, and I'm fine with that... As long as it stays right-aligned and use 2, 3 or 4 columns depending on the need.
Simply put the following line in .emacs which resolves this issue. It is in auto-complete.el.
(ac-linum-workaround)
I've written a couple of previous answers on modifying the linum-mode output, which you could probably adapt to your purposes.
Relative Line Numbers In Emacs
Colorize current line number
Edit: Here's the most basic version of that code (also on EmacsWiki, albeit somewhat buried), which doesn't modify the default output at all, but uses the techniques from those other answers to be more efficient than the default code. That's probably a more useful starting point for you.
(defvar my-linum-format-string "%4d")
(add-hook 'linum-before-numbering-hook 'my-linum-get-format-string)
(defun my-linum-get-format-string ()
(let* ((width (length (number-to-string
(count-lines (point-min) (point-max)))))
(format (concat "%" (number-to-string width) "d")))
(setq my-linum-format-string format)))
(setq linum-format 'my-linum-format)
(defun my-linum-format (line-number)
(propertize (format my-linum-format-string line-number) 'face 'linum))
Just have the same problem, after seeing 'patching the source' I believe it could be done with advice. Here is what I come up with
(defadvice linum-update
(around tung/suppress-linum-update-when-popup activate)
(unless (ac-menu-live-p)
ad-do-it))
I would like to use popup-live-p as mentioned but unfortunately it requires the variable for the popup, which we couldn't know in advance.
Update:
I ended up patching the source for linum.el. I added an extra hook that runs before updates.
Here's the patched file: linum.el (github)
Here's the code I have in my init.el:
;; Load custom linum.
(load-file "~/.emacs.d/linum.el")
;; Suppress line number updates while auto-complete window
;; is displayed.
(add-hook 'linum-before-update-hook
'(lambda ()
(when auto-complete-mode
(if (ac-menu-live-p)
(setq linum-suppress-updates t)
(setq linum-suppress-updates nil)))))
Hope it helps!