Incremental writer emits LF for a rewritten block or separator in a CRLF document

Đang mở
  • Có gì không ổn?
#966 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

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

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
78/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
rust
Lĩnh vực
backend

Hướng nghiên cứu

Start in crates/pampa/src/writers/incremental.rs, especially write_block_to_string and compute_separator; compare their freshly generated text with copied text on a CRLF input. The issue gives a reproduction shape and a suggested approach: detect the original document’s line endings and preserve them for rewritten blocks and synthesized separators. Done when the output keeps CRLF throughout after a block rewrite, while existing inline splicing still works.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Reproduction

At tag v0.37.0 (and on main at a37801fe4), on a CRLF (\r\n) document, make an edit that forces the incremental writer to rewrite a block from scratch rather than copy or splice it (for example, appending a brand-new paragraph with no original counterpart, or editing a paragraph in a way the inline-splice safety check rejects). Compute quarto_ast_reconcile::compute_reconciliation(&original, &edited) and call pampa::writers::incremental::incremental_write.

Minimal shape:

First paragraph.\r\n\r\nLast paragraph.\r\n

(all \r\n). After an edit that forces a block-level rewrite, the rewritten block and the separator immediately around it come out with \n instead of \r\n, while the rest of the file keeps \r\n.

A simpler case — editing a word in place inside a CRLF paragraph, where the result is handled by inline splicing rather than a full block rewrite — keeps \r\n correctly, because splicing copies bytes from the original rather than writing fresh text.

Observed vs expected

Observed: a rewritten block, and the separators the incremental writer has to synthesize around it (rather than copy from the original gap), use bare \n, producing a document with mixed line endings.

Expected: a rewritten block and its separators use the same line-ending convention as the rest of the document.

Cause

The standard QMD writer (crates/pampa/src/writers/qmd.rs) always emits bare \n — reasonably so, since most callers want platform-independent output. The incremental writer calls that standard writer whenever it has to rewrite a block from scratch (write_block_to_string in crates/pampa/src/writers/incremental.rs), and falls back to a literal "\n" separator in compute_separator whenever it can't copy the original gap verbatim (one of the two adjacent entries is a rewrite). Neither function looks at the original document's line-ending convention.

Suggested fix

Detect the document's line-ending convention once from original_qmd (e.g. "does it contain \r\n"), and when a block must be rewritten or a separator must be synthesized, convert/emit \r\n instead of \n in that case. The standard writer itself does not need to change — only the incremental writer's own freshly-generated text.

Ngôn ngữ chính
Rust
Star
302
Fork
22
Merge trung bình
5 giờ 8 phút
Pull request đã merge (30 ngày)
220

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 quarto-dev/q2

Tất cả issue của quarto-dev/q2

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.