I was wondering if there's a way to allow a buffer to edit multiple files at once.
Recently, I got vim working with eclim. But now I was wondering if I could edit multiple files at once in one buffer. For example, say I have an interface and a class file where I need to update a method signature is there a way I can load both of them into the same buffer and edit them simultaneously. Narrow region for multiple file regions. It would also be awesome to remember my settings but that could be a future iteration.
I saw this solution but it seems inconvenient to create a separate file to handle this interaction.
You can open all files as split windows (so you see all of them together), and :windo, :bufdo, :argdo allow you to perform mass-operations (like a :substitute) on all of them at once. There's usually no need for such artificial concatenation schemes, and as the linked article shows, it has its downsides over keeping the files separate.
Related
I'd like to merge at least 2 PDF files into one while preserving all the form elements in the original PDFs. The form elements include text fields, radio buttons, check boxes, drop down menus and others. Please have a look at this sample PDF file with forms:
http://foersom.com/net/HowTo/data/OoPdfFormExample.pdf
Now try to merge it with any other arbitrary PDF file.
Can you do it?
EDIT: As for the implementation, I'd ideally prefer a command line solution on a linux plattform using open source tools such as 'ghostscript', or any other tool that you think is appropriate to solve this task.
Of course, everybody is welcome to supply any working solution to this problem, including a coded solution that involves writing a script which makes some API calls to a pdf-processing library. However, I'd suggest to take the path of least resistance first (CMD Solution).
Best Regards
EDIT #2: Well there are indeed several CMD tools that merge PDFs. However, these tools don't seem to, AFAIK, to preserve the forms in the original PDFs! These tools appear to simply just concatenate the printouts of all those PDFs into a single Printout, which is then presented as a single PDF.
Furthermore, If you printout a PDF file with forms into a file, you lose all the forms in it. This clearly not what I'm looking for.
I have found success using pdftk, which is an open-source software that runs on linux and can be called from your terminal.
To concatenate multiple pdfs into one (and preserve form-fillable elements), you can use the following command:
pdftk input1.pdf input2.pdf cat output output-file.pdf
Here's the use case: I'm writing a novel in Emacs (in org-mode). One part of my writing/editing flow is to read over some large portion of what I've written, collecting notes/possible edits/etc as I go. The sort of thing you'd do, on paper, by printing it all out and then writing notes in the margin.
I want to prevent myself from, as I do this kind of review, actually doing any writing -- but that's surprisingly hard. Like, if the buffer is editable, I start to type a brief note about a fix, then find myself starting to restructure / fix a sentence, and next thing I know, I've spent five minute polishing
a single paragraph. This not only slows me down, it breaks my ability to imagine a reader's response.
I've tried just putting the buffer in view-mode, and that sort of works -- but then it's laborious to try to identify the places I want to go back and review/fix up.
My ideal would be, to have something in view-mode, which I genuinely can't edit, but which, as I move the cursor through it, I could hit some key combination, and it would allow me to enter a brief note in the minibuffer, which would then get inserted into the main buffer, at point, possibly inside brackets or a comment or some such.
Does anyone know of something like that? Or have any pointers to something similar which I could try to adapt?
You can easily set bookmarks at any locations. And bookmarks can contain annotations.
If you use library Bookmark+:
The annotations are in Org Mode by default, and they can even be separate files (by default they are part of the bookmarks themselves, so stored in your bookmarks file).
You can bookmark not just a position but also a region of text, whether a sentence, paragraph, page, or an arbitrary span of text.
You can automatically name bookmarks as you set them, if you don't care about the names.
Updated after OP's comment saying "I prefer to shove the comments/questions/notes directly into the text of the novel. Because I end up adding/deleting/moving text a ton, and I want the notes to move with the text":
Bookmarks move with the surrounding text. That is, they generally get relocated automatically, since the surrounding text is recorded as part of the bookmark, and when jumping to a bookmark that text is looked for.
Occasionally the context has changed so much that a bookmark can't be relocated automatically, and you are prompted to relocate it manually.
But yes, bookmarks are stored in a bookmark file, separately from the files they target. There are both advantages and disadvantages to this feature. Advantages include (1) removing clutter from the text (annotations, including notes about possible text changes are metadata), (2) immediate access to particular text locations from anywhere, (3) a separate, persistent record/history of work or thoughts on it, (4) you can have multiple, separate sets of bookmarks/annotations for the same target text.
One thing you might find handy, when using bookmarks especially for annotating a particular file: C-x p C-l switches to a bookmark file that has only bookmarks for the current file or buffer, creating such a file on the fly if none
exists. (This is available only with Bookmark+.)
I need to automatically move select code chunks from one rmd into another rmd. The current system uses copy/paste but I would like this process to be automated. I tried making the code chunks into their own R scripts (knitr::purl) and then calling those in the second rmd but the code chunks are plots and the figure captions are lost using the knitr::purl. Is there an efficient way of copying each code chunk so it is still usable in a second rmd?
I don't think it's a good idea to do this, as you will be duplicating code in the process, which may lead to different versions with different up-to-date states. This makes the maintenance of the different Rmd files almost impossible in the long run.
What you probably want to do better is to have an external script with your code chunks, and calling them into the context of you Rmd file with read_chunk():
Using an external R script with your document
This doesn't exactly answer your question, but I think it solves your problem.
What's the best way to associate file extensions with my own customizations? For example, when I open a .py file the frame would be bigger and split into 2 windows, but when a .tex file is opened the frame would be smaller with just one window. Should I split my .emacs and write all configurations associated with python in a .el file (key bindings, python shell = ipython, etc ...) and for latex in another .el file (load auctex, pdf mode = default, etc ...)? How would I "call" the files and make them work appropriately (if that'a possible and good solution)?
(First, +1 to #phils's comment. You will get better help if you are more specific about what you need/want.)
Depending on just what you need/want, see also variable (not option) file-name-handler-alist. You might not need it, but you might.
You can make use of it if you intend all or particular operations on the files to involve additional actions (such as those you describe). For any operations where you do not need special treatment, just provide the default behavior. For the others, provide the default behavior plus the extra behavior (in whichever order is appropriate).
See (elisp) Magic File Names for more information.
Is there a package that allows me to have multiple Occur result buffer for the same buffer (like grep-a-lot: http://www.emacswiki.org/emacs/grep-a-lot.el).
I run into this issue when analyzing log files for multiple keywords (say to see what different but related threads were doing).
You don't need an additional package. C-ur will rename the current occur buffer to an unique name. You can add occur-rename-buffer to occur-hook to make it automatic (see the documentation of occur-rename-buffer which mentions this, too).