Markdown-mode navigation and cycle ignore R code chunk about markdown-mode HOT 21 CLOSED

Also see #33, which I think is similar.

from markdown-mode.

Thank you. Yes, I thought this should have been fixed in 3192c9b, which was in response to #33. Can you confirm that you are using either the latest stable (2.1) or development (Git) version of markdown-mode?

What are you using for mode-switching? polymode or mmm-mode, maybe? Does cycling work As expected with that disabled?

from markdown-mode.

I suppose markdown-cycle issue is not fixed yet. How about this patch(https://gist.github.com/syohex/4060513d8bd7601c6afc), @walmes ?

Original

Applied above patch

from markdown-mode.

Yes. I agree with you @syohex. I experienced the same thing in the cycling and navigation. See the gifs below (sorry for the Portuguese, but this one of the tutorials I'm work on).

In the above figure some chunks are folded but others aren't. I don't have level one section in this document, so all single hash (italic gray color font) are R comments. The next figure show navigation. Some chunks are skipped but others aren't. I think that navigation and cycling are fixed in the same piece of code.

from markdown-mode.

@walmes I cannot reproduce navigation issue. Could you tell us how to reproduce navigation issue( and show us minimum reproduce markdown sample) ?

from markdown-mode.

I merged #76--thanks @syohex for looking into this so quickly!

@walmes Please give it a try and let us know if this also fixes the navigation issue.

from markdown-mode.

@jrblevin, I just update markdown package from melpa. Now, markdown has suffix 20160113.816. I disable all others minor modes. Now, only markdown-mode are running. Below is the gif and a gist with the contents of file used.

https://gist.github.com/walmes/1a9a5918702c465a31fd

I noticed that navigation and cycling only show R comments when # decrease 1 or 0. In other words, navigation doesn't jump from a heading level three (###) to a comment level one (#), but to the same level or one level less, it jumps. To prove my point, I did a chunk with the content duplicated but comments with # and ##. Note how happens.

from markdown-mode.

I suppose markdown-backward-same-level issue is fixed by following patch.

diff --git a/markdown-mode.el b/markdown-mode.el
index 2b811cf..e65b448 100644
--- a/markdown-mode.el
+++ b/markdown-mode.el
@@ -4852,11 +4852,24 @@ Stop at the first and last headings of a superior heading."
   (interactive "p")
   (markdown-move-heading-common 'outline-forward-same-level arg))

+(defun markdown-backward-same-level-1 (arg)
+  (markdown-back-to-heading)
+  (while (> arg 0)
+    (let ((point-to-move-to (save-excursion
+                 (outline-get-last-sibling))))
+      (if point-to-move-to
+     (progn
+       (goto-char point-to-move-to)
+       (setq arg (1- arg)))
+   (progn
+     (setq arg 0)
+     (error "No previous same-level heading"))))))
+
 (defun markdown-backward-same-level (arg)
   "Move backward to the ARG'th heading at same level as this one.
 Stop at the first and last headings of a superior heading."
   (interactive "p")
-  (markdown-move-heading-common 'outline-backward-same-level arg))
+  (markdown-move-heading-common 'markdown-backward-same-level-1 arg))

 (defun markdown-up-heading (arg)
   "Move to the visible heading line of which the present line is a subheading.

from markdown-mode.

Many thanks, @syohex. I will check it out soon.

from markdown-mode.

I am having trouble constructing a test case that fails without the above patch (the one adding markdown-backward-same-level-1).

In the GIF @walmes posted, it appears that there are some font lock issues where the GFM code blocks are not being identified properly. Since the heading movement commands use the text properties set by the fenced code block matchers, I think this is the root of the issue.

I now wonder whether this could be due to fe88278, which combined the regular expressions for the opening and closing of GFM code blocks. The combined regexp seems to be greedy, combining adjacent code blocks. I hope to look into it more tonight.

from markdown-mode.

I found some issue of my patch. Please wait for merging it. And I'll send PR with test program.

from markdown-mode.

I merged the updated patch from @syohex with the new test case.

I also fixed several related things that may help. I reverted back to identifying GFM code blocks without using a multi-line regexp (68394bb), added a test case which identified some issues with dynamically setting the syntax properties of code blocks when there are two blocks near each other (376c07d), and I updated the extend-region-function for syntax analysis so that it the region always includes entire code blocks (not partial ones, which is why it was getting confused) (b1eff38).

Hopefully the identification of fenced code blocks is more robust now, which should help prevent odd behavior with hash-mark comments. @walmes, please let me know if this fixes the issue for you.

from markdown-mode.

Sorry Gentleman, but the cycling and navigation are the same as before yet. Below is a gif in a Emacs session with the same file used before. I'm using the current markdown-mode master branch (HEAD in 72ca234).

Is possible add also a test for a major mode when decide jump the point? Using (derived-mode-p markdown-mode) return nil if the current major mode isn't markdown. So, I think, when searching to jump for the next section header the point won't jump to a R, shell, lisp, code chunk, correct? Although, a chunk without language in its head (like '''r ou '''sh) has markdown major mode, so this chunks would not be excluded by this test. Does this help?

from markdown-mode.

markdown-mode doesn't currently do language-specific font-lock within code blocks, so what other mode/package are you using for that? I think there is an interaction. See my initial questions above.

from markdown-mode.

@walmes Could you tell us how to reproduce your problem by words and minimum sample code ? I cannot understand your operations via gif animation and so I cannot write any tests.

from markdown-mode.

When a chunk has a header with a language, (lisp, r, sh, etc), polymode enables ess-mode inside it. That is why header code chunk R has a different background and proper syntax highlight. I don't know what is done by polymode to narrow this way but inside a chunk the major mode is ess-mode and outside is makdown-mode (so, inside a chunk C-c C-n calls ess-eval-line-and-step). To reproduce this, you need to install polymode, ess and R. You can install polymode and ess by melpa.

## For R and ESS.
sudo apt-get install r-base ess

This configuration on my dot file can be useful (comment lines that add hook to markdown-mode) . With all this components (R, ess, markdown and polymode), create and *.Rmd file (R markdown). Use S-TAB and C-C C-n. The snippet is a file that may be a good start point.

from markdown-mode.

I suppose you can fix this issue by following patch.

diff --git a/markdown-mode.el b/markdown-mode.el
index 524b311..67e6000 100644
--- a/markdown-mode.el
+++ b/markdown-mode.el
@@ -2405,7 +2405,9 @@ This includes pre blocks, tilde-fenced code blocks, and GFM
 quoted code blocks.  Return nil otherwise."
   (or (get-text-property pos 'markdown-pre)
       (get-text-property pos 'markdown-gfm-code)
-      (get-text-property pos 'markdown-fenced-code)))
+      (get-text-property pos 'markdown-fenced-code)
+      (and (bound-and-true-p poly-markdown-mode)
+           (car (pm/get-innermost-span)))))

 (defun markdown-code-block-at-point ()
   "Return match data if the point is inside a code block.

markdown-mode.el uses text-property for testing current area for example code block etc. However code block in poly-mode is applied another major-mode such as R in this case, so functions of markdown-mode does not work as expected.

from markdown-mode.

It changes the nature of the issue significantly when there are two other modes at play. As @syohex noticed, polymode is removing the text properties set by markdown-mode so that it can no longer identify fenced code blocks. Perhaps polymode should preserve any text properties beginning with markdown-? I think that would fix this issue. (In my brief testing, there seemed to be other issues with poly-markdown-mode as well and I think that mode might need to be updated a bit more to work reliably with the latest versions of markdown-mode.)

However, for now I implemented a fix on the markdown-mode side that I think will help. Please see if 40f00a5 fixes the issue for you.

@syohex, your suggestion above was very good; thank you for the patch. When I tried using pm/get-innermost-span, however, that function was very slow and since markdown-code-block-at-pos is called often, Emacs became very sluggish. In the commit above, I check the chunkmode text property instead, which is used by polymode. That seems to be much faster.

from markdown-mode.

Gentlemen, the problem was solved. As @syohex noticed, when polymode coexists with markdown mode it removes text properties that is why testing if the point is inside a code block based on font face is not a good idea, and testing if the font face is 'chunkmode solved the problem. Thanks! This way, all code blocks that have a header ({r}`, sh, ````lisp) are ignored by S-TAB and C-c C-{n,p} because they have 'chunkmode face given by polymode. The problem is code blocks without header because they don't have a face given by markdown (polymode removes) neither have chunkmode face given by polymode. They are markdown regular text.

One possible way to solve this is to test if the point is inside a code block not based on font lock face. If the point is inside a block, the number of ^```$ (or ~~~) matching above and below is odd. This test would be more expensive mainly for big files. However, it would be needed only when polymode would be on and could be narrowed to the inner most text section.

In the meantime, I'm using chunk header for all my code blocks. I think this is simpler than change source code, :).

from markdown-mode.

I'm glad this fixed the issue for you. Thanks for letting us know.

For future reference for others, in case other similar issues arise with polymode or other modes, let me just add a note that markdown-mode is not testing based on a font face, but rather on text properties. markdown-mode sets these properties when parsing the buffer to prevent having to re-parse it again if nothing has changed (e.g., for navigation and folding). These are similar to syntax table properties, but more general since Markdown syntax doesn't fit in the Emacs syntax table framework. There's nothing I can do if other modes remove such information from the buffer. If other modes want to preserve markdown-mode functionality, I think they should append/add other text properties rather than clearing everything.

from markdown-mode.

@walmes sorry to drag up an old issue, but would you be willing to explain how you solved this in a bit more detail, so that I can follow along at home?

What does "using chunk header for... code blocks" entail? I'm using the standard Rmarkdown style. I'm also using polymode, and both it and markdown-mode are at their latest versions.

from markdown-mode.