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

To reply to this bug, email your comments to 78043 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

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

From: Kang Tu <tninja <at> gmail.com>
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 '>'
Date: Thu, 24 Apr 2025 08:39:57 -0700

[Message part 1 (text/plain, inline)]

From: Kang Tu <tninja <at> gmail.com>

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.

 Thank you!
Date: Thu, 24 Apr 2025 08:35:23 -0700
Message-ID: <87h62do9ms.fsf <at> gmail.com>

[Message part 2 (text/html, inline)]

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.

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

From: Kang Tu <tninja <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
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 06:56:56 -0700

[Message part 1 (text/plain, inline)]

Thanks for replying!

Actually we are wondering if it is a comint-mode bug. This line suppose to
suppress markdown-mode rendering on comint input line (start with >
character): https://github.com/tninja/aider.el/blob/main/aider-core.el#L67,
However it doesn't work as expected.

We are discussed in this github issue, and font-lock-defaults seems to be
right: https://github.com/tninja/aider.el/issues/126#issuecomment-2816839141,
so we suspect it is a comint-mode bug, for not being able to override on
comint input line.

Would you mind help take a look at this?

Regards

Kang

On Thu, Apr 24, 2025 at 11:12 PM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > 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.
>

[Message part 2 (text/html, inline)]

Message #14 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 18:52:26 +0300

> From: Kang Tu <tninja <at> gmail.com>
> Date: Fri, 25 Apr 2025 06:56:56 -0700
> Cc: 78043 <at> debbugs.gnu.org
> 
> Actually we are wondering if it is a comint-mode bug. This line suppose to suppress markdown-mode
> rendering on comint input line (start with > character):
> https://github.com/tninja/aider.el/blob/main/aider-core.el#L67, However it doesn't work as expected.
> 
> We are discussed in this github issue, and font-lock-defaults seems to be right:
> https://github.com/tninja/aider.el/issues/126#issuecomment-2816839141, so we suspect it is a comint-mode
> bug, for not being able to override on comint input line.
> 
> Would you mind help take a look at this?

I would, if you could provide a recipe for reproduction that starts
from "emacs -Q" and preferably doesn't need to load markdown-mode.  If
this is a comint issue, then there should be a way of reproducing the
problem without markdown-mode.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: 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: Sat, 10 May 2025 12:26:06 +0300

Ping!  Would it be possible to have a recipe like I asked for?

> Cc: 78043 <at> debbugs.gnu.org
> Date: Fri, 25 Apr 2025 18:52:26 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > From: Kang Tu <tninja <at> gmail.com>
> > Date: Fri, 25 Apr 2025 06:56:56 -0700
> > Cc: 78043 <at> debbugs.gnu.org
> > 
> > Actually we are wondering if it is a comint-mode bug. This line suppose to suppress markdown-mode
> > rendering on comint input line (start with > character):
> > https://github.com/tninja/aider.el/blob/main/aider-core.el#L67, However it doesn't work as expected.
> > 
> > We are discussed in this github issue, and font-lock-defaults seems to be right:
> > https://github.com/tninja/aider.el/issues/126#issuecomment-2816839141, so we suspect it is a comint-mode
> > bug, for not being able to override on comint input line.
> > 
> > Would you mind help take a look at this?
> 
> I would, if you could provide a recipe for reproduction that starts
> from "emacs -Q" and preferably doesn't need to load markdown-mode.  If
> this is a comint issue, then there should be a way of reproducing the
> problem without markdown-mode.
> 
> 
> 
> 

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

From: Kang Tu <tninja <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
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: Sat, 10 May 2025 06:34:01 -0700

[Message part 1 (text/plain, inline)]

Hi Eli,

Thanks for the follow up, and sorry for my late reply.
I have some difficulty to reproduce the problem without markdown-mode

On our side, The problem got resolved by making code change on application
side in this PR <https://github.com/tninja/aider.el/pull/133>. And The
issue creator in application side are happy
<https://github.com/tninja/aider.el/issues/126> with current solution
<https://github.com/tninja/aider.el/issues/126>.

I thought it might be a comint-mode bug but still not very sure, cause our
code is applying markdown mode syntax on the comint session and it is not a
pure comint seen issue. But glad it is not a problem anymore.

Best

Kang

On Sat, May 10, 2025 at 2:26 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> Ping!  Would it be possible to have a recipe like I asked for?
>
> > Cc: 78043 <at> debbugs.gnu.org
> > Date: Fri, 25 Apr 2025 18:52:26 +0300
> > From: Eli Zaretskii <eliz <at> gnu.org>
> >
> > > From: Kang Tu <tninja <at> gmail.com>
> > > Date: Fri, 25 Apr 2025 06:56:56 -0700
> > > Cc: 78043 <at> debbugs.gnu.org
> > >
> > > Actually we are wondering if it is a comint-mode bug. This line
> suppose to suppress markdown-mode
> > > rendering on comint input line (start with > character):
> > > https://github.com/tninja/aider.el/blob/main/aider-core.el#L67,
> However it doesn't work as expected.
> > >
> > > We are discussed in this github issue, and font-lock-defaults seems to
> be right:
> > > https://github.com/tninja/aider.el/issues/126#issuecomment-2816839141,
> so we suspect it is a comint-mode
> > > bug, for not being able to override on comint input line.
> > >
> > > Would you mind help take a look at this?
> >
> > I would, if you could provide a recipe for reproduction that starts
> > from "emacs -Q" and preferably doesn't need to load markdown-mode.  If
> > this is a comint issue, then there should be a way of reproducing the
> > problem without markdown-mode.
> >
> >
> >
> >
>

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kang Tu <tninja <at> gmail.com>
Cc: 78043-done <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: Sat, 31 May 2025 12:13:48 +0300

> From: Kang Tu <tninja <at> gmail.com>
> Date: Sat, 10 May 2025 06:34:01 -0700
> Cc: 78043 <at> debbugs.gnu.org
> 
> Hi Eli,
> 
> Thanks for the follow up, and sorry for my late reply. 
> I have some difficulty to reproduce the problem without markdown-mode
> 
> On our side, The problem got resolved by making code change on application side in this PR. And The issue
> creator in application side are happy with current solution.
> 
> I thought it might be a comint-mode bug but still not very sure, cause our code is applying markdown mode
> syntax on the comint session and it is not a pure comint seen issue. But glad it is not a problem anymore.

Thanks, for the update.  Glad the problem was solved.  I'm therefore
closing this bug.

Previous Next

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