GNU bug report logs - #78043
Cursor gets stuck after inline code input in comint buffer when using markdown-mode, bypassing prompt lines starting with '>'

Previous Next

Package: emacs;

Reported by: Kang Tu <tninja <at> gmail.com>

Date: Thu, 24 Apr 2025 15:48:02 UTC

Severity: normal

Done: Eli Zaretskii <eliz <at> gnu.org>

Full log


Message #8 received at 78043 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kang Tu <tninja <at> gmail.com>
Cc: 78043 <at> debbugs.gnu.org
Subject: Re: bug#78043: Cursor gets stuck after inline code input in comint
 buffer
 when using markdown-mode, bypassing prompt lines starting with '>'
Date: Fri, 25 Apr 2025 09:12:46 +0300
> From: Kang Tu <tninja <at> gmail.com>
> Date: Thu, 24 Apr 2025 08:39:57 -0700
> 
> To: bug-gnu-emacs <at> gnu.org
> Subject: Cursor gets stuck after inline code input in comint buffer when
>  using markdown-mode, bypassing prompt lines starting with '>'
> Description:
>  To avoid interfering with input, I implemented logic to bypass markdown
>  rendering on prompt input lines, which start with '>'
> 
>  I suspect this issue is related to the interaction between markdown-mode
>  rendering and comint input handling, especially regarding the bypass logic
>  for prompt lines.
> 
> Environment:
>  > Please refactoring `main.go`
> 
>  - Emacs version: 30.1
>  - markdown-mode version: 2.5
>  - OS: ubuntu 24.04 / mac osx
> 
> Attachments:
>  I am using Emacs comint buffer with markdown-mode enabled to render the
>  output as formatted Markdown.
> 
>  Actual behavior:
>  The cursor gets stuck after inline code input on the prompt line.
> 
>  However, when I type inline code surrounded by backticks on a prompt line
>  like:
> 
>  Any advice or known fixes for this interaction issue between markdown-mode
>  and comint would be much appreciated.
> 
>  The cursor gets stuck after finishing the inline code and I cannot continue
>  typing.
> 
>  - Minimal input example
>   - Please refactoring `main.go`
>  - Relevant markdown-mode and comint configuration snippets (especially
>  bypass logic for prompt lines)
>  (defun aider--apply-markdown-highlighting ()
>   "Set up markdown highlighting for aider buffer with optimized performance.
>  Ignore lines starting with '>' (command prompts/input)."
>   ;; 1) Use `markdown-mode`'s syntax table:
>   (set-syntax-table (make-syntax-table markdown-mode-syntax-table))
>   ;; 2) For multiline constructs (like fenced code blocks), enable
>  `markdown-syntax-propertize`:
>   (setq-local syntax-propertize-function #'markdown-syntax-propertize)
>   ;; 3) Reuse `markdown-mode`'s font-lock keywords for highlighting,
>   ;;    but add a rule to prevent markdown highlighting on lines starting
>  with '>'.
>   (setq-local font-lock-defaults
>               (list (cons
>                      ;; Rule to apply default face to prompt lines, without
>  overriding.
>                      ;; This aims to prevent subsequent markdown rules in
>  this list
>                      ;; from applying, while still allowing
>  comint-highlight-input.
>                      '("^>.*$" 0 'default nil) ;; ==> this line did bypass
>  prompt input line, update nil to t doesn't help
>                      ;; Original markdown keywords
>                      markdown-mode-font-lock-keywords)
>                     nil ;; KEYWORDS-ONLY
>                     nil ;; CASE-FOLD
>                     nil ;; SYNTAX-ALIST
>                     nil)) ;; SYNTAX-BEGIN
>   ;; 4) Enable fenced code block highlighting, and disable special font
>  processing:
>   (setq-local markdown-fontify-code-blocks-natively t)
>   ;; https://github.com/tninja/aider.el/issues/113
>   ;; TODO: temporary solution to disable bold, italic. need a better way
>  than this, if we want to keep them in reply text
>   ;; Note: The rule added above is a more targeted way to handle prompts
>  than disabling these globally.
>   ;; Consider if these are still needed or can be re-enabled depending on
>  desired appearance for non-prompt text.
>   (setq-local markdown-regex-bold nil)
>   (setq-local markdown-regex-italic nil)
>   (setq-local markdown-regex-strike-through nil)
>   ;; 5) Jit-lock and other
>   (setq-local font-lock-multiline t)  ;; Handle multiline constructs
>  efficiently
>   (setq-local jit-lock-contextually nil)  ;; Disable contextual analysis
>   (setq-local font-lock-support-mode 'jit-lock-mode)  ;; Ensure JIT lock is
>  used
>   (setq-local jit-lock-defer-time 0)
>   ;; 6) Register font-lock explicitly:
>   (font-lock-mode 1)
>   ;; 7) Force immediate fontification of visible area:
>   (font-lock-flush)
>   (font-lock-ensure))
>  - Screenshots if any
> 
>  Steps to reproduce:
>  1. Open a comint buffer (e.g., shell or custom comint).
>  2. Enable markdown-mode for the buffer, with special handling to skip
>  rendering lines starting with '>'.
>  3. In the prompt line, type an inline code snippet with backticks, e.g.:
>    > Please refactoring `main.go`
>  4. Observe that after typing `main.go`, the cursor is stuck and cannot
>  continue.
> 
>  Expected behavior:
>  The cursor should move freely and the input should work normally, with
>  prompt lines properly bypassed from markdown rendering.

Thanks.

AFAIU, markdown-mode is not part of Emacs and not on GNU ELPA.  If so,
would you please report this first to the developers of markdown-mode?
If, after investigating the problem, they come to the conclusion that
it's a bug in Emacs core, please come back here with the results of
their investigations, and we will take a look at this.




This bug report was last modified 17 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.