Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Avoid automatic bracket pairing inside comments and strings

オープン
  • 何か問題がありますか？
#307 コメント 2 件 リアクション 0 件 担当者 1 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@Jonathas2127 がすでに取り組んでいます。

2026年10月14日 から。

  • #308 @Jonathas2127 による — オープン

評価

この issue はまだ評価されていません。

説明

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.

主要言語
Rust
スター
160
フォーク
64
平均マージ
1日 9時間
マージ済み PR（30日）
114

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

sysprog21/codetrial のほかの issue

sysprog21/codetrial の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。