From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: use-hard-newlines Date: Sat, 29 Aug 2015 20:23:28 +0000 Message-ID: References: <55E00167.8030300@online.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=94eb2c0b7f66b814ad051e78f92e X-Trace: ger.gmane.org 1440879824 31763 80.91.229.3 (29 Aug 2015 20:23:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 29 Aug 2015 20:23:44 +0000 (UTC) To: =?UTF-8?Q?Andreas_R=C3=B6hler?= , emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 29 22:23:44 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZVmf9-0004j8-JV for ged-emacs-devel@m.gmane.org; Sat, 29 Aug 2015 22:23:43 +0200 Original-Received: from localhost ([::1]:54487 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVmf8-0000LR-R8 for ged-emacs-devel@m.gmane.org; Sat, 29 Aug 2015 16:23:42 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39408) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVmf5-0000Kt-EK for emacs-devel@gnu.org; Sat, 29 Aug 2015 16:23:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZVmf4-0001AC-IZ for emacs-devel@gnu.org; Sat, 29 Aug 2015 16:23:39 -0400 Original-Received: from mail-yk0-x22e.google.com ([2607:f8b0:4002:c07::22e]:32854) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVmf4-00019w-D6 for emacs-devel@gnu.org; Sat, 29 Aug 2015 16:23:38 -0400 Original-Received: by ykdz80 with SMTP id z80so45662234ykd.0 for ; Sat, 29 Aug 2015 13:23:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=IRxJZW4WSld9Q9dmaRa75TMnBnwAST2wGIF9mfrv1RA=; b=0QC9f2Dd3h0nkyLlM/OZSoXkC7WewwQpD8JLyXLGU4/oFprn67vnymxIG4wLKuzciB y6ThPhmYq04jwXwl4Zxg3aI3xXqLCQydva5q8zrvzk9sD4qQSGu8w8YQesOjVDcZIUIu ygGy4ckBhuDTAIPIXXZFHAIygIT3mXW2oUIpN7mTqOXUpgEDKzhg9Cr6sH8vC08TuXfI r59RrYPlria0wS8Xqfbsj3s1CQARU7/5ZZt7QVkzE6RlWJimzZmgiwgItjUzlsg3YdoA dTNOif9coi1l7Rk/06tEaFYOqjEJ3P6opmeyV+jdc4Clq1hQPMH6/uQpyPotaF+RgChs jz+w== X-Received: by 10.129.153.1 with SMTP id q1mr12325376ywg.137.1440879818050; Sat, 29 Aug 2015 13:23:38 -0700 (PDT) In-Reply-To: <55E00167.8030300@online.de> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4002:c07::22e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:189300 Archived-At: --94eb2c0b7f66b814ad051e78f92e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Andreas R=C3=B6hler schrieb am Fr., 28. Aug. 20= 15 um 08:47 Uhr: > Hi all, > > is the concept of use-hard-newlines still considered useful? > > Just looking how to simplify fill-paragraph. > > AFAICS it introduces complexity which doesn't contribute, not reallly. > I think the concept of hard newlines is useful, just like the concept of non-breaking spaces. Especially in code comments I often want a line break that is unaffected by fill-paragraph without requiring an empty line. However the current implementation is not optimal because hard newlines rely on a text property instead of a distinct character, so IIUC hard newlines will be lost when saving (except for enriched mode, which seems mostly unused these days). Instead I'd suggest that Emacs observe the LINE SEPARATOR (U+2028) and PARAGRAPH SEPARATOR (U+2029) characters: currently they are displayed as horizontal whitespace instead of line breaks, and fill-paragraph treats both like no-break spaces. Instead, fill-paragraph should treat U+2028 like a soft newline and U+2029 like a hard newline. --94eb2c0b7f66b814ad051e78f92e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Andrea= s R=C3=B6hler <andreas.roeh= ler@online.de> schrieb am Fr., 28. Aug. 2015 um 08:47=C2=A0Uhr:
<= /div>
Hi all,

is the concept of use-hard-newlines still considered useful?

Just looking how to simplify fill-paragraph.

AFAICS it introduces complexity which doesn't contribute, not reallly.<= br>

I think the concept of hard newlines is us= eful, just like the concept of non-breaking spaces. Especially in code comm= ents I often want a line break that is unaffected by fill-paragraph without= requiring an empty line. However the current implementation is not optimal= because hard newlines rely on a text property instead of a distinct charac= ter, so IIUC hard newlines will be lost when saving (except for enriched mo= de, which seems mostly unused these days). Instead I'd suggest that Ema= cs observe the LINE SEPARATOR (U+2028) and PARAGRAPH SEPARATOR (U+2029) cha= racters: currently they are displayed as horizontal whitespace instead of l= ine breaks, and fill-paragraph treats both like no-break spaces. Instead, f= ill-paragraph should treat U+2028 like a soft newline and U+2029 like a har= d newline.
--94eb2c0b7f66b814ad051e78f92e--