turning off italics via underscores doesn't work

[hmelman]

Test lines:

• foo _bar_zot
• foo_bar_zot

In markdown-mode both lines are in italics face between the _
In gfm-mode only the first line has italics face

In both cases markdown-italic-underscore is nil. I would think that with a nil value I'd need to use * to get italics for emphasis and that text would be ignored. I'd like to use plain markdown-mode (not gfm-mode) and still be able to write notes with variable names (with underscores) in them.

[syohex]

I'll check later

[jrblevin]

The documentation is unclear; sorry about that. The custom variable you mentioned only affects the insertion commands, not font lock.

[jrblevin]

Sorry for my brevity earlier. I was typing from my phone. In case it wasn't clear, what markdown-italic-underscore does is control which symbols (_ or *) are used when markdown-insert-italic (C-c C-s e) is called. I have updated the documentation on this point (see fc1204b).

I'd like to use plain markdown-mode (not gfm-mode) and still be able to write notes with variable names (with underscores) in them.

I am with you here. What I do is either use backticks, like foo_bar_zot, or escape the underscores (which is ugly, but works when I process the file with Markdown), like foo\_bar\_zot. The underlying problem is that most Markdown processors (aside from GFM, of course) don't permit underscores in words and so markdown-mode needs to match that as closely as possible.

If you haven't lately, you might also want to give gfm-mode another try. At this point there isn't much difference between them aside from the underscore behavior and support for strikethrough text in gfm-mode. It no longer turns on visual-line-mode automatically.

[hmelman]

Thanks, that makes sense about markdown-italic-underscore. I'm not sure about many other processors, I'll note that in Marked 2 neither of the two sample lines show any italics. I'll give gfm-mode another try.

[jrblevin]

Marked 2 uses MultiMarkdown by default and indeed, on my system it does not generate italics with your examples. On the other hand, Markdown.pl does...

[hmelman]

Just seems way more natural to me that _ imbedded in a word shouldn't trigger italics. How often does anyone want part of a word emphasized? If they did, they could always use html. And I'd suspect that a high percentage of Emacs users might be programmers who write about variable or function names. Just my $0.02.

I tried with Common Mark and they don't italicize either of the examples either.

[jrblevin]

Yes, it is an unfortunate incompatibility across implementations. I can see both sides, though. Like most programmers, I usually want the GFM-like underscore behavior, but I think writers, etc. would tend to prefer the Markdown.pl behavior. In any case, for now we have one mode for each behavior (markdown-mode and gfm-mode). In the future I could see a unified markdown-mode with settings for each variation and extension, as well as predefined groups of settings for specific processors (Pandoc, MultiMarkdown, CommonMark, etc.). For now, the target for markdown-mode is Markdown.pl plus some common, unobtrusive extensions that are unlikely to have adverse interactions.

[vyp]

In the future I could see a unified markdown-mode with settings for each variation and extension, as well as predefined groups of settings for specific processors (Pandoc, MultiMarkdown, CommonMark, etc.

I've been meaning to work on this myself. I'm glad to see I'm not the only one thinking about it!

[cosmicexplorer]

The issue here seems very similar to the reason #81 is still open (and #13, even); markdown-mode currently has a single unified syntax / command set for all markdown dialects at once, and they do end up conflicting very rarely (but they do, which is why these issues are still up). In #91 I added support for pandoc metadata sections with a defcustom, which allows the user to customize the default, while allowing for overriding with directory/file-local variables.

I think a better approach would just be to define derived modes for each dialect, similar to the way gfm-mode already exists, specialize each command to each dialect as appropriate, and also allow customizing markdown-command depending upon the dialect. I'd be interested in working on this over the next month or so if you think that sounds like a good approach. I can make an issue which will keep a running tally of the differences between dialects that we do and don't support yet. The only concern I can see is how keybindings might work for things like inline footnotes (#81) which are supported in one dialect but not another; I think the best thing to do is probably just have a case-by-case choice of similar but non-conflicting keybindings for operations like that.

[jrblevin]

I'd favor a dual approach of first adding individual feature flags to markdown-mode as new features are supported. This is what I had in mind when I implemented the basic LaTeX/itex math support (see markdown-enable-math), which I use in my toolchain¹ but also happens to be supported by some Markdown processors. Things that are not likely to conflict can be enabled by default. Things that are very likely to cause conflicts (like math support, with bare dollar signs as delimiters) can be toggled as needed (even automatically with file-local variables).

When enough features of some processor are supported we could add a derived mode to enable/disable groups of features at once. My worry is that adding a named derived mode (e.g., pandoc-mode) will be seen as an implicit guarantee or goal of fully supporting all features and extensions of that processor. (Besides, in this example there is already a very nice pandoc-mode by Joost Kremers. Maybe there are others as well.)

¹ Currently itex2MML + MultiMarkdown + GNU Source Highlight and some Perl scripts to glue them together.

[cosmicexplorer]

That makes a lot of sense. Cool. I'll take a look at this next.

[jrblevin]

I'm closing this since I think the initial issue was resolved and I'm not sure there's anything else that's actionable per se. I think feature sets, derived modes, or some similar framework will be the longer term solution. Any steps in that direction can be added as new PRs.