Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Avoid automatic bracket pairing inside comments and strings

Đã đóng
  • Có gì không ổn?
#307 2 bình luận 0 reaction 1 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@Jonathas2127 đang làm issue này rồi.

Từ ngày 14/10/2026.

  • #308 của @Jonathas2127 — đang mở

Đánh giá

Issue này chưa được đánh giá.

Mô tả

Problem

Automatic bracket pairing currently inserts a closing bracket inside comments and string literals. In these contexts, an opening bracket may be ordinary text, so inserting an additional closer can interrupt typing.

This behavior was mentioned in #85, which also proposed the core pairing behavior and an optional toggle. Those features have since been addressed through #88, #165, and #252. This proposal focuses specifically on making automatic insertion aware of comments and strings.

Reproduction

With automatic bracket pairing enabled, select C++ in the interview editor.

In the examples below, | represents the caret and is not part of the code.

Line comment

Before typing (:

// note |

Actual result:

// note (|)

Expected result:

// note (|

String literal

Before typing (:

const char* s = "left| ";

Actual result:

const char* s = "left(|) ";

Expected result:

const char* s = "left(| ";

I also reproduced automatic pairing inside a multiline C++ block comment.

These behaviors were reproduced with Chromium against revision 59bde8f. I also inspected web/editor.js and its beforeinput integration at revision 8394d5489630f7ed989cd86835c57647bf7f2e44: the pairing path checks the following character but does not check whether the caret is inside a comment or string.

Proposed behavior

For a collapsed selection, typing (, [, or { inside a recognized comment or string should insert only the typed character.

Outside those contexts, the existing pairing behavior should remain unchanged, including the following-character restriction introduced by #165.

This proposal would preserve:

  • Wrapping selected text with brackets.
  • Typing over an existing closing bracket.
  • Deleting an empty pair with Backspace.
  • The Auto-close setting and its persistence.
  • Existing undo, paste, and IME behavior.

Tracking which closing brackets were automatically inserted is a separate concern and is outside this proposal.

Implementation approach

I propose checking the lexical context at the caret before attempting automatic pair insertion.

The editor already has language-aware tokenization for syntax highlighting and bracket matching. I would first investigate reusing that classification instead of introducing another independent parser.

The check should use the current editor contents and selected language. It also needs to handle partially typed code and caret positions at string or comment boundaries. If the context cannot be determined reliably, the initial implementation would preserve the existing behavior.

When pairing is suppressed, the handler should allow the browser's normal text insertion to proceed. This would avoid introducing a separate editing path for ordinary typing.

Validation

I would add focused helper tests and browser tests covering:

  • Ordinary code where automatic pairing should still occur.
  • Line and block comments where supported by the selected language.
  • Strings, including escaped quotes and supported multiline forms.
  • Caret positions immediately inside and outside comments and strings.
  • Switching languages without reusing stale context.
  • Selected-text wrapping and the Auto-close setting.
  • Undo behavior for both automatic pairing and ordinary insertion.

The browser tests would exercise actual typing in the editor. I would also run the repository's verification script and report any skipped checks.

Scope confirmation

I would like to implement this as a focused follow-up to #85. Does suppressing automatic insertion for collapsed selections inside comments and strings match the intended editor behavior?

Refs #85.

Ngôn ngữ chính
Rust
Star
160
Fork
64
Merge trung bình
1 ngày 12 giờ
Pull request đã merge (30 ngày)
124

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của sysprog21/codetrial

Tất cả issue của sysprog21/codetrial

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.