From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii 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: Sun, 17 Apr 2016 19:49:35 +0300 Message-ID: <83r3e49o4g.fsf@gnu.org> References: <87y4jchwog.fsf@mbork.pl> <87wpywhwa8.fsf@mbork.pl> <87shyku4jt.fsf@mbork.pl> <8337qkb7v7.fsf@gnu.org> <87k2jwtfkj.fsf@mbork.pl> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1460911882 6902 80.91.229.3 (17 Apr 2016 16:51:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 17 Apr 2016 16:51:22 +0000 (UTC) Cc: 20871@debbugs.gnu.org To: Marcin Borkowski Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Apr 17 18:51:12 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1arpuh-0001XS-Pb for geb-bug-gnu-emacs@m.gmane.org; Sun, 17 Apr 2016 18:51:11 +0200 Original-Received: from localhost ([::1]:48882 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1arpuh-0005xH-7H for geb-bug-gnu-emacs@m.gmane.org; Sun, 17 Apr 2016 12:51:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40156) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1arpud-0005u7-50 for bug-gnu-emacs@gnu.org; Sun, 17 Apr 2016 12:51:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1arpuY-0003qt-Ao for bug-gnu-emacs@gnu.org; Sun, 17 Apr 2016 12:51:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54501) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1arpuY-0003qo-7h for bug-gnu-emacs@gnu.org; Sun, 17 Apr 2016 12:51:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1arpuY-0002M3-0T for bug-gnu-emacs@gnu.org; Sun, 17 Apr 2016 12:51:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Apr 2016 16:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20871 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20871-submit@debbugs.gnu.org id=B20871.14609118038983 (code B ref 20871); Sun, 17 Apr 2016 16:51:01 +0000 Original-Received: (at 20871) by debbugs.gnu.org; 17 Apr 2016 16:50:03 +0000 Original-Received: from localhost ([127.0.0.1]:38605 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1arpta-0002Kp-QL for submit@debbugs.gnu.org; Sun, 17 Apr 2016 12:50:03 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:49035) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1arptZ-0002KF-Ch for 20871@debbugs.gnu.org; Sun, 17 Apr 2016 12:50:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1arptP-0003h0-7h for 20871@debbugs.gnu.org; Sun, 17 Apr 2016 12:49:56 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51720) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1arptP-0003gw-4N; Sun, 17 Apr 2016 12:49:51 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4707 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1arptO-0001Va-Du; Sun, 17 Apr 2016 12:49:50 -0400 In-reply-to: <87k2jwtfkj.fsf@mbork.pl> (message from Marcin Borkowski on Sun, 17 Apr 2016 17:34:04 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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: 208.118.235.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:116570 Archived-At: > From: Marcin Borkowski > Cc: 20871@debbugs.gnu.org > Date: Sun, 17 Apr 2016 17:34:04 +0200 > > In Polish typography, it is customary to foribid line breaks after > one-letter words (and we have quite a few of them: a, i, o, w, z - they > are conjunctions or prepositions). And it is not uncommon to have > a combination of them with a parenthesized remark or something like > that. That's why allowing a linebreak after, say "(a" when writing > something in Polish (like an email, for instance) is a bug IMO. > > > See, the function in question, fill-single-char-nobreak-p, is > > documented as a possible value to use in the fill hook, for a very > > specific purpose. If you are saying that it doesn't fulfill that > > purpose well enough, please show a use case where it fails to do that. > > At least the situation you described, with " (a", doesn't seem to fit > > the use cases which this function is supposed to cover, since the > > parenthesis makes a 2-character sequence, whereas > > fill-single-char-nobreak-p aims to support isolated one-character > > words. > > I see. So you suggest that instead of patching > `fill-single-char-nobreak-p' I should have provided another function, > customized for Polish? Yes, I think so. There's already fill-french-nobreak-p, why shouldn't there be a Polish predicate? > In fact, I'm not so sure about it. The whole point of such functions > (as I see it) is help write texts in natural langauges. It seems > unnatural to treat words preceded by a space and by a parenthesis *in > a natural language* differently, no? Not necessarily: that space that precedes the word is by itself a line-breaking opportunity. IOW, Emacs will break before 'a' in " a", and the penalty will be only 1 character. By contrast, breaking before the parenthesis in your case will yield a penalty of 2 characters, which is a different tradeoff, worthy of asking the user explicitly to agree to. The default value of fill-nobreak-predicate is nil for a reason. Thanks.