From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 24 11:47:18 2025 Received: (at submit) by debbugs.gnu.org; 24 Apr 2025 15:47:18 +0000 Received: from localhost ([127.0.0.1]:40362 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u7ynF-0006vb-KZ for submit@debbugs.gnu.org; Thu, 24 Apr 2025 11:47:18 -0400 Received: from lists.gnu.org ([2001:470:142::17]:33910) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u7ygZ-0006XC-1o for submit@debbugs.gnu.org; Thu, 24 Apr 2025 11:40:24 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1u7ygT-0000jv-MW for bug-gnu-emacs@gnu.org; Thu, 24 Apr 2025 11:40:17 -0400 Received: from mail-ed1-x531.google.com ([2a00:1450:4864:20::531]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1u7ygR-0003YN-E6 for bug-gnu-emacs@gnu.org; Thu, 24 Apr 2025 11:40:17 -0400 Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-5ed43460d6bso1811065a12.0 for ; Thu, 24 Apr 2025 08:40:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1745509212; x=1746114012; darn=gnu.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=zSy13pq++uYfo7xlALmjj209z7gXQFInOpQWT+lyYmM=; b=DAUO/wAQigj3XKUQHLiNadE4IeBjJn67JFqfWlxUvhnnTSnUlV7LFdT7CjDu/45G9n c8pEkkHnQ1YNuYnZ9dqMTJQxaHGYEdJXA4bw8hqNWzdFlTgpbPFQQte4Rj3RuZ0auRIL r1yxqysDBcbhUhQwjsAXaisoA3+uHDAzDWnfYRJmZLhGD+ARj6wKohJ9gx23NEChzytF 2w1HH1VyshHzltM38Bkp5KGncxPAhINbsvQkuyZdOE4QXRASmpFpHIxJVaCaqMeCJe4i sFKwJUtBIITpiQElK6vrL9QTBQ4ZF71qO/Q+JRiSGVaVgMqPOAD+q7GAfHuzY2a60V9k zmbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745509212; x=1746114012; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=zSy13pq++uYfo7xlALmjj209z7gXQFInOpQWT+lyYmM=; b=iQn9O2sPx5xVs474Yr7qsNs8/qxec2uYdFoaLLwKOMzXYwkx9gRI/FA62JyYz2Lv7L /f9uXt3e69RoFd6kUL2XfMjGHzNjvH+xDj2GknIxJSLbXWGi0nu01a9pmGcDyss/kZGs hMLXR47InLF97tQ+6dz44MUMnXqSLmQ4BLyA8TezU+5Z8QhcOIiX/bR9PD38/q/0otSN 2yqwcW/hc8BAkzBzaDWPrdaY21BhjssEVHh3Y+OpFbSKSGHulV/rV50szN3p7EtyDlHG J8YNDuEyG6QzrQ6nnUtMCta3lqyjc3NfFnNj7onwKDLAa+fkGAr01sGQT7EfrHvMl7QY yLqA== X-Gm-Message-State: AOJu0YypNIrz7FpuKTATnmWio8ShWB6u74M16gX7a/r+BfU7zGbloasK brc7a9ES+FcCPQ8HS8yt98ZauG/cwx5oeSBHPxVHXYEqKxSwetLOlXbih0ngqcpBsGvFtyktHcT Q0HVhhC6sVv+51E3MXAVbArO4u5phJtxDh+Y= X-Gm-Gg: ASbGnctPNFNyhId5u1884NOa5Do8pfHs17ZqTQmroFkpygASJESb6OEePnlSEMdVA23 9YB8l9CPn52s06t7NfL9XHpVwqTdFN9tp6763YVnNA2BDtmGqDBmhAwpze4aDLy6M4nMjVWJghO GydwCdzyAMILp3Sh7I2wzcN8dcsWlh5ANrNcAv24mzJIUsen5whlRdk1I= X-Google-Smtp-Source: AGHT+IGYK4afCjF/yo8byLNHLA1M9l+afhxCXYVkBkCqn/YbAN3Ez5EB7KxbZcOM/r07uajzR/VoHjg/5rKlv6tYoeE= X-Received: by 2002:a05:6402:3486:b0:5f4:d59a:81d0 with SMTP id 4fb4d7f45d1cf-5f6df53e5abmr2572003a12.29.1745509211688; Thu, 24 Apr 2025 08:40:11 -0700 (PDT) MIME-Version: 1.0 From: Kang Tu Date: Thu, 24 Apr 2025 08:39:57 -0700 X-Gm-Features: ATxdqUHUfy0ho5ip-flUwgh_Xy-BhiVCuAV4cx9QiW4VNQ7KxC1Hz0hET_HqsR8 Message-ID: Subject: Cursor gets stuck after inline code input in comint buffer when using markdown-mode, bypassing prompt lines starting with '>' To: bug-gnu-emacs@gnu.org Content-Type: multipart/alternative; boundary="00000000000083da900633880899" Received-SPF: pass client-ip=2a00:1450:4864:20::531; envelope-from=tninja@gmail.com; helo=mail-ed1-x531.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Thu, 24 Apr 2025 11:47:15 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --00000000000083da900633880899 Content-Type: text/plain; charset="UTF-8" From: Kang Tu To: bug-gnu-emacs@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@gmail.com> --00000000000083da900633880899 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
From: Kang Tu <tnin= ja@gmail.com>

To: bu= g-gnu-emacs@gnu.org
Subject: Cursor gets stuck after inline code inp= ut in comint buffer when
=C2=A0using markdown-mode, bypassing prompt lin= es starting with '>'
Description:
=C2=A0To avoid interferi= ng with input, I implemented logic to bypass markdown
=C2=A0rendering on= prompt input lines, which start with '>'

=C2=A0I suspect= this issue is related to the interaction between markdown-mode
=C2=A0re= ndering and comint input handling, especially regarding the bypass logic=C2=A0for prompt lines.

Environment:
=C2=A0> Please refactori= ng `main.go`

=C2=A0- Emacs version: 30.1
=C2=A0- markdown-mode ve= rsion: 2.5
=C2=A0- OS: ubuntu 24.04 / mac osx

Attachments:
=C2= =A0I am using Emacs comint buffer with markdown-mode enabled to render the<= br>=C2=A0output as formatted Markdown.

=C2=A0Actual behavior:
=C2= =A0The cursor gets stuck after inline code input on the prompt line.
=C2=A0However, when I type inline code surrounded by backticks on a prompt= line
=C2=A0like:

=C2=A0Any advice or known fixes for this intera= ction issue between markdown-mode
=C2=A0and comint would be much appreci= ated.

=C2=A0The cursor gets stuck after finishing the inline code an= d I cannot continue
=C2=A0typing.

=C2=A0- Minimal input example=C2=A0 - Please refactoring `main.go`
=C2=A0- Relevant markdown-mode a= nd comint configuration snippets (especially
=C2=A0bypass logic for prom= pt lines)
=C2=A0(defun aider--apply-markdown-highlighting ()
=C2=A0 &= quot;Set up markdown highlighting for aider buffer with optimized performan= ce.
=C2=A0Ignore lines starting with '>' (command prompts/inp= ut)."
=C2=A0 ;; 1) Use `markdown-mode`'s syntax table:
=C2= =A0 (set-syntax-table (make-syntax-table markdown-mode-syntax-table))
= =C2=A0 ;; 2) For multiline constructs (like fenced code blocks), enable
= =C2=A0`markdown-syntax-propertize`:
=C2=A0 (setq-local syntax-propertize= -function #'markdown-syntax-propertize)
=C2=A0 ;; 3) Reuse `markdown= -mode`'s font-lock keywords for highlighting,
=C2=A0 ;; =C2=A0 =C2= =A0but add a rule to prevent markdown highlighting on lines starting
=C2= =A0with '>'.
=C2=A0 (setq-local font-lock-defaults
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (list (cons
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; Rule to apply= default face to prompt lines, without
=C2=A0overriding.
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; This a= ims to prevent subsequent markdown rules in
=C2=A0this list
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; fro= m applying, while still allowing
=C2=A0comint-highlight-input.
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0'= ("^>.*$" 0 'default nil) ;; =3D=3D> this line did bypas= s
=C2=A0prompt input line, update nil to t doesn't help
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; Ori= ginal markdown keywords
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0markdown-mode-font-lock-keywords)
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 nil ;; KEYWORDS= -ONLY
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 nil ;; CASE-FOLD
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 nil ;; SYNTAX-ALIST
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 nil)) ;; SYNTAX-BEGIN
=C2=A0 ;; 4= ) Enable fenced code block highlighting, and disable special font
=C2=A0= processing:
=C2=A0 (setq-local markdown-fontify-code-blocks-natively t)<= br>=C2=A0 ;; http= s://github.com/tninja/aider.el/issues/113
=C2=A0 ;; TODO: temporary = solution to disable bold, italic. need a better way
=C2=A0than this, if = we want to keep them in reply text
=C2=A0 ;; Note: The rule added above = is a more targeted way to handle prompts
=C2=A0than disabling these glob= ally.
=C2=A0 ;; Consider if these are still needed or can be re-enabled = depending on
=C2=A0desired appearance for non-prompt text.
=C2=A0 (se= tq-local markdown-regex-bold nil)
=C2=A0 (setq-local markdown-regex-ital= ic nil)
=C2=A0 (setq-local markdown-regex-strike-through nil)
=C2=A0 = ;; 5) Jit-lock and other
=C2=A0 (setq-local font-lock-multiline t) =C2= =A0;; Handle multiline constructs
=C2=A0efficiently
=C2=A0 (setq-loca= l jit-lock-contextually nil) =C2=A0;; Disable contextual analysis
=C2=A0= (setq-local font-lock-support-mode 'jit-lock-mode) =C2=A0;; Ensure JIT= lock is
=C2=A0used
=C2=A0 (setq-local jit-lock-defer-time 0)
=C2= =A0 ;; 6) Register font-lock explicitly:
=C2=A0 (font-lock-mode 1)
= =C2=A0 ;; 7) Force immediate fontification of visible area:
=C2=A0 (font= -lock-flush)
=C2=A0 (font-lock-ensure))
=C2=A0- Screenshots if any
=C2=A0Steps to reproduce:
=C2=A01. Open a comint buffer (e.g., shel= l or custom comint).
=C2=A02. Enable markdown-mode for the buffer, with = special handling to skip
=C2=A0rendering lines starting with '>&#= 39;.
=C2=A03. In the prompt line, type an inline code snippet with backt= icks, e.g.:
=C2=A0 =C2=A0> Please refactoring `main.go`
=C2=A04. O= bserve that after typing `main.go`, the cursor is stuck and cannot
=C2= =A0continue.

=C2=A0Expected behavior:
=C2=A0The cursor should mov= e freely and the input should work normally, with
=C2=A0prompt lines pro= perly bypassed from markdown rendering.

=C2=A0Thank you!
Date: Th= u, 24 Apr 2025 08:35:23 -0700
Message-ID: <87h62do9ms.fsf@gmail.com>

--00000000000083da900633880899-- From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 25 02:12:57 2025 Received: (at 78043) by debbugs.gnu.org; 25 Apr 2025 06:12:57 +0000 Received: from localhost ([127.0.0.1]:45886 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u8CIy-0002EO-Lm for submit@debbugs.gnu.org; Fri, 25 Apr 2025 02:12:57 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47406) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u8CIv-0002Ds-V8 for 78043@debbugs.gnu.org; Fri, 25 Apr 2025 02:12:54 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1u8CIq-0001Ru-FJ; Fri, 25 Apr 2025 02:12:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=CGh5udf54UV9mn3fx4I5UaGpRZmAmiDoakTMLcXRtTw=; b=kqNtc6vAZA3c NFwH4MIRBQfe1kGBGamT3/LjCiUqlT47havoW+l5kXIebU26V+wFvd5kV2DacbzxPTjROH/ELBOFr vYHdpQAqPhM0CmTKSVWCOlleDcVXBuGYyBAj9QqGPYNzF6/+Xqldp+S4tHhQDeYcB9FWKWxvuC4MT 1rh5SRsazxQSzJoYS+mk31jhGtQ3AHwhbXFD5TvNkQzmtk1MciBX5fpzNh4Whxpp46vclehArEgJi zodS04nHVGYlbV7dBMZcJUs7cezrj1LMjV+IniIoZ5e0QbwhDeS3aC004htCoeLp1AvNg3XlampxW bQj87V0SJfaHhYI1my1L4g==; Date: Fri, 25 Apr 2025 09:12:46 +0300 Message-Id: <86o6wkydk1.fsf@gnu.org> From: Eli Zaretskii To: Kang Tu In-Reply-To: (message from Kang Tu on Thu, 24 Apr 2025 08:39:57 -0700) Subject: Re: bug#78043: Cursor gets stuck after inline code input in comint buffer when using markdown-mode, bypassing prompt lines starting with '>' References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78043 Cc: 78043@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Kang Tu > Date: Thu, 24 Apr 2025 08:39:57 -0700 > > To: bug-gnu-emacs@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. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 25 09:57:31 2025 Received: (at 78043) by debbugs.gnu.org; 25 Apr 2025 13:57:32 +0000 Received: from localhost ([127.0.0.1]:50197 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u8JYX-00068A-6v for submit@debbugs.gnu.org; Fri, 25 Apr 2025 09:57:30 -0400 Received: from mail-ej1-x634.google.com ([2a00:1450:4864:20::634]:44241) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1u8JYJ-00067f-1m for 78043@debbugs.gnu.org; Fri, 25 Apr 2025 09:57:23 -0400 Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-ac3eb3fdd2eso412150766b.0 for <78043@debbugs.gnu.org>; Fri, 25 Apr 2025 06:57:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1745589428; x=1746194228; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=6LUMt5//WEO8jbCIcwdEPl6iFnCU139tP5jp7xLrDwM=; b=a2CE03gjWzA+Vad19SlsdzdNTt955IY72frwoTPjytStCLRfZU6K1kuXUn+MegEtUt rTrisu17xwohc9EFl2LA7CR+N/UbpT5EvXNfm0D0OcESHBDKx6P0fs6EmGuvVGDy7D2t NJygyN8vNBtAmsP+ah/uv9MObnv4/taeHiQBAu+mxNMf2KRNw3RJKj1YF5727KWFF03P 8e0fAcyrUngieHaDGEQ6JGgNOyyU7DZZy2oauM0a/vqrMy4Cchq3GUzHSZ+BfQUlAWFT 4GI+jr4teyjBHC9NVMe5PwzFY8GyU8gkbZxG819uVexQ0zK8ffsEgmSjYpxF1TR+Re7z eaPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745589428; x=1746194228; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6LUMt5//WEO8jbCIcwdEPl6iFnCU139tP5jp7xLrDwM=; b=EW0WVtG0Xeikw1x2Wp6N3FE89xTt62RfK56wfB0ZsDX62eDjDPkQrO1qEl4N8sDVAu 5xllEjXjlaXnz+HDOdfOBCYxPj0m1BIMeFFNL7UOg2LUKvHIN2sPEf7LSFB4CP9WW1EM CUOQirtKMwT8X7pdZohtqA9J0UxubQ22pOprMqWSIvP/eElRi2szJ84k0TfGLyBs1Ihf 5sb/fwXX6lKfjrcHKpHBb/QFntKQN6Kk7SiAlIQcQXp8McNU6A/Tsl1t39eZRAls4j/L CpyCzqyDFxlQCp7RMEE669sunCqscYCA89O10p4Lo69abLTOpZmrr+7tvDRj7oDSYz/L miXw== X-Gm-Message-State: AOJu0YwSL/LxBuVHD8wMYTnzt1C05yLqVZGelx/MJp6Cz+e9a6zlUShU syc8al6jL0Ptk/rLZgjdne3cwfohndzzE7JcWLp5BTQAgV3erViemISwteNfJjYx36THtkj2FPz 3uC7EmqbdMqWjlj+lxSlHtSH6pxDykCyHBr8= X-Gm-Gg: ASbGncvh74srYxCXF5XjLFs4evE2b2y1YlHOrISFisoEoM3919BmntJ73IPTl3laALt nOyNC0HfRP2bSxplb4ZG6ZT86TRV2waAfyWsYjhGTifvsNACvXpPmbTgrepoDS0u5HBbMqkpwuD ENUK38MQEdNglG7Dd9j3pG0dAk4wqbT7vxtfBDvuham347lDRT5MJfaw== X-Google-Smtp-Source: AGHT+IGwEtqdHF6rHacWyPc559I90BWiZu55eLjEJVxKmeOeQfQ4PpGHjhKXDpoPSIBkrVt7IDL/G7jgEt0WfjCZjpI= X-Received: by 2002:a17:907:7289:b0:ace:6c29:a98c with SMTP id a640c23a62f3a-ace73b2376amr174012266b.37.1745589427974; Fri, 25 Apr 2025 06:57:07 -0700 (PDT) MIME-Version: 1.0 References: <86o6wkydk1.fsf@gnu.org> In-Reply-To: <86o6wkydk1.fsf@gnu.org> From: Kang Tu Date: Fri, 25 Apr 2025 06:56:56 -0700 X-Gm-Features: ATxdqUFklzaRFD3RmiuibDP2txrTGRH8yo4xeDJlbkwA3UdcZXNZYDXAOCyS96s Message-ID: Subject: Re: bug#78043: Cursor gets stuck after inline code input in comint buffer when using markdown-mode, bypassing prompt lines starting with '>' To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000c7379906339ab5eb" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78043 Cc: 78043@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000c7379906339ab5eb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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-281683914= 1, 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=E2=80=AFPM Eli Zaretskii wrote= : > > From: Kang Tu > > Date: Thu, 24 Apr 2025 08:39:57 -0700 > > > > To: bug-gnu-emacs@gnu.org > > Subject: Cursor gets stuck after inline code input in comint buffer whe= n > > using markdown-mode, bypassing prompt lines starting with '>' > > Description: > > To avoid interfering with input, I implemented logic to bypass markdow= n > > rendering on prompt input lines, which start with '>' > > > > I suspect this issue is related to the interaction between markdown-mo= de > > 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 th= e > > 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 starti= ng > > 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) ;; =3D=3D> 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 wa= y > > than this, if we want to keep them in reply text > > ;; Note: The rule added above is a more targeted way to handle prompt= s > > 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 analysi= s > > (setq-local font-lock-support-mode 'jit-lock-mode) ;; Ensure JIT loc= k > 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. > --000000000000c7379906339ab5eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for replying!

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

We are discusse= d in this github issue, and=C2=A0font-loc= k-defaults seems to be right: https://github.com/tninja/aider= .el/issues/126#issuecomment-2816839141, so we suspect it is a comint-mo= de 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=E2=80=AFPM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Kang Tu <tninja@gmail.com>
> Date: Thu, 24 Apr 2025 08:39:57 -0700
>
> To: bug-gnu= -emacs@gnu.org
> Subject: Cursor gets stuck after inline code input in comint buffer wh= en
>=C2=A0 using markdown-mode, bypassing prompt lines starting with '&= gt;'
> Description:
>=C2=A0 To avoid interfering with input, I implemented logic to bypass m= arkdown
>=C2=A0 rendering on prompt input lines, which start with '>'=
>
>=C2=A0 I suspect this issue is related to the interaction between markd= own-mode
>=C2=A0 rendering and comint input handling, especially regarding the by= pass logic
>=C2=A0 for prompt lines.
>
> Environment:
>=C2=A0 > Please refactoring `main.go`
>
>=C2=A0 - Emacs version: 30.1
>=C2=A0 - markdown-mode version: 2.5
>=C2=A0 - OS: ubuntu 24.04 / mac osx
>
> Attachments:
>=C2=A0 I am using Emacs comint buffer with markdown-mode enabled to ren= der the
>=C2=A0 output as formatted Markdown.
>
>=C2=A0 Actual behavior:
>=C2=A0 The cursor gets stuck after inline code input on the prompt line= .
>
>=C2=A0 However, when I type inline code surrounded by backticks on a pr= ompt line
>=C2=A0 like:
>
>=C2=A0 Any advice or known fixes for this interaction issue between mar= kdown-mode
>=C2=A0 and comint would be much appreciated.
>
>=C2=A0 The cursor gets stuck after finishing the inline code and I cann= ot continue
>=C2=A0 typing.
>
>=C2=A0 - Minimal input example
>=C2=A0 =C2=A0- Please refactoring `main.go`
>=C2=A0 - Relevant markdown-mode and comint configuration snippets (espe= cially
>=C2=A0 bypass logic for prompt lines)
>=C2=A0 (defun aider--apply-markdown-highlighting ()
>=C2=A0 =C2=A0"Set up markdown highlighting for aider buffer with o= ptimized performance.
>=C2=A0 Ignore lines starting with '>' (command prompts/input= )."
>=C2=A0 =C2=A0;; 1) Use `markdown-mode`'s syntax table:
>=C2=A0 =C2=A0(set-syntax-table (make-syntax-table markdown-mode-syntax-= table))
>=C2=A0 =C2=A0;; 2) For multiline constructs (like fenced code blocks), = enable
>=C2=A0 `markdown-syntax-propertize`:
>=C2=A0 =C2=A0(setq-local syntax-propertize-function #'markdown-synt= ax-propertize)
>=C2=A0 =C2=A0;; 3) Reuse `markdown-mode`'s font-lock keywords for h= ighlighting,
>=C2=A0 =C2=A0;;=C2=A0 =C2=A0 but add a rule to prevent markdown highlig= hting on lines starting
>=C2=A0 with '>'.
>=C2=A0 =C2=A0(setq-local font-lock-defaults
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(list (cons
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 ;; Rule to apply default face to prompt lines, without
>=C2=A0 overriding.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 ;; This aims to prevent subsequent markdown rules in
>=C2=A0 this list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 ;; from applying, while still allowing
>=C2=A0 comint-highlight-input.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 '("^>.*$" 0 'default nil) ;; =3D=3D> this li= ne did bypass
>=C2=A0 prompt input line, update nil to t doesn't help
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 ;; Original markdown keywords
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 markdown-mode-font-lock-keywords)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0nil ;; KEYWORDS-ONLY
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0nil ;; CASE-FOLD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0nil ;; SYNTAX-ALIST
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0nil)) ;; SYNTAX-BEGIN
>=C2=A0 =C2=A0;; 4) Enable fenced code block highlighting, and disable s= pecial font
>=C2=A0 processing:
>=C2=A0 =C2=A0(setq-local markdown-fontify-code-blocks-natively t)
>=C2=A0 =C2=A0;; https://github.com/tninja/aider.el/= issues/113
>=C2=A0 =C2=A0;; TODO: temporary solution to disable bold, italic. need = a better way
>=C2=A0 than this, if we want to keep them in reply text
>=C2=A0 =C2=A0;; Note: The rule added above is a more targeted way to ha= ndle prompts
>=C2=A0 than disabling these globally.
>=C2=A0 =C2=A0;; Consider if these are still needed or can be re-enabled= depending on
>=C2=A0 desired appearance for non-prompt text.
>=C2=A0 =C2=A0(setq-local markdown-regex-bold nil)
>=C2=A0 =C2=A0(setq-local markdown-regex-italic nil)
>=C2=A0 =C2=A0(setq-local markdown-regex-strike-through nil)
>=C2=A0 =C2=A0;; 5) Jit-lock and other
>=C2=A0 =C2=A0(setq-local font-lock-multiline t)=C2=A0 ;; Handle multili= ne constructs
>=C2=A0 efficiently
>=C2=A0 =C2=A0(setq-local jit-lock-contextually nil)=C2=A0 ;; Disable co= ntextual analysis
>=C2=A0 =C2=A0(setq-local font-lock-support-mode 'jit-lock-mode)=C2= =A0 ;; Ensure JIT lock is
>=C2=A0 used
>=C2=A0 =C2=A0(setq-local jit-lock-defer-time 0)
>=C2=A0 =C2=A0;; 6) Register font-lock explicitly:
>=C2=A0 =C2=A0(font-lock-mode 1)
>=C2=A0 =C2=A0;; 7) Force immediate fontification of visible area:
>=C2=A0 =C2=A0(font-lock-flush)
>=C2=A0 =C2=A0(font-lock-ensure))
>=C2=A0 - Screenshots if any
>
>=C2=A0 Steps to reproduce:
>=C2=A0 1. Open a comint buffer (e.g., shell or custom comint).
>=C2=A0 2. Enable markdown-mode for the buffer, with special handling to= skip
>=C2=A0 rendering lines starting with '>'.
>=C2=A0 3. In the prompt line, type an inline code snippet with backtick= s, e.g.:
>=C2=A0 =C2=A0 > Please refactoring `main.go`
>=C2=A0 4. Observe that after typing `main.go`, the cursor is stuck and = cannot
>=C2=A0 continue.
>
>=C2=A0 Expected behavior:
>=C2=A0 The cursor should move freely and the input should work normally= , with
>=C2=A0 prompt lines properly bypassed from markdown rendering.

Thanks.

AFAIU, markdown-mode is not part of Emacs and not on GNU ELPA.=C2=A0 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.
--000000000000c7379906339ab5eb-- From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 25 11:52:40 2025 Received: (at 78043) by debbugs.gnu.org; 25 Apr 2025 15:52:40 +0000 Received: from localhost ([127.0.0.1]:51727 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1u8LLz-00023l-Lz for submit@debbugs.gnu.org; Fri, 25 Apr 2025 11:52:40 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35440) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1u8LLw-00023B-VI for 78043@debbugs.gnu.org; Fri, 25 Apr 2025 11:52:37 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1u8LLr-0006t0-19; Fri, 25 Apr 2025 11:52:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=WXvCr4ltjyxDD2JadykpjTIiETLJWYNoF9xZRixrsxk=; b=WiMTfU4uAHr4 AXMbWSJR0Rn7pL4mi1D0a5KYZprKHBb0WX3bzqmsPGXfSBj0/EawpdNZgbHxz5Sq9qEg47zd6jhtc MvD81b783uk3YZdRQBOxppFA5HmGMCchy1NXhNM4MFABW6+RKUBu0KazlJZwgPfkRd0t3lXH5hs2o 94hFH7cNM0lXv8MA1xFcHesi0gO+QaC0yzDZTqaRbhlH556S3kt8EsoOmm60IB5zKP7C28geyHTzE l4BWcMJIy3oV/ax4qw9rypyxCd/KN3/f4DAmMEr3UZ+bKKhwYN2Bp8grv3uTSyEb9D+hDxekF9k6O Jz87pO1YXUQVLy3U/lp4ew==; Date: Fri, 25 Apr 2025 18:52:26 +0300 Message-Id: <86v7qsw85h.fsf@gnu.org> From: Eli Zaretskii To: Kang Tu In-Reply-To: (message from Kang Tu on Fri, 25 Apr 2025 06:56:56 -0700) Subject: Re: bug#78043: Cursor gets stuck after inline code input in comint buffer when using markdown-mode, bypassing prompt lines starting with '>' References: <86o6wkydk1.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78043 Cc: 78043@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Kang Tu > Date: Fri, 25 Apr 2025 06:56:56 -0700 > Cc: 78043@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. From debbugs-submit-bounces@debbugs.gnu.org Sat May 10 05:26:16 2025 Received: (at 78043) by debbugs.gnu.org; 10 May 2025 09:26:17 +0000 Received: from localhost ([127.0.0.1]:43865 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uDgTI-000540-Gj for submit@debbugs.gnu.org; Sat, 10 May 2025 05:26:16 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49342) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uDgTH-00053l-69 for 78043@debbugs.gnu.org; Sat, 10 May 2025 05:26:15 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uDgTB-0000kJ-M0; Sat, 10 May 2025 05:26:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=8yK0L7BfSk2q/CnyVtkYY9FKckxYzJ/wmK0mZJHTwO0=; b=QGkB4IChMRWS 76X9tBw0Eo6tKyMiojAr9gda7smFXzzxwkOH14zjOtT7kD5sgi/BSeL0BcPN3nNTVfG2oBqk6/AWE ktKzxxtuJf1CvGRzpt+sL2Gha3Bw7bSjaPxhPLYfBecgWnwT4m6jrJQPyAd7IZgI/FqrdcX76jdLR 3VYCEAvSPv8sa1VV7EeqcpxrZx1ILFbbUIPVyO/tiVU1PV85JCx7UQtFV63deLtPgr2uJ7hs/xlgP 0va6e0NugloPArBemtSpj23CnKvJ3eDm9r6i0WxYewxKPSaKcvjbvv3pG/bwXn1uzG4ke1zA/zk/y VMh1NjvB/QGcn+lZNIu1LQ==; Date: Sat, 10 May 2025 12:26:06 +0300 Message-Id: <86h61sbyvl.fsf@gnu.org> From: Eli Zaretskii To: tninja@gmail.com In-Reply-To: <86v7qsw85h.fsf@gnu.org> (message from Eli Zaretskii on Fri, 25 Apr 2025 18:52:26 +0300) Subject: Re: bug#78043: Cursor gets stuck after inline code input in comint buffer when using markdown-mode, bypassing prompt lines starting with '>' References: <86o6wkydk1.fsf@gnu.org> <86v7qsw85h.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78043 Cc: 78043@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Ping! Would it be possible to have a recipe like I asked for? > Cc: 78043@debbugs.gnu.org > Date: Fri, 25 Apr 2025 18:52:26 +0300 > From: Eli Zaretskii > > > From: Kang Tu > > Date: Fri, 25 Apr 2025 06:56:56 -0700 > > Cc: 78043@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. > > > > From debbugs-submit-bounces@debbugs.gnu.org Sat May 10 09:34:27 2025 Received: (at 78043) by debbugs.gnu.org; 10 May 2025 13:34:27 +0000 Received: from localhost ([127.0.0.1]:45293 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uDkLS-0000Vj-Ai for submit@debbugs.gnu.org; Sat, 10 May 2025 09:34:27 -0400 Received: from mail-ej1-x629.google.com ([2a00:1450:4864:20::629]:51649) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uDkLN-0000VO-Nd for 78043@debbugs.gnu.org; Sat, 10 May 2025 09:34:23 -0400 Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-ace333d5f7bso533828166b.3 for <78043@debbugs.gnu.org>; Sat, 10 May 2025 06:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746884053; x=1747488853; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=YQJCE+kSk071qX8BE2HMzRv1SqZTsHNANS3x4KJiE2M=; b=PtZbU3YW5nXbzZqBpUUjy28cQMUg/DPTyai9kZNhA9KyZHmDS67oayBD1d7iVYylf5 09vFroP1nf8J0fzWyZDNgmN+FJpl30DYdyYzPeZy80ap/dsrqvBQFxv+Bjx740AStfxM fWGqpmRMcu09Df7b3eTQhDGjAswbkCZ50BuAXwW67y1a+f6JBa6eUFRX5esE9FDUFMO6 2eZqSykM7IqwjaMwP0Vp47iXln0dTN6bxqs88YNNVSna3a4acnhK6vK1AVlP8YrHVH0g IVsurs7zu/rgY/dp+FhnM7/C7qrMIAZJ8h4wZKRJgaLvQFw8Rn3MYL5XY/DI9DLI+gns k6zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746884053; x=1747488853; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=YQJCE+kSk071qX8BE2HMzRv1SqZTsHNANS3x4KJiE2M=; b=Ac4Pbmo6UNp7XQHHhFjyXZOWwAbmbDrEcqIW0pMJDvndKf260PBH6MOld5ljhQUvc8 ggsEzfUUwE2dDaCat1BbbRf8TkOk4phYqLlaBToxxqc3hhSN9QB41PLNpxA+SlXrTQom lUTnOsPGd7fYzrTGs8Vlm1tQV5zUD/AovhsqMFW2kPcgeC/LmgD4FWmhlz85xJ4JDYks jMnO5h9lPDnr0pbBF4NoYLylUtAZW2L+/zVNQduIEu/zx05p0CgV2ZnwaU+Bxhqk03Wj hCsi2nKo9uRatov4DVO8n2IOmdn+i7uwkfN9LGCKIqao7ccqIlTCtZpjNU/SkEeyv36w 98Ug== X-Gm-Message-State: AOJu0YwrDsxQoVnt4puYoGfYfQqaz8iYbmj5Uhl0hqHkhC2Xz9eihrqV 4DKjcEbJOE4l+Ut91A8UMubvMQvN3r9GIrxjxNGxs1voJv/FR8FVY+X23xef6MOfM3tC9iu0b0Y kUcyioYeP80Kya68v9/Mk3XrTD3AzWF/F X-Gm-Gg: ASbGncufSP2Q96Rpl5VKtKG483fZ22sJ4Ueig/tECV4q7Hx/K6Yq3FtdS2Dli5RauvB pLsJNQqzoK4DgYZF4Su78Z05ngqP7YY5Ofo3Nm5xNny7+hTSY/EUudtc1Tnvm4rdgcZbK9fXdGo hKw/SpAm33PI0BmH3voBagJi0x/PGiN+M= X-Google-Smtp-Source: AGHT+IFLmvoz3TzuTCiLpOJn6APQ5oXxI8LsPapqmtTi3rj2O3lXbj0/RIwBYeIaUcApxt7rPwIBiaOj9Mbr1nRhqCU= X-Received: by 2002:a17:907:6b8e:b0:ac7:cdbb:bf4a with SMTP id a640c23a62f3a-ad218ea82e1mr703509366b.1.1746884052461; Sat, 10 May 2025 06:34:12 -0700 (PDT) MIME-Version: 1.0 References: <86o6wkydk1.fsf@gnu.org> <86v7qsw85h.fsf@gnu.org> <86h61sbyvl.fsf@gnu.org> In-Reply-To: <86h61sbyvl.fsf@gnu.org> From: Kang Tu Date: Sat, 10 May 2025 06:34:01 -0700 X-Gm-Features: AX0GCFvK-qLJddZEL8u7jZnVwqqcdXXqAvKxOHBWq4YBOhymyWxylpgZQUjYX6A Message-ID: Subject: Re: bug#78043: Cursor gets stuck after inline code input in comint buffer when using markdown-mode, bypassing prompt lines starting with '>' To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000692bb30634c823fa" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78043 Cc: 78043@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000692bb30634c823fa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. Best Kang On Sat, May 10, 2025 at 2:26=E2=80=AFAM Eli Zaretskii wrote: > Ping! Would it be possible to have a recipe like I asked for? > > > Cc: 78043@debbugs.gnu.org > > Date: Fri, 25 Apr 2025 18:52:26 +0300 > > From: Eli Zaretskii > > > > > From: Kang Tu > > > Date: Fri, 25 Apr 2025 06:56:56 -0700 > > > Cc: 78043@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 t= o > 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. > > > > > > > > > --000000000000692bb30634c823fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Eli,

Thanks for the follo= w up, and sorry for my late reply.
I have some difficulty to repro= duce the problem without markdown-mode

On ou= r 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 th= ought 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 pur= e comint seen issue. But glad it is not a problem anymore.

Best

Kang

On S= at, May 10, 2025 at 2:26=E2=80=AFAM Eli Zaretskii <eliz@gnu.org> wrote:
Ping!=C2=A0 Would it be possible to have a recipe li= ke I asked for?

> Cc: 78043@d= ebbugs.gnu.org
> Date: Fri, 25 Apr 2025 18:52:26 +0300
> From: Eli Zaretskii <eliz@gnu.org>
>
> > From: Kang Tu <tninja@gmail.com>
> > Date: Fri, 25 Apr 2025 06:56:56 -0700
> > Cc: 78= 043@debbugs.gnu.org
> >
> > Actually we are wondering if it is a comint-mode bug. This line s= uppose to suppress markdown-mode
> > rendering on comint input line (start with > character):
> > https://github.com/tninja/ai= der.el/blob/main/aider-core.el#L67, However it doesn't work as expe= cted.
> >
> > We are discussed in this github issue, and font-lock-defaults see= ms to be right:
> > https://github.com/tn= inja/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 mark= down-mode.=C2=A0 If
> this is a comint issue, then there should be a way of reproducing the<= br> > problem without markdown-mode.
>
>
>
>
--000000000000692bb30634c823fa-- From debbugs-submit-bounces@debbugs.gnu.org Sat May 31 05:14:03 2025 Received: (at 78043-done) by debbugs.gnu.org; 31 May 2025 09:14:04 +0000 Received: from localhost ([127.0.0.1]:55522 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uLIHx-0002zu-Vz for submit@debbugs.gnu.org; Sat, 31 May 2025 05:14:03 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51042) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uLIHs-0002yz-S5 for 78043-done@debbugs.gnu.org; Sat, 31 May 2025 05:13:59 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uLIHn-0000sV-BF; Sat, 31 May 2025 05:13:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=fiimHKd39K/697MIBEXasmAx5FmNKvO2UDUJKshkp04=; b=Z25HwGNCnINr f+M1fRnz8Wr7inFrKI1EXGJ9QA5l+BiEJeIbviWny456fGpbJS0QXcsMai7tJaKaubSpsDb2zGNuI mc59un7uS8x1lQW+NSRmFiKx7pnU/uUMDAjlR7b17whd13rFBzQuwF1raK7aYMzseITi5ac4SVis4 xz7YzwAr2PUXm9CmK3jnXltHZQenXd6E1jpEw7C/TQW9A9LeolGzW9czTU17t6lVF46Z2DFfAnE/7 EvXsem8JKd/MpM1QGP21foa/btIYOlnG38gE/ufCDdntDTCnrXFp8HZ4ZAZcJBGrR5HfO/QErmP+C q9QcUN4wkZFbw5QaWzx/Vg==; Date: Sat, 31 May 2025 12:13:48 +0300 Message-Id: <86r005rvlf.fsf@gnu.org> From: Eli Zaretskii To: Kang Tu In-Reply-To: (message from Kang Tu on Sat, 10 May 2025 06:34:01 -0700) Subject: Re: bug#78043: Cursor gets stuck after inline code input in comint buffer when using markdown-mode, bypassing prompt lines starting with '>' References: <86o6wkydk1.fsf@gnu.org> <86v7qsw85h.fsf@gnu.org> <86h61sbyvl.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78043-done Cc: 78043-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Kang Tu > Date: Sat, 10 May 2025 06:34:01 -0700 > Cc: 78043@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.