I am trying to export the file template.Rmd, available here, to pdf, using polymode in Emacs. I choose the Rmarkdown-ESS exporter. Upon pressing M-n e and selecting pdf as output format, the weaving appears to go all right, yet the Pandoc call throws up the following error message:
! Package pdftex.def Error: File "/path/template{[}exported{]}_files/figure-latex/unnamed-chunk-2-1.pdf" not found. (with simple instead of double inverted commas.)
Indeed, I can find no such file anywhere near the working directory.
One of the arguments of the command rmarkdown::render(), executed by M-n e is output_file = "/path/template[exported].pdf" (with simple inverted commas again). When I modify that to read output_file = "/path/template.pdf" everything works fine.
So the problem appears to be the default naming of the output file by polymode. How can this be changed? Thanks!
Michael
Looking at this .el file, this can be changed by adding:
(defcustom polymode-exporter-output-file-format "%s"
"Format of the exported files.
%s is substituted with the current file name sans extension."
:group 'polymode-export
:type 'string)
to the init file.
By default, it seems that %s is replaced by %s[exported] where %s is the name of the file to be exported.
Related
I am working on an application that supports the ability to launch an external editor on XML validation errors, where the validation error will include the specific line and character offset in the line the error occurs. For example, "74:62" represents the 74th line and 62nd character of that line, which is also said as, "line 74, column 62".
The problem I am having is that editors treat "column" differently. For Vim, column 62 is a character position. While in Oxygen XML Editor, Notepad++, and Emacs, column is a rendered position.
Why does this distinction matter? If the target line has tab characters, Notepad++ and Emacs "column" no longer represents character offset, and for those editors the cursor gets located differently: Notepad++ treats tab as 4 columns and Emacs as 8 (by default).
Here are the commands I use for each editor, where 'L' is the line number, 'C' is the column number, and 'FILE' is the file to open:
gvim "+call cursor(L,C)" FILE
oxygen FILE#line=L;column=C
notepad++ -nL -cC -lxml FILE
emacs +L:C FILE (See #Rorschach's answer below for method that does work)
For Notepad++ and Emacs, are there command-line invocations that will place the cursor at a character position relative to the line?
Edit
Oxygen XML Editor behaves as expected, where column parameter is interepreted as a character offset from line. See #Rorschach's answer below regarding Emacs, I do not have a solution for Notepad++.
As a workaround for different character display widths in emacs you could add a hook to run after the file loads.
# assuming there are some variables (eg. shell)
# holding the line/column as in the normal command
L=4
C=2
emacs --eval "(add-hook 'emacs-startup-hook (lambda () (goto-line $L) (forward-char $C)))" input_file.xml
I work for Oxygen XML Editor and as far as I know Oxygen places the caret at that specific character offset, so we do not use the visual tab width representation for anything in this context.
One thing you should be aware is that in Oxygen by default if you press the "Tab" key you actually insert 4 spaces, if you want to insert the "Tab" character instead, in the Preferences->"Editor / Format" page there is a setting named "Indent with tabs" which needs to be checked.
For whatever reason, VSCode is copying non-breaking spaces, when I copy/paste code with syntax highlighting. This is no problem as long as I work inside VSCode, but it's a nightmare when copy/pasting stuff in and out of VSCode.
I'm using MSWord with the "hidden characters" feature activated as an easy means to understand what is happening. I can reproduce it like this:
Create a new file (no extension, not saved) in VSCode, type some text, select
all and copy/paste in MSWord -> spaces are normal U+0020 spaces,
NO syntax highlighting was copied.
Save the file as a ".txt" file, select all and copy/paste in MSWord -> spaces are normal U+0020 spaces, NO syntax highlighting was copied.
Save as a python file ".py" (or Markdown, or HTML...), select all and copy/paste in MSWord -> spaces are non-breaking-spaces U+00A0 spaces, syntax highlighting was copied.
Save as a text file ".txt", select all and copy/paste in MSWord -> spaces are non-breaking-spaces U+00A0 spaces, syntax highlighting was copied.
Since a picture is better than 1000 words, here's the output from MSWord:
Any idea?
It seems that VSCode copy styled or unstyled content into the clipboard depending on the context. That may cause trouble when pasting into some kind of rich text editor.
In the settings JSON file add editor.copyWithSyntaxHighlighting set to false in order to disable this behaviour for good.
Note that there is still a separate command Copy With Syntax Highlighting in the pallete which you can bind to some other keys in case you need it. This one does not affected by the option above.
Refer to this PR https://github.com/microsoft/vscode/pull/54155
I just reinstalled Eclipse Juno.
The problem i have is when i create a new file and start writing, CRLFs are inserted on Return.
Second case: When i fully mark the text of a file (without CRLFs) ans COPY them into another file (i use CRTL+A and DEL to get rid of the file contents and then PASTE i get the file content with CRLFs!)
The resulting file looks like:
Test blah CRLF
Line two ... CRLF
CRLF
How can i get rid of them?
Solution to this is to configure Eclipse accordingly.
Windows->Preferences->General->Workspace
In the right lower corner there is a setting called "New text fiel line delimiter" which i had to switch from Windows to Unix.
The already CRLF prensent i had to remove using Eclispe->File->Convert line delimiters to ->Unix .
I would like to color source header and assembly files in the dired mode and differently.
Basically, when viewing the folder contents I want to color the files differently.
I also would like a way to color files that have a specific word in them differently.
With Dired+, your file names and files extensions will use different colours.
http://wikemacs.org/index.php/Dired+
http://www.emacswiki.org/emacs/DiredPlus
And to colour files that have a specific word in their names, I don't know, but you could use Dired with wildcards:
C-x d path/to/all/containing/*foo*
will open a Dired buffer with all files containing foo in their names.
Hope it helps !
How about using diredful?
Follow the link to find a description of how to setup diredful and add colourisation for a file type of your choosing.
How to do it (You should read the wiki article... it even has screenshots!):
Install diredful (by putting diredful.el somewhere in your load-path)
add (require 'diredful) to your init file.
Call diredful-add
Enter name you want to give this matching pattern (e.g. c-Files)
In the field pattern add the file name pattern to be matched, e.g. c h
Under face to use select the face features you want to use
Someplace I saw a snippet of code which told vi to use soft tabs and set the size of a tab. If you put this snippet at the bottom of a source file, then vi would magically use those settings for that file.
What is the syntax and rules for including that snippet in a source file? Can emacs be made to use these settings as well?
You can put this in a comment in your source file:
ex: set softtabstop=4 shiftwidth=4 tabstop=4 expandtab:
The comment syntax depends on the type of the source file.
For C/C++/Java, this would be:
// ex: set softtabstop=4 shiftwidth=4 tabstop=4 expandtab:
For JSP, this would be:
<%-- ex: set softtabstop=4 shiftwidth=4 tabstop=4 expandtab: --%>
This works if it is placed at the beginning of the source file, but I'm not sure that this'll work if placed at the end of it too.
This will not work for emacs. There might be a different way of achieving the same for emacs.
Check out :h modeline.
Example:
/* vim: ai set sw=4 ts=4 */
See :h modelines for how many lines into a file Vim will check for modeline info. The default is to check the first 5 lines.
As far as I know, vi didn't have this capability. You're likely thinking of the modeline feature of Vim. There is similar functionality in emacs, where you can put local variables in the file.
Note that, at least in Vim, modelines have had a history of vulnerabilities. This is primarily due to problematic options being specifically blacklisted instead of only allowing a certain subset of variables to be set in modelines. I'd suggest using a plugin like securemodelines.
Put this in your C++ source file:
// vim: set ft=cpp
The modeline feature looks for the string "vim:" and then executes what follows. Note: this could open up potential exploits if you don't trust the files you are opening, so think twice before enabling this feature.
Okay, first of all, in real vi you do this in the .exrc file.
Second, use
set autoindent tabstop=8 shiftwidth=4
because otherwise vi will insert tabs it thinks are only 4 characters wide. The resulting text file will not look like it makes sense in any other editor.