From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Line wrap reconsidered Date: Sun, 19 Jul 2020 17:52:24 +0300 Message-ID: <83sgdnh80n.fsf@gnu.org> References: <92FF4412-04FB-4521-B6CE-52B08526E4E5@gmail.com> <878shfsq35.fsf@gnus.org> <83imgivjak.fsf@gnu.org> <83lfletr03.fsf@gnu.org> <4895C6EE-5E1F-44BF-93C1-CC5F7C096F73@gmail.com> <9766BA3D-B8F9-456B-9F59-60D21B86E390@gmail.com> <83sgfls2ul.fsf@gnu.org> <83v9kgq6jy.fsf@gnu.org> <5E75D1E2-8BFF-45DA-A643-40DBD5784508@gmail.com> <83r1v3qlel.fsf@gnu.org> <83blm6lzj3.fsf@gnu.org> <83pnakj8fs.fsf@gnu.org> <83k10sj60l.fsf@gnu.org> <0B30F8C8-9B8F-4FCB-B9FB-1B5A0E993CDB@gmail.com> <838sgjzij2.fsf@gnu.org> <83sgerxmbs.fsf@gnu.org> <83bllfx80g.fsf@gnu.org> <2F9680C4-11D8-4092-A485-2590AAF62CC9@gmail.com> <837dw2ykeb.fsf@gnu.org> <43C485E7-A9E7-448A-B1EC-9085F83670E9@gmail.com> <83365woafv.fsf@gnu.org> <214EBF50-8BEE-4935-9DE9-526E82F7D85C@gmail.com> <838sfhi6hm.fsf@gnu.org> <3A15EC3E-78EC-40BA-8841-47B3F9749092@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31835"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, emacs-devel@gnu.org To: Yuan Fu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jul 19 16:53:04 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jxAga-0008DD-JI for ged-emacs-devel@m.gmane-mx.org; Sun, 19 Jul 2020 16:53:04 +0200 Original-Received: from localhost ([::1]:47116 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jxAgZ-0002rG-Ko for ged-emacs-devel@m.gmane-mx.org; Sun, 19 Jul 2020 10:53:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42036) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jxAg5-0002QX-Hy for emacs-devel@gnu.org; Sun, 19 Jul 2020 10:52:33 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45589) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jxAg5-0006b3-7U; Sun, 19 Jul 2020 10:52:33 -0400 Original-Received: from [176.228.60.248] (port=1551 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jxAg4-0002gm-Jx; Sun, 19 Jul 2020 10:52:33 -0400 In-Reply-To: <3A15EC3E-78EC-40BA-8841-47B3F9749092@gmail.com> (message from Yuan Fu on Sat, 18 Jul 2020 13:14:15 -0400) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:253102 Archived-At: > From: Yuan Fu > Date: Sat, 18 Jul 2020 13:14:15 -0400 > Cc: Lars Ingebrigtsen , > emacs-devel@gnu.org > > > A minor stylistic nit: I'd prefer the if - elseif clauses to yield the > > relevant character, and then apply CHAR_HAS_CATEGORY only once to that > > character at the end. (It is generally better to have only one return > > point from a function, especially when the function is short. If > > nothing else, it makes debugging easier.) > > I changed the it, do you code below this is ok? > > if (ch == 0) > return false; > else > return CHAR_HAS_CATEGORY(ch, cat); Yes. Or any of the variants shown by Stefan. > >> if (it->line_wrap == WORD_WRAP && it->area == TEXT_AREA) > >> { > >> - if (IT_DISPLAYING_WHITESPACE (it)) > >> - may_wrap = true; > >> - else if (may_wrap) > >> + /* Can we wrap here? */ > >> + if (may_wrap && char_can_wrap_before (it)) > > > > Likewise here. > > > In both can_wrap_before and can_wrap_after, I have a short circuit for the case when cjk_word_wrap is nil: > > if (!Vcjk_word_wrap) > return IT_DISPLAYING_WHITESPACE (it); > > That should guarantee the old behavior when cjk_word_wrap is nil, if that’s what you are asking about. I've seen that, but what bothers me is not this. It's the fact that the old code didn't test may_wrap, whereas the new code does. > >> + DEFVAR_BOOL("cjk-word-wrap", Vcjk_word_wrap, > >> + doc: /* Non-nil means wrap after CJK chracters. > > > > This is unclear. Does it mean after _any_ CJK character, or just > > after some? And if the latter, which ones? > > I added more detail and hopefully they are clearer now. Looks much better, thanks.