From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Micha=C5=82?= Nazarewicz Newsgroups: gmane.emacs.bugs Subject: bug#20871: 25.0.50; fill-single-char-nobreak-p does not recognize a single-letter word when it is preceded by an open paren Date: Mon, 19 Aug 2019 15:07:56 +0100 Message-ID: References: <9A9C6F59-CB27-42D1-911E-F027B443B9BE@acm.org> <8336i1p8zd.fsf@gnu.org> <83mug8nut2.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="230431"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , mbork@mbork.pl, 20871@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Aug 19 16:09:15 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hziLS-000xnr-Vg for geb-bug-gnu-emacs@m.gmane.org; Mon, 19 Aug 2019 16:09:15 +0200 Original-Received: from localhost ([::1]:51844 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1hziLR-00030L-Ix for geb-bug-gnu-emacs@m.gmane.org; Mon, 19 Aug 2019 10:09:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33600) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1hziLH-0002uR-NU for bug-gnu-emacs@gnu.org; Mon, 19 Aug 2019 10:09:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hziLG-0005Ky-J4 for bug-gnu-emacs@gnu.org; Mon, 19 Aug 2019 10:09:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51488) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hziLG-0005Kk-Fi for bug-gnu-emacs@gnu.org; Mon, 19 Aug 2019 10:09:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hziLG-0008ID-8i for bug-gnu-emacs@gnu.org; Mon, 19 Aug 2019 10:09:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Micha=C5=82?= Nazarewicz Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 19 Aug 2019 14:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20871 X-GNU-PR-Package: emacs Original-Received: via spool by 20871-submit@debbugs.gnu.org id=B20871.156622369531824 (code B ref 20871); Mon, 19 Aug 2019 14:09:02 +0000 Original-Received: (at 20871) by debbugs.gnu.org; 19 Aug 2019 14:08:15 +0000 Original-Received: from localhost ([127.0.0.1]:60309 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hziKV-0008HE-8Y for submit@debbugs.gnu.org; Mon, 19 Aug 2019 10:08:15 -0400 Original-Received: from mail-wm1-f52.google.com ([209.85.128.52]:55479) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hziKT-0008H0-1X for 20871@debbugs.gnu.org; Mon, 19 Aug 2019 10:08:13 -0400 Original-Received: by mail-wm1-f52.google.com with SMTP id f72so1752247wmf.5 for <20871@debbugs.gnu.org>; Mon, 19 Aug 2019 07:08:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=5ohUhnTddAcdVnGV6QxXxdN+unihNJYkYNhtPHRptKw=; b=C72TmLEf6tCzgH/y3iYxG7X5lHyKyIAiZI/z7Cp7v6bawI7tp7lLL/MJrgVMZ03azt k2DM0ODK+pZUTN67+3+Zt0mxLj8lsPTv1v6GsDsPp64GTnozxOOWP8/N2Z+ub3+D28q4 95WY50gUIypgxGAwH6Fukh0pq3RBdW+8aIgOFM4GrPH8zCWm+dyQlnV6fCBGchsAxeDp bbI7IEafKTtqQIqkTpU1DxQ++orBvfqlZsn1xce3CNUQWbpgOiBWiAPEp2H+Ge0oksuj cZBfKaVDhcxfvFg7e/JRwqiNdcPaaT3NxRlod266swn1vZnnFSOsYkCnyshFvHsrx38K hw4g== X-Gm-Message-State: APjAAAXCkTrP9JYhBDwT1l7ad4nprHZANtOZ+eqoDlxyd/7J87o8b9Br XVxXxk+U18tADnZJdRnSDVzHMP+Zmp5CBVvHb1o= X-Google-Smtp-Source: APXvYqxBWOqdmcCGRfQgCdepNUG2tpxzw07MP+aG3UD8IKmAMvv1Zk77kmLJPecKZ6OdxapryRcIbxET8I31l2qYSBQ= X-Received: by 2002:a05:600c:2102:: with SMTP id u2mr21367640wml.105.1566223687285; Mon, 19 Aug 2019 07:08:07 -0700 (PDT) In-Reply-To: <83mug8nut2.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:165379 Archived-At: On Sat, 17 Aug 2019 at 07:57, Eli Zaretskii wrote: > My problem is conceptual rather than practical. Since in , e.g., > English it is okay to break a line after single-letter words, whereas > in Polish it is not, I wonder how can we have a single function > satisfy both requirements. We would need some option, and then we > would need to decide what is the trigger for changing the value of > that option -- it could be the user, or the language environment, or > maybe something else. This sounds related to what we=E2=80=99ve discussed when I was working on t= he Unicode casing rules. There also some rules need to be enabled only if the text is in a certain language. Having buffer-local variable or a text-property defining language of the buffer sounds to me like the only possible solution if we want this fully automatic. > tildify.el explicitly says that its defaults are for a specific > language, so I don't think it solves the problem that bothers me, as > described above. This is why I originally suggested a separate > function -- having that is equivalent to having an option which > determines a behavior that depends on the language. To be honest, I don=E2=80=99t understand the issue. If having separate functions is equivalent to having an option than users already have an option: either add the function to =E2=80=98fill-nobreak-predicate=E2=80=99= or not. As discussed previously, =E2=80=98fill-single-char-nobreak-p=E2=80=99 and =E2=80=98fill-polish-nobreak-p=E2=80=99 and serve pretty much the same purp= ose. When I wrote the former I had Polish typography in mind and obviously the latter is meant to handle the same case. As such, having those two functions don=E2=80=99t provide much option to the user. > I'm also okay with extending tildify.el to support more than just > Czech rules, but that's a separate issue. The differences between Czech and Polish can largely be ignored. The regex in tildify.el will work for Polish just fine. The character group simply lists all existing one-letter Czech words which is superset of one-letter Polish words. At the same time, those two languages are, to my knowledge, the only which observe this typography rule, so there=E2=80=99s no need to add suppo= rt for more. =E2=80=98fill-single-char-nobreak-p=E2=80=99 matches any single-letter word= s just for the sake of simplicity plus it then works with other languages, which may have different one-letter words, if someone wishes to use it with them. --=20 Best regards =E3=83=9F=E3=83=8F=E3=82=A6 =E2=80=9C=F0=9D=93=B6=F0=9D=93=B2=F0=9D=93=B7= =F0=9D=93=AA86=E2=80=9D =E3=83=8A=E3=82=B6=E3=83=AC=E3=83=B4=E3=82=A4=E3=83= =84 =C2=ABIf at first you don=E2=80=99t succeed, give up skydiving=C2=BB