คำถามติดแท็ก line-break

10
ฉันจะป้องกันไม่ให้สายยาวมาก ๆ ทำให้ Emacs ทำงานช้าได้อย่างไร
ฉันเห็นประสิทธิภาพที่หลากหลายขึ้นอยู่กับจำนวนบรรทัดใหม่ที่มีในไฟล์ที่ฉันกำลังเยี่ยมชม นี่คือตัวอย่าง ฉันมีไฟล์ JSON สองไฟล์: $ wget https://github.com/Wilfred/ReVo-utilities/blob/a4bdc40dd2656c496defc461fc19c403c8306d9f/revo-export/dictionary.json?raw=true -O one_line.json $ python -m json.tool <one_line.json >pretty_printed.json นี่เป็นไฟล์ JSON สองไฟล์ที่มีเนื้อหาเดียวกัน one_line.jsonคือ 18MiB ของ JSON โดยไม่มีการขึ้นบรรทัดใหม่ pretty_printed.jsonมีการขึ้นบรรทัดใหม่และเพิ่มช่องว่างทำให้ 41MiB อย่างไรก็ตามไฟล์ที่ใหญ่กว่าที่แบ่งออกเป็นหลายบรรทัดนั้นเร็วกว่ามากที่จะเปิดใน Emacs ทั้งในโหมด Javascript และโหมด Fundamental ทำไม Emacs ถึงมีประสิทธิภาพต่ำเช่นนี้เนื่องจากมีความยาวน้อยกว่าจริง ๆ ? มีอะไรที่ฉันสามารถทำได้เพื่อปรับปรุงประสิทธิภาพโดยไม่ต้องฟอร์แมตข้อมูลภายนอก Emacs หรือไม่?

2
ทำให้โหมดบรรทัดภาพสามารถทำงานร่วมกับโหมด org ได้มากขึ้น
visual-line-modeมีประโยชน์มากในการตัดบรรทัดที่มีการเปลี่ยนแปลงขนาดหน้าต่างโดยไม่ต้องแทรกบรรทัดใหม่ แต่ในorg-modeนั้นมันครอบคลุมพาดหัวและซอร์สบล็อกซึ่งค่อนข้างน่ารำคาญเล็กน้อย ดังนั้นคำถามของฉันมาที่นี่: ฉันจะปิดโหมดแสดงภาพสำหรับส่วนหัวขององค์กรและบล็อกแหล่งที่มาอย่างถาวรในโหมดองค์กรได้อย่างไร

4
การแก้ไขไฟล์ด้วยหนึ่งประโยคต่อหนึ่งบรรทัด
พื้นหลังเล็กน้อย ฉันพยายามที่จะรุ่นควบคุมเอกสารน้ำยางของฉันและประสิทธิผลของโครงการนี้จะได้รับการปรับปรุงอย่างมากถ้าผมนำมาใช้เป็นหนึ่งประโยคต่อบรรทัดวิธีการ ตัวอย่างเช่นต่อไปนี้เป็นเอกสารของฉันที่มีลักษณะเป็นอย่างไร Some text here. New stencence on the same paragraph. Some more text, still on the same paragraph. This is another paragraph. คำถามของฉันง่าย ฉันสามารถทำการ / ปรับปรุงโดยอัตโนมัติด้วย Emacs ได้เท่าใด จุดสองจุดต่อไปนี้เป็นสิ่งที่ฉันมีอยู่ในใจ ประโยคของฉันมีความยาวดังนั้นฉันจึงจำเป็นต้องพันเส้นโดยไม่ต้องเติมพวกเขาจริง ๆ นั่นคือประโยคที่ยาวมากจำเป็นต้องแสดงบนหลาย ๆ บรรทัดบนหน้าจอของฉัน แต่มันต้องเป็นบรรทัดเดียวในไฟล์“ .tex” สิ่งนี้ควรทำในวิธีที่ไม่ห่อหุ้มสมการ visual-line-modeล้อมที่ความกว้างหน้าต่างที่กว้างเกินไป ฉันต้องการบางสิ่งที่ล้อมรอบเส้นและจำกัดความกว้างของพวกเขาไว้ที่ 80 ตัวอักษรหรือมากกว่านั้น fill-paragraphปกติแล้วจะชอบแต่โดยไม่ทำลายเส้นในไฟล์ ฉันสามารถแบ่งบรรทัดด้วยตนเองหลังจากแต่ละประโยค แต่มันจะดีกว่าถ้าฉันสามารถกำหนดค่าfill-paragraph(หรืออาจจะauto-fill-mode) ให้ใส่หนึ่งประโยคต่อบรรทัดเช่นกัน

2
จะป้องกันไม่ให้ช้าลงเมื่อกระบวนการที่ด้อยกว่าสร้างเส้นยาวได้อย่างไร
ฉันใช้ Emacs กับ Geiser เพื่อแฮกรหัส Scheme ขณะที่ฉันเล่นไปรอบ ๆ ใน REPL บางครั้งฉันประเมินนิพจน์ที่ให้ผลลัพธ์จำนวนมากซึ่งมักจะอยู่ในหนึ่งบรรทัด ตัวอย่างเช่นฉันเพิ่งเล่นกับ SRFI-41 (สตรีม) และสร้างสตรีมตัวละครจากไฟล์ขนาดใหญ่ จากนั้นฉันบังคับสตรีมและ Geiser แก้ไขเนื้อหาทั้งหมดของไฟล์เป็นสตรีมอักขระลงในบัฟเฟอร์ของฉัน เกือบจะในทันที Emacs ต้องหยุดชะงักเหมือนตัวละครมากขึ้นเรื่อย ๆ ที่ต่อท้ายบรรทัดเอาท์พุทและไม่ว่าฉันจะกดค้างไว้นานเท่าไหร่C-gหรือC-c C-cไม่สามารถหยุด Emacs (หรือ Geiser) ได้ สิ่งนี้ทำให้เซสชัน Emacs ของฉันทั้งหมดเสียหายเนื่องจากตอนนี้ Emacs ไม่สนใจอินพุตของฉันอย่างสมบูรณ์โดยคิดว่าจำเป็นต้องให้ความสำคัญกับการพิมพ์สตรีมตัวละครขนาดใหญ่นี้ในบรรทัดเดียวให้เป็นบัฟเฟอร์ Geiser REPL ที่ไม่ตอบสนอง มีสิ่งที่ฉันสามารถทำได้เพื่อปกป้องเซสชั่น Emacs ของฉันจากความอยากรู้อยากเห็นของฉันทำลาย? (เพราะเหตุใด Emac จึงช้ามากเมื่อแสดงเส้นที่ยาวมากอยู่แล้ว) ฉันสามารถกำหนดขีด จำกัด ของเส้นยาวและบอก Emacs ได้ว่าไม่เป็นไรที่จะไม่พยายามแสดงเส้นที่ยาวมาก ๆ ?

2
ฉันจะแบ่งย่อหน้าออกเป็นหนึ่งบรรทัดต่อประโยค แต่ยังคงซ่อนอยู่ได้อย่างไร?
สิ่งนี้คล้ายกับการแก้ไขไฟล์ที่มีหนึ่งประโยคต่อบรรทัด (ในฟังก์ชั่นรวมถึงแรงจูงใจ) แต่ฉันต้องการที่จะมีย่อหน้าที่สมบูรณ์และลื่นไหลมากกว่าที่จะเห็นภาพทุกประโยค ฉันอยากมีโหมดย่อยที่เมื่อใช้งานจะเข้าร่วมสายตาบรรทัดจากวรรคเดียวกัน (ไม่แยกจากกันโดย\n\nหรือparagraph-separateหรือ ... ) และพฤติกรรมการเปิดใช้งานแล้ว (อาจจะมาจากvisual-line-mode) \nที่จะตัดสายโดยไม่ต้องใส่ มีโหมดดังกล่าวหรือไม่? ถ้าไม่ฉันจะไปเกี่ยวกับกระบวนการแก้ไขคุณสมบัติการแสดงผลของย่อหน้าเพื่อให้ได้ผลลัพธ์อย่างไร (หลังจากทั้งหมดนี่คือ crux ของโหมดดังกล่าวและสามารถพัฒนาได้จากข้อมูลโค้ด)

2
วิธีจัดการบรรทัดถัดไปในแมโครแป้นพิมพ์
ฉันสร้างแมโครคีย์บอร์ดเพื่อรวมบรรทัดในบัฟเฟอร์โดยใช้: F3 C-n M-x join-line RET F4. มันทำงานได้ดียกเว้นเมื่อบรรทัดยาวเกินไปและเริ่มตัด - ซึ่งทำให้แมโครนี้ขึ้นอยู่กับความกว้างของเฟรม next-lineดูเหมือนจะไม่ไปที่บรรทัดจริงถัดไป แต่ไปที่ส่วน "การตัด" ของบรรทัดปัจจุบัน จะแก้ไขปัญหานั้นได้อย่างไร

4
วิธีแปลงชุดบรรทัดเป็นรายการ HTML ที่ใช้งานได้
ตอนนี้นี่เป็นงานที่ฉันพบเจอได้ง่ายกว่าในบางอย่างเช่น gedit เพราะฉันสามารถแทนที่ "\ n" (ตัวแบ่งบรรทัด) ด้วย "</li> \ n <li>" จากนั้นฉันก็มีรายการ หนึ่งในสิ่งเล็กน้อยที่ฉันไม่สามารถทำได้ใน Emacs อย่างรวดเร็ว แต่สิ่งที่ฉันใช้บ่อยมาก

1
ทำให้ org-blank-before-new-entry แยกความแตกต่างระหว่างรายการสิ่งที่ต้องทำและเค้าร่างข้อความหรือไม่
เช่นเดียวกับพวกเราหลายคนฉันใช้โหมด org สำหรับสองสิ่งที่ต่างกัน: เป็นผู้จัดการรายการสิ่งที่ต้องทำ เป็นตัวห้อยข้อความ ฉันต้องการให้บรรทัดว่างของฉันทำงานแตกต่างกันตามบริบท รายการสิ่งที่ต้องทำ: ไม่มีบรรทัดว่าง เค้าร่างข้อความ: แทรก 1 บรรทัดว่างโดยอัตโนมัติเมื่อข้อความที่ไม่ใช่ส่วนหัวนำหน้าหัวเรื่อง กล่าวอีกนัยหนึ่งเมื่อฉันทำรายการสิ่งที่ต้องทำเมื่อฉันมีหัวเรื่องเป็นจำนวนมากในแถวฉันไม่ต้องการให้ตัวแบ่งบรรทัดหลงทางระหว่างพวกเขา โหมดรายการสิ่งที่ต้องทำไม่มีการแบ่งบรรทัด: * Organize Party [33%] ** TODO Call people [1/2] *** TODO Peter *** DONE Sarah ** TODO Buy food ** DONE Talk to neighbor อย่างไรก็ตามเมื่อฉันเขียนข้อความฉันต้องการให้ตัวแบ่งบรรทัดเพื่อประโยชน์ในการมองเห็นพื้นที่ว่าง / อ่านง่าย โหมดเค้าร่างบรรทัดว่างก่อนส่วนหัว: * Heading This is a document that has …

3
เดินต่อไปจนสุดบรรทัด
ค่าเริ่มต้นของการเชื่อมโยงคีย์C-a/C-eนั้นมีเพียงสิ่งเดียวเท่านั้นย้ายไปที่จุดเริ่มต้น / สิ้นสุดของบรรทัดมีแพ็คเกจใด ๆ ที่สามารถทำให้ Emacs ทำหน้าที่ดังนี้ หากฉันไม่ได้อยู่ที่ท้ายบรรทัดC-eจะไปที่ท้ายบรรทัดมิฉะนั้นให้ไปจบบรรทัดถัดไป ถ้าฉันไม่อยู่ที่จุดเริ่มต้นของบรรทัดC-aจะไปที่จุดเริ่มต้นของบรรทัดมิฉะนั้นไปที่จุดเริ่มต้นของบรรทัดถัดไป ประเด็นก็คือคุณก็สามารถให้การกดปุ่มC-a/eเพื่อไปยังจุดเริ่มต้น / C-n/pท้ายของทุกสายโดยไม่ต้องย้ายนิ้วของคุณเพื่อการเข้าถึง และด้วยคำนำหน้า ( C-u) พวกเขาจะไปที่จุดเริ่มต้น / สิ้นสุดของบรรทัดในทิศทางตรงกันข้าม
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.