I'm troubleshooting a podcast feed. I'm not sure the best tool for a job like this, but I started by opening the feed in emacs sgml-mode and running sgml-pretty-print hoping to get a better look.
The pretty printing and syntax highlighting do not work properly. They are thrown off by markup similar to this:
<item>
<description>
<![CDATA[ Some text... "quoted text” ... and so on.]]>
</description>
</item>
Notice the opening double quote followed by the closing back quotes. I believe that's valid SGML. It's inside CDATA. However at that point emacs pretty printing and syntax highlighting get screwed up. It can't tell when the quote ends or when the CDATA ends.
Is there some way I can get emacs to handle this document properly?
For the curious, you can see the feed I'm working with is http://audio.commonwealthclub.org/audio/podcast/climateone.xml
Related
I'm trying to write some markdown text in Visual Studio Code and whenever I write this:
*some text*
It's being replaced by this as soon as I save the file:
_some text_
I narrowed it down to be caused by the Prettier extension. I tried looking for a setting that might control this but didn't find any - well none that was obvious to relate to the issue.
I'd really like to keep Prettier enabled for markdown files as it also keeps tables nice and tidy.
Is there a way around this one issue?
UPDATE:
I am aware that both asterisk and underscore works for italic emphasis when the file is shown through a markdown viewer, but when reading the file as pure text, the asterisk feels more natural to me for emphasis and I'd much prefer keep using it if possible.
I also feel the same way, but from what I can tell Prettier simply does not have that option (https://prettier.io/docs/en/options.html)
Prettier is not a kitchen-sink code formatter that attempts to print your code in any way you wish. It is opinionated.
https://prettier.io/docs/en/option-philosophy.html
Given that philosophy, I doubt this will ever change. As for me, I think I'm going to try to just get over it.
I think the only way to avoid this would be to use something different, for example:
https://marketplace.visualstudio.com/items?itemName=DavidAnson.vscode-markdownlint
Does anybody know how to maintain symbols in markdown internal links?
For example:
[A](#A) works fine
[A and B](#a-and-b) works fine
...whereas:
[A/B](#a-b) does not work
[A-B](#a-b) does not work
Thanks for your help!
I remember running into this problem too.
[A/B](#ab) should work, instead of using [A/B](#a-b).
A / character is considered a non-character in this case, but when it is not part of a word (ex. Movies / Shows / Videos) then it needs to be treated like an empty word:
[Movies / Shows / Videos](#movies--shows--videos)
I'm not sure how [A-B](#a-b) isn't working for you, because it should work?
I recommend checking here, every now and then, for additional information being added to the conversation around Github Markdown Heading Anchors: https://gist.github.com/asabaylus/3071099
This is also known as github-slugging or GitHub-style slugging.
After copying and pasting your code into my markdown editor, Mou, I see no issues with either statement. In fact, I copied the link as well, and it keeps the symbols you want.
Perhaps this is an issue with your version of markdown or your editor. If you are using a different flavor of markdown, like github, I'd be sure to specify that with tags as that may be your issue. Basic markdown should handle escaping characters though unless it's a bracket. If you want some helpful information, please visit this stack overflow thread: Escaping Brackets
I'd like to use emacs in some kind of batch mode to just render a file with syntax highlighting and exit. Specifically, I want to dump the fontified buffer with ANSI escape codes so that it shows up reasonably syntax-highlighted on my terminal. Is there any way to do this?
The ansi-lpr.el library seems to be kind of along the lines of what I want, but the output isn't colorified. I can't figure out how to get over that final hurdle — there are a lot of modules to digest ANSI escape codes into Emacs text properties (e.g. ansi-color.el) but I haven't found anything that does the reverse. If anyone can point me to something that does, I think I can piece together the rest.
Alternatively, I've seen some hacky approaches like this answer (using script and capturing the output) but in my experiments that approach has seemed unlikely to be fruitful — you get tons of undesirable control sequences mixed in with the highlighted text.
The overarching motivation here is to use emacs in a $LESSOPEN pipe to get syntax highlighting when I page files. In case you're going to say it, I've tried and "just page files in Emacs" is not acceptable for me.
I'm glad to announce a new package, e2ansi, that (hopefully) does what you asked for.
The package provides a command-line tool e2ansi-cat that starts Emacs in batch mode, opens files, syntax highlight them (using font-lock), and creates ANSI-colored versions of the syntax highlighted files.
You can integrate this into less by setting the following variables to, for example:
export "LESSOPEN=|emacs --batch -Q -l ~/.emacs -l bin/e2ansi-cat %s"
export "LESS=-R"
export MORE=$LESS
The end result looks like the following:
You can vary the colors and attributes like bold, underline, and
italics by using a suitable Emacs theme.
The e2ansi package is located at https://github.com/Lindydancer/e2ansi
Personal note
I would like to thank you for posting this question, it directly inspired me to write e2ansi.
I'm using org mode to make a list that I would like exported to PDF. some items in the list have the combination (*) and this seems to throw org mode off.
This MWE
#+TITLE: Bug?
#+OPTIONS: *:nil toc:nil author:nil
- hello (*) I would like to have two items
- may (*) I please?
results in
even though the #+OPTIONS: *:nil part was obviously read and understood (the part between the stars is not bold as it would be had that line been missing.
Is this is bug? Am I doing something wrong? Is there a workaround?
The *:nil option is not the problem here.
The problem comes from the fact that the * in (*) actually do emphasize the text (it is in bold font in the buffer). Given that, the exporter does its best, which is not very good.
The bug here is to allow multiline fontification over distinct list items -- we'll try to fix it, but that's a rather complex issue.
On top of the workaround above, have a look at `org-emphasis-regexp-components', thru which you can prevent parentheses as post/pre-characters in a fontified string.
I found a work-around for this behavior (bug?): add an empty line between the two offending lines:
#+TITLE: Workaround!
#+OPTIONS: toc:nil author:nil
- hello (*) I would like to have two items
- may (*) I please?
gives:
Thus allowing the string (*) to exist in an item (or rather in two consecutive items)
I'm not certain if this is a bug or not. I was able to reproduce it, however if I escaped the * the export occurred as expected.
#+TITLE: Bug?
#+OPTIONS: toc:nil author:nil
- hello (\*) I would like to have two items
- may (\*) I please?
Latex created:
\begin{itemize}
\item hello (\*) I would like to have two items
\item may (\*) I please?
\end{itemize}
I will however post the question to the mailing to confirm whether this is the expected behaviour or not in this situation. The thread for this question is HERE.
EDIT I edited to correct the LaTeX that was exported (needed to add this as 1 char is not enough, feel free to remove this line.)
I'm writing a text with Latex in English but written my comments in Finnish. When I'm running the spell checking with ispell, I got to run through all the comments. Is there a handy way to skip the comments with the ispell? If that could be done with emacs, that would be double handy =)
One way would be to run the ispell within console and process the input with sed, for example, but I'd like to have my changes straight on the file...
(setq ispell-check-comments nil)
You'd have to dig in the code a bit, but when you spell-check a file, it's running the detex tool to strip out the TeX code. You should be able to modify the pipeline to have a sed or perl script strip the comment lines.
I kind of vaguely think AuC-TeX makes this configurable, but 30 seconds looking didn't reveal it.
Adding a modern answer to this old question, because I also had the problem:
Just use aspell, which does this out of the box.