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

More accurate modified line counts

オープン
#347 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
停滞
領域
tooling

調査の方向性

まず、提案の行置換がどのように生成され、変更された行がどのように数えられるかをたどり、issue にある入れ子からモジュールレベルまでの Scheme の例を再現します。移動された行を変更された行とどのように区別すべきかを判断し、その結果のカウントが意図された pull request の規模および --max-modified-lines の動作と一致することを検証します。

索引モデルが issue の本文から書いたものです。

説明

bug

If Resyntax suggests replacing this code:

(define (foo)
  (define (bar)
    42)
  ... hundreds of lines of code ...)

With this code:

(define (foo)
  ... hundreds of lines of code ...)

(define (bar)
    42)

Then something odd happens with modified line counting. GitHub will say that the diff removes two lines (the original nested bar definition) and adds three lines (the new, module-level bar definition). Resyntax, however, will say that hundreds of lines of code were modified because everything in foo after the original nested bar definition has to be included in the line replacement. Using ~focus-replacement-on doesn't help either, because we're not changing an expression within a nested context: we're moving it to a different context entirely. This causes --max-modified-lines to appear to disagree with the GitHub pull request size.

A possible fix might be to inspect the line-replacement generated by a suggestion and do something a bit smarter to determine whether any lines were simply moved instead of actually modified.

主要言語
Racket
スター
70
フォーク
11
30日以内にマージされた PR はありません

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

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

jackfirth/resyntax のほかの issue

jackfirth/resyntax の issue をすべて見る

似ている issue

DevTools の issue をもっと見る

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

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