From unknown Fri Jun 20 07:09:20 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#13399 <13399@debbugs.gnu.org> To: bug#13399 <13399@debbugs.gnu.org> Subject: Status: 24.3.50; Word-wrap can't wrap at zero-width space U-200B Reply-To: bug#13399 <13399@debbugs.gnu.org> Date: Fri, 20 Jun 2025 14:09:20 +0000 retitle 13399 24.3.50; Word-wrap can't wrap at zero-width space U-200B reassign 13399 emacs submitter 13399 martin rudalics severity 13399 wishlist thanks From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 10 03:30:18 2013 Received: (at submit) by debbugs.gnu.org; 10 Jan 2013 08:30:18 +0000 Received: from localhost ([127.0.0.1]:52655 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtDWc-0002Bn-E0 for submit@debbugs.gnu.org; Thu, 10 Jan 2013 03:30:17 -0500 Received: from eggs.gnu.org ([208.118.235.92]:40087) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtDW9-0002AC-FL for submit@debbugs.gnu.org; Thu, 10 Jan 2013 03:29:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TtDW2-0002fC-Jm for submit@debbugs.gnu.org; Thu, 10 Jan 2013 03:29:36 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-101.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, USER_IN_WHITELIST autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:42877) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtDW2-0002ep-Gt for submit@debbugs.gnu.org; Thu, 10 Jan 2013 03:29:34 -0500 Received: from eggs.gnu.org ([208.118.235.92]:51440) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtDW0-0002K8-FN for bug-gnu-emacs@gnu.org; Thu, 10 Jan 2013 03:29:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TtDVz-0002aV-H1 for bug-gnu-emacs@gnu.org; Thu, 10 Jan 2013 03:29:32 -0500 Received: from mout.gmx.net ([212.227.17.20]:50691) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtDVz-0002XJ-7p for bug-gnu-emacs@gnu.org; Thu, 10 Jan 2013 03:29:31 -0500 Received: from mailout-de.gmx.net ([10.1.76.10]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MPKAQ-1TxbEe3qUK-004SMi for ; Thu, 10 Jan 2013 09:29:28 +0100 Received: (qmail invoked by alias); 10 Jan 2013 08:29:28 -0000 Received: from 62-47-38-101.adsl.highway.telekom.at (EHLO [62.47.38.101]) [62.47.38.101] by mail.gmx.net (mp010) with SMTP; 10 Jan 2013 09:29:28 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/oGrRL5yLogvhh56hg+m+JVZASFkz2Li2l4mlt/z eYOUdIPC53mLRY Message-ID: <50EE7BE5.2060806@gmx.at> Date: Thu, 10 Jan 2013 09:29:25 +0100 From: martin rudalics MIME-Version: 1.0 To: Bug-Gnu-Emacs Subject: 24.3.50; Word-wrap can't wrap at zero-width space U-200B Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -4.2 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) With emacs -Q evaluate (with-current-buffer (get-buffer-create "*foo*") (dotimes (i 1000) (insert "1234=E2=80=8B")) ; U-200B (setq word-wrap t) (display-buffer "*foo*")) where the character after 1234 is a zero-width space character with unicode code point U-200B. As can be seen in the window showing *foo*, lines are not regularly wrapped at that character. Doing (with-current-buffer (get-buffer-create "*foo*") (dotimes (i 1000) (insert "1234 ")) (setq word-wrap t) (display-buffer "*foo*")) instead wraps lines as expected. Observed with GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600) of 2013-01-07 on MACHNO martin From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 10 14:14:57 2013 Received: (at 13399) by debbugs.gnu.org; 10 Jan 2013 19:14:57 +0000 Received: from localhost ([127.0.0.1]:54451 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtNaa-0001J4-NZ for submit@debbugs.gnu.org; Thu, 10 Jan 2013 14:14:57 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:34231) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtNaZ-0001Iq-2L for 13399@debbugs.gnu.org; Thu, 10 Jan 2013 14:14:56 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MGF00M00C0S2D00@a-mtaout20.012.net.il> for 13399@debbugs.gnu.org; Thu, 10 Jan 2013 21:14:46 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MGF00LLUC4LUO60@a-mtaout20.012.net.il>; Thu, 10 Jan 2013 21:14:46 +0200 (IST) Date: Thu, 10 Jan 2013 21:15:04 +0200 From: Eli Zaretskii Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B In-reply-to: <50EE7BE5.2060806@gmx.at> To: martin rudalics Message-id: <83hamohmtj.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: QUOTED-PRINTABLE X-012-Sender: halo1@inter.net.il References: <50EE7BE5.2060806@gmx.at> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Thu, 10 Jan 2013 09:29:25 +0100 > From: martin rudalics > > With emacs -Q evaluate > > (with-current-buffer (get-buffer-create "*foo*") > (dotimes (i 1000) > (insert "1234​")) ; U-200B > (setq word-wrap t) > (display-buffer "*foo*")) > > where the character after 1234 is a zero-width space character with > unicode code point U-200B. As can be seen in the window showing *foo*, > lines are not regularly wrapped at that character. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4980] X-Debbugs-Envelope-To: 13399 Cc: 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.7 (/) > Date: Thu, 10 Jan 2013 09:29:25 +0100 > From: martin rudalics >=20 > With emacs -Q evaluate >=20 > (with-current-buffer (get-buffer-create "*foo*") > (dotimes (i 1000) > (insert "1234=E2=80=8B")) ; U-200B > (setq word-wrap t) > (display-buffer "*foo*")) >=20 > where the character after 1234 is a zero-width space character with > unicode code point U-200B. As can be seen in the window showing *f= oo*, > lines are not regularly wrapped at that character. You mean, not wrapped at all. Witness the continuation bitmaps in th= e fringes, which shouldn't appear when a line is wrapped. > Doing >=20 > (with-current-buffer (get-buffer-create "*foo*") > (dotimes (i 1000) > (insert "1234 ")) > (setq word-wrap t) > (display-buffer "*foo*")) >=20 > instead wraps lines as expected. If anything, this is a missing feature, since word-wrap is explicitly coded to break lines only on SPC and TAB characters. See the IT_DISPLAYING_WHITESPACE macro in xdisp.c. If we want to add more characters to the set, we should probably arrange a special char-table for this, and have it exposed to Lisp, s= o it could be customized. Patches are welcome. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 11 03:17:06 2013 Received: (at 13399) by debbugs.gnu.org; 11 Jan 2013 08:17:06 +0000 Received: from localhost ([127.0.0.1]:55058 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtZnV-000455-Ge for submit@debbugs.gnu.org; Fri, 11 Jan 2013 03:17:05 -0500 Received: from mout.gmx.net ([212.227.17.21]:61065) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtZnS-00044S-73 for 13399@debbugs.gnu.org; Fri, 11 Jan 2013 03:17:03 -0500 Received: from mailout-de.gmx.net ([10.1.76.19]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0M7nJe-1T6zTe1ckS-00vSQZ for <13399@debbugs.gnu.org>; Fri, 11 Jan 2013 09:16:50 +0100 Received: (qmail invoked by alias); 11 Jan 2013 08:16:50 -0000 Received: from 62-47-43-86.adsl.highway.telekom.at (EHLO [62.47.43.86]) [62.47.43.86] by mail.gmx.net (mp019) with SMTP; 11 Jan 2013 09:16:50 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/kikg/eQLk0g4q3BoUXMt+opa2FOCziwqcEFAALY exb13anbu9lEOl Message-ID: <50EFCA6D.7090702@gmx.at> Date: Fri, 11 Jan 2013 09:16:45 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> In-Reply-To: <83hamohmtj.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 13399 Cc: 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.8 (/) >> As can be seen in the window showing *foo*, >> lines are not regularly wrapped at that character. > > You mean, not wrapped at all. Witness the continuation bitmaps in the > fringes, which shouldn't appear when a line is wrapped. I thought these bitmaps appear when a line is wrapped. > If anything, this is a missing feature, since word-wrap is explicitly > coded to break lines only on SPC and TAB characters. The doc-string of `word-wrap' says When word-wrapping is on, continuation lines are wrapped at the space or tab character nearest to the right window edge Since U-200B is a space character the line should wrap at it. Also this character is intended for invisible word separation and for line break control; it has no width, but its presence between two characters does not prevent increased letter spacing in justification and Emacs apparently does handle it specially since it reserves a few pixels when drawing it. But documentation on `word-wrap' is scarce ... > See the > IT_DISPLAYING_WHITESPACE macro in xdisp.c. I tried to understand the code but failed. > If we want to add more characters to the set, we should probably > arrange a special char-table for this, and have it exposed to Lisp, so > it could be customized. Patches are welcome. IIUC all breakable spaces are between U-2000 and U-200B so maybe a character table is not needed. Anway, exposing displayed text to Lisp would be great. We'd just need two functions - one that gets the pixel width of an arbitrary buffer string wrt a specific window, and one that gets the pixel height of an arbitrary buffer string (newlines ignored) wrt a specific window. This way we could get rid of lots of problems currently hidden in the display engine ... martin From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 11 03:58:15 2013 Received: (at 13399) by debbugs.gnu.org; 11 Jan 2013 08:58:15 +0000 Received: from localhost ([127.0.0.1]:55096 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtaRK-00053Q-IT for submit@debbugs.gnu.org; Fri, 11 Jan 2013 03:58:14 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:52128) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtaRH-00053A-KJ for 13399@debbugs.gnu.org; Fri, 11 Jan 2013 03:58:13 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MGG00600E3HAV00@a-mtaout20.012.net.il> for 13399@debbugs.gnu.org; Fri, 11 Jan 2013 10:57:50 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MGG006E6E8DBJ00@a-mtaout20.012.net.il>; Fri, 11 Jan 2013 10:57:50 +0200 (IST) Date: Fri, 11 Jan 2013 10:58:08 +0200 From: Eli Zaretskii Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B In-reply-to: <50EFCA6D.7090702@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83ip74ume7.fsf@gnu.org> References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Fri, 11 Jan 2013 09:16:45 +0100 > From: martin rudalics > CC: 13399@debbugs.gnu.org > > >> As can be seen in the window showing *foo*, > >> lines are not regularly wrapped at that character. > > > > You mean, not wrapped at all. Witness the continuation bitmaps in the > > fringes, which shouldn't appear when a line is wrapped. > > I thought these bitmaps appear when a line is wrapped. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4988] X-Debbugs-Envelope-To: 13399 Cc: 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Fri, 11 Jan 2013 09:16:45 +0100 > From: martin rudalics > CC: 13399@debbugs.gnu.org > > >> As can be seen in the window showing *foo*, > >> lines are not regularly wrapped at that character. > > > > You mean, not wrapped at all. Witness the continuation bitmaps in the > > fringes, which shouldn't appear when a line is wrapped. > > I thought these bitmaps appear when a line is wrapped. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4672] > Date: Fri, 11 Jan 2013 09:16:45 +0100 > From: martin rudalics > CC: 13399@debbugs.gnu.org > > >> As can be seen in the window showing *foo*, > >> lines are not regularly wrapped at that character. > > > > You mean, not wrapped at all. Witness the continuation bitmaps in the > > fringes, which shouldn't appear when a line is wrapped. > > I thought these bitmaps appear when a line is wrapped. Not by default. Not unless you customize visual-line-fringe-indicators. > > If anything, this is a missing feature, since word-wrap is explicitly > > coded to break lines only on SPC and TAB characters. > > The doc-string of `word-wrap' says > > When word-wrapping is on, continuation lines are wrapped at the space > or tab character nearest to the right window edge > > Since U-200B is a space character the line should wrap at it. No, it means literally "the space character", U+0020. > Also > > this character is intended for invisible word separation and for line > break control; it has no width, but its presence between two > characters does not prevent increased letter spacing in justification > > and Emacs apparently does handle it specially since it reserves a few > pixels when drawing it. See glyphless-char-display and glyphless-char-display-control for why. > But documentation on `word-wrap' is scarce ... Actually, it doesn't exist, apart of the doc string. > > See the > > IT_DISPLAYING_WHITESPACE macro in xdisp.c. > > I tried to understand the code but failed. #define IT_DISPLAYING_WHITESPACE(it) \ /* If the character to be displayed is SPC or TAB */ ((it->what == IT_CHARACTER && (it->c == ' ' || it->c == '\t')) \ /* Or we are iterating over a display or overlay string, ... */ || ((STRINGP (it->string) \ /* ... and the character at current string position is SPC or TAB */ && (SREF (it->string, IT_STRING_BYTEPOS (*it)) == ' ' \ || SREF (it->string, IT_STRING_BYTEPOS (*it)) == '\t')) \ /* Or we are iterating over a C string, ... */ || (it->s \ /* ... and the character at current string position is SPC or TAB */ && (it->s[IT_BYTEPOS (*it)] == ' ' \ || it->s[IT_BYTEPOS (*it)] == '\t')) \ /* Or the iterator is before end of buffer's reachable portion, ... */ || (IT_BYTEPOS (*it) < ZV_BYTE \ /* ... and the character at current buffer position is SPC or TAB */ && (*BYTE_POS_ADDR (IT_BYTEPOS (*it)) == ' ' \ || *BYTE_POS_ADDR (IT_BYTEPOS (*it)) == '\t')))) \ In any case, you can clearly see that it only tests for literal SPC and TAB characters. > > If we want to add more characters to the set, we should probably > > arrange a special char-table for this, and have it exposed to Lisp, so > > it could be customized. Patches are welcome. > > IIUC all breakable spaces are between U-2000 and U-200B so maybe a > character table is not needed. Who said we want only break at breakable space characters? Who said Unicode will never add more such characters in another block? And what about low-ASCII characters, which are already in a different block? In any case, even if you are right, a char-table is a way to store character properties efficiently. In particular, it will waste very little storage to mark a contiguous range of characters with the same property. The advantage of using a char-table is that it will dynamically expand as needed if more characters are added to the set. > Anway, exposing displayed text to Lisp would be great. We'd just need > two functions - one that gets the pixel width of an arbitrary buffer > string wrt a specific window, and one that gets the pixel height of an > arbitrary buffer string (newlines ignored) wrt a specific window. This > way we could get rid of lots of problems currently hidden in the display > engine ... You lost me here. By "exposing to Lisp" I meant expose the char-table of word-wrap characters to Lisp. What did _you_ want exposed to Lisp? From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 11 05:30:08 2013 Received: (at 13399) by debbugs.gnu.org; 11 Jan 2013 10:30:08 +0000 Received: from localhost ([127.0.0.1]:55133 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtbsF-0007DY-8u for submit@debbugs.gnu.org; Fri, 11 Jan 2013 05:30:07 -0500 Received: from mout.gmx.net ([212.227.15.18]:63573) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtbsB-0007C8-O6 for 13399@debbugs.gnu.org; Fri, 11 Jan 2013 05:30:05 -0500 Received: from mailout-de.gmx.net ([10.1.76.32]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Ljfl8-1TI47r2lmy-00bdlv for <13399@debbugs.gnu.org>; Fri, 11 Jan 2013 11:29:51 +0100 Received: (qmail invoked by alias); 11 Jan 2013 10:29:51 -0000 Received: from 62-47-43-86.adsl.highway.telekom.at (EHLO [62.47.43.86]) [62.47.43.86] by mail.gmx.net (mp032) with SMTP; 11 Jan 2013 11:29:51 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/YqvV0ShnYom1Ac2T1WpBwWA3KdkprnDK6BgvCMa udPx/Wb8BTZBys Message-ID: <50EFE99A.5070508@gmx.at> Date: Fri, 11 Jan 2013 11:29:46 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> In-Reply-To: <83ip74ume7.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 13399 Cc: 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.8 (/) >> > You mean, not wrapped at all. Witness the continuation bitmaps in the >> > fringes, which shouldn't appear when a line is wrapped. >> >> I thought these bitmaps appear when a line is wrapped. > > Not by default. Not unless you customize visual-line-fringe-indicators. With emacs -Q I see curly arrows in the fringes regardless of whether I set `visual-line-fringe-indicators' or not. What am I missing? >> The doc-string of `word-wrap' says >> >> When word-wrapping is on, continuation lines are wrapped at the space >> or tab character nearest to the right window edge >> >> Since U-200B is a space character the line should wrap at it. > > No, it means literally "the space character", U+0020. So `word-wrap' is ASCII-only? The doc-string should say so. >> and Emacs apparently does handle it specially since it reserves a few >> pixels when drawing it. > > See glyphless-char-display and glyphless-char-display-control for why. IIUC it has a `thin-space' display method entry and I could set this to `zero-width' (the doc-string of `glyphless-char-display' is ambiguous about that)? Does this also mean that I can separate text properties of adjacent words by inserting a zero-width space between them? > #define IT_DISPLAYING_WHITESPACE(it) \ > /* If the character to be displayed is SPC or TAB */ [...] > In any case, you can clearly see that it only tests for literal SPC > and TAB characters. Even if I don't understand the code I can see that, yes. >> > If we want to add more characters to the set, we should probably >> > arrange a special char-table for this, and have it exposed to Lisp, so >> > it could be customized. Patches are welcome. >> >> IIUC all breakable spaces are between U-2000 and U-200B so maybe a >> character table is not needed. > > Who said we want only break at breakable space characters? Who said > Unicode will never add more such characters in another block? And > what about low-ASCII characters, which are already in a different > block? But implementing a character table and working with it is harder. > In any case, even if you are right, a char-table is a way to store > character properties efficiently. In particular, it will waste very > little storage to mark a contiguous range of characters with the same > property. The advantage of using a char-table is that it will > dynamically expand as needed if more characters are added to the set. Is it useful to make a _separate_ table for line-break properties? >> Anway, exposing displayed text to Lisp would be great. We'd just need >> two functions - one that gets the pixel width of an arbitrary buffer >> string wrt a specific window, and one that gets the pixel height of an >> arbitrary buffer string (newlines ignored) wrt a specific window. This >> way we could get rid of lots of problems currently hidden in the display >> engine ... > > You lost me here. By "exposing to Lisp" I meant expose the char-table > of word-wrap characters to Lisp. I only now understand what you meant. > What did _you_ want exposed to Lisp? Two functions: One to get the width of some arbitrary buffer text in pixels and one to get the full height of a buffer text line in pixels. The former would be used for doing word-wrapping variants in Lisp, the latter for fitting windows to their buffers. martin From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 11 05:57:33 2013 Received: (at 13399) by debbugs.gnu.org; 11 Jan 2013 10:57:33 +0000 Received: from localhost ([127.0.0.1]:55159 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtcIn-0007px-BV for submit@debbugs.gnu.org; Fri, 11 Jan 2013 05:57:33 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:37233) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtcIl-0007pi-06 for 13399@debbugs.gnu.org; Fri, 11 Jan 2013 05:57:32 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MGG00900JR4UK00@a-mtaout22.012.net.il> for 13399@debbugs.gnu.org; Fri, 11 Jan 2013 12:57:18 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MGG009YUJRHKT50@a-mtaout22.012.net.il>; Fri, 11 Jan 2013 12:57:18 +0200 (IST) Date: Fri, 11 Jan 2013 12:57:38 +0200 From: Eli Zaretskii Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B In-reply-to: <50EFE99A.5070508@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <838v80ugv1.fsf@gnu.org> References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Fri, 11 Jan 2013 11:29:46 +0100 > From: martin rudalics > CC: 13399@debbugs.gnu.org > > >> > You mean, not wrapped at all. Witness the continuation bitmaps in the > >> > fringes, which shouldn't appear when a line is wrapped. > >> > >> I thought these bitmaps appear when a line is wrapped. > > > > Not by default. Not unless you customize visual-line-fringe-indicators. > > With emacs -Q I see curly arrows in the fringes regardless of whether I > set `visual-line-fringe-indicators' or not. What am I missing? [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.172 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4998] X-Debbugs-Envelope-To: 13399 Cc: 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.7 (/) > Date: Fri, 11 Jan 2013 11:29:46 +0100 > From: martin rudalics > CC: 13399@debbugs.gnu.org > > >> > You mean, not wrapped at all. Witness the continuation bitmaps in the > >> > fringes, which shouldn't appear when a line is wrapped. > >> > >> I thought these bitmaps appear when a line is wrapped. > > > > Not by default. Not unless you customize visual-line-fringe-indicators. > > With emacs -Q I see curly arrows in the fringes regardless of whether I > set `visual-line-fringe-indicators' or not. What am I missing? If this is still with u+200B? You need to try with regular spaces. Then the indicators should disappear on wrapped lines. > >> The doc-string of `word-wrap' says > >> > >> When word-wrapping is on, continuation lines are wrapped at the space > >> or tab character nearest to the right window edge > >> > >> Since U-200B is a space character the line should wrap at it. > > > > No, it means literally "the space character", U+0020. > > So `word-wrap' is ASCII-only? Yes. > The doc-string should say so. Well, I personally find it hard to imagine that "the space character" could be interpreted as something other than U+0020. But I see what you mean. > >> and Emacs apparently does handle it specially since it reserves a few > >> pixels when drawing it. > > > > See glyphless-char-display and glyphless-char-display-control for why. > > IIUC it has a `thin-space' display method entry and I could set this to > `zero-width' (the doc-string of `glyphless-char-display' is ambiguous > about that)? Yes. > Does this also mean that I can separate text properties of > adjacent words by inserting a zero-width space between them? Yes, I think so (if I understand correctly what you mean). > >> > If we want to add more characters to the set, we should probably > >> > arrange a special char-table for this, and have it exposed to Lisp, so > >> > it could be customized. Patches are welcome. > >> > >> IIUC all breakable spaces are between U-2000 and U-200B so maybe a > >> character table is not needed. > > > > Who said we want only break at breakable space characters? Who said > > Unicode will never add more such characters in another block? And > > what about low-ASCII characters, which are already in a different > > block? > > But implementing a character table and working with it is harder. I don't think it's harder, it's actually very simple. You have a simple API for setting values in the table and a simple API for accessing a property of a character. > > In any case, even if you are right, a char-table is a way to store > > character properties efficiently. In particular, it will waste very > > little storage to mark a contiguous range of characters with the same > > property. The advantage of using a char-table is that it will > > dynamically expand as needed if more characters are added to the set. > > Is it useful to make a _separate_ table for line-break properties? Why not? What existing table would you reuse for that? > > What did _you_ want exposed to Lisp? > > Two functions: One to get the width of some arbitrary buffer text in > pixels and one to get the full height of a buffer text line in pixels. > The former would be used for doing word-wrapping variants in Lisp, the > latter for fitting windows to their buffers. The latter already exists as window-line-height, doesn't it? Anyway, how would you word-wrap in Lisp, except by adding display strings with newlines (which AFAIR features like longlines etc. already do)? From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 11 09:30:35 2013 Received: (at 13399) by debbugs.gnu.org; 11 Jan 2013 14:30:35 +0000 Received: from localhost ([127.0.0.1]:55311 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ttfco-0005Lq-MP for submit@debbugs.gnu.org; Fri, 11 Jan 2013 09:30:33 -0500 Received: from mout.gmx.net ([212.227.15.19]:53611) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ttfcj-0005La-L2 for 13399@debbugs.gnu.org; Fri, 11 Jan 2013 09:30:23 -0500 Received: from mailout-de.gmx.net ([10.1.76.17]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MF6gP-1TjUKp2YmZ-00GJSF for <13399@debbugs.gnu.org>; Fri, 11 Jan 2013 15:30:08 +0100 Received: (qmail invoked by alias); 11 Jan 2013 14:30:08 -0000 Received: from 62-47-43-86.adsl.highway.telekom.at (EHLO [62.47.43.86]) [62.47.43.86] by mail.gmx.net (mp017) with SMTP; 11 Jan 2013 15:30:08 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/ok1IDj2boy9ujGyPFBiY3Y3gTTsltoYBrW1y1hg YkXAWKwIxTl3tk Message-ID: <50F021EC.4040107@gmx.at> Date: Fri, 11 Jan 2013 15:30:04 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> <838v80ugv1.fsf@gnu.org> In-Reply-To: <838v80ugv1.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 13399 Cc: 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.8 (/) >> With emacs -Q I see curly arrows in the fringes regardless of whether I >> set `visual-line-fringe-indicators' or not. What am I missing? > > If this is still with u+200B? You need to try with regular spaces. My bad. It works when I enable `visual-line-mode'. It doesn't with only `word-wrap' set to t. > Then the indicators should disappear on wrapped lines. [...] >> So `word-wrap' is ASCII-only? > > Yes. > >> The doc-string should say so. > > Well, I personally find it hard to imagine that "the space character" > could be interpreted as something other than U+0020. But I see what > you mean. Nothing serious. I detected zero-width spaces and noticed that emacs can display them, so I was mislead that word wrap would handle them. >> IIUC it has a `thin-space' display method entry and I could set this to >> `zero-width' (the doc-string of `glyphless-char-display' is ambiguous >> about that)? > > Yes. Good. >> Does this also mean that I can separate text properties of >> adjacent words by inserting a zero-width space between them? > > Yes, I think so (if I understand correctly what you mean). Never mind, it works. What I meant was that when, for example, I have two adjacent parts of text with the same mouse-face property and the mouse hovers over one of the words, the other word gets highlighted as well. Maybe it's just stickyness or whatever, but till now I hadn't found a method to turn this off. Not recommended for normal buffers because `forward-char' appears to hang, but that's a different story. >> But implementing a character table and working with it is harder. > > I don't think it's harder, it's actually very simple. You have a > simple API for setting values in the table and a simple API for > accessing a property of a character. OK. I take your word for it. Maybe it could be also useful for adding soft hyphens (if we can make `forward-char' handle them). >> Is it useful to make a _separate_ table for line-break properties? > > Why not? What existing table would you reuse for that? No idea. Do we have a list of predefined character tables somewhere? >> Two functions: One to get the width of some arbitrary buffer text in >> pixels and one to get the full height of a buffer text line in pixels. >> The former would be used for doing word-wrapping variants in Lisp, the >> latter for fitting windows to their buffers. > > The latter already exists as window-line-height, doesn't it? This needs an up to date display, IIUC :-( > Anyway, how would you word-wrap in Lisp, except by adding display > strings with newlines (which AFAIR features like longlines > etc. already do)? By adding hard newlines. All I care about is to (1) show the entire buffer text in a fixed-width window and (2) make that window as small as possible. martin From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 11 09:48:56 2013 Received: (at 13399) by debbugs.gnu.org; 11 Jan 2013 14:48:56 +0000 Received: from localhost ([127.0.0.1]:55320 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ttfui-0005mF-FX for submit@debbugs.gnu.org; Fri, 11 Jan 2013 09:48:56 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:62001) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ttfuf-0005lx-St for 13399@debbugs.gnu.org; Fri, 11 Jan 2013 09:48:55 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MGG00B00UETZU00@a-mtaout22.012.net.il> for 13399@debbugs.gnu.org; Fri, 11 Jan 2013 16:48:40 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MGG00BYXUH4RF70@a-mtaout22.012.net.il>; Fri, 11 Jan 2013 16:48:40 +0200 (IST) Date: Fri, 11 Jan 2013 16:49:01 +0200 From: Eli Zaretskii Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B In-reply-to: <50F021EC.4040107@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <831udrvkpu.fsf@gnu.org> References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> <838v80ugv1.fsf@gnu.org> <50F021EC.4040107@gmx.at> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Fri, 11 Jan 2013 15:30:04 +0100 > From: martin rudalics > CC: 13399@debbugs.gnu.org > > >> Does this also mean that I can separate text properties of > >> adjacent words by inserting a zero-width space between them? > > > > Yes, I think so (if I understand correctly what you mean). > > Never mind, it works. What I meant was that when, for example, I have > two adjacent parts of text with the same mouse-face property and the > mouse hovers over one of the words, the other word gets highlighted as > well. Maybe it's just stickyness or whatever [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.172 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4999] X-Debbugs-Envelope-To: 13399 Cc: 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.7 (/) > Date: Fri, 11 Jan 2013 15:30:04 +0100 > From: martin rudalics > CC: 13399@debbugs.gnu.org > > >> Does this also mean that I can separate text properties of > >> adjacent words by inserting a zero-width space between them? > > > > Yes, I think so (if I understand correctly what you mean). > > Never mind, it works. What I meant was that when, for example, I have > two adjacent parts of text with the same mouse-face property and the > mouse hovers over one of the words, the other word gets highlighted as > well. Maybe it's just stickyness or whatever No, it's because, when mouse highlight finds a character with mouse-face, it looks forward for the first character without that face, and highlights everything in between. > >> Two functions: One to get the width of some arbitrary buffer text in > >> pixels and one to get the full height of a buffer text line in pixels. > >> The former would be used for doing word-wrapping variants in Lisp, the > >> latter for fitting windows to their buffers. > > > > The latter already exists as window-line-height, doesn't it? > > This needs an up to date display, IIUC :-( Yes, but only because the code to do that without looking at the current glyph matrix was never written. We do similar things all over the display engine. > > Anyway, how would you word-wrap in Lisp, except by adding display > > strings with newlines (which AFAIR features like longlines > > etc. already do)? > > By adding hard newlines. I thought that way is "deprecated" in favor of C-level word-wrap, which is why longlines.el is in obsolete/... From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 11 10:17:24 2013 Received: (at 13399) by debbugs.gnu.org; 11 Jan 2013 15:17:24 +0000 Received: from localhost ([127.0.0.1]:55647 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtgMG-0006Vd-0q for submit@debbugs.gnu.org; Fri, 11 Jan 2013 10:17:24 -0500 Received: from mout.gmx.net ([212.227.15.18]:56046) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtgME-0006VP-3m for 13399@debbugs.gnu.org; Fri, 11 Jan 2013 10:17:22 -0500 Received: from mailout-de.gmx.net ([10.1.76.28]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MKfbV-1Tvbd544bX-001xw0 for <13399@debbugs.gnu.org>; Fri, 11 Jan 2013 16:17:09 +0100 Received: (qmail invoked by alias); 11 Jan 2013 15:17:08 -0000 Received: from 62-47-43-86.adsl.highway.telekom.at (EHLO [62.47.43.86]) [62.47.43.86] by mail.gmx.net (mp028) with SMTP; 11 Jan 2013 16:17:08 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/7RN9KYyD7NHeX3Vji2ofuNqpYjujmkpuaNiLttv 7WBB4Re8GIa0+f Message-ID: <50F02CF0.5010904@gmx.at> Date: Fri, 11 Jan 2013 16:17:04 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> <838v80ugv1.fsf@gnu.org> <50F021EC.4040107@gmx.at> <831udrvkpu.fsf@gnu.org> In-Reply-To: <831udrvkpu.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 13399 Cc: 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.0 (/) > No, it's because, when mouse highlight finds a character with > mouse-face, it looks forward for the first character without that > face, and highlights everything in between. I thought so. Seems like zero-width spaces is the only means to fix this. >> This needs an up to date display, IIUC :-( > > Yes, but only because the code to do that without looking at the > current glyph matrix was never written. We do similar things all over > the display engine. Could you give writing this sort of "maybe this year" priority? Look at that silly code in `fit-window-to-buffer' for a motivation. Just that the return value of such a function would have to include the height needed for continuation lines as well. >> By adding hard newlines. > > I thought that way is "deprecated" in favor of C-level word-wrap, > which is why longlines.el is in obsolete/... But I have to calculate the height of the window _before_ redisplay. And for knowing the height of the window I have to know the number of displayed lines. martin From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 11 10:23:00 2013 Received: (at submit) by debbugs.gnu.org; 11 Jan 2013 15:23:00 +0000 Received: from localhost ([127.0.0.1]:55652 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtgRg-0006dX-6e for submit@debbugs.gnu.org; Fri, 11 Jan 2013 10:23:00 -0500 Received: from eggs.gnu.org ([208.118.235.92]:53420) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtgRe-0006dL-NJ for submit@debbugs.gnu.org; Fri, 11 Jan 2013 10:22:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TtgRP-0006Xh-Kk for submit@debbugs.gnu.org; Fri, 11 Jan 2013 10:22:46 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD, T_DKIM_INVALID autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:45807) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtgRP-0006Xc-Gb for submit@debbugs.gnu.org; Fri, 11 Jan 2013 10:22:43 -0500 Received: from eggs.gnu.org ([208.118.235.92]:36545) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtgRK-0000nG-MW for bug-gnu-emacs@gnu.org; Fri, 11 Jan 2013 10:22:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TtgRE-0006Wd-26 for bug-gnu-emacs@gnu.org; Fri, 11 Jan 2013 10:22:38 -0500 Received: from ristopher.com ([146.185.21.93]:41569 helo=saturn.ch.ristopher.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtgRD-0006WV-PR for bug-gnu-emacs@gnu.org; Fri, 11 Jan 2013 10:22:31 -0500 Received: by saturn.ch.ristopher.com (Postfix, from userid 0) id 3AA5F203F6; Fri, 11 Jan 2013 15:22:29 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ch.ristopher.com; s=mail; t=1357917749; bh=oSPUEefRRLL3PdMtcTG2cMT/xx7gaHIgJRIIQ3uEKAs=; h=From:To:Subject:In-Reply-To:Message-ID:References:MIME-Version: Content-Type:Date; b=R5vYJIAqaQeurySPLsM5WtB9rMZXiivWMBmRSfLUcCo2SOYejI/NHJdsxRk5/IuyR dAneWQU56jLo5ghtfJlyur3CCSfUqvakWfpqicqTD2LNN7CkDJjNTn73wALeH+GoZw 4QWztGyzzRgtRILzle30+C6pfhJ2HS0IIHAxOi+4= From: Christopher Schmidt To: bug-gnu-emacs@gnu.org Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B In-Reply-To: <50F02CF0.5010904@gmx.at> (martin rudalics's message of "Fri, 11 Jan 2013 16:17:04 +0100") Message-ID: <87bocvagnd@ch.ristopher.com> References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> <838v80ugv1.fsf@gnu.org> <50F021EC.4040107@gmx.at> <831udrvkpu.fsf@gnu.org> <50F02CF0.5010904@gmx.at> Mail-Followup-To: bug-gnu-emacs@gnu.org MIME-Version: 1.0 Content-Type: text/plain Date: Fri, 11 Jan 2013 15:22:29 +0000 (GMT) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -4.2 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.0 (-----) martin rudalics writes: >> No, it's because, when mouse highlight finds a character with >> mouse-face, it looks forward for the first character without that >> face, and highlights everything in between. > > I thought so. Seems like zero-width spaces is the only means to fix > this. You can insert invisible text in between the characters, such as (propertize " " 'invisible t) Christopher From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 11 10:54:03 2013 Received: (at 13399) by debbugs.gnu.org; 11 Jan 2013 15:54:03 +0000 Received: from localhost ([127.0.0.1]:55681 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ttgvg-0007PQ-4O for submit@debbugs.gnu.org; Fri, 11 Jan 2013 10:54:03 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:44185) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ttgva-0007P6-VE for 13399@debbugs.gnu.org; Fri, 11 Jan 2013 10:53:58 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MGG00C00XGPKO00@a-mtaout22.012.net.il> for 13399@debbugs.gnu.org; Fri, 11 Jan 2013 17:53:36 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MGG00C8MXHCAK90@a-mtaout22.012.net.il>; Fri, 11 Jan 2013 17:53:36 +0200 (IST) Date: Fri, 11 Jan 2013 17:53:57 +0200 From: Eli Zaretskii Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B In-reply-to: <50F02CF0.5010904@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83wqvju356.fsf@gnu.org> References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> <838v80ugv1.fsf@gnu.org> <50F021EC.4040107@gmx.at> <831udrvkpu.fsf@gnu.org> <50F02CF0.5010904@gmx.at> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Fri, 11 Jan 2013 16:17:04 +0100 > From: martin rudalics > CC: 13399@debbugs.gnu.org > > >> This needs an up to date display, IIUC :-( > > > > Yes, but only because the code to do that without looking at the > > current glyph matrix was never written. We do similar things all over > > the display engine. > > Could you give writing this sort of "maybe this year" priority? [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.172 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4974] X-Debbugs-Envelope-To: 13399 Cc: 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.7 (/) > Date: Fri, 11 Jan 2013 16:17:04 +0100 > From: martin rudalics > CC: 13399@debbugs.gnu.org > > >> This needs an up to date display, IIUC :-( > > > > Yes, but only because the code to do that without looking at the > > current glyph matrix was never written. We do similar things all over > > the display engine. > > Could you give writing this sort of "maybe this year" priority? I cannot promise that, but I will try. (It is actually a very good exercise for someone who wants to get to know the display engine, hint, hint...) > But I have to calculate the height of the window _before_ redisplay. > And for knowing the height of the window I have to know the number of > displayed lines. Doesn't vertical-motion, pos-visible-in-window-p, and its ilk provide that already? From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 11 11:08:18 2013 Received: (at 13399) by debbugs.gnu.org; 11 Jan 2013 16:08:19 +0000 Received: from localhost ([127.0.0.1]:55695 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tth9W-0007lW-LR for submit@debbugs.gnu.org; Fri, 11 Jan 2013 11:08:18 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:12061) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tth9U-0007lJ-Sn for 13399@debbugs.gnu.org; Fri, 11 Jan 2013 11:08:17 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoHAG6Zu09MCpYP/2dsb2JhbABEgXuuTYNJgQiCFQEBBAFWIwULCzQSFBgNJIgcBboJkEQDiEKacYFYgwc X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="212303688" Received: from 76-10-150-15.dsl.teksavvy.com (HELO pastel.home) ([76.10.150.15]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 11 Jan 2013 11:08:03 -0500 Received: by pastel.home (Postfix, from userid 20848) id F0DEE59441; Fri, 11 Jan 2013 11:08:02 -0500 (EST) From: Stefan Monnier To: martin rudalics Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B Message-ID: References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> <838v80ugv1.fsf@gnu.org> <50F021EC.4040107@gmx.at> Date: Fri, 11 Jan 2013 11:08:02 -0500 In-Reply-To: <50F021EC.4040107@gmx.at> (martin rudalics's message of "Fri, 11 Jan 2013 15:30:04 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 13399 Cc: Eli Zaretskii , 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > Never mind, it works. What I meant was that when, for example, I have > two adjacent parts of text with the same mouse-face property and the > mouse hovers over one of the words, the other word gets highlighted as > well. Maybe it's just stickyness or whatever, but till now I hadn't > found a method to turn this off. Not recommended for normal buffers > because `forward-char' appears to hang, but that's a different story. Text properties apply to characters, so they don't have a natural notion of "extent" and "boundaries", but Emacs usually invents those notions when needed by treating any run of characters whose text-property value is `eq' as one extent. In the case of the mouse-face property that means you can use (list 'my-face) on the chunk you want to make sure it's not `eq' to an adjacent chunk. >> The latter already exists as window-line-height, doesn't it? > This needs an up to date display, IIUC :-( W.r.t. functions that return the pixel width/height of a string, I guess you'd presume that the string would be displayed at the leftmost position on a line, since the width/height of a string will depend on where it's displayed in the window (which affects the width of TAB chars, and the placement of line wraps). >> Anyway, how would you word-wrap in Lisp, except by adding display >> strings with newlines (which AFAIR features like longlines >> etc. already do)? > By adding hard newlines. All I care about is to (1) show the entire > buffer text in a fixed-width window and (2) make that window as small as > possible. How 'bout starting my making the window as high as you can, then call (posn-at-point (point-max)), then shrink the window accordingly? Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 11 13:04:52 2013 Received: (at submit) by debbugs.gnu.org; 11 Jan 2013 18:04:52 +0000 Received: from localhost ([127.0.0.1]:55772 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtiyJ-0002A5-D7 for submit@debbugs.gnu.org; Fri, 11 Jan 2013 13:04:51 -0500 Received: from eggs.gnu.org ([208.118.235.92]:60181) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtiyG-00029p-RP for submit@debbugs.gnu.org; Fri, 11 Jan 2013 13:04:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ttixy-0000dF-Bh for submit@debbugs.gnu.org; Fri, 11 Jan 2013 13:04:35 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-101.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, USER_IN_WHITELIST autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:42191) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ttixy-0000d1-6F for submit@debbugs.gnu.org; Fri, 11 Jan 2013 13:04:30 -0500 Received: from eggs.gnu.org ([208.118.235.92]:43246) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ttixu-00054Q-Vu for bug-gnu-emacs@gnu.org; Fri, 11 Jan 2013 13:04:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ttixp-0000Ts-AJ for bug-gnu-emacs@gnu.org; Fri, 11 Jan 2013 13:04:26 -0500 Received: from mout.gmx.net ([212.227.17.21]:54472) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ttixp-0000TW-1N for bug-gnu-emacs@gnu.org; Fri, 11 Jan 2013 13:04:21 -0500 Received: from mailout-de.gmx.net ([10.1.76.28]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MOEAc-1TqP3205Su-005d9a for ; Fri, 11 Jan 2013 19:04:20 +0100 Received: (qmail invoked by alias); 11 Jan 2013 18:04:19 -0000 Received: from 62-47-43-86.adsl.highway.telekom.at (EHLO [62.47.43.86]) [62.47.43.86] by mail.gmx.net (mp028) with SMTP; 11 Jan 2013 19:04:19 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/Qx4RgnljQ8+Gs/R2b9bVT+CJaPJGBOXXno9dLrK HxIMU6QQfIabMH Message-ID: <50F0541E.4010903@gmx.at> Date: Fri, 11 Jan 2013 19:04:14 +0100 From: martin rudalics MIME-Version: 1.0 To: bug-gnu-emacs@gnu.org Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> <838v80ugv1.fsf@gnu.org> <50F021EC.4040107@gmx.at> <831udrvkpu.fsf@gnu.org> <50F02CF0.5010904@gmx.at> <87bocvagnd@ch.ristopher.com> In-Reply-To: <87bocvagnd@ch.ristopher.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -4.2 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.0 (-----) > You can insert invisible text in between the characters, such as > > (propertize " " 'invisible t) One could also use display properties or overlays. But zero-width spaces can be easily saved to file and read back (not that this is something I'd need in the case at hand). martin From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 11 13:05:10 2013 Received: (at 13399) by debbugs.gnu.org; 11 Jan 2013 18:05:10 +0000 Received: from localhost ([127.0.0.1]:55776 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ttiyb-0002Az-4T for submit@debbugs.gnu.org; Fri, 11 Jan 2013 13:05:09 -0500 Received: from mout.gmx.net ([212.227.17.21]:54401) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtiyY-0002AQ-Jj for 13399@debbugs.gnu.org; Fri, 11 Jan 2013 13:05:07 -0500 Received: from mailout-de.gmx.net ([10.1.76.12]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0LhhsN-1T7l7F1VgH-00mpla for <13399@debbugs.gnu.org>; Fri, 11 Jan 2013 19:04:52 +0100 Received: (qmail invoked by alias); 11 Jan 2013 18:04:52 -0000 Received: from 62-47-43-86.adsl.highway.telekom.at (EHLO [62.47.43.86]) [62.47.43.86] by mail.gmx.net (mp012) with SMTP; 11 Jan 2013 19:04:52 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18FnIAJ86sFhPAwxYBT6bZUTAgVDeTEFhAtfdOFPt Kyy2kCWh5Y3lPb Message-ID: <50F0543F.5070805@gmx.at> Date: Fri, 11 Jan 2013 19:04:47 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> <838v80ugv1.fsf@gnu.org> <50F021EC.4040107@gmx.at> <831udrvkpu.fsf@gnu.org> <50F02CF0.5010904@gmx.at> <83wqvju356.fsf@gnu.org> In-Reply-To: <83wqvju356.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 13399 Cc: 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.8 (/) > I cannot promise that, but I will try. (It is actually a very good > exercise for someone who wants to get to know the display engine, > hint, hint...) ... a talented, young programmer. Where do you find them these days? >> But I have to calculate the height of the window _before_ redisplay. >> And for knowing the height of the window I have to know the number of >> displayed lines. > > Doesn't vertical-motion, pos-visible-in-window-p, and its ilk provide > that already? `fit-window-to-buffer' uses `pos-visible-in-window-p' already, with poor results here (in particular when drawing boxes around text). And `vertical-motion' doesn't pay attention to the height of text. At least that was my experience when I tried to rewrite `fit-window-to-buffer' using `count-screen-lines'. martin From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 11 13:06:46 2013 Received: (at 13399) by debbugs.gnu.org; 11 Jan 2013 18:06:46 +0000 Received: from localhost ([127.0.0.1]:55780 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ttj09-0002DT-5r for submit@debbugs.gnu.org; Fri, 11 Jan 2013 13:06:46 -0500 Received: from mout.gmx.net ([212.227.17.20]:61960) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ttj07-0002DF-69 for 13399@debbugs.gnu.org; Fri, 11 Jan 2013 13:06:43 -0500 Received: from mailout-de.gmx.net ([10.1.76.2]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MN7F0-1TrW4z3BX6-006f2V for <13399@debbugs.gnu.org>; Fri, 11 Jan 2013 19:06:29 +0100 Received: (qmail invoked by alias); 11 Jan 2013 18:06:29 -0000 Received: from 62-47-43-86.adsl.highway.telekom.at (EHLO [62.47.43.86]) [62.47.43.86] by mail.gmx.net (mp002) with SMTP; 11 Jan 2013 19:06:29 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+qE89LiCyqM/WMKUWr1lbtvKlAH1pJ+QBKPNM+pt 8LqyvD6iTMarEH Message-ID: <50F054A0.2040606@gmx.at> Date: Fri, 11 Jan 2013 19:06:24 +0100 From: martin rudalics MIME-Version: 1.0 To: Stefan Monnier Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> <838v80ugv1.fsf@gnu.org> <50F021EC.4040107@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 13399 Cc: Eli Zaretskii , 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > In the case of the mouse-face property that means you can use (list 'my-face) > on the chunk you want to make sure it's not `eq' to an adjacent chunk. Good to know that trick (undocumented I presume). > W.r.t. functions that return the pixel width/height of a string, I guess > you'd presume that the string would be displayed at the leftmost > position on a line, since the width/height of a string will depend on > where it's displayed in the window (which affects the width of TAB > chars, and the placement of line wraps). Yes. In my use case the buffer has no newline. >>> Anyway, how would you word-wrap in Lisp, except by adding display >>> strings with newlines (which AFAIR features like longlines >>> etc. already do)? >> By adding hard newlines. All I care about is to (1) show the entire >> buffer text in a fixed-width window and (2) make that window as small as >> possible. > > How 'bout starting my making the window as high as you can, then call > (posn-at-point (point-max)), then shrink the window accordingly? How could `posn-at-point' possibly work if the display is not up to date? And what I want to avoid is the redisplay. martin From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 11 13:50:17 2013 Received: (at 13399) by debbugs.gnu.org; 11 Jan 2013 18:50:17 +0000 Received: from localhost ([127.0.0.1]:55806 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtjgH-0003I8-4o for submit@debbugs.gnu.org; Fri, 11 Jan 2013 13:50:17 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:6587) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtjgE-0003Hw-RJ for 13399@debbugs.gnu.org; Fri, 11 Jan 2013 13:50:15 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoHAG6Zu09MCpYP/2dsb2JhbABEgXuuTYNJgQiCFQEBBAFWIwULCzQSFBgNJIgcBboJkEQDiEKacYFYgwc X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="212317594" Received: from 76-10-150-15.dsl.teksavvy.com (HELO pastel.home) ([76.10.150.15]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 11 Jan 2013 13:50:01 -0500 Received: by pastel.home (Postfix, from userid 20848) id 7F7E15943D; Fri, 11 Jan 2013 13:50:00 -0500 (EST) From: Stefan Monnier To: martin rudalics Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B Message-ID: References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> <838v80ugv1.fsf@gnu.org> <50F021EC.4040107@gmx.at> <50F054A0.2040606@gmx.at> Date: Fri, 11 Jan 2013 13:50:00 -0500 In-Reply-To: <50F054A0.2040606@gmx.at> (martin rudalics's message of "Fri, 11 Jan 2013 19:06:24 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 13399 Cc: Eli Zaretskii , 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> In the case of the mouse-face property that means you can use (list >> 'my-face) on the chunk you want to make sure it's not `eq' to an >> adjacent chunk. > Good to know that trick (undocumented I presume). Maybe it's documented somewhere, but at least the doc of the `mouse-face' text property doesn't mention how boundaries are determined, indeed. >> W.r.t. functions that return the pixel width/height of a string, I guess >> you'd presume that the string would be displayed at the leftmost >> position on a line, since the width/height of a string will depend on >> where it's displayed in the window (which affects the width of TAB >> chars, and the placement of line wraps). > Yes. In my use case the buffer has no newline. Does the absence of newline make a difference to the problem? > How could `posn-at-point' possibly work if the display is not up to > date? Actually, it does not require the display to be up-to-date, only the glyph-matrices. > And what I want to avoid is the redisplay. You should be able to update the glyph-matrices without causing the display to immediately reflect the changes. E.g. window-end with a non-nil `update' argument should do that, IIUC. Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 11 14:08:05 2013 Received: (at 13399) by debbugs.gnu.org; 11 Jan 2013 19:08:06 +0000 Received: from localhost ([127.0.0.1]:55811 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtjxV-0003iU-Pi for submit@debbugs.gnu.org; Fri, 11 Jan 2013 14:08:05 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:55508) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtjxT-0003hv-Hf for 13399@debbugs.gnu.org; Fri, 11 Jan 2013 14:08:04 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MGH00E006B6AC00@a-mtaout22.012.net.il> for 13399@debbugs.gnu.org; Fri, 11 Jan 2013 21:07:48 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MGH00EU86GS4330@a-mtaout22.012.net.il>; Fri, 11 Jan 2013 21:07:40 +0200 (IST) Date: Fri, 11 Jan 2013 21:08:02 +0200 From: Eli Zaretskii Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B In-reply-to: <50F054A0.2040606@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83pq1btu5p.fsf@gnu.org> References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> <838v80ugv1.fsf@gnu.org> <50F021EC.4040107@gmx.at> <50F054A0.2040606@gmx.at> X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 13399 Cc: monnier@iro.umontreal.ca, 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > Date: Fri, 11 Jan 2013 19:06:24 +0100 > From: martin rudalics > CC: Eli Zaretskii , 13399@debbugs.gnu.org > > How could `posn-at-point' possibly work if the display is not up to > date? Very simply: it simulates the display. See pos_visible_p (which posn-at-point calls). That's what I meant when I said that doing this for determining the line width or height should be easy. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 11 14:29:32 2013 Received: (at 13399) by debbugs.gnu.org; 11 Jan 2013 19:29:32 +0000 Received: from localhost ([127.0.0.1]:55824 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtkIF-0004E5-Oa for submit@debbugs.gnu.org; Fri, 11 Jan 2013 14:29:32 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:59932) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtkID-0004Dq-5Q for 13399@debbugs.gnu.org; Fri, 11 Jan 2013 14:29:30 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MGH00E007DEHG00@a-mtaout22.012.net.il> for 13399@debbugs.gnu.org; Fri, 11 Jan 2013 21:29:03 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MGH00EC97G84380@a-mtaout22.012.net.il>; Fri, 11 Jan 2013 21:28:57 +0200 (IST) Date: Fri, 11 Jan 2013 21:29:19 +0200 From: Eli Zaretskii Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83libztt68.fsf@gnu.org> References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> <838v80ugv1.fsf@gnu.org> <50F021EC.4040107@gmx.at> <50F054A0.2040606@gmx.at> X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 13399 Cc: rudalics@gmx.at, 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Stefan Monnier > Cc: Eli Zaretskii , 13399@debbugs.gnu.org > Date: Fri, 11 Jan 2013 13:50:00 -0500 > > > How could `posn-at-point' possibly work if the display is not up to > > date? > > Actually, it does not require the display to be up-to-date, only the > glyph-matrices. No, you cannot have up-to-date glyph matrices without triggering redisplay. Updating the glyph matrices is the first stage of redisplay (the second stage being updating the windows using the differences between the "current" and the "desired" glyph matrices). What you mean is use move_it_* family of functions. These _simulate_ redisplay by computing all the metrics of all the characters they move across, but without producing glyphs and glyph matrices. Because you don't actually need the glyph matrices for the task at hand, you only need the metrics of each display line (its ascent, descent, and pixel width), and those are computed and tracked by the display iterator even if no glyphs are produced. > You should be able to update the glyph-matrices without causing the > display to immediately reflect the changes. E.g. window-end with > a non-nil `update' argument should do that, IIUC. window-end with a non-nil UPDATE arg uses the above mentioned technique: it calls move_it_vertically, which moves through the lines computing their metrics, but doesn't produce any glyphs. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 11 17:48:06 2013 Received: (at 13399) by debbugs.gnu.org; 11 Jan 2013 22:48:06 +0000 Received: from localhost ([127.0.0.1]:55865 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtnOQ-0000TZ-LH for submit@debbugs.gnu.org; Fri, 11 Jan 2013 17:48:06 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:30626) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtnOO-0000T3-JN for 13399@debbugs.gnu.org; Fri, 11 Jan 2013 17:48:04 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoHAG6Zu09MCpYP/2dsb2JhbABEgXuuTYNJgQiCFQEBBAFWIxALNBIUGA0kiBwFugmQRAOIQppxgViDBw X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="212334354" Received: from 76-10-150-15.dsl.teksavvy.com (HELO pastel.home) ([76.10.150.15]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 11 Jan 2013 17:47:49 -0500 Received: by pastel.home (Postfix, from userid 20848) id 043C95943D; Fri, 11 Jan 2013 17:47:46 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B Message-ID: References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> <838v80ugv1.fsf@gnu.org> <50F021EC.4040107@gmx.at> <50F054A0.2040606@gmx.at> <83libztt68.fsf@gnu.org> Date: Fri, 11 Jan 2013 17:47:46 -0500 In-Reply-To: <83libztt68.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 11 Jan 2013 21:29:19 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 13399 Cc: rudalics@gmx.at, 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> > How could `posn-at-point' possibly work if the display is not up to >> > date? >> Actually, it does not require the display to be up-to-date, only the >> glyph-matrices. > No, you cannot have up-to-date glyph matrices without triggering > redisplay. Looks like I misunderstood, indeed. This said, I don't see why we couldn't provide ways to update the glyph matrices while leaving the display update for later. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 12 03:28:12 2013 Received: (at 13399) by debbugs.gnu.org; 12 Jan 2013 08:28:12 +0000 Received: from localhost ([127.0.0.1]:56214 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtwRo-0006g8-6c for submit@debbugs.gnu.org; Sat, 12 Jan 2013 03:28:12 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:44120) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtwRm-0006fu-DH for 13399@debbugs.gnu.org; Sat, 12 Jan 2013 03:28:11 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MGI00I007FKXD00@a-mtaout20.012.net.il> for 13399@debbugs.gnu.org; Sat, 12 Jan 2013 10:27:52 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MGI00I3J7IGPN60@a-mtaout20.012.net.il>; Sat, 12 Jan 2013 10:27:52 +0200 (IST) Date: Sat, 12 Jan 2013 10:28:15 +0200 From: Eli Zaretskii Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83hammu7og.fsf@gnu.org> References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> <838v80ugv1.fsf@gnu.org> <50F021EC.4040107@gmx.at> <50F054A0.2040606@gmx.at> <83libztt68.fsf@gnu.org> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > From: Stefan Monnier > Cc: rudalics@gmx.at, 13399@debbugs.gnu.org > Date: Fri, 11 Jan 2013 17:47:46 -0500 > > >> > How could `posn-at-point' possibly work if the display is not up to > >> > date? > >> Actually, it does not require the display to be up-to-date, only the > >> glyph-matrices. > > No, you cannot have up-to-date glyph matrices without triggering > > redisplay. > > Looks like I misunderstood, indeed. This said, I don't see why we > couldn't provide ways to update the glyph matrices while leaving the > display update for later. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4776] X-Debbugs-Envelope-To: 13399 Cc: rudalics@gmx.at, 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.2 (/) > From: Stefan Monnier > Cc: rudalics@gmx.at, 13399@debbugs.gnu.org > Date: Fri, 11 Jan 2013 17:47:46 -0500 > > >> > How could `posn-at-point' possibly work if the display is not up to > >> > date? > >> Actually, it does not require the display to be up-to-date, only the > >> glyph-matrices. > > No, you cannot have up-to-date glyph matrices without triggering > > redisplay. > > Looks like I misunderstood, indeed. This said, I don't see why we > couldn't provide ways to update the glyph matrices while leaving the > display update for later. Generating up-to-date matrices without reflecting them on the glass is easy: just skip the calls to update_frame in redisplay_internal. But why would we need that? Most everything we need to know about display is already tracked by the display iterator, so available even without generating glyphs, and that's what the move_it_* functions do. These function do their job by traversing only small portions of the buffer, just large enough for the job at hand to be done. OTOH, updating the entire glyph matrices of all of the windows on all of the frames AFAIR takes the lion's share of time used by redisplay, so we might as well force a complete redisplay when we do need complete up-to-date matrices. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 12 08:21:11 2013 Received: (at 13399) by debbugs.gnu.org; 12 Jan 2013 13:21:11 +0000 Received: from localhost ([127.0.0.1]:56403 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tu11K-0006FR-Lx for submit@debbugs.gnu.org; Sat, 12 Jan 2013 08:21:11 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:46142) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tu11I-0006FB-KS for 13399@debbugs.gnu.org; Sat, 12 Jan 2013 08:21:08 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoHAG6Zu09FpZpV/2dsb2JhbABEgXuuTYNJgQiCFQEBBAFWIwULCzQSFBgNJIgcBboJkEQDiEKacYFYgwc X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="212360024" Received: from 69-165-154-85.dsl.teksavvy.com (HELO pastel.home) ([69.165.154.85]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 12 Jan 2013 08:20:50 -0500 Received: by pastel.home (Postfix, from userid 20848) id 3076C592A5; Sat, 12 Jan 2013 08:20:50 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B Message-ID: References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> <838v80ugv1.fsf@gnu.org> <50F021EC.4040107@gmx.at> <50F054A0.2040606@gmx.at> <83libztt68.fsf@gnu.org> <83hammu7og.fsf@gnu.org> Date: Sat, 12 Jan 2013 08:20:50 -0500 In-Reply-To: <83hammu7og.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 12 Jan 2013 10:28:15 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 13399 Cc: rudalics@gmx.at, 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.5 (/) > But why would we need that? Most everything we need to know about > display is already tracked by the display iterator, so available even > without generating glyphs, and that's what the move_it_* functions do. > These function do their job by traversing only small portions of the > buffer, just large enough for the job at hand to be done. What about posn-at-point? > OTOH, updating the entire glyph matrices of all of the windows on all > of the frames AFAIR takes the lion's share of time used by redisplay, > so we might as well force a complete redisplay when we do need > complete up-to-date matrices. posn-at-point doesn't need to refresh all glyph matrices, only the one of the selected window. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 12 09:12:39 2013 Received: (at 13399) by debbugs.gnu.org; 12 Jan 2013 14:12:40 +0000 Received: from localhost ([127.0.0.1]:56455 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tu1p9-0007UV-Kd for submit@debbugs.gnu.org; Sat, 12 Jan 2013 09:12:39 -0500 Received: from mtaout21.012.net.il ([80.179.55.169]:61632) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tu1p7-0007UG-JL for 13399@debbugs.gnu.org; Sat, 12 Jan 2013 09:12:38 -0500 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MGI00J00NF0QD00@a-mtaout21.012.net.il> for 13399@debbugs.gnu.org; Sat, 12 Jan 2013 16:12:14 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MGI00JIYNGEM850@a-mtaout21.012.net.il>; Sat, 12 Jan 2013 16:12:14 +0200 (IST) Date: Sat, 12 Jan 2013 16:12:38 +0200 From: Eli Zaretskii Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83sj66sd61.fsf@gnu.org> References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> <838v80ugv1.fsf@gnu.org> <50F021EC.4040107@gmx.at> <50F054A0.2040606@gmx.at> <83libztt68.fsf@gnu.org> <83hammu7og.fsf@gnu.org> X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 13399 Cc: rudalics@gmx.at, 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.2 (/) > From: Stefan Monnier > Cc: rudalics@gmx.at, 13399@debbugs.gnu.org > Date: Sat, 12 Jan 2013 08:20:50 -0500 > > > But why would we need that? Most everything we need to know about > > display is already tracked by the display iterator, so available even > > without generating glyphs, and that's what the move_it_* functions do. > > These function do their job by traversing only small portions of the > > buffer, just large enough for the job at hand to be done. > > What about posn-at-point? What about it? It already uses move_it_*, see pos_visible_p, which does all the work. > > OTOH, updating the entire glyph matrices of all of the windows on all > > of the frames AFAIR takes the lion's share of time used by redisplay, > > so we might as well force a complete redisplay when we do need > > complete up-to-date matrices. > > posn-at-point doesn't need to refresh all glyph matrices, only the one > of the selected window. Look at pos_visible_p, and you will see that what it does is start_display at window top, then move the display iterator to where point is displayed, and taking the pixel coordinates from the display iterator when that's done. What else is needed, that the glyph matrix of the window would provide? From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 12 09:30:58 2013 Received: (at 13399) by debbugs.gnu.org; 12 Jan 2013 14:30:58 +0000 Received: from localhost ([127.0.0.1]:56468 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tu26p-0007uV-Ql for submit@debbugs.gnu.org; Sat, 12 Jan 2013 09:30:57 -0500 Received: from mout.gmx.net ([212.227.17.20]:57321) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tu26K-0007tZ-Dp for 13399@debbugs.gnu.org; Sat, 12 Jan 2013 09:30:41 -0500 Received: from mailout-de.gmx.net ([10.1.76.4]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LqGOk-1TGYY905lQ-00dqCm for <13399@debbugs.gnu.org>; Sat, 12 Jan 2013 15:30:05 +0100 Received: (qmail invoked by alias); 12 Jan 2013 14:30:04 -0000 Received: from 62-47-61-165.adsl.highway.telekom.at (EHLO [62.47.61.165]) [62.47.61.165] by mail.gmx.net (mp004) with SMTP; 12 Jan 2013 15:30:04 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX186rhIYOxM6jniSTrfhGpQn5S0YdaeLBhy78ZbG8A 8Su5CHBU9fWRKy Message-ID: <50F17365.6050006@gmx.at> Date: Sat, 12 Jan 2013 15:29:57 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> <838v80ugv1.fsf@gnu.org> <50F021EC.4040107@gmx.at> <50F054A0.2040606@gmx.at> <83pq1btu5p.fsf@gnu.org> In-Reply-To: <83pq1btu5p.fsf@gnu.org> Content-Type: multipart/mixed; boundary="------------080101040400070603010307" X-Y-GMX-Trusted: 0 X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 13399 Cc: monnier@iro.umontreal.ca, 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) This is a multi-part message in MIME format. --------------080101040400070603010307 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit > Very simply: it simulates the display. See pos_visible_p (which > posn-at-point calls). That's what I meant when I said that doing this > for determining the line width or height should be easy. Here I see the following call sequences: `fit-window-to-buffer' -> `count-screen-lines' -> `vertical-motion' -> move_it_to -> `pos-visible-in-window-p' -> pos_visible_p -> move_it_to So everything `fit-window-to-buffer' does ends up calling move_it_to and the loop called via `pos-visible-in-window-p' is likely silly. Using `posn-at-point' -> `pos-visible-in-window-p' -> pos_visible_p -> move_it_to `window-end' -> move_it_vertically -> move_it_to probably won't produce anything else. This means that somehow move_it_to fails to DTRT here. I don't have a deterministic scenario to produce the bug. I attach a file you can try via `eval-buffer' followed by M-x foo. After that you'd have to resize the frame randomly (usually shrinking it vertically) until it hides the last line(s) of the *foo* window. This usually takes a few seconds here. The hiding does not occur when I do not draw a box around characters. I didn't try different character heights, bold face, etc. so far. Note that in normal work I use a maximized frame and the bug shows up frequently when changing text in *foo* (using another hook) or the window configuration. I now have to manually trigger `window-line-height' on each of *foo*'s lines when the hiding occurs, add the return values, and try to find out what goes on. This will take some time. If you have a better idea, I'd be all ears. martin --------------080101040400070603010307 Content-Type: application/emacs-lisp; name="foo.el" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="foo.el" KGRlZmZhY2UgZm9vDQogICcoKHQgOmJveCAoOmxpbmUtd2lkdGggMiA6Y29sb3IgImdyZXk3 MiIpDQogICAgICAgOmZvcmVncm91bmQgImJsYWNrIg0KICAgICAgIDpiYWNrZ3JvdW5kICJw aW5rIikpDQogICJGYWNlLiINCiAgOmdyb3VwICd3aW5kb3cpDQoNCihkZWZ2YXIgZm9vLXRp bWVyIG5pbCkNCihkZWZ2YXIgZm9vLXJ1biBuaWwpDQoNCihkZWZ1biBmb28tdXBkYXRlICgp DQogICh1bndpbmQtcHJvdGVjdA0KICAgICAgKHByb2duDQoJKHNldHEgZm9vLXJ1biB0KQ0K CShsZXQgKCh3aW5kb3cgKGdldC1idWZmZXItd2luZG93ICIqZm9vKiIpKSkNCgkgICh3aGVu IHdpbmRvdyAoZml0LXdpbmRvdy10by1idWZmZXIgd2luZG93KSkpKQ0KICAgIChzZXRxIGZv by1ydW4gbmlsKQ0KICAgIChjYW5jZWwtdGltZXIgZm9vLXRpbWVyKSkpDQoNCihkZWZ1biBm b28tcnVuLXRpbWVyICgpDQogICh1bmxlc3MgZm9vLXJ1bg0KICAgICh3aGVuICh0aW1lcnAg Zm9vLXRpbWVyKQ0KICAgICAgKGNhbmNlbC10aW1lciBmb28tdGltZXIpKQ0KICAgIChzZXRx IGZvby10aW1lcg0KCSAgKHJ1bi13aXRoLWlkbGUtdGltZXIgMC4wIHQgJ2Zvby11cGRhdGUp KSkpDQoNCihkZWZ1biBmb28gKCkNCiAgKGludGVyYWN0aXZlKQ0KICAod2l0aC1jdXJyZW50 LWJ1ZmZlciAoZ2V0LWJ1ZmZlci1jcmVhdGUgIipmb28qIikNCiAgICAoZXJhc2UtYnVmZmVy KQ0KICAgIChkb3RpbWVzIChpIDEwMCkNCiAgICAgIChsZXQgKChsaW1pdCAoMSsgKHJhbmRv bSA4KSkpKQ0KCShpbnNlcnQNCgkgKHByb3BlcnRpemUNCgkgIChzdWJzdHJpbmcgIkZvb0Jh ckJheiIgMCBsaW1pdCkgJ2ZhY2UgJ2ZvbykNCgkgIiAiKSkpDQogICAgKGluc2VydCAiXG4i KQ0KICAgIChnb3RvLWNoYXIgKHBvaW50LW1pbikpDQogICAgKHNldCAobWFrZS1sb2NhbC12 YXJpYWJsZSAnd29yZC13cmFwKSB0KQ0KICAgIChzZXQgKG1ha2UtbG9jYWwtdmFyaWFibGUg J3RydW5jYXRlLWxpbmVzKSBuaWwpDQogICAgKHNldCAobWFrZS1sb2NhbC12YXJpYWJsZSAn dHJ1bmNhdGUtcGFydGlhbC13aWR0aC13aW5kb3dzKSBuaWwpDQogICAgKHNldC13aW5kb3ct YnVmZmVyIChzcGxpdC13aW5kb3cgbmlsIG5pbCAnYWJvdmUpICIqZm9vKiIpDQogICAgKGZp dC13aW5kb3ctdG8tYnVmZmVyIChnZXQtYnVmZmVyLXdpbmRvdyAiKmZvbyoiKSkNCiAgICAo c3BsaXQtd2luZG93IG5pbCBuaWwgJ3JpZ2h0KSkNCiAgKGFkZC1ob29rICd3aW5kb3ctY29u ZmlndXJhdGlvbi1jaGFuZ2UtaG9vayAnZm9vLXJ1bi10aW1lciAnYXBwZW5kKSkNCg== --------------080101040400070603010307-- From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 12 09:56:55 2013 Received: (at 13399) by debbugs.gnu.org; 12 Jan 2013 14:56:55 +0000 Received: from localhost ([127.0.0.1]:57080 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tu2Vl-0000Dn-Ok for submit@debbugs.gnu.org; Sat, 12 Jan 2013 09:56:48 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:36919) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tu2VW-0000De-O3 for 13399@debbugs.gnu.org; Sat, 12 Jan 2013 09:56:30 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MGI00M00PDKDC00@a-mtaout20.012.net.il> for 13399@debbugs.gnu.org; Sat, 12 Jan 2013 16:56:07 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MGI00MNGPHJ3Y70@a-mtaout20.012.net.il>; Sat, 12 Jan 2013 16:56:07 +0200 (IST) Date: Sat, 12 Jan 2013 16:56:31 +0200 From: Eli Zaretskii Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B In-reply-to: <50F17365.6050006@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83obgusb4w.fsf@gnu.org> References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> <838v80ugv1.fsf@gnu.org> <50F021EC.4040107@gmx.at> <50F054A0.2040606@gmx.at> <83pq1btu5p.fsf@gnu.org> <50F17365.6050006@gmx.at> X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 13399 Cc: monnier@iro.umontreal.ca, 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > Date: Sat, 12 Jan 2013 15:29:57 +0100 > From: martin rudalics > CC: monnier@iro.umontreal.ca, 13399@debbugs.gnu.org > > > Very simply: it simulates the display. See pos_visible_p (which > > posn-at-point calls). That's what I meant when I said that doing this > > for determining the line width or height should be easy. > > Here I see the following call sequences: > > `fit-window-to-buffer' > -> `count-screen-lines' -> `vertical-motion' -> move_it_to > -> `pos-visible-in-window-p' -> pos_visible_p -> move_it_to > > So everything `fit-window-to-buffer' does ends up calling move_it_to and > the loop called via `pos-visible-in-window-p' is likely silly. fit-window-to-buffer should probably call pos-visible-in-window-p with argument PARTIALLY non-nil, and then it should be possible to get rid of the loop. > Using > > `posn-at-point' -> `pos-visible-in-window-p' -> pos_visible_p -> move_it_to > > `window-end' -> move_it_vertically -> move_it_to > > probably won't produce anything else. This means that somehow > move_it_to fails to DTRT here. If you can show a case where it fails, it should be possible to fix it. OTOH, it could be that these Lisp tricks try to work around failures in move_it_to that were already fixed. > I don't have a deterministic scenario to produce the bug. I attach a > file you can try via `eval-buffer' followed by M-x foo. After that > you'd have to resize the frame randomly (usually shrinking it > vertically) until it hides the last line(s) of the *foo* window. This > usually takes a few seconds here. > > The hiding does not occur when I do not draw a box around characters. I > didn't try different character heights, bold face, etc. so far. Note > that in normal work I use a maximized frame and the bug shows up > frequently when changing text in *foo* (using another hook) or the > window configuration. I think what you see only happens when the last line is partially visible (where "partially" might mean just one of its pixels). If that is not desirable, then we will need to be more accurate when we say "visible" and have a more precise definition of what exactly constitutes a window's height when a single line, in particular the last one, might have characters of different descent values. In any case, this is a failure in fit-window-to-buffer, if anything, it is not necessarily an evidence that move_it_* functions fail. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 12 11:06:57 2013 Received: (at 13399) by debbugs.gnu.org; 12 Jan 2013 16:06:57 +0000 Received: from localhost ([127.0.0.1]:57105 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tu3bl-0001sd-93 for submit@debbugs.gnu.org; Sat, 12 Jan 2013 11:06:57 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:3815) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tu3bj-0001sO-N0 for 13399@debbugs.gnu.org; Sat, 12 Jan 2013 11:06:56 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoHAG6Zu09FpZpV/2dsb2JhbABEgXuuTYNJgQiCFQEBBAFWIwULCzQSFBgNJIgcBboJkEQDiEKacYFYgwc X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="212364961" Received: from 69-165-154-85.dsl.teksavvy.com (HELO pastel.home) ([69.165.154.85]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 12 Jan 2013 11:06:36 -0500 Received: by pastel.home (Postfix, from userid 20848) id 5E666592A5; Sat, 12 Jan 2013 11:06:33 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B Message-ID: References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> <838v80ugv1.fsf@gnu.org> <50F021EC.4040107@gmx.at> <50F054A0.2040606@gmx.at> <83libztt68.fsf@gnu.org> <83hammu7og.fsf@gnu.org> <83sj66sd61.fsf@gnu.org> Date: Sat, 12 Jan 2013 11:06:33 -0500 In-Reply-To: <83sj66sd61.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 12 Jan 2013 16:12:38 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 13399 Cc: rudalics@gmx.at, 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > What else is needed, that the glyph matrix > of the window would provide? Caching, tho maybe it doesn't matter. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 12 11:38:26 2013 Received: (at 13399) by debbugs.gnu.org; 12 Jan 2013 16:38:27 +0000 Received: from localhost ([127.0.0.1]:57142 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tu46E-0002dA-FS for submit@debbugs.gnu.org; Sat, 12 Jan 2013 11:38:26 -0500 Received: from mout.gmx.net ([212.227.15.18]:61774) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tu46C-0002cy-SV for 13399@debbugs.gnu.org; Sat, 12 Jan 2013 11:38:25 -0500 Received: from mailout-de.gmx.net ([10.1.76.31]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0LaI9g-1TFpVz2370-00lzz7 for <13399@debbugs.gnu.org>; Sat, 12 Jan 2013 17:38:05 +0100 Received: (qmail invoked by alias); 12 Jan 2013 16:38:05 -0000 Received: from 62-47-61-165.adsl.highway.telekom.at (EHLO [62.47.61.165]) [62.47.61.165] by mail.gmx.net (mp031) with SMTP; 12 Jan 2013 17:38:05 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/VmoUH8AXVypRkuZTRF4vXPl1U0nHWSa9Xqt1/E2 6nzuejdxpnA9eI Message-ID: <50F19165.1060600@gmx.at> Date: Sat, 12 Jan 2013 17:37:57 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> <838v80ugv1.fsf@gnu.org> <50F021EC.4040107@gmx.at> <50F054A0.2040606@gmx.at> <83pq1btu5p.fsf@gnu.org> <50F17365.6050006@gmx.at> <83obgusb4w.fsf@gnu.org> In-Reply-To: <83obgusb4w.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 13399 Cc: monnier@iro.umontreal.ca, 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > fit-window-to-buffer should probably call pos-visible-in-window-p with > argument PARTIALLY non-nil, and then it should be possible to get rid > of the loop. But PARTIALLY nil means to return nil if the position is only partially visible. And in this case `fit-window-to-buffer' should try to enlarge the window. > I think what you see only happens when the last line is partially > visible (where "partially" might mean just one of its pixels). If > that is not desirable, then we will need to be more accurate when we > say "visible" and have a more precise definition of what exactly > constitutes a window's height when a single line, in particular the > last one, might have characters of different descent values. > > In any case, this is a failure in fit-window-to-buffer, if anything, > it is not necessarily an evidence that move_it_* functions fail. Maybe. I now call `count-screen-lines' with COUNT-FINAL-NEWLINE t and this seems to work although I'm quite sure that it didn't work earlier. I think for the moment I'll just add a COUNT-FINAL-NEWLINE argument to `fit-window-to-buffer' and see whether it works. martin From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 12 11:52:15 2013 Received: (at 13399) by debbugs.gnu.org; 12 Jan 2013 16:52:15 +0000 Received: from localhost ([127.0.0.1]:57150 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tu4Ja-0002wl-UA for submit@debbugs.gnu.org; Sat, 12 Jan 2013 11:52:15 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:40548) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tu4JX-0002wW-Hl for 13399@debbugs.gnu.org; Sat, 12 Jan 2013 11:52:12 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MGI00200UO7IW00@a-mtaout22.012.net.il> for 13399@debbugs.gnu.org; Sat, 12 Jan 2013 18:51:34 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MGI002EAUTY4CB0@a-mtaout22.012.net.il>; Sat, 12 Jan 2013 18:51:34 +0200 (IST) Date: Sat, 12 Jan 2013 18:51:59 +0200 From: Eli Zaretskii Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B In-reply-to: <50F19165.1060600@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83libys5sg.fsf@gnu.org> References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> <838v80ugv1.fsf@gnu.org> <50F021EC.4040107@gmx.at> <50F054A0.2040606@gmx.at> <83pq1btu5p.fsf@gnu.org> <50F17365.6050006@gmx.at> <83obgusb4w.fsf@gnu.org> <50F19165.1060600@gmx.at> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 13399 Cc: monnier@iro.umontreal.ca, 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > Date: Sat, 12 Jan 2013 17:37:57 +0100 > From: martin rudalics > CC: monnier@iro.umontreal.ca, 13399@debbugs.gnu.org > > > fit-window-to-buffer should probably call pos-visible-in-window-p with > > argument PARTIALLY non-nil, and then it should be possible to get rid > > of the loop. > > But PARTIALLY nil means to return nil if the position is only partially > visible. And in this case `fit-window-to-buffer' should try to enlarge > the window. Should it? It enlarges the window in line units, so the enlarged window will again show a partially visible line, no? > I now call `count-screen-lines' with COUNT-FINAL-NEWLINE t and > this seems to work although I'm quite sure that it didn't work earlier. count-screen-lines relies on vertical-motion, which got several improvements lately. Maybe this is the reason. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 12 13:01:47 2013 Received: (at 13399) by debbugs.gnu.org; 12 Jan 2013 18:01:47 +0000 Received: from localhost ([127.0.0.1]:57198 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tu5Os-0004dK-7Y for submit@debbugs.gnu.org; Sat, 12 Jan 2013 13:01:47 -0500 Received: from mout.gmx.net ([212.227.15.18]:57869) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tu5Op-0004d3-Q6 for 13399@debbugs.gnu.org; Sat, 12 Jan 2013 13:01:44 -0500 Received: from mailout-de.gmx.net ([10.1.76.30]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MckQB-1TcHWn1OKH-00HyYq for <13399@debbugs.gnu.org>; Sat, 12 Jan 2013 19:01:24 +0100 Received: (qmail invoked by alias); 12 Jan 2013 18:01:24 -0000 Received: from 62-47-61-165.adsl.highway.telekom.at (EHLO [62.47.61.165]) [62.47.61.165] by mail.gmx.net (mp030) with SMTP; 12 Jan 2013 19:01:24 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18kbtp9Y/gk4jBmoUTPiqjm0s2Rj//KZOYNRSlBh0 76dQ0FYChz0d7k Message-ID: <50F1A4EC.7090702@gmx.at> Date: Sat, 12 Jan 2013 19:01:16 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> <838v80ugv1.fsf@gnu.org> <50F021EC.4040107@gmx.at> <50F054A0.2040606@gmx.at> <83pq1btu5p.fsf@gnu.org> <50F17365.6050006@gmx.at> <83obgusb4w.fsf@gnu.org> <50F19165.1060600@gmx.at> <83libys5sg.fsf@gnu.org> In-Reply-To: <83libys5sg.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 13399 Cc: monnier@iro.umontreal.ca, 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> But PARTIALLY nil means to return nil if the position is only partially >> visible. And in this case `fit-window-to-buffer' should try to enlarge >> the window. > > Should it? It enlarges the window in line units, so the enlarged > window will again show a partially visible line, no? That's the clue. The bug is in this part of `fit-window-to-buffer': (if (zerop delta) ;; Return zero if DELTA became zero in the process. 0 The delta comes from `count-screen-lines' and that function returns the number of lines in the buffer but NOT in canonical line units. Removing this conditional now seems to fix the problem for sure. Still `fit-window-to-buffer' would benefit from a function that returned either the pixel height needed for displaying the region or its number of canonical line units. Obviously, the former would be preferable when we switch to pixel-sized windows. martin From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 12 13:38:34 2013 Received: (at 13399) by debbugs.gnu.org; 12 Jan 2013 18:38:34 +0000 Received: from localhost ([127.0.0.1]:57234 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tu5yT-0005UT-Uh for submit@debbugs.gnu.org; Sat, 12 Jan 2013 13:38:34 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:61871) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tu5yR-0005UG-Vl for 13399@debbugs.gnu.org; Sat, 12 Jan 2013 13:38:33 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MGI00100ZFZ7700@a-mtaout20.012.net.il> for 13399@debbugs.gnu.org; Sat, 12 Jan 2013 20:38:11 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MGI000R7ZRMQAC0@a-mtaout20.012.net.il>; Sat, 12 Jan 2013 20:38:11 +0200 (IST) Date: Sat, 12 Jan 2013 20:38:35 +0200 From: Eli Zaretskii Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B In-reply-to: <50F1A4EC.7090702@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83hamms0us.fsf@gnu.org> References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> <838v80ugv1.fsf@gnu.org> <50F021EC.4040107@gmx.at> <50F054A0.2040606@gmx.at> <83pq1btu5p.fsf@gnu.org> <50F17365.6050006@gmx.at> <83obgusb4w.fsf@gnu.org> <50F19165.1060600@gmx.at> <83libys5sg.fsf@gnu.org> <50F1A4EC.7090702@gmx.at> X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 13399 Cc: monnier@iro.umontreal.ca, 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > Date: Sat, 12 Jan 2013 19:01:16 +0100 > From: martin rudalics > CC: monnier@iro.umontreal.ca, 13399@debbugs.gnu.org > > Still `fit-window-to-buffer' would benefit from a function that returned > either the pixel height needed for displaying the region or its number > of canonical line units. Obviously, the former would be preferable when > we switch to pixel-sized windows. Would something like this be good enough? (save-excursion (move-beginning-of-line 1) (setq pos1 (posn-at-point))) (save-excursion (move-beginning-of-line 2) (setq pos2 (posn-at-point))) Then use the Y member of the returned information in pos1 and pos2. (Alternatively, you could do something similar with pos-visible-in-window-p instead of posn-at-point.) Will this fit the bill? From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 14 13:05:03 2013 Received: (at 13399) by debbugs.gnu.org; 14 Jan 2013 18:05:03 +0000 Received: from localhost ([127.0.0.1]:60175 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TuoP7-0006Yy-Ul for submit@debbugs.gnu.org; Mon, 14 Jan 2013 13:05:02 -0500 Received: from mout.gmx.net ([212.227.15.18]:60631) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TuoP3-0006YV-Gv for 13399@debbugs.gnu.org; Mon, 14 Jan 2013 13:04:59 -0500 Received: from mailout-de.gmx.net ([10.1.76.32]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MRydg-1TX7fE29t4-00TENN for <13399@debbugs.gnu.org>; Mon, 14 Jan 2013 19:04:26 +0100 Received: (qmail invoked by alias); 14 Jan 2013 18:04:26 -0000 Received: from 62-47-40-2.adsl.highway.telekom.at (EHLO [62.47.40.2]) [62.47.40.2] by mail.gmx.net (mp032) with SMTP; 14 Jan 2013 19:04:26 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18aYC06EWAaxN1mKm7IF0ZNNI6dGCyrWHSy7yirlF ILpbPz+2O3630P Message-ID: <50F4489F.4090801@gmx.at> Date: Mon, 14 Jan 2013 19:04:15 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> <838v80ugv1.fsf@gnu.org> <50F021EC.4040107@gmx.at> <50F054A0.2040606@gmx.at> <83pq1btu5p.fsf@gnu.org> <50F17365.6050006@gmx.at> <83obgusb4w.fsf@gnu.org> <50F19165.1060600@gmx.at> <83libys5sg.fsf@gnu.org> <50F1A4EC.7090702@gmx.at> <83hamms0us.fsf@gnu.org> In-Reply-To: <83hamms0us.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 13399 Cc: monnier@iro.umontreal.ca, 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.5 (/) > Would something like this be good enough? > > (save-excursion > (move-beginning-of-line 1) > (setq pos1 (posn-at-point))) > (save-excursion > (move-beginning-of-line 2) > (setq pos2 (posn-at-point))) > > Then use the Y member of the returned information in pos1 and pos2. Looks like this should work. But at the moment I'm a bit lost with the information returned by `posn-at-point': What precisely stands the value of (nth 2 (posn-at-point (point-max))) for? If my buffer ends with a newline, is that the value of the lowest pixel of the chararacter box of the character just above the cursor? Can it include line spacing? I wonder because I find this calculation in `posn-col-row' confusing: (- (/ (cdr pair) (+ (frame-char-height frame) spacing)) (if (null (with-current-buffer (window-buffer window) header-line-format)) 0 1)))))))) It does not round values, so the value of rows can be less than needed for showing the entire text. OTOH it seems to apply spacing to the last line of a buffer. Finally, if a buffer wants a headerline, evaluating (posn-col-row (posn-at-point (point-min))) gives (0 . -1). Is that useful? So I'm working with the raw data returned by `posn-at-point' and the results are not worse than with the current approach. But I still seem to lose some pixels somewhere ... martin From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 02 11:49:57 2013 Received: (at 13399) by debbugs.gnu.org; 2 Feb 2013 16:49:57 +0000 Received: from localhost ([127.0.0.1]:33075 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U1gHq-0004N5-WB for submit@debbugs.gnu.org; Sat, 02 Feb 2013 11:49:57 -0500 Received: from mout.gmx.net ([212.227.15.18]:58831) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U1gHk-0004Mn-Df for 13399@debbugs.gnu.org; Sat, 02 Feb 2013 11:49:52 -0500 Received: from mailout-de.gmx.net ([10.1.76.2]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MQ9JV-1U6Mxq0btj-005J57 for <13399@debbugs.gnu.org>; Sat, 02 Feb 2013 17:48:53 +0100 Received: (qmail invoked by alias); 02 Feb 2013 16:48:51 -0000 Received: from 62-47-50-198.adsl.highway.telekom.at (EHLO [62.47.50.198]) [62.47.50.198] by mail.gmx.net (mp002) with SMTP; 02 Feb 2013 17:48:51 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18UlkYyLkwUIjYnIzTL8mSgx6xxA5k1CxwyojXVFW 5jEI+oBRmH36Sj Message-ID: <510D436A.1000603@gmx.at> Date: Sat, 02 Feb 2013 17:48:42 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> <838v80ugv1.fsf@gnu.org> <50F021EC.4040107@gmx.at> <50F054A0.2040606@gmx.at> <83libztt68.fsf@gnu.org> <83hammu7og.fsf@gnu.org> In-Reply-To: <83hammu7og.fsf@gnu.org> Content-Type: multipart/mixed; boundary="------------010408070805070106050800" X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 13399 Cc: Stefan Monnier , 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) This is a multi-part message in MIME format. --------------010408070805070106050800 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit > But why would we need that? Most everything we need to know about > display is already tracked by the display iterator, so available even > without generating glyphs, and that's what the move_it_* functions do. > These function do their job by traversing only small portions of the > buffer, just large enough for the job at hand to be done. I rewrote `fit-window-to-buffer' and `fit-frame-to-buffer' using the display iterator. Please have a look at the attached patch. Thanks, martin --------------010408070805070106050800 Content-Type: text/plain; name="fit-window-to-buffer.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="fit-window-to-buffer.diff" =3D=3D=3D modified file 'lisp/window.el' --- lisp/window.el 2013-01-02 16:13:04 +0000 +++ lisp/window.el 2013-02-02 14:58:22 +0000 @@ -6074,211 +6074,428 @@ (eobp) window)))) =20 -;;; Resizing buffers to fit their contents exactly. +;;; Resizing windows and frames to fit their contents exactly. +(defcustom fit-window-to-buffer-horizontally nil + "Non-nil means `fit-window-to-buffer' can resize windows horizontally.= +If this is nil, `fit-window-to-buffer' never resizes windows +horizontally. If this is `only', it can resize windows +horizontally only. Any other value means `fit-window-to-buffer' +can resize windows in both dimensions." + :type 'boolean + :version "24.4" + :group 'help) + (defcustom fit-frame-to-buffer nil - "Non-nil means `fit-window-to-buffer' can resize frames. + "Non-nil means `fit-frame-to-buffer' can resize frames. A frame can be resized if and only if its root window is a live -window. The height of the root window is subject to the values -of `fit-frame-to-buffer-max-height' and `window-min-height'." +window. If this is `horizontally', frames can be resized +horizontally only. If this is `vertically', frames can be +resized vertically only. Any other non-nil value means frames +can be resized in both dimensions. See also +`fit-frame-to-buffer-margins' and `fit-frame-to-buffer-sizes'." :type 'boolean - :version "24.3" + :version "24.4" :group 'help) =20 -(defcustom fit-frame-to-buffer-bottom-margin 4 - "Bottom margin for the command `fit-frame-to-buffer'. -This is the number of lines that function leaves free at the bottom of -the display, in order to not obscure any system task bar or panel. -If you do not have one (or if it is vertical) you might want to -reduce this. If it is thicker, you might want to increase this." - ;; If you set this too small, fit-frame-to-buffer can shift the - ;; frame up to avoid the panel. - :type 'integer - :version "24.3" - :group 'windows) - -(defun fit-frame-to-buffer (&optional frame max-height min-height) +(defcustom fit-frame-to-buffer-margins '(0 0 0 72) + "Margins around frame for `fit-frame-to-buffer'. +This list specifies the numbers of pixels to be left free on the +left, above, the right, and below a frame that shall be fit to +its buffer. The value specified here can be overridden for a +specific frame by that frame's `fit-frame-to-buffer-margins' +parameter, if present. + +On some window systems the calculation of frame sizes can be +incorrect. Increasing the value of the third and/or fourth +element of this variable can fix that. + +See also `fit-frame-to-buffer-sizes'." + :version "24.4" + :type '(list + (integer :tag "Left" :size 5) + (integer :tag " Above" :size 5) + (integer :tag " Right" :size 5) + (integer :tag " Below" :size 5)) + :group 'windows) + +(defcustom fit-frame-to-buffer-sizes '(nil nil nil nil) + "Size boundaries of frame for `fit-frame-to-buffer'. +This list specifies the total maximum and minimum lines and +maximum and minimum columns of the root window of any frame that +shall be fit to its buffer. If any of these values is non-nil, +it will override the value supplied by the respective arguments +of `fit-frame-to-buffer'. + +On window systems where the menubar can wrap, fitting a frame to +its buffer may swallow the last line(s). Specifying an +appropriate minimum width value here can avoid such wrapping. + +See also `fit-frame-to-buffer-margins'." + :version "24.4" + :type '(list + (choice + :tag "Maximum Height" + :value nil + :format "%[MaxHeight%] %v " + (const :tag "None" :format "%t" nil) + (integer :tag "Lines" :size 5)) + (choice + :tag "Minimum Height" + :value nil + :format "%[MinHeight%] %v " + (const :tag "None" :format "%t" nil) + (integer :tag "Lines" :size 5)) + (choice + :tag "Maximum Width" + :value nil + :format "%[MaxWidth%] %v " + (const :tag "None" :format "%t" nil) + (integer :tag "Columns" :size 5)) + (choice + :tag "Minimum Width" + :value nil + :format "%[MinWidth%] %v\n" + (const :tag "None" :format "%t" nil) + (integer :tag "Columns" :size 5))) + :group 'windows) + +(defun window--sanitize-margin (margin left right) + "Return MARGIN if it's a number between LEFT and RIGHT." + (if (and (numberp margin) + (<=3D left (- right margin)) (<=3D margin right)) + margin + 0)) + +(defun fit-frame-to-buffer (&optional frame max-height min-height max-wi= dth min-width) "Adjust height of FRAME to display its buffer contents exactly. FRAME can be any live frame and defaults to the selected one. +MAX-HEIGHT, MIN-HEIGHT, MAX-WIDTH and MIN-WIDTH specify bounds on +the new total size of FRAME's root window. =20 -Optional argument MAX-HEIGHT specifies the maximum height of FRAME. -It defaults to the height of the display below the current -top line of FRAME, minus `fit-frame-to-buffer-bottom-margin'. -Optional argument MIN-HEIGHT specifies the minimum height of FRAME. -The default corresponds to `window-min-height'." +The option `fit-frame-to-buffer' controls whether this function +has any effect. New position and size of FRAME are additionally +determined by the options `fit-frame-to-buffer-sizes' and +`fit-frame-to-buffer-margins' or the corresponding parameters of +FRAME. This function can fail to fit the buffer's height when +`word-wrap' is turned on in that buffer." (interactive) (setq frame (window-normalize-frame frame)) - (let* ((root (frame-root-window frame)) - (frame-min-height - (+ (- (frame-height frame) (window-total-size root)) - window-min-height)) - (frame-top (frame-parameter frame 'top)) - (top (if (consp frame-top) - (funcall (car frame-top) (cadr frame-top)) - frame-top)) - (frame-max-height - (- (/ (- (x-display-pixel-height frame) top) - (frame-char-height frame)) - fit-frame-to-buffer-bottom-margin)) - (compensate 0) - delta) - (when (and (window-live-p root) (not (window-size-fixed-p root))) - (with-selected-window root - (cond - ((not max-height) - (setq max-height frame-max-height)) - ((numberp max-height) - (setq max-height (min max-height frame-max-height))) - (t - (error "%s is an invalid maximum height" max-height))) - (cond - ((not min-height) - (setq min-height frame-min-height)) - ((numberp min-height) - (setq min-height (min min-height frame-min-height))) - (t - (error "%s is an invalid minimum height" min-height))) - ;; When tool-bar-mode is enabled and we have just created a new - ;; frame, reserve lines for toolbar resizing. This is needed - ;; because for reasons unknown to me Emacs (1) reserves one line - ;; for the toolbar when making the initial frame and toolbars - ;; are enabled, and (2) later adds the remaining lines needed. - ;; Our code runs IN BETWEEN (1) and (2). YMMV when you're on a - ;; system that behaves differently. - (let ((quit-restore (window-parameter root 'quit-restore)) - (lines (tool-bar-lines-needed frame))) - (when (and quit-restore (eq (car quit-restore) 'frame) - (not (zerop lines))) - (setq compensate (1- lines)))) - (message "%s" compensate) - (setq delta - ;; Always count a final newline - we don't do any - ;; post-processing, so let's play safe. - (+ (count-screen-lines nil nil t) - (- (window-body-size)) - compensate))) - ;; Move away from final newline. - (when (and (eobp) (bolp) (not (bobp))) - (set-window-point root (line-beginning-position 0))) - (set-window-start root (point-min)) - (set-window-vscroll root 0) - (condition-case nil - (set-frame-height - frame - (min (max (+ (frame-height frame) delta) - min-height) - max-height)) - (error (setq delta nil)))) - delta)) + (when (and (window-live-p (frame-root-window frame)) + fit-frame-to-buffer + (or (not window-size-fixed) + (and (eq window-size-fixed 'height) + (not (eq fit-frame-to-buffer 'vertically))) + (and (eq window-size-fixed 'width) + (not (eq fit-frame-to-buffer 'horizontally))))) + (with-selected-window (frame-root-window frame) + (let* ((window (frame-root-window frame)) + (char-width (frame-char-width)) + (char-height (frame-char-height)) + (display-width (display-pixel-width frame)) + (display-height (display-pixel-height frame)) + ;; Sanitize margins. + (margins (or (frame-parameter frame 'fit-frame-to-buffer-margins) + fit-frame-to-buffer-margins)) + (left-margin (window--sanitize-margin + (nth 0 margins) 0 display-width)) + (top-margin (window--sanitize-margin + (nth 1 margins) 0 display-height)) + (right-margin (window--sanitize-margin + (nth 2 margins) left-margin display-width)) + (bottom-margin (window--sanitize-margin + (nth 3 margins) top-margin display-height)) + ;; The pixel width of FRAME. + (frame-width (frame-pixel-width)) + ;; The difference between FRAME's pixel and parameter + ;; widths. + (frame-extra-width + (- frame-width (* (frame-width) char-width))) + ;; The pixel height of FRAME's window. + (window-body-width (* (window-body-width) char-width)) + ;; The difference in pixels between total and body width of + ;; FRAME's window. + (window-extra-width + (- (* (window-total-width) char-width) window-body-width)) + ;; The difference in pixels between the frame's pixel width + ;; and the window's body width. + (extra-width + (* char-width (- (frame-width) (window-body-width)))) + ;; The maximum width we can use for fitting. + (fit-width + (- display-width (- frame-width window-body-width) + left-margin right-margin)) + ;; The pixel position of FRAME's left border. We usually + ;; try to leave this alone. + (left + (let ((left (frame-parameter nil 'left))) + (if (consp left) + (funcall (car left) (cadr left)) + left))) + ;; The pixel height of FRAME. + (frame-height (frame-pixel-height)) + ;; The difference between FRAME's pixel and parameter + ;; heights. + (frame-extra-height + (- frame-height (* (frame-height) char-height))) + ;; When tool-bar-mode is enabled and we just created a new + ;; frame, reserve lines for toolbar resizing. Needed + ;; because for reasons unknown to me Emacs (1) reserves one + ;; line for the toolbar when making the initial frame and + ;; toolbars are enabled, and (2) later adds the remaining + ;; lines needed. Our code runs IN BETWEEN (1) and (2). + ;; YMMV when you're on a system that behaves differently. + (toolbar-extra-height + (let ((quit-restore (window-parameter window 'quit-restore)) + (lines (tool-bar-lines-needed frame))) + (* char-height + (if (and quit-restore (eq (car quit-restore) 'frame) + (not (zerop lines))) + (1- lines) + 0)))) + ;; The pixel height of FRAME's window. + (window-body-height (* (window-body-height) char-height)) + ;; The difference in pixels between total and body height + ;; of FRAME's window. + (window-extra-height + (- (* (window-total-height) char-height) window-body-height)) + ;; The difference in pixels between the frame's pixel + ;; height and the window's body height. + (extra-height + (* (- (frame-height) (window-body-height)) char-height)) + ;; The maximum height we can use for fitting. + (fit-height + (- display-height (- frame-height window-body-height) + top-margin bottom-margin toolbar-extra-height)) + ;; The pixel position of FRAME's top border. We usually + ;; try to leave this alone. + (top + (let ((top (frame-parameter nil 'top))) + (if (consp top) + (funcall (car top) (cadr top)) + top))) + ;; Sanitize minimum and maximum sizes. + (sizes (or (frame-parameter frame 'fit-frame-to-buffer-sizes) + fit-frame-to-buffer-sizes)) + (max-height + (cond + ((numberp (nth 0 sizes)) + (- (* (nth 0 sizes) char-height) window-extra-height)) + ((numberp max-height) + (- (* max-height char-height) window-extra-height)))) + (min-height + (cond + ((numberp (nth 1 sizes)) + (- (* (nth 1 sizes) char-height) window-extra-height)) + ((numberp min-height) + (- (* min-height char-height) window-extra-height)))) + (max-width + (cond + ((numberp (nth 2 sizes)) + (- (* (nth 2 sizes) char-width) window-extra-width)) + ((numberp max-width) + (- (* max-width char-width) window-extra-width)))) + (min-width + (cond + ((numberp (nth 3 sizes)) + (- (* (nth 3 sizes) char-width) window-extra-width)) + ((numberp min-width) + (- (* min-width char-width) window-extra-width)))) + (value (window-buffer-pixel-size + nil (point-min) (point-max) + display-width display-height)) + (width (car value)) + (height (cdr value)) + remainder) + ;; Round sizes (hopefully we can drop these as soon as we can + ;; resize pixelwise). First add pixels to obtain full last + ;; lines and columns. + (setq remainder (% width char-width)) + (unless (zerop remainder) + (setq width (+ width (- char-width remainder)))) + (setq remainder (% height char-height)) + (setq height (+ height (- char-height remainder))) + ;; Now make sure that we don't get larger than our rounded + ;; maximum lines and columns. + (when (> width fit-width) + (setq width (- fit-width (% fit-width char-width)))) + (when (> height fit-height) + (setq height (- fit-height (% fit-height char-height)))) + ;; Don't change height or width when the window's size is fixed + ;; in either direction. + (cond + ((eq window-size-fixed 'height) + (setq height nil)) + ((eq window-size-fixed 'width) + (setq height nil))) + (when width + ;; Fit to maximum and minimum widths. + (when max-width + (setq width (min width max-width))) + (when min-width + (setq width (max width min-width))) + ;; Add extra width. + (setq width (+ width extra-width)) + ;; Preserve right margin. + (let ((right (+ left width frame-extra-width)) + (max-right (- display-width right-margin))) + (cond + ((> right max-right) + ;; Move FRAME to left. + (setq left (max 0 (- left (- right max-right))))) + ((< left left-margin) + ;; Move frame to right. + (setq left left-margin))))) + (when height + ;; Fit to maximum and minimum heights. + (when max-height + (setq height (min height max-height))) + (when min-height + (setq height (max height min-height))) + ;; Add extra height. + (setq height (+ height extra-height)) + ;; Preserve bottom and top margins. + (let ((bottom (+ top height frame-extra-height)) + (max-bottom (- display-height bottom-margin))) + (cond + ((> bottom max-bottom) + ;; Move FRAME to left. + (setq top (max 0 (- top (- bottom max-bottom))))) + ((< top top-margin) + ;; Move frame down. + (setq top top-margin))))) + ;; Apply changes. + (set-frame-position frame left top) + (set-frame-size + frame + (if width (/ width char-width) (frame-width)) + (if height (/ height char-height) (frame-height))))))) =20 -(defun fit-window-to-buffer (&optional window max-height min-height) - "Adjust height of WINDOW to display its buffer's contents exactly. +(defun fit-window-to-buffer (&optional window max-height min-height max-= width min-width) + "Adjust size of WINDOW to display its buffer's contents exactly. WINDOW must be a live window and defaults to the selected one. =20 -Optional argument MAX-HEIGHT specifies the maximum height of -WINDOW and defaults to the height of WINDOW's frame. Optional -argument MIN-HEIGHT specifies the minimum height of WINDOW and -defaults to `window-min-height'. Both MAX-HEIGHT and MIN-HEIGHT -are specified in lines and include the mode line and header line, -if any. - -If WINDOW is a full height window, then if the option -`fit-frame-to-buffer' is non-nil, this calls the function -`fit-frame-to-buffer' to adjust the frame height. - -Return the number of lines by which WINDOW was enlarged or -shrunk. If an error occurs during resizing, return nil but don't -signal an error. +If WINDOW is part of a vertical combination, adjust WINDOW's +height. The new height is calculated from the number of lines of +the accessible portion of its buffer. The optional argument +MAX-HEIGHT specifies a maximum height and defaults to the height +of WINDOW's frame. The optional argument MIN-HEIGHT specifies a +minimum height and defaults to `window-min-height'. Both +MAX-HEIGHT and MIN-HEIGHT are specified in lines and include the +mode line and header line, if any. + +If WINDOW is part of a horizontal combination and the value of +the option `fit-window-to-buffer-horizontally' is non-nil, adjust +WINDOW's height. The new width of WINDOW is calculated from the +maximum length of its buffer's lines that follow the current +start position of WINDOW. The optional argument MAX-WIDTH +specifies a maximum width and defaults to the width of WINDOW's +frame. The optional argument MIN-WIDTH specifies a minimum width +and defaults to `window-min-width'. Both MAX-WIDTH and MIN-WIDTH +are specified in columns and include fringes, margins and +scrollbars, if any. + +If WINDOW is its frame's root window, then if the option +`fit-frame-to-buffer' is non-nil, call `fit-frame-to-buffer' to +adjust the frame's size. =20 Note that even if this function makes WINDOW large enough to show -_all_ lines of its buffer you might not see the first lines when -WINDOW was scrolled." +_all_ parts of its buffer you might not see the first part when +WINDOW was scrolled. If WINDOW is resized horizontally, you will +not see the top of its buffer unless WINDOW starts at its minimum +accessible position." (interactive) (setq window (window-normalize-window window t)) - (cond - ((window-size-fixed-p window)) - ((window-full-height-p window) - (when fit-frame-to-buffer - (fit-frame-to-buffer (window-frame window)))) - (t + (if (eq window (frame-root-window window)) + (when fit-frame-to-buffer + ;; Fit WINDOW's frame to buffer. + (fit-frame-to-buffer + (window-frame window) max-height min-height max-width min-width)) (with-selected-window window - (let* ((height (window-total-size)) + (let* ((frame (window-frame)) + (char-height (frame-char-height)) + (char-width (frame-char-width)) + (display-height (display-pixel-height)) + (total-height (window-total-height)) + (body-height (window-body-height)) + (body-width (window-body-width)) (min-height - ;; Adjust MIN-HEIGHT. + ;; Sanitize MIN-HEIGHT. (if (numberp min-height) ;; Can't get smaller than `window-safe-min-height'. (max min-height window-safe-min-height) ;; Preserve header and mode line if present. (window-min-size nil nil t))) (max-height - ;; Adjust MAX-HEIGHT. + ;; Sanitize MAX-HEIGHT. (if (numberp max-height) - ;; Can't get larger than height of frame. - (min max-height - (window-total-size (frame-root-window window))) - ;; Don't delete other windows. - (+ height (window-max-delta nil nil window)))) - ;; Make `desired-height' the height necessary to show - ;; all of WINDOW's buffer, constrained by MIN-HEIGHT - ;; and MAX-HEIGHT. - (desired-height - (max - (min - (+ (count-screen-lines) - ;; For non-minibuffers count the mode line, if any. - (if (and (not (window-minibuffer-p window)) - mode-line-format) - 1 - 0) - ;; Count the header line, if any. - (if header-line-format 1 0)) - max-height) - min-height)) - (desired-delta - (- desired-height (window-total-size window))) - (delta - (if (> desired-delta 0) - (min desired-delta - (window-max-delta window nil window)) - (max desired-delta - (- (window-min-delta window nil window)))))) - (condition-case nil - (if (zerop delta) - ;; Return zero if DELTA became zero in the process. - 0 - ;; Don't try to redisplay with the cursor at the end on its - ;; own line--that would force a scroll and spoil things. - (when (and (eobp) (bolp) (not (bobp))) - ;; It's silly to put `point' at the end of the previous - ;; line and so maybe force horizontal scrolling. - (set-window-point window (line-beginning-position 0))) - ;; Call `window-resize' with OVERRIDE argument equal WINDOW. - (window-resize window delta nil window) - ;; Check if the last line is surely fully visible. If - ;; not, enlarge the window. - (let ((end (save-excursion - (goto-char (point-max)) - (when (and (bolp) (not (bobp))) - ;; Don't include final newline. - (backward-char 1)) - (when truncate-lines - ;; If line-wrapping is turned off, test the - ;; beginning of the last line for - ;; visibility instead of the end, as the - ;; end of the line could be invisible by - ;; virtue of extending past the edge of the - ;; window. - (forward-line 0)) - (point)))) - (set-window-vscroll window 0) - ;; This loop might in some rare pathological cases raise - ;; an error - another reason for the `condition-case'. - (while (and (< desired-height max-height) - (=3D desired-height (window-total-size)) - (not (pos-visible-in-window-p end))) - (window-resize window 1 nil window) - (setq desired-height (1+ desired-height))))) - (error (setq delta nil))) - delta))))) + (min (+ total-height (window-max-delta)) max-height) + (+ total-height (window-max-delta)))) + height) + (cond + ;; If WINDOW is vertically combined, try to resize it + ;; vertically. + ((and (not (eq fit-window-to-buffer-horizontally 'only)) + (not (window-size-fixed-p window)) + (window-combined-p)) + ;; Vertically we always want to fit the entire buffer. + ;; WINDOW'S height can't get larger than its frame's pixel + ;; height. Its width remains fixed. + (setq height (cdr (window-buffer-pixel-size + nil (point-min) (point-max) + (* body-width char-width) + (frame-pixel-height)))) + ;; Round height. + (setq height (+ (/ height char-height) + (if (zerop (% height char-height)) 0 1))) + (unless (=3D height body-height) + (window-resize-no-error + window + (- (max min-height + (min max-height + (+ total-height (- height body-height)))) + total-height) + nil window))) + ;; If WINDOW is horizontally combined, try to resize it + ;; horizontally. + ((and fit-window-to-buffer-horizontally + (not (window-size-fixed-p window t)) + (window-combined-p nil t)) + (let* ((display-width (display-pixel-width)) + (total-width (window-total-width)) + (min-width + ;; Sanitize MIN-WIDTH. + (if (numberp min-width) + ;; Can't get smaller than `window-safe-min-width'. + (max min-width window-safe-min-width) + ;; Preserve fringes, margines, scrollbars if present. + (window-min-size nil nil t))) + (max-width + ;; Sanitize MAX-WIDTH. + (if (numberp max-width) + (min (+ total-width (window-max-delta nil t)) max-width) + (+ total-width (window-max-delta nil t)))) + ;; When fitting vertically, assume that WINDOW's start + ;; position remains unaltered. WINDOW can't get wider + ;; than its frame's pixel width, its height remains + ;; unaltered. + (width (car (window-buffer-pixel-size + nil (window-start) (point-max) + (frame-pixel-width) + ;; Add one char-height to assure that + ;; we're on the safe side. This + ;; overshoots when the first line below + ;; the bottom is wider than the window. + (* body-height char-height))))) + (setq width (+ (/ width char-width) + (if (zerop (% width char-width)) 0 1))) + (unless (=3D width body-width) + (window-resize-no-error + window + (- (max min-width + (min max-width + (+ total-width (- width body-width)))) + total-width) + t window))))))))) =20 (defun window-safely-shrinkable-p (&optional window) "Return t if WINDOW can be shrunk without shrinking other windows. =3D=3D=3D modified file 'src/dispextern.h' --- src/dispextern.h 2013-01-02 16:13:04 +0000 +++ src/dispextern.h 2013-02-02 14:56:54 +0000 @@ -2489,6 +2489,9 @@ pixel_width with each call to produce_glyphs. */ int current_x; =20 + /* Maximum x pixel position encountered within a display line. */ + int max_current_x; + /* Accumulated width of continuation lines. If > 0, this means we are currently in a continuation line. This is initially zero and incremented/reset by display_line, move_it_to etc. */ =3D=3D=3D modified file 'src/xdisp.c' --- src/xdisp.c 2013-01-05 21:18:01 +0000 +++ src/xdisp.c 2013-02-02 14:56:32 +0000 @@ -2996,7 +2996,7 @@ =20 it->current_y =3D first_y; it->vpos =3D 0; - it->current_x =3D it->hpos =3D 0; + it->current_x =3D it->max_current_x =3D it->hpos =3D 0; } } } @@ -8814,7 +8814,10 @@ =20 /* If TO_CHARPOS is reached or ZV, we don't have to do more. */ if (skip =3D=3D MOVE_POS_MATCH_OR_ZV) - reached =3D 5; + { + it->max_current_x =3D max (it->current_x, it->max_current_x); + reached =3D 5; + } else if (skip =3D=3D MOVE_X_REACHED) { /* If TO_X was reached, we want to know whether TO_Y is @@ -8883,6 +8886,8 @@ skip =3D move_it_in_display_line_to (it, -1, prev_x, MOVE_TO_X); } + + it->max_current_x =3D max (it->current_x, it->max_current_x); reached =3D 6; } } @@ -8908,15 +8913,18 @@ switch (skip) { case MOVE_POS_MATCH_OR_ZV: + it->max_current_x =3D max (it->current_x, it->max_current_x); reached =3D 8; goto out; =20 case MOVE_NEWLINE_OR_CR: + it->max_current_x =3D max (it->current_x, it->max_current_x); set_iterator_to_next (it, 1); it->continuation_lines_width =3D 0; break; =20 case MOVE_LINE_TRUNCATED: + it->max_current_x =3D it->last_visible_x; it->continuation_lines_width =3D 0; reseat_at_next_visible_line_start (it, 0); if ((op & MOVE_TO_POS) !=3D 0 @@ -8928,6 +8936,7 @@ break; =20 case MOVE_LINE_CONTINUED: + it->max_current_x =3D it->last_visible_x; /* For continued lines ending in a tab, some of the glyphs associated with the tab are displayed on the current line. Since it->current_x does not include these glyphs, @@ -9326,6 +9335,93 @@ && it->dpvec + it->current.dpvec_index !=3D it->dpend); } =20 +DEFUN ("window-buffer-pixel-size", Fwindow_buffer_pixel_size, Swindow_bu= ffer_pixel_size, 0, 5, 0, + doc: /* Return size of WINDOW's buffer in pixels. +WINDOW must be a live window and defaults to the selected one. The +return value is a cons of the maximum pixel-width of any line and the +maximum pixel-height of all lines. + +The optional argument X_LIMIT, if non-nil, specifies the maximum +pixel-width that can be returned. X_LIMIT nil or omitted, means to use +the pixel-width of WINDOW's body; use this if you do not intend to +change the width of WINDOW. Use the maximum width WINDOW can be +expanded to if you intend to change WINDOW's width. + +The optional argument Y_LIMIT, if non-nil, specifies the maximum +pixel-height to scan. Lines starting below Y_LIMIT are not scanned. +Since calculating the pixel-height of a large buffer can take some time,= +it makes sense to specify this argument if the size of the buffer is +unknown. */) + (Lisp_Object window, Lisp_Object from, Lisp_Object to, Lisp_Object x_l= imit, Lisp_Object y_limit) +{ + struct window *w =3D decode_live_window (window); + Lisp_Object buf, value; + struct buffer *b; + struct it it; + struct buffer *old_buffer =3D NULL; + ptrdiff_t start, end; + struct text_pos startp, endp; + void *itdata =3D NULL; + int max_y =3D -1; + + buf =3D w->buffer; + CHECK_BUFFER (buf); + b =3D XBUFFER (buf); + + if (NILP (from)) + start =3D BEGV; + else + { + CHECK_NUMBER_COERCE_MARKER (from); + start =3D min (max (XINT (from), BEGV), ZV); + } + + if (NILP (to)) + end =3D ZV; + else + { + CHECK_NUMBER_COERCE_MARKER (to); + end =3D max (start, min (XINT (to), ZV)); + } + + if (b !=3D current_buffer) + { + old_buffer =3D current_buffer; + set_buffer_internal (b); + } + + if (!NILP (y_limit)) + { + CHECK_NUMBER (y_limit); + max_y =3D XINT (y_limit); + } + + itdata =3D bidi_shelve_cache (); + SET_TEXT_POS (startp, start, CHAR_TO_BYTE (start)); + start_display (&it, w, startp); + + if (!NILP (x_limit)) + { + CHECK_NUMBER (x_limit); + it.last_visible_x =3D XINT (x_limit); + } + + /* Actually, we never want move_it_to stop at to_x. But to make sure + that move_it_in_display_line_to always moves far enough, we set it + to MOST_POSITIVE_FIXNUM and specify MOVE_TO_X. */ + move_it_to (&it, end, MOST_POSITIVE_FIXNUM, max_y, -1, + MOVE_TO_POS | MOVE_TO_X | MOVE_TO_Y); + last_height =3D 0; + value =3D Fcons (make_number (it.max_current_x), + make_number (it.current_y)); +/** make_number (line_bottom_y (&it))); **/ + bidi_unshelve_cache (itdata, 0); + + if (old_buffer) + set_buffer_internal (old_buffer); + + return value; +} =0C /***********************************************************************= Messages @@ -28808,6 +28904,7 @@ defsubr (&Sformat_mode_line); defsubr (&Sinvisible_p); defsubr (&Scurrent_bidi_paragraph_direction); + defsubr (&Swindow_buffer_pixel_size); =20 DEFSYM (Qmenu_bar_update_hook, "menu-bar-update-hook"); DEFSYM (Qoverriding_terminal_local_map, "overriding-terminal-local-map= "); --------------010408070805070106050800-- From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 02 12:53:17 2013 Received: (at 13399) by debbugs.gnu.org; 2 Feb 2013 17:53:18 +0000 Received: from localhost ([127.0.0.1]:33120 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U1hHB-0006in-8S for submit@debbugs.gnu.org; Sat, 02 Feb 2013 12:53:17 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:56702) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U1hH8-0006iX-4d for 13399@debbugs.gnu.org; Sat, 02 Feb 2013 12:53:15 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MHL00L00TF4HS00@a-mtaout22.012.net.il> for 13399@debbugs.gnu.org; Sat, 02 Feb 2013 19:52:18 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MHL00LWTTN48Q70@a-mtaout22.012.net.il>; Sat, 02 Feb 2013 19:52:17 +0200 (IST) Date: Sat, 02 Feb 2013 19:52:19 +0200 From: Eli Zaretskii Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B In-reply-to: <510D436A.1000603@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83a9rmbo30.fsf@gnu.org> References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> <838v80ugv1.fsf@gnu.org> <50F021EC.4040107@gmx.at> <50F054A0.2040606@gmx.at> <83libztt68.fsf@gnu.org> <83hammu7og.fsf@gnu.org> <510D436A.1000603@gmx.at> X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 13399 Cc: monnier@iro.umontreal.ca, 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.2 (/) > Date: Sat, 02 Feb 2013 17:48:42 +0100 > From: martin rudalics > CC: Stefan Monnier , 13399@debbugs.gnu.org > > I rewrote `fit-window-to-buffer' and `fit-frame-to-buffer' using the > display iterator. Please have a look at the attached patch. I looked at the C parts. > --- src/dispextern.h 2013-01-02 16:13:04 +0000 > +++ src/dispextern.h 2013-02-02 14:56:54 +0000 > @@ -2489,6 +2489,9 @@ > pixel_width with each call to produce_glyphs. */ > int current_x; > > + /* Maximum x pixel position encountered within a display line. */ > + int max_current_x; Adding a struct member for the sake of just one user sounds unjustified. Can we instead make move_it_to accumulate the value internally and return it? In any case, the comment is inaccurate, since the value is accumulated across all the display lines traversed by the iterator, not computed per display line. > +DEFUN ("window-buffer-pixel-size", Fwindow_buffer_pixel_size, Swindow_buffer_pixel_size, 0, 5, 0, Why not window-text-pixel-size? The "buffer" part doesn't belong here, I think. > + doc: /* Return size of WINDOW's buffer in pixels. > +WINDOW must be a live window and defaults to the selected one. The > +return value is a cons of the maximum pixel-width of any line and the > +maximum pixel-height of all lines. > + > +The optional argument X_LIMIT, if non-nil, specifies the maximum > +pixel-width that can be returned. X_LIMIT nil or omitted, means to use > +the pixel-width of WINDOW's body; use this if you do not intend to > +change the width of WINDOW. Use the maximum width WINDOW can be > +expanded to if you intend to change WINDOW's width. > + > +The optional argument Y_LIMIT, if non-nil, specifies the maximum > +pixel-height to scan. Lines starting below Y_LIMIT are not scanned. "Lines starting below Y_LIMIT" is ambiguous. I suggest Lines whose y-coordinate is beyond Y_LIMIT will not be scanned. > +Since calculating the pixel-height of a large buffer can take some time, > +it makes sense to specify this argument if the size of the buffer is > +unknown. */) The doc string keeps silent about arguments FROM and TO. > + /* Actually, we never want move_it_to stop at to_x. But to make sure > + that move_it_in_display_line_to always moves far enough, we set it > + to MOST_POSITIVE_FIXNUM and specify MOVE_TO_X. */ > + move_it_to (&it, end, MOST_POSITIVE_FIXNUM, max_y, -1, > + MOVE_TO_POS | MOVE_TO_X | MOVE_TO_Y); Did you test what this does when END is covered by a display string? Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 02 13:22:02 2013 Received: (at 13399) by debbugs.gnu.org; 2 Feb 2013 18:22:02 +0000 Received: from localhost ([127.0.0.1]:33147 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U1hj0-0007n0-6L for submit@debbugs.gnu.org; Sat, 02 Feb 2013 13:22:02 -0500 Received: from mout.gmx.net ([212.227.15.19]:65227) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U1hik-0007m2-Vy for 13399@debbugs.gnu.org; Sat, 02 Feb 2013 13:22:00 -0500 Received: from mailout-de.gmx.net ([10.1.76.27]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MAiu5-1U8bbU11Tf-00BwLa for <13399@debbugs.gnu.org>; Sat, 02 Feb 2013 19:20:51 +0100 Received: (qmail invoked by alias); 02 Feb 2013 18:20:51 -0000 Received: from 62-47-50-198.adsl.highway.telekom.at (EHLO [62.47.50.198]) [62.47.50.198] by mail.gmx.net (mp027) with SMTP; 02 Feb 2013 19:20:51 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19JHQ9y/kpJuRb+Rhb+tjipC3XtmbKJdMvyZAbjCB TsxwaAmcNc4khT Message-ID: <510D58FC.2030605@gmx.at> Date: Sat, 02 Feb 2013 19:20:44 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> <838v80ugv1.fsf@gnu.org> <50F021EC.4040107@gmx.at> <50F054A0.2040606@gmx.at> <83libztt68.fsf@gnu.org> <83hammu7og.fsf@gnu.org> <510D436A.1000603@gmx.at> <83a9rmbo30.fsf@gnu.org> In-Reply-To: <83a9rmbo30.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 13399 Cc: monnier@iro.umontreal.ca, 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> + /* Maximum x pixel position encountered within a display line. */ >> + int max_current_x; > > Adding a struct member for the sake of just one user sounds > unjustified. Can we instead make move_it_to accumulate the value > internally and return it? I don't know. IIUC most iterator functions never return something useful. And if one wants to glue together the results of subsequent calls of move_it_to, it might make sense to not reset the value internally. > In any case, the comment is inaccurate, since the value is accumulated > across all the display lines traversed by the iterator, not computed > per display line. Would "within any line traversed by the iterator" be better? >> +DEFUN ("window-buffer-pixel-size", Fwindow_buffer_pixel_size, Swindow_buffer_pixel_size, 0, 5, 0, > > Why not window-text-pixel-size? The "buffer" part doesn't belong > here, I think. Since I also look at buffer portions outside the window, such a term wouldn't be very accurate either. > "Lines starting below Y_LIMIT" is ambiguous. I suggest > > Lines whose y-coordinate is beyond Y_LIMIT will not be scanned. OK. >> +Since calculating the pixel-height of a large buffer can take some time, >> +it makes sense to specify this argument if the size of the buffer is >> +unknown. */) > > The doc string keeps silent about arguments FROM and TO. ... because I only added them later on ;-) Initially I always scanned from `point-min' to min (`point-max', y_limit) but later I noticed that with side-by-side windows it makes sense to start at `window-start'. >> + /* Actually, we never want move_it_to stop at to_x. But to make sure >> + that move_it_in_display_line_to always moves far enough, we set it >> + to MOST_POSITIVE_FIXNUM and specify MOVE_TO_X. */ >> + move_it_to (&it, end, MOST_POSITIVE_FIXNUM, max_y, -1, >> + MOVE_TO_POS | MOVE_TO_X | MOVE_TO_Y); > > Did you test what this does when END is covered by a display string? No. I didn't try invisible text and other atrocities either. In fact, I never experimented with a non-ZV end position so far. Which problems do you see? martin From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 02 13:37:21 2013 Received: (at 13399) by debbugs.gnu.org; 2 Feb 2013 18:37:21 +0000 Received: from localhost ([127.0.0.1]:33170 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U1hxo-0008OV-Ic for submit@debbugs.gnu.org; Sat, 02 Feb 2013 13:37:20 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:33407) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U1hxl-0008OI-Cw for 13399@debbugs.gnu.org; Sat, 02 Feb 2013 13:37:18 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MHL00L00UICQB00@a-mtaout22.012.net.il> for 13399@debbugs.gnu.org; Sat, 02 Feb 2013 20:36:10 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MHL00LTOVO7Q950@a-mtaout22.012.net.il>; Sat, 02 Feb 2013 20:36:07 +0200 (IST) Date: Sat, 02 Feb 2013 20:36:10 +0200 From: Eli Zaretskii Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B In-reply-to: <510D58FC.2030605@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <837gmqbm1x.fsf@gnu.org> References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> <838v80ugv1.fsf@gnu.org> <50F021EC.4040107@gmx.at> <50F054A0.2040606@gmx.at> <83libztt68.fsf@gnu.org> <83hammu7og.fsf@gnu.org> <510D436A.1000603@gmx.at> <83a9rmbo30.fsf@gnu.org> <510D58FC.2030605@gmx.at> X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 13399 Cc: monnier@iro.umontreal.ca, 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > Date: Sat, 02 Feb 2013 19:20:44 +0100 > From: martin rudalics > CC: monnier@iro.umontreal.ca, 13399@debbugs.gnu.org > > >> + /* Maximum x pixel position encountered within a display line. */ > >> + int max_current_x; > > > > Adding a struct member for the sake of just one user sounds > > unjustified. Can we instead make move_it_to accumulate the value > > internally and return it? > > I don't know. IIUC most iterator functions never return something > useful. Because there was no need. Now there is. > And if one wants to glue together the results of subsequent calls of > move_it_to, it might make sense to not reset the value internally. It should be simple enough to add them up externally. Adding a member to 'struct it' has the downside of enlarging the structure, which slows down any code that copies such structs. We are going to punish all the users for the benefit of just one. So I think we should avoid that. > > In any case, the comment is inaccurate, since the value is accumulated > > across all the display lines traversed by the iterator, not computed > > per display line. > > Would "within any line traversed by the iterator" be better? Yes. > > >> +DEFUN ("window-buffer-pixel-size", Fwindow_buffer_pixel_size, Swindow_buffer_pixel_size, 0, 5, 0, > > > > Why not window-text-pixel-size? The "buffer" part doesn't belong > > here, I think. > > Since I also look at buffer portions outside the window, such a term > wouldn't be very accurate either. Then how about text-pixel-size? > >> + /* Actually, we never want move_it_to stop at to_x. But to make sure > >> + that move_it_in_display_line_to always moves far enough, we set it > >> + to MOST_POSITIVE_FIXNUM and specify MOVE_TO_X. */ > >> + move_it_to (&it, end, MOST_POSITIVE_FIXNUM, max_y, -1, > >> + MOVE_TO_POS | MOVE_TO_X | MOVE_TO_Y); > > > > Did you test what this does when END is covered by a display string? > > No. I didn't try invisible text and other atrocities either. In fact, > I never experimented with a non-ZV end position so far. Which problems > do you see? move_it_to might overshoot in those cases, i.e. you get more pixels than strictly needed. But OTOH, I see no way of asking for more specific limits in these cases, nor a use-case where that could be needed. So I guess we are okay until someone hollers. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 03 04:45:21 2013 Received: (at 13399) by debbugs.gnu.org; 3 Feb 2013 09:45:21 +0000 Received: from localhost ([127.0.0.1]:33618 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U1w8X-0002Fj-6F for submit@debbugs.gnu.org; Sun, 03 Feb 2013 04:45:21 -0500 Received: from mout.gmx.net ([212.227.17.20]:52957) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U1w8U-0002Fa-6c for 13399@debbugs.gnu.org; Sun, 03 Feb 2013 04:45:19 -0500 Received: from mailout-de.gmx.net ([10.1.76.31]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MNfCm-1U3a0m1fti-007FEL for <13399@debbugs.gnu.org>; Sun, 03 Feb 2013 10:44:18 +0100 Received: (qmail invoked by alias); 03 Feb 2013 09:44:17 -0000 Received: from 62-47-43-97.adsl.highway.telekom.at (EHLO [62.47.43.97]) [62.47.43.97] by mail.gmx.net (mp031) with SMTP; 03 Feb 2013 10:44:17 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+Juh9IxBiJBmOaAQT6JomWhdNYBy5rVCwyZe828J vUdHDKLdXeQWNV Message-ID: <510E3167.9070707@gmx.at> Date: Sun, 03 Feb 2013 10:44:07 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> <838v80ugv1.fsf@gnu.org> <50F021EC.4040107@gmx.at> <50F054A0.2040606@gmx.at> <83libztt68.fsf@gnu.org> <83hammu7og.fsf@gnu.org> <510D436A.1000603@gmx.at> <83a9rmbo30.fsf@gnu.org> <510D58FC.2030605@gmx.at> <837gmqbm1x.fsf@gnu.org> In-Reply-To: <837gmqbm1x.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 13399 Cc: monnier@iro.umontreal.ca, 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> I don't know. IIUC most iterator functions never return something >> useful. > > Because there was no need. Now there is. But hardly anyone delving into move_it_to wants to know that it returns the maximum length of any row it encountered. So I'm quite reluctant to break this tradition. > Adding a member to 'struct it' has the downside of enlarging the > structure, which slows down any code that copies such structs. We are > going to punish all the users for the benefit of just one. So I think > we should avoid that. How about making this static in xdisp.c like last_max_ascent and last_height? >> >> +DEFUN ("window-buffer-pixel-size", Fwindow_buffer_pixel_size, Swindow_buffer_pixel_size, 0, 5, 0, >> > >> > Why not window-text-pixel-size? The "buffer" part doesn't belong >> > here, I think. >> >> Since I also look at buffer portions outside the window, such a term >> wouldn't be very accurate either. > > Then how about text-pixel-size? This would imply that I had to accept any text as argument. Maybe `window-buffer-text-pixel-size' would be most accurate - after all it's about a window, its buffer, and (part of) that buffer's text. > move_it_to might overshoot in those cases, i.e. you get more pixels > than strictly needed. I earlier tried (line_bottom_y (&it)) as the return value but that simply added the last line's height twice. Anyway, in my limited experience with this function it's still better to overshoot than getting too few pixels. The thing that troubled me most was this If TO_X is not specified, use a TO_X of zero. The reason is to make the outcome of this function more predictable. If we didn't use TO_X == 0, we would stop at the end of the line which is probably not what a caller would expect to happen. which caused me to exit a line too early and consequently not show the end of the last visible line of a window when it was the longest one. I eventually fixed this by calling move_it_to with to_x equal to MOST_POSITIVE_FIXNUM. Yet, having to_x equal -1 _not_ go to last_visible_x seems quite arbitrary to me. > But OTOH, I see no way of asking for more > specific limits in these cases, nor a use-case where that could be > needed. So I guess we are okay until someone hollers. I think so too. I didn't try testing any special cases and IIUC nobody tried my patch so far. martin From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 03 11:02:31 2013 Received: (at 13399) by debbugs.gnu.org; 3 Feb 2013 16:02:31 +0000 Received: from localhost ([127.0.0.1]:34441 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U221T-0004P1-6v for submit@debbugs.gnu.org; Sun, 03 Feb 2013 11:02:31 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:38318) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U221N-0004Oq-15 for 13399@debbugs.gnu.org; Sun, 03 Feb 2013 11:02:25 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At8KABK/CFFFpZnt/2dsb2JhbABEuzWCWAQCexdzgh4BAQQBViMQCzQSFBgNJIgeBsEtkQoDiGGcGYFegxU X-IPAS-Result: At8KABK/CFFFpZnt/2dsb2JhbABEuzWCWAQCexdzgh4BAQQBViMQCzQSFBgNJIgeBsEtkQoDiGGcGYFegxU X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="328787" Received: from 69-165-153-237.dsl.teksavvy.com (HELO pastel.home) ([69.165.153.237]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 03 Feb 2013 11:01:20 -0500 Received: by pastel.home (Postfix, from userid 20848) id 6519459527; Sun, 3 Feb 2013 11:01:20 -0500 (EST) From: Stefan Monnier To: martin rudalics Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B Message-ID: References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> <838v80ugv1.fsf@gnu.org> <50F021EC.4040107@gmx.at> <50F054A0.2040606@gmx.at> <83libztt68.fsf@gnu.org> <83hammu7og.fsf@gnu.org> <510D436A.1000603@gmx.at> <83a9rmbo30.fsf@gnu.org> <510D58FC.2030605@gmx.at> <837gmqbm1x.fsf@gnu.org> <510E3167.9070707@gmx.at> Date: Sun, 03 Feb 2013 11:01:20 -0500 In-Reply-To: <510E3167.9070707@gmx.at> (martin rudalics's message of "Sun, 03 Feb 2013 10:44:07 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 13399 Cc: Eli Zaretskii , 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> Then how about text-pixel-size? > This would imply that I had to accept any text as argument. No, I think it's OK. window-buffer-pixel-size was OK as well, as far as I'm concerned. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 03 13:58:53 2013 Received: (at 13399) by debbugs.gnu.org; 3 Feb 2013 18:58:53 +0000 Received: from localhost ([127.0.0.1]:34549 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U24mC-0008Mb-Qa for submit@debbugs.gnu.org; Sun, 03 Feb 2013 13:58:53 -0500 Received: from mout.gmx.net ([212.227.17.21]:62539) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U24mA-0008MS-DY for 13399@debbugs.gnu.org; Sun, 03 Feb 2013 13:58:51 -0500 Received: from mailout-de.gmx.net ([10.1.76.12]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Mfl5W-1UN1xY1DHA-00N89n for <13399@debbugs.gnu.org>; Sun, 03 Feb 2013 19:57:48 +0100 Received: (qmail invoked by alias); 03 Feb 2013 18:57:39 -0000 Received: from 62-47-33-209.adsl.highway.telekom.at (EHLO [62.47.33.209]) [62.47.33.209] by mail.gmx.net (mp012) with SMTP; 03 Feb 2013 19:57:39 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18NMpNenoMNutKfGb5/DSYmlUu7erYNoinVhwR4Su Fb5xLsKBIURPCx Message-ID: <510EB31B.1070809@gmx.at> Date: Sun, 03 Feb 2013 19:57:31 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> In-Reply-To: <83hamohmtj.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Y-GMX-Trusted: 0 X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 13399 Cc: 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.5 (/) Just to recite the initial problem and your proposal: >> With emacs -Q evaluate >> >> (with-current-buffer (get-buffer-create "*foo*") >> (dotimes (i 1000) >> (insert "1234=E2=80=8B")) ; U-200B >> (setq word-wrap t) >> (display-buffer "*foo*")) >> >> where the character after 1234 is a zero-width space character with >> unicode code point U-200B. As can be seen in the window showing *foo= *, >> lines are not regularly wrapped at that character. > > You mean, not wrapped at all. Witness the continuation bitmaps in the= > fringes, which shouldn't appear when a line is wrapped. > >> Doing >> >> (with-current-buffer (get-buffer-create "*foo*") >> (dotimes (i 1000) >> (insert "1234 ")) >> (setq word-wrap t) >> (display-buffer "*foo*")) >> >> instead wraps lines as expected. > > If anything, this is a missing feature, since word-wrap is explicitly > coded to break lines only on SPC and TAB characters. See the > IT_DISPLAYING_WHITESPACE macro in xdisp.c. > > If we want to add more characters to the set, we should probably > arrange a special char-table for this, and have it exposed to Lisp, so= > it could be customized. Patches are welcome. I now rewrote IT_DISPLAYING_WHITESPACE as #define IT_DISPLAYING_WHITESPACE(it) \ ((it->what =3D=3D IT_CHARACTER \ && !NILP (CHAR_TABLE_REF (Vword_wrap_chars, it->c))) \ || ((STRINGP (it->string) \ && !NILP (CHAR_TABLE_REF \ (Vword_wrap_chars, \ SREF (it->string, IT_STRING_BYTEPOS (*it))))) \ || (it->s && !NILP (CHAR_TABLE_REF \ (Vword_wrap_chars, \ it->s[IT_BYTEPOS (*it)]))) \ || (IT_BYTEPOS (*it) < ZV_BYTE \ && !NILP (CHAR_TABLE_REF \ (Vword_wrap_chars, \ (*BYTE_POS_ADDR (IT_BYTEPOS (*it)))))))) \ and have a character table called `word-wrap-chars' such that (aref word-wrap-chars ?=E2=80=8B) returns t, but it doesn't wrap at a U-200B character. Is there some additional wrinkle like some hardcoded space/tab in the word-wrap code I have to observe? Or is my code wrong? Thanks, martin From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 03 14:33:04 2013 Received: (at 13399) by debbugs.gnu.org; 3 Feb 2013 19:33:04 +0000 Received: from localhost ([127.0.0.1]:34563 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U25JI-0000jq-5K for submit@debbugs.gnu.org; Sun, 03 Feb 2013 14:33:04 -0500 Received: from mtaout23.012.net.il ([80.179.55.175]:38919) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U25JE-0000jQ-Vk for 13399@debbugs.gnu.org; Sun, 03 Feb 2013 14:33:02 -0500 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MHN00L00SUCAX00@a-mtaout23.012.net.il> for 13399@debbugs.gnu.org; Sun, 03 Feb 2013 21:31:56 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MHN00L2NSX77B30@a-mtaout23.012.net.il>; Sun, 03 Feb 2013 21:31:56 +0200 (IST) Date: Sun, 03 Feb 2013 21:32:01 +0200 From: Eli Zaretskii Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B In-reply-to: <510E3167.9070707@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83y5f59osu.fsf@gnu.org> References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> <838v80ugv1.fsf@gnu.org> <50F021EC.4040107@gmx.at> <50F054A0.2040606@gmx.at> <83libztt68.fsf@gnu.org> <83hammu7og.fsf@gnu.org> <510D436A.1000603@gmx.at> <83a9rmbo30.fsf@gnu.org> <510D58FC.2030605@gmx.at> <837gmqbm1x.fsf@gnu.org> <510E3167.9070707@gmx.at> X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 13399 Cc: monnier@iro.umontreal.ca, 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > Date: Sun, 03 Feb 2013 10:44:07 +0100 > From: martin rudalics > CC: monnier@iro.umontreal.ca, 13399@debbugs.gnu.org > > >> I don't know. IIUC most iterator functions never return something > >> useful. > > > > Because there was no need. Now there is. > > But hardly anyone delving into move_it_to wants to know that it returns > the maximum length of any row it encountered. So I'm quite reluctant to > break this tradition. There's no tradition. Callers that don't care about the return value are free to ignore it. I don't see a problem here. We have many internal functions that return values which might be useful to someone. > How about making this static in xdisp.c like last_max_ascent and > last_height? That'd be even worse, IMO. > > Then how about text-pixel-size? > > This would imply that I had to accept any text as argument. I don't think so, but maybe you will like text-region-pixel-size? > Maybe > `window-buffer-text-pixel-size' would be most accurate - after all it's > about a window, its buffer, and (part of) that buffer's text. It hints that it returns size of text in a window, which is false. But we are bike-shedding. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 03 14:46:30 2013 Received: (at 13399) by debbugs.gnu.org; 3 Feb 2013 19:46:30 +0000 Received: from localhost ([127.0.0.1]:34576 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U25WH-00015A-US for submit@debbugs.gnu.org; Sun, 03 Feb 2013 14:46:30 -0500 Received: from mtaout23.012.net.il ([80.179.55.175]:40037) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U25WE-000150-To for 13399@debbugs.gnu.org; Sun, 03 Feb 2013 14:46:28 -0500 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MHN00L00THVC000@a-mtaout23.012.net.il> for 13399@debbugs.gnu.org; Sun, 03 Feb 2013 21:45:25 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MHN00LG0TJN2IB0@a-mtaout23.012.net.il>; Sun, 03 Feb 2013 21:45:25 +0200 (IST) Date: Sun, 03 Feb 2013 21:45:29 +0200 From: Eli Zaretskii Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B In-reply-to: <510EB31B.1070809@gmx.at> To: martin rudalics Message-id: <83wqup9o6e.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: QUOTED-PRINTABLE X-012-Sender: halo1@inter.net.il References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <510EB31B.1070809@gmx.at> X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 13399 Cc: 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > Date: Sun, 03 Feb 2013 19:57:31 +0100 > From: martin rudalics > CC: 13399@debbugs.gnu.org >=20 > I now rewrote IT_DISPLAYING_WHITESPACE as >=20 > #define IT_DISPLAYING_WHITESPACE(it)=09=09=09=09=09\ > ((it->what =3D=3D IT_CHARACTER=09=09=09=09=09=09\ > && !NILP (CHAR_TABLE_REF (Vword_wrap_chars, it->c)))=09=09\ > || ((STRINGP (it->string)=09=09=09=09=09=09\ > =09&& !NILP (CHAR_TABLE_REF=09=09=09=09=09\ > =09=09 (Vword_wrap_chars,=09=09=09=09=09\ > =09=09 SREF (it->string, IT_STRING_BYTEPOS (*it)))))=09\ > || (it->s && !NILP (CHAR_TABLE_REF=09=09=09=09\ > =09=09=09 (Vword_wrap_chars,=09=09=09=09\ > =09=09=09 it->s[IT_BYTEPOS (*it)])))=09=09\ > || (IT_BYTEPOS (*it) < ZV_BYTE=09=09=09=09=09\ > =09 && !NILP (CHAR_TABLE_REF=09=09=09=09=09\ > =09=09 (Vword_wrap_chars,=09=09=09=09\ > =09=09=09 (*BYTE_POS_ADDR (IT_BYTEPOS (*it))))))))=09\ >=20 >=20 > and have a character table called `word-wrap-chars' such that > (aref word-wrap-chars ?=E2=80=8B) returns t, but it doesn't wrap at= a > U-200B character. Is there some additional wrinkle like some > hardcoded space/tab in the word-wrap code I have to observe? > Or is my code wrong? Does CHAR_TABLE_REF return the right value? Also, the code is wrong here: SREF (it->string, IT_STRING_BYTEPOS (*it)) and here: it->s[IT_BYTEPOS (*it)] and here: *BYTE_POS_ADDR (IT_BYTEPOS (*it)) in that that it assumes the character is always one byte, which is clearly wrong with non-ASCII characters. You should instead use FETCH_CHAR and STRING_CHAR. From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 04 12:05:44 2013 Received: (at 13399) by debbugs.gnu.org; 4 Feb 2013 17:05:44 +0000 Received: from localhost ([127.0.0.1]:36212 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U2PUE-0002MX-MG for submit@debbugs.gnu.org; Mon, 04 Feb 2013 12:05:44 -0500 Received: from mout.gmx.net ([212.227.15.18]:56136) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U2PU8-0002MK-OP for 13399@debbugs.gnu.org; Mon, 04 Feb 2013 12:05:40 -0500 Received: from mailout-de.gmx.net ([10.1.76.35]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MDjZQ-1UBjfP1pIU-00HB1p for <13399@debbugs.gnu.org>; Mon, 04 Feb 2013 18:04:29 +0100 Received: (qmail invoked by alias); 04 Feb 2013 17:04:27 -0000 Received: from 62-47-55-214.adsl.highway.telekom.at (EHLO [62.47.55.214]) [62.47.55.214] by mail.gmx.net (mp035) with SMTP; 04 Feb 2013 18:04:27 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19fNtUP9oBfdpouTa4ji1CVYZbY02ty0lXYPUzErd 0pR1I/gdtdk7yo Message-ID: <510FEA0E.2000405@gmx.at> Date: Mon, 04 Feb 2013 18:04:14 +0100 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> <838v80ugv1.fsf@gnu.org> <50F021EC.4040107@gmx.at> <50F054A0.2040606@gmx.at> <83libztt68.fsf@gnu.org> <83hammu7og.fsf@gnu.org> <510D436A.1000603@gmx.at> <83a9rmbo30.fsf@gnu.org> <510D58FC.2030605@gmx.at> <837gmqbm1x.fsf@gnu.org> <510E3167.9070707@gmx.at> <83y5f59osu.fsf@gnu.org> In-Reply-To: <83y5f59osu.fsf@gnu.org> Content-Type: multipart/mixed; boundary="------------010404010304040906020503" X-Y-GMX-Trusted: 0 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 13399 Cc: monnier@iro.umontreal.ca, 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) This is a multi-part message in MIME format. --------------010404010304040906020503 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit > But we are bike-shedding. Indeed. How about the attached patch? martin --------------010404010304040906020503 Content-Type: text/plain; name="fit-window-to-buffer.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="fit-window-to-buffer.diff" =3D=3D=3D modified file 'lisp/window.el' --- lisp/window.el 2013-01-02 16:13:04 +0000 +++ lisp/window.el 2013-02-04 10:17:41 +0000 @@ -6074,211 +6074,428 @@ (eobp) window)))) =20 -;;; Resizing buffers to fit their contents exactly. +;;; Resizing windows and frames to fit their contents exactly. +(defcustom fit-window-to-buffer-horizontally nil + "Non-nil means `fit-window-to-buffer' can resize windows horizontally.= +If this is nil, `fit-window-to-buffer' never resizes windows +horizontally. If this is `only', it can resize windows +horizontally only. Any other value means `fit-window-to-buffer' +can resize windows in both dimensions." + :type 'boolean + :version "24.4" + :group 'help) + (defcustom fit-frame-to-buffer nil - "Non-nil means `fit-window-to-buffer' can resize frames. + "Non-nil means `fit-frame-to-buffer' can resize frames. A frame can be resized if and only if its root window is a live -window. The height of the root window is subject to the values -of `fit-frame-to-buffer-max-height' and `window-min-height'." +window. If this is `horizontally', frames can be resized +horizontally only. If this is `vertically', frames can be +resized vertically only. Any other non-nil value means frames +can be resized in both dimensions. See also +`fit-frame-to-buffer-margins' and `fit-frame-to-buffer-sizes'." :type 'boolean - :version "24.3" + :version "24.4" :group 'help) =20 -(defcustom fit-frame-to-buffer-bottom-margin 4 - "Bottom margin for the command `fit-frame-to-buffer'. -This is the number of lines that function leaves free at the bottom of -the display, in order to not obscure any system task bar or panel. -If you do not have one (or if it is vertical) you might want to -reduce this. If it is thicker, you might want to increase this." - ;; If you set this too small, fit-frame-to-buffer can shift the - ;; frame up to avoid the panel. - :type 'integer - :version "24.3" - :group 'windows) - -(defun fit-frame-to-buffer (&optional frame max-height min-height) +(defcustom fit-frame-to-buffer-margins '(0 0 0 72) + "Margins around frame for `fit-frame-to-buffer'. +This list specifies the numbers of pixels to be left free on the +left, above, the right, and below a frame that shall be fit to +its buffer. The value specified here can be overridden for a +specific frame by that frame's `fit-frame-to-buffer-margins' +parameter, if present. + +On some window systems the calculation of frame sizes can be +incorrect. Increasing the value of the third and/or fourth +element of this variable can fix that. + +See also `fit-frame-to-buffer-sizes'." + :version "24.4" + :type '(list + (integer :tag "Left" :size 5) + (integer :tag " Above" :size 5) + (integer :tag " Right" :size 5) + (integer :tag " Below" :size 5)) + :group 'windows) + +(defcustom fit-frame-to-buffer-sizes '(nil nil nil nil) + "Size boundaries of frame for `fit-frame-to-buffer'. +This list specifies the total maximum and minimum lines and +maximum and minimum columns of the root window of any frame that +shall be fit to its buffer. If any of these values is non-nil, +it will override the value supplied by the respective arguments +of `fit-frame-to-buffer'. + +On window systems where the menubar can wrap, fitting a frame to +its buffer may swallow the last line(s). Specifying an +appropriate minimum width value here can avoid such wrapping. + +See also `fit-frame-to-buffer-margins'." + :version "24.4" + :type '(list + (choice + :tag "Maximum Height" + :value nil + :format "%[MaxHeight%] %v " + (const :tag "None" :format "%t" nil) + (integer :tag "Lines" :size 5)) + (choice + :tag "Minimum Height" + :value nil + :format "%[MinHeight%] %v " + (const :tag "None" :format "%t" nil) + (integer :tag "Lines" :size 5)) + (choice + :tag "Maximum Width" + :value nil + :format "%[MaxWidth%] %v " + (const :tag "None" :format "%t" nil) + (integer :tag "Columns" :size 5)) + (choice + :tag "Minimum Width" + :value nil + :format "%[MinWidth%] %v\n" + (const :tag "None" :format "%t" nil) + (integer :tag "Columns" :size 5))) + :group 'windows) + +(defun window--sanitize-margin (margin left right) + "Return MARGIN if it's a number between LEFT and RIGHT." + (if (and (numberp margin) + (<=3D left (- right margin)) (<=3D margin right)) + margin + 0)) + +(defun fit-frame-to-buffer (&optional frame max-height min-height max-wi= dth min-width) "Adjust height of FRAME to display its buffer contents exactly. FRAME can be any live frame and defaults to the selected one. +MAX-HEIGHT, MIN-HEIGHT, MAX-WIDTH and MIN-WIDTH specify bounds on +the new total size of FRAME's root window. =20 -Optional argument MAX-HEIGHT specifies the maximum height of FRAME. -It defaults to the height of the display below the current -top line of FRAME, minus `fit-frame-to-buffer-bottom-margin'. -Optional argument MIN-HEIGHT specifies the minimum height of FRAME. -The default corresponds to `window-min-height'." +The option `fit-frame-to-buffer' controls whether this function +has any effect. New position and size of FRAME are additionally +determined by the options `fit-frame-to-buffer-sizes' and +`fit-frame-to-buffer-margins' or the corresponding parameters of +FRAME. This function can fail to fit the buffer's height when +`word-wrap' is turned on in that buffer." (interactive) (setq frame (window-normalize-frame frame)) - (let* ((root (frame-root-window frame)) - (frame-min-height - (+ (- (frame-height frame) (window-total-size root)) - window-min-height)) - (frame-top (frame-parameter frame 'top)) - (top (if (consp frame-top) - (funcall (car frame-top) (cadr frame-top)) - frame-top)) - (frame-max-height - (- (/ (- (x-display-pixel-height frame) top) - (frame-char-height frame)) - fit-frame-to-buffer-bottom-margin)) - (compensate 0) - delta) - (when (and (window-live-p root) (not (window-size-fixed-p root))) - (with-selected-window root - (cond - ((not max-height) - (setq max-height frame-max-height)) - ((numberp max-height) - (setq max-height (min max-height frame-max-height))) - (t - (error "%s is an invalid maximum height" max-height))) - (cond - ((not min-height) - (setq min-height frame-min-height)) - ((numberp min-height) - (setq min-height (min min-height frame-min-height))) - (t - (error "%s is an invalid minimum height" min-height))) - ;; When tool-bar-mode is enabled and we have just created a new - ;; frame, reserve lines for toolbar resizing. This is needed - ;; because for reasons unknown to me Emacs (1) reserves one line - ;; for the toolbar when making the initial frame and toolbars - ;; are enabled, and (2) later adds the remaining lines needed. - ;; Our code runs IN BETWEEN (1) and (2). YMMV when you're on a - ;; system that behaves differently. - (let ((quit-restore (window-parameter root 'quit-restore)) - (lines (tool-bar-lines-needed frame))) - (when (and quit-restore (eq (car quit-restore) 'frame) - (not (zerop lines))) - (setq compensate (1- lines)))) - (message "%s" compensate) - (setq delta - ;; Always count a final newline - we don't do any - ;; post-processing, so let's play safe. - (+ (count-screen-lines nil nil t) - (- (window-body-size)) - compensate))) - ;; Move away from final newline. - (when (and (eobp) (bolp) (not (bobp))) - (set-window-point root (line-beginning-position 0))) - (set-window-start root (point-min)) - (set-window-vscroll root 0) - (condition-case nil - (set-frame-height - frame - (min (max (+ (frame-height frame) delta) - min-height) - max-height)) - (error (setq delta nil)))) - delta)) + (when (and (window-live-p (frame-root-window frame)) + fit-frame-to-buffer + (or (not window-size-fixed) + (and (eq window-size-fixed 'height) + (not (eq fit-frame-to-buffer 'vertically))) + (and (eq window-size-fixed 'width) + (not (eq fit-frame-to-buffer 'horizontally))))) + (with-selected-window (frame-root-window frame) + (let* ((window (frame-root-window frame)) + (char-width (frame-char-width)) + (char-height (frame-char-height)) + (display-width (display-pixel-width frame)) + (display-height (display-pixel-height frame)) + ;; Sanitize margins. + (margins (or (frame-parameter frame 'fit-frame-to-buffer-margins) + fit-frame-to-buffer-margins)) + (left-margin (window--sanitize-margin + (nth 0 margins) 0 display-width)) + (top-margin (window--sanitize-margin + (nth 1 margins) 0 display-height)) + (right-margin (window--sanitize-margin + (nth 2 margins) left-margin display-width)) + (bottom-margin (window--sanitize-margin + (nth 3 margins) top-margin display-height)) + ;; The pixel width of FRAME. + (frame-width (frame-pixel-width)) + ;; The difference between FRAME's pixel and parameter + ;; widths. + (frame-extra-width + (- frame-width (* (frame-width) char-width))) + ;; The pixel height of FRAME's window. + (window-body-width (* (window-body-width) char-width)) + ;; The difference in pixels between total and body width of + ;; FRAME's window. + (window-extra-width + (- (* (window-total-width) char-width) window-body-width)) + ;; The difference in pixels between the frame's pixel width + ;; and the window's body width. + (extra-width + (* char-width (- (frame-width) (window-body-width)))) + ;; The maximum width we can use for fitting. + (fit-width + (- display-width (- frame-width window-body-width) + left-margin right-margin)) + ;; The pixel position of FRAME's left border. We usually + ;; try to leave this alone. + (left + (let ((left (frame-parameter nil 'left))) + (if (consp left) + (funcall (car left) (cadr left)) + left))) + ;; The pixel height of FRAME. + (frame-height (frame-pixel-height)) + ;; The difference between FRAME's pixel and parameter + ;; heights. + (frame-extra-height + (- frame-height (* (frame-height) char-height))) + ;; When tool-bar-mode is enabled and we just created a new + ;; frame, reserve lines for toolbar resizing. Needed + ;; because for reasons unknown to me Emacs (1) reserves one + ;; line for the toolbar when making the initial frame and + ;; toolbars are enabled, and (2) later adds the remaining + ;; lines needed. Our code runs IN BETWEEN (1) and (2). + ;; YMMV when you're on a system that behaves differently. + (toolbar-extra-height + (let ((quit-restore (window-parameter window 'quit-restore)) + (lines (tool-bar-lines-needed frame))) + (* char-height + (if (and quit-restore (eq (car quit-restore) 'frame) + (not (zerop lines))) + (1- lines) + 0)))) + ;; The pixel height of FRAME's window. + (window-body-height (* (window-body-height) char-height)) + ;; The difference in pixels between total and body height + ;; of FRAME's window. + (window-extra-height + (- (* (window-total-height) char-height) window-body-height)) + ;; The difference in pixels between the frame's pixel + ;; height and the window's body height. + (extra-height + (* (- (frame-height) (window-body-height)) char-height)) + ;; The maximum height we can use for fitting. + (fit-height + (- display-height (- frame-height window-body-height) + top-margin bottom-margin toolbar-extra-height)) + ;; The pixel position of FRAME's top border. We usually + ;; try to leave this alone. + (top + (let ((top (frame-parameter nil 'top))) + (if (consp top) + (funcall (car top) (cadr top)) + top))) + ;; Sanitize minimum and maximum sizes. + (sizes (or (frame-parameter frame 'fit-frame-to-buffer-sizes) + fit-frame-to-buffer-sizes)) + (max-height + (cond + ((numberp (nth 0 sizes)) + (- (* (nth 0 sizes) char-height) window-extra-height)) + ((numberp max-height) + (- (* max-height char-height) window-extra-height)))) + (min-height + (cond + ((numberp (nth 1 sizes)) + (- (* (nth 1 sizes) char-height) window-extra-height)) + ((numberp min-height) + (- (* min-height char-height) window-extra-height)))) + (max-width + (cond + ((numberp (nth 2 sizes)) + (- (* (nth 2 sizes) char-width) window-extra-width)) + ((numberp max-width) + (- (* max-width char-width) window-extra-width)))) + (min-width + (cond + ((numberp (nth 3 sizes)) + (- (* (nth 3 sizes) char-width) window-extra-width)) + ((numberp min-width) + (- (* min-width char-width) window-extra-width)))) + (value (window-text-pixel-size + nil (point-min) (point-max) + display-width display-height)) + (width (car value)) + (height (cdr value)) + remainder) + ;; Round sizes (hopefully we can drop these as soon as we can + ;; resize pixelwise). First add pixels to obtain full last + ;; lines and columns. + (setq remainder (% width char-width)) + (unless (zerop remainder) + (setq width (+ width (- char-width remainder)))) + (setq remainder (% height char-height)) + (setq height (+ height (- char-height remainder))) + ;; Now make sure that we don't get larger than our rounded + ;; maximum lines and columns. + (when (> width fit-width) + (setq width (- fit-width (% fit-width char-width)))) + (when (> height fit-height) + (setq height (- fit-height (% fit-height char-height)))) + ;; Don't change height or width when the window's size is fixed + ;; in either direction. + (cond + ((eq window-size-fixed 'height) + (setq height nil)) + ((eq window-size-fixed 'width) + (setq height nil))) + (when width + ;; Fit to maximum and minimum widths. + (when max-width + (setq width (min width max-width))) + (when min-width + (setq width (max width min-width))) + ;; Add extra width. + (setq width (+ width extra-width)) + ;; Preserve right margin. + (let ((right (+ left width frame-extra-width)) + (max-right (- display-width right-margin))) + (cond + ((> right max-right) + ;; Move FRAME to left. + (setq left (max 0 (- left (- right max-right))))) + ((< left left-margin) + ;; Move frame to right. + (setq left left-margin))))) + (when height + ;; Fit to maximum and minimum heights. + (when max-height + (setq height (min height max-height))) + (when min-height + (setq height (max height min-height))) + ;; Add extra height. + (setq height (+ height extra-height)) + ;; Preserve bottom and top margins. + (let ((bottom (+ top height frame-extra-height)) + (max-bottom (- display-height bottom-margin))) + (cond + ((> bottom max-bottom) + ;; Move FRAME to left. + (setq top (max 0 (- top (- bottom max-bottom))))) + ((< top top-margin) + ;; Move frame down. + (setq top top-margin))))) + ;; Apply changes. + (set-frame-position frame left top) + (set-frame-size + frame + (if width (/ width char-width) (frame-width)) + (if height (/ height char-height) (frame-height))))))) =20 -(defun fit-window-to-buffer (&optional window max-height min-height) - "Adjust height of WINDOW to display its buffer's contents exactly. +(defun fit-window-to-buffer (&optional window max-height min-height max-= width min-width) + "Adjust size of WINDOW to display its buffer's contents exactly. WINDOW must be a live window and defaults to the selected one. =20 -Optional argument MAX-HEIGHT specifies the maximum height of -WINDOW and defaults to the height of WINDOW's frame. Optional -argument MIN-HEIGHT specifies the minimum height of WINDOW and -defaults to `window-min-height'. Both MAX-HEIGHT and MIN-HEIGHT -are specified in lines and include the mode line and header line, -if any. - -If WINDOW is a full height window, then if the option -`fit-frame-to-buffer' is non-nil, this calls the function -`fit-frame-to-buffer' to adjust the frame height. - -Return the number of lines by which WINDOW was enlarged or -shrunk. If an error occurs during resizing, return nil but don't -signal an error. +If WINDOW is part of a vertical combination, adjust WINDOW's +height. The new height is calculated from the number of lines of +the accessible portion of its buffer. The optional argument +MAX-HEIGHT specifies a maximum height and defaults to the height +of WINDOW's frame. The optional argument MIN-HEIGHT specifies a +minimum height and defaults to `window-min-height'. Both +MAX-HEIGHT and MIN-HEIGHT are specified in lines and include the +mode line and header line, if any. + +If WINDOW is part of a horizontal combination and the value of +the option `fit-window-to-buffer-horizontally' is non-nil, adjust +WINDOW's height. The new width of WINDOW is calculated from the +maximum length of its buffer's lines that follow the current +start position of WINDOW. The optional argument MAX-WIDTH +specifies a maximum width and defaults to the width of WINDOW's +frame. The optional argument MIN-WIDTH specifies a minimum width +and defaults to `window-min-width'. Both MAX-WIDTH and MIN-WIDTH +are specified in columns and include fringes, margins and +scrollbars, if any. + +If WINDOW is its frame's root window, then if the option +`fit-frame-to-buffer' is non-nil, call `fit-frame-to-buffer' to +adjust the frame's size. =20 Note that even if this function makes WINDOW large enough to show -_all_ lines of its buffer you might not see the first lines when -WINDOW was scrolled." +_all_ parts of its buffer you might not see the first part when +WINDOW was scrolled. If WINDOW is resized horizontally, you will +not see the top of its buffer unless WINDOW starts at its minimum +accessible position." (interactive) (setq window (window-normalize-window window t)) - (cond - ((window-size-fixed-p window)) - ((window-full-height-p window) - (when fit-frame-to-buffer - (fit-frame-to-buffer (window-frame window)))) - (t + (if (eq window (frame-root-window window)) + (when fit-frame-to-buffer + ;; Fit WINDOW's frame to buffer. + (fit-frame-to-buffer + (window-frame window) max-height min-height max-width min-width)) (with-selected-window window - (let* ((height (window-total-size)) + (let* ((frame (window-frame)) + (char-height (frame-char-height)) + (char-width (frame-char-width)) + (display-height (display-pixel-height)) + (total-height (window-total-height)) + (body-height (window-body-height)) + (body-width (window-body-width)) (min-height - ;; Adjust MIN-HEIGHT. + ;; Sanitize MIN-HEIGHT. (if (numberp min-height) ;; Can't get smaller than `window-safe-min-height'. (max min-height window-safe-min-height) ;; Preserve header and mode line if present. (window-min-size nil nil t))) (max-height - ;; Adjust MAX-HEIGHT. + ;; Sanitize MAX-HEIGHT. (if (numberp max-height) - ;; Can't get larger than height of frame. - (min max-height - (window-total-size (frame-root-window window))) - ;; Don't delete other windows. - (+ height (window-max-delta nil nil window)))) - ;; Make `desired-height' the height necessary to show - ;; all of WINDOW's buffer, constrained by MIN-HEIGHT - ;; and MAX-HEIGHT. - (desired-height - (max - (min - (+ (count-screen-lines) - ;; For non-minibuffers count the mode line, if any. - (if (and (not (window-minibuffer-p window)) - mode-line-format) - 1 - 0) - ;; Count the header line, if any. - (if header-line-format 1 0)) - max-height) - min-height)) - (desired-delta - (- desired-height (window-total-size window))) - (delta - (if (> desired-delta 0) - (min desired-delta - (window-max-delta window nil window)) - (max desired-delta - (- (window-min-delta window nil window)))))) - (condition-case nil - (if (zerop delta) - ;; Return zero if DELTA became zero in the process. - 0 - ;; Don't try to redisplay with the cursor at the end on its - ;; own line--that would force a scroll and spoil things. - (when (and (eobp) (bolp) (not (bobp))) - ;; It's silly to put `point' at the end of the previous - ;; line and so maybe force horizontal scrolling. - (set-window-point window (line-beginning-position 0))) - ;; Call `window-resize' with OVERRIDE argument equal WINDOW. - (window-resize window delta nil window) - ;; Check if the last line is surely fully visible. If - ;; not, enlarge the window. - (let ((end (save-excursion - (goto-char (point-max)) - (when (and (bolp) (not (bobp))) - ;; Don't include final newline. - (backward-char 1)) - (when truncate-lines - ;; If line-wrapping is turned off, test the - ;; beginning of the last line for - ;; visibility instead of the end, as the - ;; end of the line could be invisible by - ;; virtue of extending past the edge of the - ;; window. - (forward-line 0)) - (point)))) - (set-window-vscroll window 0) - ;; This loop might in some rare pathological cases raise - ;; an error - another reason for the `condition-case'. - (while (and (< desired-height max-height) - (=3D desired-height (window-total-size)) - (not (pos-visible-in-window-p end))) - (window-resize window 1 nil window) - (setq desired-height (1+ desired-height))))) - (error (setq delta nil))) - delta))))) + (min (+ total-height (window-max-delta)) max-height) + (+ total-height (window-max-delta)))) + height) + (cond + ;; If WINDOW is vertically combined, try to resize it + ;; vertically. + ((and (not (eq fit-window-to-buffer-horizontally 'only)) + (not (window-size-fixed-p window)) + (window-combined-p)) + ;; Vertically we always want to fit the entire buffer. + ;; WINDOW'S height can't get larger than its frame's pixel + ;; height. Its width remains fixed. + (setq height (cdr (window-text-pixel-size + nil (point-min) (point-max) + (* body-width char-width) + (frame-pixel-height)))) + ;; Round height. + (setq height (+ (/ height char-height) + (if (zerop (% height char-height)) 0 1))) + (unless (=3D height body-height) + (window-resize-no-error + window + (- (max min-height + (min max-height + (+ total-height (- height body-height)))) + total-height) + nil window))) + ;; If WINDOW is horizontally combined, try to resize it + ;; horizontally. + ((and fit-window-to-buffer-horizontally + (not (window-size-fixed-p window t)) + (window-combined-p nil t)) + (let* ((display-width (display-pixel-width)) + (total-width (window-total-width)) + (min-width + ;; Sanitize MIN-WIDTH. + (if (numberp min-width) + ;; Can't get smaller than `window-safe-min-width'. + (max min-width window-safe-min-width) + ;; Preserve fringes, margines, scrollbars if present. + (window-min-size nil nil t))) + (max-width + ;; Sanitize MAX-WIDTH. + (if (numberp max-width) + (min (+ total-width (window-max-delta nil t)) max-width) + (+ total-width (window-max-delta nil t)))) + ;; When fitting vertically, assume that WINDOW's start + ;; position remains unaltered. WINDOW can't get wider + ;; than its frame's pixel width, its height remains + ;; unaltered. + (width (car (window-text-pixel-size + nil (window-start) (point-max) + (frame-pixel-width) + ;; Add one char-height to assure that + ;; we're on the safe side. This + ;; overshoots when the first line below + ;; the bottom is wider than the window. + (* body-height char-height))))) + (setq width (+ (/ width char-width) + (if (zerop (% width char-width)) 0 1))) + (unless (=3D width body-width) + (window-resize-no-error + window + (- (max min-width + (min max-width + (+ total-width (- width body-width)))) + total-width) + t window))))))))) =20 (defun window-safely-shrinkable-p (&optional window) "Return t if WINDOW can be shrunk without shrinking other windows. =3D=3D=3D modified file 'src/dispextern.h' --- src/dispextern.h 2013-01-02 16:13:04 +0000 +++ src/dispextern.h 2013-02-04 10:23:56 +0000 @@ -3054,7 +3054,7 @@ void init_iterator_to_row_start (struct it *, struct window *, struct glyph_row *); void start_display (struct it *, struct window *, struct text_pos); -void move_it_to (struct it *, ptrdiff_t, int, int, int, int); +int move_it_to (struct it *, ptrdiff_t, int, int, int, int); void move_it_vertically (struct it *, int); void move_it_vertically_backward (struct it *, int); void move_it_by_lines (struct it *, ptrdiff_t); =3D=3D=3D modified file 'src/xdisp.c' --- src/xdisp.c 2013-01-05 21:18:01 +0000 +++ src/xdisp.c 2013-02-04 13:43:35 +0000 @@ -8734,13 +8734,17 @@ =20 If TO_CHARPOS is in invisible text, e.g. a truncated part of a screen line, this function will set IT to the next position that is - displayed to the right of TO_CHARPOS on the screen. */ - -void + displayed to the right of TO_CHARPOS on the screen. + + Return the maximum pixel length of any line scanned but never more + than it.last_visible_x. */ + +int move_it_to (struct it *it, ptrdiff_t to_charpos, int to_x, int to_y, int= to_vpos, int op) { enum move_it_result skip, skip2 =3D MOVE_X_REACHED; int line_height, line_start_x =3D 0, reached =3D 0; + int max_current_x =3D 0; void *backup_data =3D NULL; =20 for (;;) @@ -8814,7 +8818,10 @@ =20 /* If TO_CHARPOS is reached or ZV, we don't have to do more. */ if (skip =3D=3D MOVE_POS_MATCH_OR_ZV) - reached =3D 5; + { + max_current_x =3D max (it->current_x, max_current_x); + reached =3D 5; + } else if (skip =3D=3D MOVE_X_REACHED) { /* If TO_X was reached, we want to know whether TO_Y is @@ -8871,6 +8878,9 @@ if (to_y >=3D it->current_y && to_y < it->current_y + line_height) { + if (to_y > it->current_y) + max_current_x =3D max (it->current_x, max_current_x); + /* When word-wrap is on, TO_X may lie past the end of a wrapped line. Then it->current is the character on the next line, so backtrack to the @@ -8883,6 +8893,7 @@ skip =3D move_it_in_display_line_to (it, -1, prev_x, MOVE_TO_X); } + reached =3D 6; } } @@ -8908,15 +8919,18 @@ switch (skip) { case MOVE_POS_MATCH_OR_ZV: + max_current_x =3D max (it->current_x, max_current_x); reached =3D 8; goto out; =20 case MOVE_NEWLINE_OR_CR: + max_current_x =3D max (it->current_x, max_current_x); set_iterator_to_next (it, 1); it->continuation_lines_width =3D 0; break; =20 case MOVE_LINE_TRUNCATED: + max_current_x =3D it->last_visible_x; it->continuation_lines_width =3D 0; reseat_at_next_visible_line_start (it, 0); if ((op & MOVE_TO_POS) !=3D 0 @@ -8928,6 +8942,7 @@ break; =20 case MOVE_LINE_CONTINUED: + max_current_x =3D it->last_visible_x; /* For continued lines ending in a tab, some of the glyphs associated with the tab are displayed on the current line. Since it->current_x does not include these glyphs, @@ -8997,6 +9012,8 @@ bidi_unshelve_cache (backup_data, 1); =20 TRACE_MOVE ((stderr, "move_it_to: reached %d\n", reached)); + + return max_current_x; } =20 =20 @@ -9326,6 +9343,95 @@ && it->dpvec + it->current.dpvec_index !=3D it->dpend); } =20 +DEFUN ("window-text-pixel-size", Fwindow_text_pixel_size, Swindow_text_p= ixel_size, 0, 5, 0, + doc: /* Return the size of the text of WINDOW's buffer in pixels.= +WINDOW must be a live window and defaults to the selected one. The +return value is a cons of the maximum pixel-width of any text line and +the maximum pixel-height of all text lines. + +The optional argument FROM, if non-nil, specifies the first text +position and defaults to the minimum accessible position of the buffer. +TO, if non-nil, specifies the last text position and defaults to the +maximum accessible position of the buffer. + +The optional argument X_LIMIT, if non-nil, specifies the maximum text +width that can be returned. X_LIMIT nil or omitted, means to use the +pixel-width of WINDOW's body; use this if you do not intend to change +the width of WINDOW. Use the maximum width WINDOW may assume if you +intend to change WINDOW's width. + +The optional argument Y_LIMIT, if non-nil, specifies the maximum text +height that can be returned. Text lines whose y-coordinate is beyond +Y_LIMIT are ignored. Since calculating the text height of a large +buffer can take some time, it makes sense to specify this argument if +the size of the buffer is unknown. */) + (Lisp_Object window, Lisp_Object from, Lisp_Object to, Lisp_Object x_l= imit, Lisp_Object y_limit) +{ + struct window *w =3D decode_live_window (window); + Lisp_Object buf; + struct buffer *b; + struct it it; + struct buffer *old_buffer =3D NULL; + ptrdiff_t start, end; + struct text_pos startp, endp; + void *itdata =3D NULL; + int max_y =3D -1, x, y; + + buf =3D w->buffer; + CHECK_BUFFER (buf); + b =3D XBUFFER (buf); + + if (NILP (from)) + start =3D BEGV; + else + { + CHECK_NUMBER_COERCE_MARKER (from); + start =3D min (max (XINT (from), BEGV), ZV); + } + + if (NILP (to)) + end =3D ZV; + else + { + CHECK_NUMBER_COERCE_MARKER (to); + end =3D max (start, min (XINT (to), ZV)); + } + + if (b !=3D current_buffer) + { + old_buffer =3D current_buffer; + set_buffer_internal (b); + } + + if (!NILP (y_limit)) + { + CHECK_NUMBER (y_limit); + max_y =3D XINT (y_limit); + } + + itdata =3D bidi_shelve_cache (); + SET_TEXT_POS (startp, start, CHAR_TO_BYTE (start)); + start_display (&it, w, startp); + + if (!NILP (x_limit)) + { + CHECK_NUMBER (x_limit); + it.last_visible_x =3D XINT (x_limit); + } + + /* Actually, we never want move_it_to stop at to_x. But to make sure + that move_it_in_display_line_to always moves far enough, we set it + to MOST_POSITIVE_FIXNUM and specify MOVE_TO_X. */ + x =3D move_it_to (&it, end, MOST_POSITIVE_FIXNUM, max_y, -1, + MOVE_TO_POS | MOVE_TO_X | MOVE_TO_Y); + y =3D it.current_y; + bidi_unshelve_cache (itdata, 0); + + if (old_buffer) + set_buffer_internal (old_buffer); + + return Fcons (make_number (x), make_number (y)); +} =0C /***********************************************************************= Messages @@ -28808,6 +28914,7 @@ defsubr (&Sformat_mode_line); defsubr (&Sinvisible_p); defsubr (&Scurrent_bidi_paragraph_direction); + defsubr (&Swindow_text_pixel_size); =20 DEFSYM (Qmenu_bar_update_hook, "menu-bar-update-hook"); DEFSYM (Qoverriding_terminal_local_map, "overriding-terminal-local-map= "); --------------010404010304040906020503-- From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 04 12:58:50 2013 Received: (at 13399) by debbugs.gnu.org; 4 Feb 2013 17:58:50 +0000 Received: from localhost ([127.0.0.1]:36282 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U2QJd-0003c7-Mi for submit@debbugs.gnu.org; Mon, 04 Feb 2013 12:58:50 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:32993) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U2QJa-0003by-Pg for 13399@debbugs.gnu.org; Mon, 04 Feb 2013 12:58:48 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MHP00700IZ7KP00@a-mtaout20.012.net.il> for 13399@debbugs.gnu.org; Mon, 04 Feb 2013 19:57:23 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MHP007MKJ7NB560@a-mtaout20.012.net.il>; Mon, 04 Feb 2013 19:57:23 +0200 (IST) Date: Mon, 04 Feb 2013 19:57:31 +0200 From: Eli Zaretskii Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B In-reply-to: <510FEA0E.2000405@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83obg09d2s.fsf@gnu.org> References: <50EE7BE5.2060806@gmx.at> <83hamohmtj.fsf@gnu.org> <50EFCA6D.7090702@gmx.at> <83ip74ume7.fsf@gnu.org> <50EFE99A.5070508@gmx.at> <838v80ugv1.fsf@gnu.org> <50F021EC.4040107@gmx.at> <50F054A0.2040606@gmx.at> <83libztt68.fsf@gnu.org> <83hammu7og.fsf@gnu.org> <510D436A.1000603@gmx.at> <83a9rmbo30.fsf@gnu.org> <510D58FC.2030605@gmx.at> <837gmqbm1x.fsf@gnu.org> <510E3167.9070707@gmx.at> <83y5f59osu.fsf@gnu.org> <510FEA0E.2000405@gmx.at> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 13399 Cc: monnier@iro.umontreal.ca, 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > Date: Mon, 04 Feb 2013 18:04:14 +0100 > From: martin rudalics > CC: monnier@iro.umontreal.ca, 13399@debbugs.gnu.org > > How about the attached patch? The C parts look OK to me. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 07 21:37:47 2017 Received: (at 13399) by debbugs.gnu.org; 8 Dec 2017 02:37:47 +0000 Received: from localhost ([127.0.0.1]:51222 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eN8Xr-00053t-34 for submit@debbugs.gnu.org; Thu, 07 Dec 2017 21:37:47 -0500 Received: from mail-ot0-f179.google.com ([74.125.82.179]:44243) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eN73P-0005Ty-6b for 13399@debbugs.gnu.org; Thu, 07 Dec 2017 20:02:16 -0500 Received: by mail-ot0-f179.google.com with SMTP id d27so7975759ote.11 for <13399@debbugs.gnu.org>; Thu, 07 Dec 2017 17:02:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=+b0iCIbG3itir6CUgI0WACppNWZFwloXR18Olax6+FQ=; b=RjVY10isL+MT1nnnJTHI/FoD2dsOLdWKBPdP84axWHiq5VXPBewuaMbq33Sdn9T5HG f7Ih/CWLNvDvkICn9OLE9JdIRLv3hnZ2N4lcmpEuyNWGoCps2Icn3p1Q1e3GnDYgFOEA LlEIbnWNyiqXaAkqmzS+0hUu55nFs+wHOkMySCc4+1Ma4OJTp9JBAMTLp6gaWiRUyN1T 1OXqj7BdKVCD6HgpXckmhF+N/MldxCPEpFhSHRQfsvT6urQf/KQBNAW3TwcoeyXIMeAR u/eCZRWW1AXpgWogInVQAhQBTetYuqKRFmqx/3zz6vBr+VhY89LL2JdyXl/X4Myv9FBL LKZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=+b0iCIbG3itir6CUgI0WACppNWZFwloXR18Olax6+FQ=; b=LB2ZNk0dWQCx1URdbPTKK2K3eTqcmP1LsvIVXlerntEjk4Xe0Ae+zyvRRvl50WOhCV tiEN6fEZPh/lu0fE9QV+ZgjjmGOCBSznTZHE18GPPsU32XblvlRgrqxfqRdZhloMKFkX c/9cIF7bRAChWI3JuMq3AHAStGXnS7HS0XiZtn3H9oj6S3cKfP2ZiJbPcHJZswWP6OqD ZbJGsKvRGWP3Om+t9jxsT+pK7r2bjA+uTrTW13L9EFjZNQokA9LAndlC1RSpkw1DRffT iGcwXuHze+5ndGkzj4CLjXhwxA1PuCqwhKN1EeB7t2BDJ9qTsdrUr8D6cTjAysO0tKfz u2wg== X-Gm-Message-State: AKGB3mL1Oq2TZwT1L18gNaQAZbHc7F4aO6mdOMvaDBv8jFTGC09ptW5q OUcTBMOKFw4N57Ng58EHj1Wvusb4eKgU1rnhDEUyyA== X-Google-Smtp-Source: AGs4zMZfkO+G66v+Pyf1//Veb9R6801aYWtq0Qith2KtWmZD9B/cVSyVAGwYLRzn6+dNo/OSxL+aJjky1rjJd6lueHI= X-Received: by 10.157.34.37 with SMTP id o34mr6099606ota.237.1512694929287; Thu, 07 Dec 2017 17:02:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.140.100 with HTTP; Thu, 7 Dec 2017 17:02:08 -0800 (PST) From: Adam Tack Date: Fri, 8 Dec 2017 01:02:08 +0000 Message-ID: Subject: 24.3.50; Word-wrap can't wrap at zero-width space U-200B To: 13399@debbugs.gnu.org Content-Type: multipart/mixed; boundary="001a11370fe8ea2677055fc9bbd2" X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 13399 X-Mailman-Approved-At: Thu, 07 Dec 2017 21:37:46 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) --001a11370fe8ea2677055fc9bbd2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have a patch for the original issue of word-wrap not wrapping at a zero-width space. The implementation uses a character table, and is closely based on that written by Martin Rudalics (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D13399#113), with Eli Zaretski's suggestions regarding unicode. The patch applies cleanly to the latest master, compiles on GNU+Linux (Ubuntu Xenial) and appears to work =E2=80=94 both of the following tests result in the expected wrapping on the zero-width space character (the first of these is taken verbatim from this bug thread, the second, adapted from the first, checks that there is no regression of Bug#11341): (with-current-buffer (get-buffer-create "*foo*") (dotimes (i 1000) (insert "1234")) ; U-200B (setq word-wrap t) (display-buffer "*foo*")) (with-current-buffer (get-buffer-create "*bar*") (dotimes (i 1000) (insert "1234")) ; U-200B (setq word-wrap t) (setq whitespace-display-mappings '((space-mark 32 [183] [46]) (space-mark 160 [164] [95]) (space-mark 8203 [164] [95]) (newline-mark 10 [36 10]) (tab-mark 9 [187 9] [92 9]))) (whitespace-mode) (display-buffer "*bar*")) Setting other word-wrap characters using set-char-table-range with lisp also works as expected in the simple situations that I tested. However, this is my first foray into modifying a serious C codebase, so I am not sure if I have done the right thing. In particular, I have serious doubts about the second and third cases from IT_DISPLAYING_WHITESPACE, especially since I don't really know when they would be applicable. || ((STRINGP (it->string) \ && !NILP (CHAR_TABLE_REF \ (Vword_wrap_chars, STRING_CHAR \ (SDATA (it->string) + IT_STRING_BYTEPOS (*it))))) \ || (it->s && !NILP (CHAR_TABLE_REF \ (Vword_wrap_chars, \ STRING_CHAR(it->s + IT_BYTEPOS (*it))))) \ Additionally, I'm not certain whether syms_of_character in character.c is the right location for the definition of the char-table and whether the range of characters U+2000 to U+200B should be in the chartable, or if it should just be space and tab, by default. I am aware that if this were to be accepted, I would also need to make a change to etc/NEWS, probably the docstring of `word-wrap' and somewhere in the Texinfo manual. I have not yet filled out a copyright assignment form, though I will do so if this patch (modulo changes) is considered acceptable. Thanks! --001a11370fe8ea2677055fc9bbd2 Content-Type: text/plain; charset="US-ASCII"; name="word_wrap_char_table.diff" Content-Disposition: attachment; filename="word_wrap_char_table.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_jax7e7ne0 ZGlmZiAtLWdpdCBhL3NyYy9jaGFyYWN0ZXIuYyBiL3NyYy9jaGFyYWN0ZXIuYwppbmRleCBjOGZm YTJiLi42ZTdmNTVhIDEwMDY0NAotLS0gYS9zcmMvY2hhcmFjdGVyLmMKKysrIGIvc3JjL2NoYXJh Y3Rlci5jCkBAIC0xMTQ1LDQgKzExNDUsMTUgQEAgQWxsIFVuaWNvZGUgY2hhcmFjdGVycyBoYXZl IG9uZSBvZiB0aGUgZm9sbG93aW5nIHZhbHVlcyAoc3ltYm9sKToKIFNlZSBUaGUgVW5pY29kZSBT dGFuZGFyZCBmb3IgdGhlIG1lYW5pbmcgb2YgdGhvc2UgdmFsdWVzLiAgKi8pOwogICAvKiBUaGUg Y29ycmVjdCBjaGFyLXRhYmxlIGlzIHNldHVwIGluIGNoYXJhY3RlcnMuZWwuICAqLwogICBWdW5p Y29kZV9jYXRlZ29yeV90YWJsZSA9IFFuaWw7CisKKyAgREVGVkFSX0xJU1AgKCJ3b3JkLXdyYXAt Y2hhcnMiLCBWd29yZF93cmFwX2NoYXJzLAorCSAgICAgICBkb2M6IC8qIEEgY2hhci10YWJsZSBm b3IgY2hhcmFjdGVycyBhdCB3aGljaCB3b3JkLXdyYXAgb2NjdXJzLgorU3VjaCBjaGFyYWN0ZXJz IGhhdmUgdmFsdWUgdCBpbiB0aGlzIHRhYmxlLgorQnkgZGVmYXVsdCB0aGVzZSBhcmUgdGhlIHdo aXRlc3BhY2UgY2hhcmFjdGVycy4gKi8pOworICBWd29yZF93cmFwX2NoYXJzID0gRm1ha2VfY2hh cl90YWJsZSAoUW5pbCwgUW5pbCk7CisgIEZzZXRfY2hhcl90YWJsZV9yYW5nZSAoVndvcmRfd3Jh cF9jaGFycywgbWFrZV9udW1iZXIgKDkpLCBRdCk7CisgIEZzZXRfY2hhcl90YWJsZV9yYW5nZSAo VndvcmRfd3JhcF9jaGFycywgbWFrZV9udW1iZXIgKDMyKSwgUXQpOworICBGc2V0X2NoYXJfdGFi bGVfcmFuZ2UgKFZ3b3JkX3dyYXBfY2hhcnMsCisJCQkgRmNvbnMgKG1ha2VfbnVtYmVyICg4MTky KSwKKwkJCQltYWtlX251bWJlciAoODIwMykpLCBRdCk7CiB9CmRpZmYgLS1naXQgYS9zcmMveGRp c3AuYyBiL3NyYy94ZGlzcC5jCmluZGV4IDdlNDdjMDYuLjcxNTIyMjAgMTAwNjQ0Ci0tLSBhL3Ny Yy94ZGlzcC5jCisrKyBiL3NyYy94ZGlzcC5jCkBAIC0zNDgsMjAgKzM0OCwyMyBAQCBzdGF0aWMg TGlzcF9PYmplY3QgbGlzdF9vZl9lcnJvcjsKICNlbmRpZiAvKiBIQVZFX1dJTkRPV19TWVNURU0g Ki8KIAogLyogVGVzdCBpZiB0aGUgZGlzcGxheSBlbGVtZW50IGxvYWRlZCBpbiBJVCwgb3IgdGhl IHVuZGVybHlpbmcgYnVmZmVyCi0gICBvciBzdHJpbmcgY2hhcmFjdGVyLCBpcyBhIHNwYWNlIG9y IGEgVEFCIGNoYXJhY3Rlci4gIFRoaXMgaXMgdXNlZAotICAgdG8gZGV0ZXJtaW5lIHdoZXJlIHdv cmQgd3JhcHBpbmcgY2FuIG9jY3VyLiAgKi8KKyAgIG9yIHN0cmluZyBjaGFyYWN0ZXIsIGJlbG9u Z3MgdG8gdGhlIHdvcmQtd3JhcC1jaGFycyBjaGFyLXRhYmxlLgorICAgVGhpcyBpcyB1c2VkIHRv IGRldGVybWluZSB3aGVyZSB3b3JkIHdyYXBwaW5nIGNhbiBvY2N1ci4gICovCiAKICNkZWZpbmUg SVRfRElTUExBWUlOR19XSElURVNQQUNFKGl0KQkJCQkJXAotICAoKGl0LT53aGF0ID09IElUX0NI QVJBQ1RFUiAmJiAoaXQtPmMgPT0gJyAnIHx8IGl0LT5jID09ICdcdCcpKQlcCisgICgoaXQtPndo YXQgPT0gSVRfQ0hBUkFDVEVSCQkJCQkJXAorICAgICYmICFOSUxQIChDSEFSX1RBQkxFX1JFRiAo VndvcmRfd3JhcF9jaGFycywgaXQtPmMpKSkJCVwKICAgIHx8ICgoU1RSSU5HUCAoaXQtPnN0cmlu ZykJCQkJCQlcCi0JJiYgKFNSRUYgKGl0LT5zdHJpbmcsIElUX1NUUklOR19CWVRFUE9TICgqaXQp KSA9PSAnICcJCVwKLQkgICAgfHwgU1JFRiAoaXQtPnN0cmluZywgSVRfU1RSSU5HX0JZVEVQT1Mg KCppdCkpID09ICdcdCcpKQlcCi0gICAgICAgfHwgKGl0LT5zCQkJCQkJCVwKLQkgICAmJiAoaXQt PnNbSVRfQllURVBPUyAoKml0KV0gPT0gJyAnCQkJCVwKLQkgICAgICAgfHwgaXQtPnNbSVRfQllU RVBPUyAoKml0KV0gPT0gJ1x0JykpCQkJXAorCSYmICFOSUxQIChDSEFSX1RBQkxFX1JFRgkJCQkJ XAorCQkgIChWd29yZF93cmFwX2NoYXJzLCBTVFJJTkdfQ0hBUgkJCVwKKwkJICAgKFNEQVRBIChp dC0+c3RyaW5nKSArIElUX1NUUklOR19CWVRFUE9TICgqaXQpKSkpKQlcCisgICAgICAgfHwgKGl0 LT5zICYmICFOSUxQIChDSEFSX1RBQkxFX1JFRgkJCQlcCisJCQkgICAoVndvcmRfd3JhcF9jaGFy cywJCQkJXAorCQkJICAgIFNUUklOR19DSEFSKGl0LT5zICsgSVRfQllURVBPUyAoKml0KSkpKSkJ XAogICAgICAgIHx8IChJVF9CWVRFUE9TICgqaXQpIDwgWlZfQllURQkJCQkJXAotCSAgICYmICgq QllURV9QT1NfQUREUiAoSVRfQllURVBPUyAoKml0KSkgPT0gJyAnCQkJXAotCSAgICAgICB8fCAq QllURV9QT1NfQUREUiAoSVRfQllURVBPUyAoKml0KSkgPT0gJ1x0JykpKSkJCVwKKwkgICAmJiAh TklMUCAoQ0hBUl9UQUJMRV9SRUYJCQkJCVwKKwkJICAgICAoVndvcmRfd3JhcF9jaGFycywJCQkJ CVwKKwkJICAgICAgKEZFVENIX0NIQVIoSVRfQllURVBPUyAoKml0KSkpKSkpKSkJCVwKIAogLyog VHJ1ZSBtZWFucyBwcmludCBuZXdsaW5lIHRvIHN0ZG91dCBiZWZvcmUgbmV4dCBtaW5pLWJ1ZmZl ciBtZXNzYWdlLiAgKi8KIAo= --001a11370fe8ea2677055fc9bbd2-- From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 08 05:12:43 2017 Received: (at 13399) by debbugs.gnu.org; 8 Dec 2017 10:12:43 +0000 Received: from localhost ([127.0.0.1]:51387 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eNFe7-0000ef-J4 for submit@debbugs.gnu.org; Fri, 08 Dec 2017 05:12:43 -0500 Received: from mout.gmx.net ([212.227.17.22]:63778) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eNFe5-0000eR-TS for 13399@debbugs.gnu.org; Fri, 08 Dec 2017 05:12:42 -0500 Received: from [192.168.1.100] ([46.125.250.26]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MPppG-1eR7WT02ni-0052TN; Fri, 08 Dec 2017 11:12:35 +0100 Message-ID: <5A2A6587.9060207@gmx.at> Date: Fri, 08 Dec 2017 11:12:23 +0100 From: martin rudalics MIME-Version: 1.0 To: Adam Tack , 13399@debbugs.gnu.org Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B References: <50EE7BE5.2060806@gmx.at> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:tyOaAa8kDfDOVWe4ZZmQWXFuKYtMTnsZ2ajGPkRMY7QNw16r69R rEBpdHuFAdAOcwZ5fF0wv+BsCC1yLkVrwBZ86VYV4dXefXHE5BtDM5ohBRWG3GUM2kCKWLJ +nwe7FpBa27v2mF5o1Jeu4GQCmYwZEnX70knWoJnG4oxmM2CpyJRK96BfpHqM+X6dz5i081 54idPCTB6MDLnyuUfJJoQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:DD2/xJgFMoU=:vXi611n8RH0gmV+wnXaLoA g5BWw64qfROLlxrV3Jn62E8e+zPK28Vh8/wRkItTrW1Dr5210h+KCofVV+596XKr0SdseqKPM BJ5DumL1wYt2QD2L2itWoDTYRrk79NgQXPsER0GpZ6h3SZYJ8pSvNZzGfT/P1rmIlgzFba4VX aZkVhWcuqhQ9wOt3c+6pP+Cxaw2VJgG+nvfJP+39zbvU2p7pd1Rew2fck5B9y7LT7B38luTrs HAr8hBl8fTYX1TAFHTrXZHFOg3Ojki6Y9wUxFS3RYrsLVOtpu8aCFxbTUUpvvkTHgvTqHtqyk Wahba0j+oZje8qTEEaP8ZtKacxOFSfaniUthpn6a8BMGM21JiI9yDgVwn7tyWTw2ajW4XXdL1 43vq6fs1mJZm9k6V1O/MpZIFzke0MTXDYt+3lgt5ka5bUjIWWBSMnKJdYybEq+jYkxaRuDCY0 VMyKG5CytCZodjMzEQp9RdyyxwCU39loqbwYw8ZMRHVVemACmwr1H8HHT+9/IRhl54rHuhCPE ytfzTnGyPnvp3wiaKnDHTBmpCjcGrWWRdUxIOlDiFjSBqJ968CBPWNiBkESaR4W3Ijvt1WVi9 1swSn3+kNV1IiPtDAyPOW2v6nOjpW16uw4DZw24OXge9Cg7qWfWiVB75GuMc+FNC0HZjn3g/I 31PwKVFpWbjRkzBE+BsDMYtyuCXCr7eH0BRjrkBQe2O62U0fQUveGyGKBdS4iOL5V92E6rN7c wLE6oPRPhL2kVGXEitxeW0xnr/U5A/3Rx4DphHBFQtYNY6C2UX3uvIHMn9ftB9JE4QyW0E+4L cQ47qnFGyesqUgpvIj01DZIMEderVb+PzTg+5XyuD0VaXnHtbpozKwAwDoLFuteN/obrdJSpO x3fbWxu5/tzX3UhTpY6g== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 13399 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > I have a patch for the original issue of word-wrap not wrapping at a > zero-width space. The implementation uses a character table, and is > closely based on that written by Martin Rudalics > (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D13399#113), with Eli > Zaretski's suggestions regarding unicode. > > The patch applies cleanly to the latest master, compiles on GNU+Linux > (Ubuntu Xenial) and appears to work =E2=80=94 both of the following te= sts > result in the expected wrapping on the zero-width space character (the= > first of these is taken verbatim from this bug thread, the second, > adapted from the first, checks that there is no regression of Bug#1134= 1): Thank you very much for woking on this. The patch applies here and seems to work as needed. martin From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 08 10:39:02 2017 Received: (at 13399) by debbugs.gnu.org; 8 Dec 2017 15:39:02 +0000 Received: from localhost ([127.0.0.1]:52705 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eNKjt-0001z4-Vw for submit@debbugs.gnu.org; Fri, 08 Dec 2017 10:39:02 -0500 Received: from eggs.gnu.org ([208.118.235.92]:43191) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eNKjs-0001yY-E4 for 13399@debbugs.gnu.org; Fri, 08 Dec 2017 10:39:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eNKjj-0003xc-BP for 13399@debbugs.gnu.org; Fri, 08 Dec 2017 10:38:55 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD, URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:40616) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eNKjj-0003xT-8C; Fri, 08 Dec 2017 10:38:51 -0500 Received: from [176.228.60.248] (port=3220 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eNKji-0005Te-EO; Fri, 08 Dec 2017 10:38:51 -0500 Date: Fri, 08 Dec 2017 17:38:29 +0200 Message-Id: <83609hw7pm.fsf@gnu.org> From: Eli Zaretskii To: Adam Tack In-reply-to: (message from Adam Tack on Fri, 8 Dec 2017 01:02:08 +0000) Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B References: <50EE7BE5.2060806@gmx.at> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 13399 Cc: 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Adam Tack > Date: Fri, 8 Dec 2017 01:02:08 +0000 > > I have a patch for the original issue of word-wrap not wrapping at a > zero-width space. The implementation uses a character table, and is > closely based on that written by Martin Rudalics > (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=13399#113), with Eli > Zaretski's suggestions regarding unicode. Thanks for working on this! > However, this is my first foray into modifying a serious C codebase, > so I am not sure if I have done the right thing. In particular, I > have serious doubts about the second and third cases from > IT_DISPLAYING_WHITESPACE, especially since I don't really know when > they would be applicable. > > || ((STRINGP (it->string) \ > && !NILP (CHAR_TABLE_REF \ > (Vword_wrap_chars, STRING_CHAR \ > (SDATA (it->string) + IT_STRING_BYTEPOS (*it))))) \ > || (it->s && !NILP (CHAR_TABLE_REF \ > (Vword_wrap_chars, \ > STRING_CHAR(it->s + IT_BYTEPOS (*it))))) \ I think this is okay, but maybe the macro could be converted into an inline function, and then fetching the character from the various objects separated from looking up the char-table for that character? > Additionally, I'm not certain whether syms_of_character in character.c > is the right location for the definition of the char-table and whether > the range of characters U+2000 to U+200B should be in the chartable, > or if it should just be space and tab, by default. Well, since it's a char-table, users will probably want to control which characters cause word-wrap. One idea would be to have a minor mode or some such, providing users an ability to include or exclude different groups of related whitespace characters as a whole? This could be in follow-up patches, though. We could also look at LineBreak.txt in the Unicode database for inspiration and ideas. But I do think that the default should be only TAB and SPC, as Emacs always did, and the rest should be optional, and probably in Lisp, not C. > I am aware that if this were to be accepted, I would also need to make > a change to etc/NEWS, probably the docstring of `word-wrap' and > somewhere in the Texinfo manual. And also a couple of tests (the ones you used would be a good start). > I have not yet filled out a copyright assignment form, though I will > do so if this patch (modulo changes) is considered acceptable. I will send the forms off-list, thanks. From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 08 15:09:05 2017 Received: (at 13399) by debbugs.gnu.org; 8 Dec 2017 20:09:05 +0000 Received: from localhost ([127.0.0.1]:52909 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eNOxC-0005W1-O0 for submit@debbugs.gnu.org; Fri, 08 Dec 2017 15:09:02 -0500 Received: from eggs.gnu.org ([208.118.235.92]:53767) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eNOxA-0005VX-SK for 13399@debbugs.gnu.org; Fri, 08 Dec 2017 15:09:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eNOx0-0002h6-Sf for 13399@debbugs.gnu.org; Fri, 08 Dec 2017 15:08:55 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD, URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:44599) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eNOx0-0002h0-Ou; Fri, 08 Dec 2017 15:08:50 -0500 Received: from [176.228.60.248] (port=3792 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eNOwz-00058b-5w; Fri, 08 Dec 2017 15:08:50 -0500 Date: Fri, 08 Dec 2017 22:08:22 +0200 Message-Id: <83r2s5ugnd.fsf@gnu.org> From: Eli Zaretskii To: adam.tack.513@gmail.com In-reply-to: <83609hw7pm.fsf@gnu.org> (message from Eli Zaretskii on Fri, 08 Dec 2017 17:38:29 +0200) Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B References: <50EE7BE5.2060806@gmx.at> <83609hw7pm.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 13399 Cc: 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Date: Fri, 08 Dec 2017 17:38:29 +0200 > From: Eli Zaretskii > Cc: 13399@debbugs.gnu.org > > > || ((STRINGP (it->string) \ > > && !NILP (CHAR_TABLE_REF \ > > (Vword_wrap_chars, STRING_CHAR \ > > (SDATA (it->string) + IT_STRING_BYTEPOS (*it))))) \ > > || (it->s && !NILP (CHAR_TABLE_REF \ > > (Vword_wrap_chars, \ > > STRING_CHAR(it->s + IT_BYTEPOS (*it))))) \ One other thought: since TAB and SPC are single-byte characters, whereas the other "whitespace" characters are not, supporting the non-ASCII whitespace will be associated with some performance hit in the display engine, because it requires a char-table look up and fetching multibyte characters. So perhaps we should allow the word-wrap-chars char-table to be nil (and make that the default), and in that case support only TAB and SPC as word-wrap characters. This would let the default configuration work as fast is it does now, imposing the performance penalty only on those who want to support more whitespace characters. WDYT? From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 08 22:50:15 2017 Received: (at 13399) by debbugs.gnu.org; 9 Dec 2017 03:50:15 +0000 Received: from localhost ([127.0.0.1]:53055 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eNW9X-0007fZ-0I for submit@debbugs.gnu.org; Fri, 08 Dec 2017 22:50:15 -0500 Received: from mail-wm0-f52.google.com ([74.125.82.52]:42172) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eNW9U-0007fJ-DO for 13399@debbugs.gnu.org; Fri, 08 Dec 2017 22:50:12 -0500 Received: by mail-wm0-f52.google.com with SMTP id b199so2270322wme.1 for <13399@debbugs.gnu.org>; Fri, 08 Dec 2017 19:50:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JmcVX1CB8cbP/h7WgHG4LWlC3UkrV5LOU5m7bMktvJE=; b=an7R+wzn9UO0mL95s+Aqs5rXPVejqwT3uJm3wmrBnsdJcdUuDSyH55YoO7JIzqKAEZ fxp/G0PbUkNjanfSipVnNMNtPUAr/5Iq/zazKh9hblkGyPcZfd4bCX58hwMQymyVU344 GobSMMW6WVnRwXvZcdGU2RHX32WMzOXL0sAdx7wBwPpIxWkYR945cEsoq+U4VaLUjGsH UOQ5zypTg5x5dH7MgvWX5ClZZ6ODaogLYduZbH43b2LQOO7NI/b4kAtr6NOkRW/G5IN6 KdLEk9QCfE0oJhKZAdkS587OylotDydg3Hp8i3AwY1qGGlUfLG+As0KEVo1bX6Q/ZPdV j0wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JmcVX1CB8cbP/h7WgHG4LWlC3UkrV5LOU5m7bMktvJE=; b=f+c9CAJhHCi6XD8IMclm1cgT4BPOEgt+e4SJ9pp5cgHKI9biIAF5+imybFgOy3nXN9 xlzq1b3Q4cby7hhR+Tf8Qry2ibFIIaE83xIgHlQWB45uNxIRLsBXnKS+nVmiZ37Gmkp+ B1hJvO29CBnvFWy1bTu+4W2HusHYfkNmdVM0DexIltq2CWa+OCWz+CjcVkC4+mrqkBC8 0yaBotZYn4bH3M7STmbci5OBGKQgwInY1NrafnLJ3l5HLRzJprKzwxJgj0Yv8aFVXB9J jBifYb3768erX1ruwv4tcVCS9X9Ay78ppMhj1FE91KuwM99Vr0hgRce2lpydZhwwFLSZ nzTQ== X-Gm-Message-State: AKGB3mKxO+rTvB8k2YxJJOQYRSaxwCEJMcfsIwwhq+rbtw75ca7HJ2c8 W6EsjKANt5Y+b8aY61sA/jXV+WZACnCH2q4Be2E= X-Google-Smtp-Source: AGs4zMZGmLKBXCe96fwYMuiN5D88qKWeGq75yI1PorHHDv68IkehcZkLn8FCvI4gEAsNg6vy2ek75fS2WPSI65+obL8= X-Received: by 10.28.13.145 with SMTP id 139mr5580721wmn.24.1512791406581; Fri, 08 Dec 2017 19:50:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.52.145 with HTTP; Fri, 8 Dec 2017 19:50:05 -0800 (PST) In-Reply-To: <83r2s5ugnd.fsf@gnu.org> References: <50EE7BE5.2060806@gmx.at> <83609hw7pm.fsf@gnu.org> <83r2s5ugnd.fsf@gnu.org> From: Adam Tack Date: Sat, 9 Dec 2017 03:50:05 +0000 Message-ID: Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B To: Eli Zaretskii Content-Type: multipart/mixed; boundary="001a114433ea68d23e055fe032f4" X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 13399 Cc: 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) --001a114433ea68d23e055fe032f4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the very fast replies and the suggestions! > I think this is okay, but maybe the macro could be converted into an > inline function, and then fetching the character from the various > objects separated from looking up the char-table for that character? I've made the conversion =E2=80=94 it's now slightly less messy. Regarding the separation, I think that the most that can be done is to have the look-up in a separate function. Regrettably, trying to first obtain the character, for example via a set of if-else clauses, and then looking it up, which would be cleaner, can't really work since the cases (in particular the first and fourth) are not disjunct. > Well, since it's a char-table, users will probably want to control > which characters cause word-wrap. One idea would be to have a minor > mode or some such, providing users an ability to include or exclude > different groups of related whitespace characters as a whole? This > could be in follow-up patches, though. Customisability was the idea. :) I'm not sure how best to expose it in a reasonably user-friendly way, though. For the time being, allowing control directly via the char-table might suffice. > We could also look at LineBreak.txt in the Unicode database for > inspiration and ideas. The three main customisation options that I'm considering are: i) Unicode whitespace (U+2000 - U+200B), ii) vim's breakat characters (default " ^I!@*-+;:,./?"), since presumably they had given it some thought, iii) The characters in LineBreak.txt (parsing the file shouldn't be hard, if there aren't copyright issues). > But I do think that the default should be only TAB and SPC, as Emacs > always did, and the rest should be optional, and probably in Lisp, not > C. > And also a couple of tests (the ones you used would be a good start). These would presumably have to be in tests/manual since the position of the word-wrap depends on too many variables (width of window, font type, font size)? > I will send the forms off-list, thanks. Thanks! > One other thought: since TAB and SPC are single-byte characters, > whereas the other "whitespace" characters are not, supporting the > non-ASCII whitespace will be associated with some performance hit in > the display engine, because it requires a char-table look up and > fetching multibyte characters. So perhaps we should allow the > word-wrap-chars char-table to be nil (and make that the default), and > in that case support only TAB and SPC as word-wrap characters. This > would let the default configuration work as fast is it does now, > imposing the performance penalty only on those who want to support > more whitespace characters. > WDYT? That seems sensible. The old behaviour will now be the default and look-up using the char-table only enabled with the global minor mode `word-wrap-char-table-mode' (suggestions for a catchier name very welcome). For the time being, its definition is in a new file `lisp/word-wrap.el'. Also temporarily, for ease of testing, it allows wrapping on the unicode whitespace characters. The current iteration is attached. Until they've found a proper home, the slightly updated tests are below. (require 'word-wrap) (with-current-buffer (get-buffer-create "*bar*") (dotimes (i 1000) (insert "1234")) ; U-200B (setq word-wrap t) (setq whitespace-display-mappings '((space-mark 32 [183] [46]) (space-mark 160 [164] [95]) (space-mark 8203 [164] [95]) (newline-mark 10 [36 10]) (tab-mark 9 [187 9] [92 9]))) (whitespace-mode) (word-wrap-char-table-mode) (display-buffer "*bar*")) (with-current-buffer (get-buffer-create "*foo*") (dotimes (i 1000) (insert "1234")) ; U-200B (setq word-wrap t) (word-wrap-char-table-mode) (display-buffer "*foo*")) --001a114433ea68d23e055fe032f4 Content-Type: text/plain; charset="US-ASCII"; name="word_wrap_char_table.diff" Content-Disposition: attachment; filename="word_wrap_char_table.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_jaysjybf0 ZGlmZiAtLWdpdCBhL2xpc3Avd29yZC13cmFwLmVsIGIvbGlzcC93b3JkLXdyYXAuZWwKbmV3IGZp bGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uNmQ1OWE4MwotLS0gL2Rldi9udWxsCisrKyBi L2xpc3Avd29yZC13cmFwLmVsCkBAIC0wLDAgKzEsMjEgQEAKKyhkZWZpbmUtbWlub3ItbW9kZSB3 b3JkLXdyYXAtY2hhci10YWJsZS1tb2RlCisgICJUb2dnbGUgd3JhcHBpbmcgdXNpbmcgYSBsb29r LXVwIHRvIHdvcmQtd3JhcC1jaGFycywgZ2xvYmFsbHkuCisKK0N1cnJlbnRseSwgdGhpcyBhbGxv d3Mgd29yZCB3cmFwcGluZyBvbiB0aGUgY2hhcmFjdGVycyBVKzIwMDAgdG8KK1UrMjAwQiBpbiBh ZGRpdGlvbiB0byB0aGUgZGVmYXVsdCBvZiBzcGFjZSBhbmQgdGFwLCB3aGVuCitgd29yZC13cmFw JyBpcyBzZXQgdG8gdC4KKworKFByb3Zpc2lvbmFsIGFuZCB1bnN0YWJsZS4pCisiCisgIDpnbG9i YWwgdAorICA6bGlnaHRlciAidXdzICIKKyAgKGlmIHdvcmQtd3JhcC1jaGFyLXRhYmxlLW1vZGUK KyAgICAgIChwcm9nbiAoc2V0cSB3b3JkLXdyYXAtY2hhcnMgKG1ha2UtY2hhci10YWJsZSBuaWwg bmlsKSkKKyAgICAgICAgICAgICAoc2V0LWNoYXItdGFibGUtcmFuZ2Ugd29yZC13cmFwLWNoYXJz IDkgdCkKKyAgICAgICAgICAgICAoc2V0LWNoYXItdGFibGUtcmFuZ2Ugd29yZC13cmFwLWNoYXJz IDMyIHQpCisgICAgICAgICAgICAgKHNldC1jaGFyLXRhYmxlLXJhbmdlIHdvcmQtd3JhcC1jaGFy cworICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAnKDgxOTIgLiA4MjAzKSB0KSkK KyAgICAoc2V0cSB3b3JkLXdyYXAtY2hhcnMgbmlsKSkpCisKKyhwcm92aWRlICd3b3JkLXdyYXAp CisKZGlmZiAtLWdpdCBhL3NyYy9jaGFyYWN0ZXIuYyBiL3NyYy9jaGFyYWN0ZXIuYwppbmRleCBj OGZmYTJiLi5hZjg5YThiIDEwMDY0NAotLS0gYS9zcmMvY2hhcmFjdGVyLmMKKysrIGIvc3JjL2No YXJhY3Rlci5jCkBAIC0xMTQ1LDQgKzExNDUsMTAgQEAgQWxsIFVuaWNvZGUgY2hhcmFjdGVycyBo YXZlIG9uZSBvZiB0aGUgZm9sbG93aW5nIHZhbHVlcyAoc3ltYm9sKToKIFNlZSBUaGUgVW5pY29k ZSBTdGFuZGFyZCBmb3IgdGhlIG1lYW5pbmcgb2YgdGhvc2UgdmFsdWVzLiAgKi8pOwogICAvKiBU aGUgY29ycmVjdCBjaGFyLXRhYmxlIGlzIHNldHVwIGluIGNoYXJhY3RlcnMuZWwuICAqLwogICBW dW5pY29kZV9jYXRlZ29yeV90YWJsZSA9IFFuaWw7CisKKyAgREVGVkFSX0xJU1AgKCJ3b3JkLXdy YXAtY2hhcnMiLCBWd29yZF93cmFwX2NoYXJzLAorCSAgICAgICBkb2M6IC8qIEEgY2hhci10YWJs ZSBmb3IgY2hhcmFjdGVycyBhdCB3aGljaCB3b3JkLXdyYXAgb2NjdXJzLgorU3VjaCBjaGFyYWN0 ZXJzIGhhdmUgdmFsdWUgdCBpbiB0aGlzIHRhYmxlLgorVGhpcyBpcyBzZXQgdXAgaW4gLi4uICov KTsKKyAgVndvcmRfd3JhcF9jaGFycyA9IFFuaWw7CiB9CmRpZmYgLS1naXQgYS9zcmMveGRpc3Au YyBiL3NyYy94ZGlzcC5jCmluZGV4IDdlNDdjMDYuLjRlOGIwNDUgMTAwNjQ0Ci0tLSBhL3NyYy94 ZGlzcC5jCisrKyBiL3NyYy94ZGlzcC5jCkBAIC0zNDgsMjAgKzM0OCw0MSBAQCBzdGF0aWMgTGlz cF9PYmplY3QgbGlzdF9vZl9lcnJvcjsKICNlbmRpZiAvKiBIQVZFX1dJTkRPV19TWVNURU0gKi8K IAogLyogVGVzdCBpZiB0aGUgZGlzcGxheSBlbGVtZW50IGxvYWRlZCBpbiBJVCwgb3IgdGhlIHVu ZGVybHlpbmcgYnVmZmVyCi0gICBvciBzdHJpbmcgY2hhcmFjdGVyLCBpcyBhIHNwYWNlIG9yIGEg VEFCIGNoYXJhY3Rlci4gIFRoaXMgaXMgdXNlZAotICAgdG8gZGV0ZXJtaW5lIHdoZXJlIHdvcmQg d3JhcHBpbmcgY2FuIG9jY3VyLiAgKi8KLQotI2RlZmluZSBJVF9ESVNQTEFZSU5HX1dISVRFU1BB Q0UoaXQpCQkJCQlcCi0gICgoaXQtPndoYXQgPT0gSVRfQ0hBUkFDVEVSICYmIChpdC0+YyA9PSAn ICcgfHwgaXQtPmMgPT0gJ1x0JykpCVwKLSAgIHx8ICgoU1RSSU5HUCAoaXQtPnN0cmluZykJCQkJ CQlcCi0JJiYgKFNSRUYgKGl0LT5zdHJpbmcsIElUX1NUUklOR19CWVRFUE9TICgqaXQpKSA9PSAn ICcJCVwKLQkgICAgfHwgU1JFRiAoaXQtPnN0cmluZywgSVRfU1RSSU5HX0JZVEVQT1MgKCppdCkp ID09ICdcdCcpKQlcCi0gICAgICAgfHwgKGl0LT5zCQkJCQkJCVwKLQkgICAmJiAoaXQtPnNbSVRf QllURVBPUyAoKml0KV0gPT0gJyAnCQkJCVwKLQkgICAgICAgfHwgaXQtPnNbSVRfQllURVBPUyAo Kml0KV0gPT0gJ1x0JykpCQkJXAotICAgICAgIHx8IChJVF9CWVRFUE9TICgqaXQpIDwgWlZfQllU RQkJCQkJXAotCSAgICYmICgqQllURV9QT1NfQUREUiAoSVRfQllURVBPUyAoKml0KSkgPT0gJyAn CQkJXAotCSAgICAgICB8fCAqQllURV9QT1NfQUREUiAoSVRfQllURVBPUyAoKml0KSkgPT0gJ1x0 JykpKSkJCVwKKyAgIG9yIHN0cmluZyBjaGFyYWN0ZXIsIGlzIGEgc3BhY2Ugb3IgdGFiIChieSBk ZWZhdWx0LCB0byBhdm9pZCB0aGUKKyAgIHVubmVjZXNzYXJ5IHBlcmZvcm1hbmNlIGhpdCBvZiBj aGFyLXRhYmxlIGxvb2t1cCkuICBJZgorICAgd29yZC13cmFwLWNoYXJzIGlzIGEgY2hhci10YWJs ZSwgdGhlbiBpbnN0ZWFkIGNoZWNrIGlmIHRoZSByZWxldmFudAorICAgZWxlbWVudCBvciBjaGFy YWN0ZXIgYmVsb25ncyB0byB0aGUgY2hhci10YWJsZS4gIFRoaXMgaXMgdXNlZCB0bworICAgZGV0 ZXJtaW5lIHdoZXJlIHdvcmQgd3JhcHBpbmcgY2FuIG9jY3VyLiAgKi8KKworc3RhdGljIGlubGlu ZSBib29sCitjaGFyX2lzX3doaXRlc3BhY2VfcCAoaW50IGMpIHsKKyAgcmV0dXJuICFOSUxQIChD SEFSX1RBQkxFX1JFRiAoVndvcmRfd3JhcF9jaGFycywgYykpOworfQorCitzdGF0aWMgaW5saW5l IGJvb2wKK2l0X2Rpc3BsYXlpbmdfd2hpdGVzcGFjZSAoc3RydWN0IGl0ICppdCkgeworICBpZiAo IUNIQVJfVEFCTEVfUCAoVndvcmRfd3JhcF9jaGFycykpIHsKKyAgICByZXR1cm4gKChpdC0+d2hh dCA9PSBJVF9DSEFSQUNURVIgJiYgKGl0LT5jID09ICcgJyB8fCBpdC0+YyA9PSAnXHQnKSkKKwkg ICAgfHwgKChTVFJJTkdQIChpdC0+c3RyaW5nKQorCQkgJiYgKFNSRUYgKGl0LT5zdHJpbmcsIElU X1NUUklOR19CWVRFUE9TICgqaXQpKSA9PSAnICcKKwkJICAgICB8fCBTUkVGIChpdC0+c3RyaW5n LCBJVF9TVFJJTkdfQllURVBPUyAoKml0KSkgPT0gJ1x0JykpCisJCXx8IChpdC0+cworCQkgICAg JiYgKGl0LT5zW0lUX0JZVEVQT1MgKCppdCldID09ICcgJworCQkJfHwgaXQtPnNbSVRfQllURVBP UyAoKml0KV0gPT0gJ1x0JykpCisJCXx8IChJVF9CWVRFUE9TICgqaXQpIDwgWlZfQllURQorCQkg ICAgJiYgKCpCWVRFX1BPU19BRERSIChJVF9CWVRFUE9TICgqaXQpKSA9PSAnICcKKwkJCXx8ICpC WVRFX1BPU19BRERSIChJVF9CWVRFUE9TICgqaXQpKSA9PSAnXHQnKSkpKTsKKyAgfSBlbHNlIHsK KyAgICByZXR1cm4gKChpdC0+d2hhdCA9PSBJVF9DSEFSQUNURVIgJiYgY2hhcl9pc193aGl0ZXNw YWNlX3AgKGl0LT5jKSkKKwkgICAgfHwgKFNUUklOR1AgKGl0LT5zdHJpbmcpICYmIGNoYXJfaXNf d2hpdGVzcGFjZV9wCisJCShTVFJJTkdfQ0hBUgorCQkgKFNEQVRBIChpdC0+c3RyaW5nKSArIElU X1NUUklOR19CWVRFUE9TICgqaXQpKSkpCisJICAgIHx8IChpdC0+cyAmJiBjaGFyX2lzX3doaXRl c3BhY2VfcAorCQkoU1RSSU5HX0NIQVIoaXQtPnMgKyBJVF9CWVRFUE9TICgqaXQpKSkpCisJICAg IHx8IChJVF9CWVRFUE9TICgqaXQpIDwgWlZfQllURSAmJiBjaGFyX2lzX3doaXRlc3BhY2VfcAor CQkoRkVUQ0hfQ0hBUiAoSVRfQllURVBPUyAoKml0KSkpKSk7CisgIH0KK30KIAogLyogVHJ1ZSBt ZWFucyBwcmludCBuZXdsaW5lIHRvIHN0ZG91dCBiZWZvcmUgbmV4dCBtaW5pLWJ1ZmZlciBtZXNz YWdlLiAgKi8KIApAQCAtODc4NSw3ICs4ODA2LDcgQEAgbW92ZV9pdF9pbl9kaXNwbGF5X2xpbmVf dG8gKHN0cnVjdCBpdCAqaXQsCiAJewogCSAgaWYgKGl0LT5saW5lX3dyYXAgPT0gV09SRF9XUkFQ ICYmIGl0LT5hcmVhID09IFRFWFRfQVJFQSkKIAkgICAgewotCSAgICAgIGlmIChJVF9ESVNQTEFZ SU5HX1dISVRFU1BBQ0UgKGl0KSkKKwkgICAgICBpZiAoaXRfZGlzcGxheWluZ193aGl0ZXNwYWNl IChpdCkpCiAJCW1heV93cmFwID0gdHJ1ZTsKIAkgICAgICBlbHNlIGlmIChtYXlfd3JhcCkKIAkJ ewpAQCAtODk1MCw3ICs4OTcxLDcgQEAgbW92ZV9pdF9pbl9kaXNwbGF5X2xpbmVfdG8gKHN0cnVj dCBpdCAqaXQsCiAJCQkJICBTQVZFX0lUICh0ZW1faXQsICppdCwgdGVtX2RhdGEpOwogCQkJCSAg c2V0X2l0ZXJhdG9yX3RvX25leHQgKGl0LCB0cnVlKTsKIAkJCQkgIGlmIChnZXRfbmV4dF9kaXNw bGF5X2VsZW1lbnQgKGl0KQotCQkJCSAgICAgICYmIElUX0RJU1BMQVlJTkdfV0hJVEVTUEFDRSAo aXQpKQorCQkJCSAgICAgICYmIGl0X2Rpc3BsYXlpbmdfd2hpdGVzcGFjZSAoaXQpKQogCQkJCSAg ICBjYW5fd3JhcCA9IGZhbHNlOwogCQkJCSAgUkVTVE9SRV9JVCAoaXQsICZ0ZW1faXQsIHRlbV9k YXRhKTsKIAkJCQl9CkBAIC05MDQxLDcgKzkwNjIsNyBAQCBtb3ZlX2l0X2luX2Rpc3BsYXlfbGlu ZV90byAoc3RydWN0IGl0ICppdCwKIAkJCSB3cmFwcGVkIGluIHRoZSBtaWRkbGUgb2Ygd2hpdGVz cGFjZS4KIAkJCSBUaGVyZWZvcmUsIHdyYXBfaXQgX2lzXyByZWxldmFudCBpbiB0aGF0CiAJCQkg Y2FzZS4gICovCi0JCSAgICAgICYmICEobW92ZWRfZm9yd2FyZCAmJiBJVF9ESVNQTEFZSU5HX1dI SVRFU1BBQ0UgKGl0KSkpCisJCSAgICAgICYmICEobW92ZWRfZm9yd2FyZCAmJiBpdF9kaXNwbGF5 aW5nX3doaXRlc3BhY2UgKGl0KSkpCiAJCSAgICB7CiAJCSAgICAgIC8qIElmIHdlJ3ZlIGZvdW5k IFRPX1gsIGdvIGJhY2sgdGhlcmUsIGFzIHdlIG5vdwogCQkJIGtub3cgdGhlIGxhc3Qgd29yZCBm aXRzIG9uIHRoaXMgc2NyZWVuIGxpbmUuICAqLwpAQCAtMjE0MjcsNyArMjE0NDgsNyBAQCBkaXNw bGF5X2xpbmUgKHN0cnVjdCBpdCAqaXQsIGludCBjdXJzb3JfdnBvcykKIAogCSAgaWYgKGl0LT5s aW5lX3dyYXAgPT0gV09SRF9XUkFQICYmIGl0LT5hcmVhID09IFRFWFRfQVJFQSkKIAkgICAgewot CSAgICAgIGlmIChJVF9ESVNQTEFZSU5HX1dISVRFU1BBQ0UgKGl0KSkKKwkgICAgICBpZiAoaXRf ZGlzcGxheWluZ193aGl0ZXNwYWNlIChpdCkpCiAJCW1heV93cmFwID0gdHJ1ZTsKIAkgICAgICBl bHNlIGlmIChtYXlfd3JhcCkKIAkJewpAQCAtMjE1NzEsNyArMjE1OTIsNyBAQCBkaXNwbGF5X2xp bmUgKHN0cnVjdCBpdCAqaXQsIGludCBjdXJzb3JfdnBvcykKIAkJCQkgd2FzIGEgc3BhY2Ugb3Ig dGFiIEFORCAoaWkpIHRoZQogCQkJCSBjdXJyZW50IGNoYXJhY3RlciBpcyBub3QuICAqLwogCQkJ ICAgICAgJiYgKCFtYXlfd3JhcAotCQkJCSAgfHwgSVRfRElTUExBWUlOR19XSElURVNQQUNFIChp dCkpKQorCQkJCSAgfHwgaXRfZGlzcGxheWluZ193aGl0ZXNwYWNlIChpdCkpKQogCQkJICAgIGdv dG8gYmFja190b193cmFwOwogCiAJCQkgIC8qIFJlY29yZCB0aGUgbWF4aW11bSBhbmQgbWluaW11 bSBidWZmZXIKQEAgLTIxNjA1LDcgKzIxNjI2LDcgQEAgZGlzcGxheV9saW5lIChzdHJ1Y3QgaXQg Kml0LCBpbnQgY3Vyc29yX3Zwb3MpCiAJCQkJCSAgd2FzIGEgc3BhY2Ugb3IgdGFiIEFORCAoaWkp IHRoZQogCQkJCQkgIGN1cnJlbnQgY2hhcmFjdGVyIGlzIG5vdC4gICovCiAJCQkJICAgICAgICYm ICghbWF5X3dyYXAKLQkJCQkJICAgfHwgSVRfRElTUExBWUlOR19XSElURVNQQUNFIChpdCkpKQor CQkJCQkgICB8fCBpdF9kaXNwbGF5aW5nX3doaXRlc3BhY2UgKGl0KSkpCiAJCQkJZ290byBiYWNr X3RvX3dyYXA7CiAKIAkJCSAgICB9Cg== --001a114433ea68d23e055fe032f4-- From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 12 12:13:52 2017 Received: (at 13399) by debbugs.gnu.org; 12 Dec 2017 17:13:53 +0000 Received: from localhost ([127.0.0.1]:58799 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eOo7s-00055R-KU for submit@debbugs.gnu.org; Tue, 12 Dec 2017 12:13:52 -0500 Received: from eggs.gnu.org ([208.118.235.92]:58313) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eOo7r-00055E-Pz for 13399@debbugs.gnu.org; Tue, 12 Dec 2017 12:13:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eOo7h-0004Dc-MQ for 13399@debbugs.gnu.org; Tue, 12 Dec 2017 12:13:46 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51319) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eOo7h-0004DM-IM; Tue, 12 Dec 2017 12:13:41 -0500 Received: from [176.228.60.248] (port=1035 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eOo7g-0002N7-VQ; Tue, 12 Dec 2017 12:13:41 -0500 Date: Tue, 12 Dec 2017 19:13:33 +0200 Message-Id: <838te7swci.fsf@gnu.org> From: Eli Zaretskii To: Adam Tack In-reply-to: (message from Adam Tack on Sat, 9 Dec 2017 03:50:05 +0000) Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B References: <50EE7BE5.2060806@gmx.at> <83609hw7pm.fsf@gnu.org> <83r2s5ugnd.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 13399 Cc: 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Adam Tack > Date: Sat, 9 Dec 2017 03:50:05 +0000 > Cc: 13399@debbugs.gnu.org > > > I think this is okay, but maybe the macro could be converted into an > > inline function, and then fetching the character from the various > > objects separated from looking up the char-table for that character? > > I've made the conversion — it's now slightly less messy. Regarding > the separation, I think that the most that can be done is to have the > look-up in a separate function. Regrettably, trying to first obtain > the character, for example via a set of if-else clauses, and then > looking it up, which would be cleaner, can't really work since the > cases (in particular the first and fourth) are not disjunct. Hmm... not sure why you arrived at this conclusion. E.g., what's wrong with the implementation at the bottom of this message? > > We could also look at LineBreak.txt in the Unicode database for > > inspiration and ideas. > > The three main customisation options that I'm considering are: > > i) Unicode whitespace (U+2000 - U+200B), Yes. > ii) vim's breakat characters (default " ^I!@*-+;:,./?"), since > presumably they had given it some thought, Maybe. I'm not sure in what modes this would be TRT. > iii) The characters in LineBreak.txt (parsing the file shouldn't be > hard, if there aren't copyright issues). We already import several UCD files, see admin/unidata, where you will also find copyright.html from the Unicode Consortium. > > And also a couple of tests (the ones you used would be a good start). > > These would presumably have to be in tests/manual since the position of > the word-wrap depends on too many variables (width of window, font > type, font size)? test/manual is okay. > diff --git a/lisp/word-wrap.el b/lisp/word-wrap.el > new file mode 100644 > index 0000000..6d59a83 > --- /dev/null > +++ b/lisp/word-wrap.el > @@ -0,0 +1,21 @@ > +(define-minor-mode word-wrap-char-table-mode > + "Toggle wrapping using a look-up to word-wrap-chars, globally. > + > +Currently, this allows word wrapping on the characters U+2000 to > +U+200B in addition to the default of space and tap, when > +`word-wrap' is set to t. > + > +(Provisional and unstable.) > +" > + :global t > + :lighter "uws " > + (if word-wrap-char-table-mode > + (progn (setq word-wrap-chars (make-char-table nil nil)) > + (set-char-table-range word-wrap-chars 9 t) > + (set-char-table-range word-wrap-chars 32 t) > + (set-char-table-range word-wrap-chars > + '(8192 . 8203) t)) > + (setq word-wrap-chars nil))) This should probably go into simple.el. Thanks. Here's the implementation of IT_DISPLAYING_WHITESPACE I had in mind: static inline bool IT_DISPLAYING_WHITESPACE (struct it *it) { bool char_table_p = CHAR_TABLE_P (Vword_wrap_chars); int c; if (it->what == IT_CHARACTER) c = it->c; else if (!char_table_p) { if (STRINGP (it->string)) c = SREF (it->string, IT_STRING_BYTEPOS (*it)); else if (it->s) c = it->s[IT_BYTEPOS (*it)]; else if (IT_BYTEPOS (*it) < ZV_BYTE) c = *BYTE_POS_ADDR (IT_BYTEPOS (*it)); } else { if (STRINGP (it->string)) c = STRING_CHAR (SDATA (it->string) + IT_STRING_BYTEPOS (*it)); else if (it->s) c = STRING_CHAR (it->s + IT_BYTEPOS (*it)); else if (IT_BYTEPOS (*it) < ZV_BYTE) c = FETCH_CHAR_AS_MULTIBYTE (IT_BYTEPOS (*it)); } return char_table_p ? !NILP (CHAR_TABLE_REF (Vword_wrap_chars, c)) : (c == ' ' || c == '\t'); } From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 12 23:01:04 2017 Received: (at 13399) by debbugs.gnu.org; 13 Dec 2017 04:01:04 +0000 Received: from localhost ([127.0.0.1]:59265 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eOyEB-00074q-VI for submit@debbugs.gnu.org; Tue, 12 Dec 2017 23:01:04 -0500 Received: from mail-wm0-f41.google.com ([74.125.82.41]:34580) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eOyEA-00074G-Cr for 13399@debbugs.gnu.org; Tue, 12 Dec 2017 23:01:02 -0500 Received: by mail-wm0-f41.google.com with SMTP id y82so19944552wmg.1 for <13399@debbugs.gnu.org>; Tue, 12 Dec 2017 20:01:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=6EkmMhj7pU+5mtwMz4xWgILIX2HrB1pC2MHnKuC64MY=; b=IKXf6at4S1fFrXxqqhOa1UJAxvY1Qt506i7s9HWunEb5oUeUnHP29/1+c/G1Zvn6qm pxJxOb3m+Hnf54T3y5FPs1Sgz6jh7ClLMP9apNG+o4uzgVt0JdY0C/+uh9N8camvJf2q bMqVjpPRrE0VH6uk2BOVb/rT3HqxqDtgmwmhCExT1GtOOrEjJkc8hAieQcdjwYRUS8zu gK1Qvo0GtjgOReJsM3vHSZ73xPTqKstwyhAatgL/nHu2mcqvfWA+QuhV9cowvg7sbfxn zzTXdZS3nHWwCf4Qw5ezppIxi/b7zK0hk7DW63k54n9UuPnHQzZj5+3OMpw7QknDhBlN 11Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=6EkmMhj7pU+5mtwMz4xWgILIX2HrB1pC2MHnKuC64MY=; b=QdSDXGHU5uzGIPZ5yY73mjlmh347fZnUrqTP5/3+xoxCypjr8jEg6emQCR6okqVFch OSLMB8Sbm/PrAH+Uls1MQv1Opk5IuW0x/mRkwB8nYLjf440X0CPaZ79mhxiMSRBBTF/H QFBCBKDx35xMoRl7Yzlju6DBFdkQ1qh1JQ8PRw9Zob1MOb0ejIrmOdBzlIl0813+3U5i +pgzC4eMXNzBpFxC/1AXdXuj0pyvmf65x94nEcShJsBdd1fjv2HJ8VZXx3qD8DhGXd0H XX80T2PRQMC7J8KGiIZHW5G0oMIWuFuiFABt1fD7gnbEwYIKy37YUGntv2OPxzQ/DPZQ 4aMg== X-Gm-Message-State: AKGB3mJDbgJFEllJh99FDKnXmEGVmX8xFgm5h2jvHGwsLPFtozoKM5nz AWlwsHsfvECIzWaiN2SF0tuajRx/KloPBLdT7K8= X-Google-Smtp-Source: ACJfBot4XmGWhvEVFTN2n51Ibl+Xp7c7YsaZklVjWq98qSilngC1xSsckr5CVTYtfrUwmDVJrZxri+RmlTlk3N/jmo4= X-Received: by 10.28.108.11 with SMTP id h11mr700730wmc.28.1513137656466; Tue, 12 Dec 2017 20:00:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.52.145 with HTTP; Tue, 12 Dec 2017 20:00:56 -0800 (PST) In-Reply-To: <838te7swci.fsf@gnu.org> References: <50EE7BE5.2060806@gmx.at> <83609hw7pm.fsf@gnu.org> <83r2s5ugnd.fsf@gnu.org> <838te7swci.fsf@gnu.org> From: Adam Tack Date: Wed, 13 Dec 2017 04:00:56 +0000 Message-ID: Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 13399 Cc: 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) Sorry for not working further on this, but I didn't have time. I will get back to finishing this, soon. > Hmm... not sure why you arrived at this conclusion. E.g., what's > wrong with the implementation at the bottom of this message? This was very similar to my first try. Unfortunately, it doesn't work correctly in whitespace-mode, even with just normal spaces, regressing on Bug#11341. (with-current-buffer (get-buffer-create "*bar*") (dotimes (i 1000) (insert "1234 ")) ; Space (setq word-wrap t) (whitespace-mode) (display-buffer "*bar*")) The spaces are displayed as `=C2=B7', so it->c returns 183, none of the further tests are checked and IT_DISPLAYING_WHITESPACE returns False. (In the currently used implementation, if it->c is not one of ' ' or '\t' then the later tests are all checked.) I thought about changing the order of the tests to something like the following (ignoring the special case of ' ' and '\t', here, for brevity): static inline bool IT_DISPLAYING_WHITESPACE (struct it *it) { int c; if (IT_BYTEPOS (*it) < ZV_BYTE) c =3D FETCH_CHAR (IT_BYTEPOS (*it)); else if (it->what =3D=3D IT_CHARACTER) c =3D it->c; else if (STRINGP (it->string)) c =3D STRING_CHAR (SDATA (it->string) + IT_STRING_BYTEPOS (*it)); else if (it->s) c =3D STRING_CHAR (it->s + IT_BYTEPOS (*it)); else return false; return !NILP (CHAR_TABLE_REF (Vword_wrap_chars, c)); } which in the case of whitespace-mode does TRT, but I worried that there might be situations where wrapping on the display character is correct. The crux (as I had previously, but very unclearly, written) is that under "normal" circumstances, both `(it->what =3D=3D IT_CHARACTER)' and `(IT_BYTEPOS (*it) < ZV_BYTE)' are true. Additionally, I wasn't sure whether there should be a fall-through, since on the one hand, it prevents emacs crashing if (weirdly) all the previous tests return false, but on the other, it might preclude some magic compiler optimisation. Chaining ORs side-stepped both issues, so I settled on keeping it, though it might have been the wrong decision. > > ii) vim's breakat characters (default " ^I!@*-+;:,./?"), since > > presumably they had given it some thought, > Maybe. I'm not sure in what modes this would be TRT. It should almost certainly not be the default in any mode, but it might, perhaps, be a useful, pre-defined option for some users. (For instance, when wrapping long URLs or paths in comments: |;; | |https://very.long.url/that-will-not-fit-on-a-single-lin| |e-anyway-but-could-at-least-start-on-the-same-line-as-t| |he-comment-sign-and-break-at-slightly-more-logical-plac| |es | looks (IMO at least!) less aesthetically pleasing than: |;; https://very.long.url/that-will-not-fit-on-a-single-| |line-anyway-but-could-at-least-start-on-the-same-line- | |as-the-comment-sign-and-break-at-slightly-more-logical-| |places | where `|' is the margin. The same sometimes holds for excessively long variable names. I definitely wouldn't impose this preference on others, but I assume that some might share it.) Using vim's choice helps avoid bike-shedding. > We already import several UCD files, see admin/unidata, where you will > also find copyright.html from the Unicode Consortium. Great! That's convenient. > test/manual is okay. Thanks! > This should probably go into simple.el. I'll move it there. Thanks for the help! From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 13 11:09:32 2017 Received: (at 13399) by debbugs.gnu.org; 13 Dec 2017 16:09:33 +0000 Received: from localhost ([127.0.0.1]:60653 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eP9bA-0005A9-Mt for submit@debbugs.gnu.org; Wed, 13 Dec 2017 11:09:32 -0500 Received: from eggs.gnu.org ([208.118.235.92]:56834) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eP9b8-00059s-VX for 13399@debbugs.gnu.org; Wed, 13 Dec 2017 11:09:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eP9b0-0002DC-Nz for 13399@debbugs.gnu.org; Wed, 13 Dec 2017 11:09:25 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39262) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eP9b0-0002D4-KL; Wed, 13 Dec 2017 11:09:22 -0500 Received: from [176.228.60.248] (port=2494 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eP9b0-0005Xt-4A; Wed, 13 Dec 2017 11:09:22 -0500 Date: Wed, 13 Dec 2017 18:09:17 +0200 Message-Id: <83lgi6vccy.fsf@gnu.org> From: Eli Zaretskii To: Adam Tack In-reply-to: (message from Adam Tack on Wed, 13 Dec 2017 04:00:56 +0000) Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B References: <50EE7BE5.2060806@gmx.at> <83609hw7pm.fsf@gnu.org> <83r2s5ugnd.fsf@gnu.org> <838te7swci.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 13399 Cc: 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Adam Tack > Date: Wed, 13 Dec 2017 04:00:56 +0000 > Cc: 13399@debbugs.gnu.org > > > Hmm... not sure why you arrived at this conclusion. E.g., what's > > wrong with the implementation at the bottom of this message? > > This was very similar to my first try. Unfortunately, it doesn't work > correctly in whitespace-mode, even with just normal spaces, regressing > on Bug#11341. Right, I missed that. But then I guess it might be better to leave this a macro, as the function is not prettier. Or maybe leave the case of the char-table being nil as a macro, and put the rest in a function, like we do in several other places. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 16 21:22:22 2017 Received: (at 13399) by debbugs.gnu.org; 17 Dec 2017 02:22:22 +0000 Received: from localhost ([127.0.0.1]:37934 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eQOar-00085Y-8X for submit@debbugs.gnu.org; Sat, 16 Dec 2017 21:22:21 -0500 Received: from mail-wr0-f177.google.com ([209.85.128.177]:35325) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eQOao-00085L-Mt for 13399@debbugs.gnu.org; Sat, 16 Dec 2017 21:22:20 -0500 Received: by mail-wr0-f177.google.com with SMTP id z104so2177946wrb.2 for <13399@debbugs.gnu.org>; Sat, 16 Dec 2017 18:22:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UbpwPdBFiadR0CyG7l+cvuVZOCBc3G7HeTr3Bbm6ZKI=; b=Aoxs/cFGZLaxkq1xCwpt322YPwVh95oiMBMQ7GhPLCacRzqrhrCl9+v837qMBOxh0O uAfyjnL10uazovuANaGfmimYMBE2hxDX/080ElEmzaJYHJhcbR8fCJQoF6xn3lt7G6jN aVprjRxfPQ4LosKyt0pu7fKMcLvQ2B/6oh+ghP3O+JcK5KJjLkeT1GsunbxUrzDbxcJh OCbwlteEuO2cKow+DxoOtPN5tE8Ud9wX6k/gknEGE7Zt3n1RgnLJAfNNK+f9NCeTvUGQ EDw4h8LeWxI9tOdAQ4QMZ57nvRuZ5Wf+maRtrJw4XMbXwVltwV6xRMm28M5HSkyNpaLl fWyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UbpwPdBFiadR0CyG7l+cvuVZOCBc3G7HeTr3Bbm6ZKI=; b=YjtlGDj4LmGmhyZG5j/g62oTi6UKSJ+86dGAz47+cGOwo3FmDGHDASRRMVy4usRLoH g/tww0fsDGuhQ1JMZVCB9hgbel7g2SZlPAaEuEME+ZNH5fMuQqj6taADmblXdEa/K4Er yfMGPB/b7ReQVd4aN/lHmucYJjn/QP7gVzw30F2C/qNRIVhW/+lC/s8/oXJSp/9xTJsN wALTckpv0LshinPlAwjOS/qOYFh4K2nCed796fcRzZbEGvOmCqbUCMTzQd61f547xT69 IRmdKv85Vd/bLmcigFMX6K8CmxnqRKmYCpSgyry1PF8+/ODiDSR85vzPSGNR8hNm8joi eplw== X-Gm-Message-State: AKGB3mILyfyiVP+utZ7ayILJxbph0odmXRVzhVL8LmAfRwgeisLeZZS+ /eUcI5Yb5wuYYpA/FKzbVQae51/R6vh1e+MBq2fo/g== X-Google-Smtp-Source: ACJfBotv2LGwGt1CQiL5FD2dH4YymNuBeeJUUw4doasQZ7ZlHqbgnLHnwJzm03xHuHohNsNYBUKRQIrtcnP+Xjg1L8o= X-Received: by 10.223.136.56 with SMTP id d53mr2303219wrd.36.1513477332860; Sat, 16 Dec 2017 18:22:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.52.145 with HTTP; Sat, 16 Dec 2017 18:22:12 -0800 (PST) In-Reply-To: <83lgi6vccy.fsf@gnu.org> References: <50EE7BE5.2060806@gmx.at> <83609hw7pm.fsf@gnu.org> <83r2s5ugnd.fsf@gnu.org> <838te7swci.fsf@gnu.org> <83lgi6vccy.fsf@gnu.org> From: Adam Tack Date: Sun, 17 Dec 2017 02:22:12 +0000 Message-ID: Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B To: Eli Zaretskii Content-Type: multipart/mixed; boundary="001a114915c8cd6a5605607fe6e9" X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 13399 Cc: 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) --001a114915c8cd6a5605607fe6e9 Content-Type: text/plain; charset="UTF-8" > Right, I missed that. But then I guess it might be better to leave > this a macro, as the function is not prettier. Or maybe leave the > case of the char-table being nil as a macro, and put the rest in a > function, like we do in several other places. I've split out the non-nil char-table case out into a function, as I think that using a named function slightly improves readability, and having a macro over 20 lines long, somehow feels "wrong". If the compiler does actually follow the inline directive, there should be no additional performance hit. Is the convention for "static inline" functions to be in lower-case? (The few cases that I've found in w32term.c are not capitalised.) Attached is a working (and hopefully complete) patch for word-wrap using the `word-wrap-chars' char-table (without a nice lisp interface). Also attached is a patch for the lisp interface. However, upon reflection, I'm not sure whether my approach of using a new minor mode (the horribly named `word-wrap-chars-mode') is the best, as it's not very discoverable and adds yet another minor mode, whose existence must be remembered and whose lighter will clutter the mode-line. The alternative would be to just use `visual-line-mode', without changing the default behaviour and allow customization by customizing `word-wrap-type'. `visual-line-mode' would then be modified slightly so that, when being enabled: i) it calls `set-word-wrap-chars', ii) it saves `word-wrap-chars' to `visual-line--saved-state', if it had been locally set (like for the other relevant variables), and when disabled, it unsets `word-wrap-chars'. The default of `word-wrap-type' would be changed to ascii-whitespace. By default, the effect of `visual-line-mode' would not change, other than a redundant call to `set-word-wrap-chars' which would keep `word-wrap-chars' set to nil. `word-wrap-type' would have to be customized for char-table-based wrapping to be used. Would such a change to `visual-line-mode' be acceptable? (The attached patch for the lisp interface then mostly stays the same, other than the dropping of `word-wrap-chars-mode'.) An option to add all unicode line breaking characters from LineBreak.txt to the `word-wrap-chars' char-table is still missing, as I'm not too comfortable with the unicode-category-table, it's probably not an option too urgently needed and it would be an incomplete implementation anyway, since the algorithm can only use the last character, not the following one, or the surroundings. Would the cleanest approach be to add a new `line-break' character property (corresponding to the Unicode Line_Break: http://unicode.org/reports/tr44/#Line_Break ), set it by parsing LineBreak.txt (during compilation of emacs), and then set `word-wrap-chars' based on which characters have the correct `line-break' property (SP, ZW, BA, B2, HY (?), SY (?), CB (???), SA (???)) when needed (and perhaps cache it)? Thank you for your continued guidance and best wishes, Adam --001a114915c8cd6a5605607fe6e9 Content-Type: text/plain; name="word_wrap_char_table.diff"; charset="US-ASCII" Content-Disposition: attachment; filename="word_wrap_char_table.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_jba57dlr0 ZGlmZiAtLWdpdCBhL2RvYy9lbWFjcy9kaXNwbGF5LnRleGkgYi9kb2MvZW1hY3MvZGlzcGxheS50 ZXhpCmluZGV4IDU4NjBiYWMuLmU3YmQwNmUgMTAwNjQ0Ci0tLSBhL2RvYy9lbWFjcy9kaXNwbGF5 LnRleGkKKysrIGIvZG9jL2VtYWNzL2Rpc3BsYXkudGV4aQpAQCAtMTcxOSw2ICsxNzE5LDEyIEBA IGxvZ2ljYWwgbGluZXMsIHNvIGhhdmluZyBhIGZyaW5nZSBpbmRpY2F0b3IgZm9yIGVhY2ggd3Jh cHBlZCBsaW5lCiB3b3VsZCBiZSB2aXN1YWxseSBkaXN0cmFjdGluZy4gIFlvdSBjYW4gY2hhbmdl IHRoaXMgYnkgY3VzdG9taXppbmcgdGhlCiB2YXJpYWJsZSBAY29kZXt2aXN1YWwtbGluZS1mcmlu Z2UtaW5kaWNhdG9yc30uCiAKK0B2aW5kZXggd29yZC13cmFwLWNoYXJzCisgIFdvcmQgYm91bmRh cmllcyBhbmQgaGVuY2UgcG9pbnRzIGF0IHdoaWNoIHdvcmQgd3JhcCBjYW4gb2NjdXIgYXJlLAor YnkgZGVmYXVsdCwgY29uc2lkZXJlZCB0byBvY2N1ciBvbiB0aGUgc3BhY2UgYW5kIHRhYiBjaGFy YWN0ZXJzLiAgSWYKK3lvdSBwcmVmZXIgd29yZC13cmFwIHRvIGJlIHBlcm1pc3NpYmxlIGF0IG90 aGVyIGNoYXJhY3RlcnMsIHlvdSBjYW4KK2NoYW5nZSB0aGUgdmFsdWUgb2YgdGhlIGNoYXItdGFi bGUgQGNvZGV7d29yZC13cmFwLWNoYXJzfS4KKwogQG5vZGUgRGlzcGxheSBDdXN0b20KIEBzZWN0 aW9uIEN1c3RvbWl6YXRpb24gb2YgRGlzcGxheQogCmRpZmYgLS1naXQgYS9ldGMvTkVXUyBiL2V0 Yy9ORVdTCmluZGV4IGNiZDUwZjAuLmE4N2VhYmMgMTAwNjQ0Ci0tLSBhL2V0Yy9ORVdTCisrKyBi L2V0Yy9ORVdTCkBAIC02MCw2ICs2MCwxMiBAQCBzdGF0ZSB0byB0YWtlIGVmZmVjdCAobWFraW5n IGEgZnJhbWUgdmlzaWJsZSwgZm9yIGV4YW1wbGUpLgogd2hldGhlciAnIicgaXMgYWxzbyByZXBs YWNlZCBpbiAnZWxlY3RyaWMtcXVvdGUtbW9kZScuICBJZiBub24tbmlsLAogJyInIGlzIHJlcGxh Y2VkIGJ5IGEgZG91YmxlIHR5cG9ncmFwaGljIHF1b3RlLgogCisrKysKKyoqIFRoZSBjaGFyYWN0 ZXJzIGF0IHdoaWNoIHdvcmQtd3JhcHBpbmcgb2NjdXJzIGNhbiBub3cgYmUgY29udHJvbGxlZAor dXNpbmcgdGhlIG5ldyBgd29yZC13cmFwLWNoYXJzJyBjaGFyLXRhYmxlLiAgSWYgYHdvcmQtd3Jh cC1jaGFycycgaXMKK25pbCAodGhlIGRlZmF1bHQpLCB0aGVuIHdvcmQtd3JhcHBpbmcgd2lsbCBv Y2N1ciBvbmx5IG9uIHRoZSBzcGFjZSBvcgordGFiIGNoYXJhY3RlcnMsIGFzIGhhcyBiZWVuIHRo ZSBjYXNlIHVudGlsIG5vdy4KKwogDAogKiBDaGFuZ2VzIGluIFNwZWNpYWxpemVkIE1vZGVzIGFu ZCBQYWNrYWdlcyBpbiBFbWFjcyAyNy4xCiAKZGlmZiAtLWdpdCBhL3NyYy9idWZmZXIuYyBiL3Ny Yy9idWZmZXIuYwppbmRleCAxMmE0NjdkLi4zZTI2MGJiIDEwMDY0NAotLS0gYS9zcmMvYnVmZmVy LmMKKysrIGIvc3JjL2J1ZmZlci5jCkBAIC01NzMwLDcgKzU3MzAsMTEgQEAgSW5zdGVhZCBvZiBz ZXR0aW5nIHRoaXMgdmFyaWFibGUgZGlyZWN0bHksIG1vc3QgdXNlcnMgc2hvdWxkIHVzZQogVmlz dWFsIExpbmUgbW9kZS4gIFZpc3VhbCBMaW5lIG1vZGUsIHdoZW4gZW5hYmxlZCwgc2V0cyBgd29y ZC13cmFwJwogdG8gdCwgYW5kIGFkZGl0aW9uYWxseSByZWRlZmluZXMgc2ltcGxlIGVkaXRpbmcg Y29tbWFuZHMgdG8gYWN0IG9uCiB2aXN1YWwgbGluZXMgcmF0aGVyIHRoYW4gbG9naWNhbCBsaW5l cy4gIFNlZSB0aGUgZG9jdW1lbnRhdGlvbiBvZgotYHZpc3VhbC1saW5lLW1vZGUnLiAgKi8pOwor YHZpc3VhbC1saW5lLW1vZGUnLgorCitJZiBgd29yZC13cmFwLWNoYXJzJyBpcyBub24tbmlsIGFu ZCBhIGNoYXItdGFibGUsIGNvbnRpbnVhdGlvbiBsaW5lcworYXJlIHdyYXBwZWQgb24gdGhlIGNo YXJhY3RlcnMgaW4gYHdvcmQtd3JhcC1jaGFycycgd2hvc2UgdmFsdWUgaXMgdCwKK3JhdGhlciB0 aGFuIHRoZSBzcGFjZSBhbmQgdGFiIGNoYXJhY3RlcnMuICAqLyk7CiAKICAgREVGVkFSX1BFUl9C VUZGRVIgKCJkZWZhdWx0LWRpcmVjdG9yeSIsICZCVkFSIChjdXJyZW50X2J1ZmZlciwgZGlyZWN0 b3J5KSwKIAkJICAgICBRc3RyaW5ncCwKZGlmZiAtLWdpdCBhL3NyYy9jaGFyYWN0ZXIuYyBiL3Ny Yy9jaGFyYWN0ZXIuYwppbmRleCBjOGZmYTJiLi5mZDFhOWQzIDEwMDY0NAotLS0gYS9zcmMvY2hh cmFjdGVyLmMKKysrIGIvc3JjL2NoYXJhY3Rlci5jCkBAIC0xMTQ1LDQgKzExNDUsMTAgQEAgQWxs IFVuaWNvZGUgY2hhcmFjdGVycyBoYXZlIG9uZSBvZiB0aGUgZm9sbG93aW5nIHZhbHVlcyAoc3lt Ym9sKToKIFNlZSBUaGUgVW5pY29kZSBTdGFuZGFyZCBmb3IgdGhlIG1lYW5pbmcgb2YgdGhvc2Ug dmFsdWVzLiAgKi8pOwogICAvKiBUaGUgY29ycmVjdCBjaGFyLXRhYmxlIGlzIHNldHVwIGluIGNo YXJhY3RlcnMuZWwuICAqLwogICBWdW5pY29kZV9jYXRlZ29yeV90YWJsZSA9IFFuaWw7CisKKyAg REVGVkFSX0xJU1AgKCJ3b3JkLXdyYXAtY2hhcnMiLCBWd29yZF93cmFwX2NoYXJzLAorCSAgICAg ICBkb2M6IC8qIEEgY2hhci10YWJsZSBmb3IgY2hhcmFjdGVycyBhdCB3aGljaCB3b3JkLXdyYXAg b2NjdXJzLgorU3VjaCBjaGFyYWN0ZXJzIGhhdmUgdmFsdWUgdCBpbiB0aGlzIHRhYmxlLiAgSWYg dGhlIGNoYXItdGFibGUgaXMgbmlsLAord29yZC13cmFwIG9jY3VycyBvbmx5IG9uIHNwYWNlIGFu ZCB0YWIuICAqLyk7CisgIFZ3b3JkX3dyYXBfY2hhcnMgPSBRbmlsOwogfQpkaWZmIC0tZ2l0IGEv c3JjL3hkaXNwLmMgYi9zcmMveGRpc3AuYwppbmRleCA3ZTQ3YzA2Li5kY2EwNzI2IDEwMDY0NAot LS0gYS9zcmMveGRpc3AuYworKysgYi9zcmMveGRpc3AuYwpAQCAtMzQ4LDIwICszNDgsNDIgQEAg c3RhdGljIExpc3BfT2JqZWN0IGxpc3Rfb2ZfZXJyb3I7CiAjZW5kaWYgLyogSEFWRV9XSU5ET1df U1lTVEVNICovCiAKIC8qIFRlc3QgaWYgdGhlIGRpc3BsYXkgZWxlbWVudCBsb2FkZWQgaW4gSVQs IG9yIHRoZSB1bmRlcmx5aW5nIGJ1ZmZlcgotICAgb3Igc3RyaW5nIGNoYXJhY3RlciwgaXMgYSBz cGFjZSBvciBhIFRBQiBjaGFyYWN0ZXIuICBUaGlzIGlzIHVzZWQKLSAgIHRvIGRldGVybWluZSB3 aGVyZSB3b3JkIHdyYXBwaW5nIGNhbiBvY2N1ci4gICovCisgICBvciBzdHJpbmcgY2hhcmFjdGVy LCBpcyBhIHNwYWNlIG9yIHRhYiAoYnkgZGVmYXVsdCwgdG8gYXZvaWQgdGhlCisgICB1bm5lY2Vz c2FyeSBwZXJmb3JtYW5jZSBoaXQgb2YgY2hhci10YWJsZSBsb29rdXApLiAgSWYKKyAgIHdvcmQt d3JhcC1jaGFycyBpcyBhIGNoYXItdGFibGUsIHRoZW4gaW5zdGVhZCBjaGVjayBpZiB0aGUgcmVs ZXZhbnQKKyAgIGVsZW1lbnQgb3IgY2hhcmFjdGVyIGJlbG9uZ3MgdG8gdGhlIGNoYXItdGFibGUu ICBUaGlzIGlzIHVzZWQgdG8KKyAgIGRldGVybWluZSB3aGVyZSB3b3JkIHdyYXBwaW5nIGNhbiBv Y2N1ci4gICovCiAKICNkZWZpbmUgSVRfRElTUExBWUlOR19XSElURVNQQUNFKGl0KQkJCQkJXAot ICAoKGl0LT53aGF0ID09IElUX0NIQVJBQ1RFUiAmJiAoaXQtPmMgPT0gJyAnIHx8IGl0LT5jID09 ICdcdCcpKQlcCi0gICB8fCAoKFNUUklOR1AgKGl0LT5zdHJpbmcpCQkJCQkJXAotCSYmIChTUkVG IChpdC0+c3RyaW5nLCBJVF9TVFJJTkdfQllURVBPUyAoKml0KSkgPT0gJyAnCQlcCi0JICAgIHx8 IFNSRUYgKGl0LT5zdHJpbmcsIElUX1NUUklOR19CWVRFUE9TICgqaXQpKSA9PSAnXHQnKSkJXAot ICAgICAgIHx8IChpdC0+cwkJCQkJCQlcCi0JICAgJiYgKGl0LT5zW0lUX0JZVEVQT1MgKCppdCld ID09ICcgJwkJCQlcCi0JICAgICAgIHx8IGl0LT5zW0lUX0JZVEVQT1MgKCppdCldID09ICdcdCcp KQkJCVwKLSAgICAgICB8fCAoSVRfQllURVBPUyAoKml0KSA8IFpWX0JZVEUJCQkJCVwKLQkgICAm JiAoKkJZVEVfUE9TX0FERFIgKElUX0JZVEVQT1MgKCppdCkpID09ICcgJwkJCVwKLQkgICAgICAg fHwgKkJZVEVfUE9TX0FERFIgKElUX0JZVEVQT1MgKCppdCkpID09ICdcdCcpKSkpCQlcCisgICgh Q0hBUl9UQUJMRV9QIChWd29yZF93cmFwX2NoYXJzKQkJCQkJXAorICAgPyAoKGl0LT53aGF0ID09 IElUX0NIQVJBQ1RFUiAmJiAoaXQtPmMgPT0gJyAnIHx8IGl0LT5jID09ICdcdCcpKQlcCisgICAg ICB8fCAoKFNUUklOR1AgKGl0LT5zdHJpbmcpCQkJCQkJXAorCSAgICYmIChTUkVGIChpdC0+c3Ry aW5nLCBJVF9TVFJJTkdfQllURVBPUyAoKml0KSkgPT0gJyAnCVwKKwkgICAgICAgfHwgU1JFRiAo aXQtPnN0cmluZywgSVRfU1RSSU5HX0JZVEVQT1MgKCppdCkpID09ICdcdCcpKQlcCisJICB8fCAo aXQtPnMJCQkJCQkJXAorCSAgICAgICYmIChpdC0+c1tJVF9CWVRFUE9TICgqaXQpXSA9PSAnICcJ CQlcCisJCSAgfHwgaXQtPnNbSVRfQllURVBPUyAoKml0KV0gPT0gJ1x0JykpCQkJXAorCSAgfHwg KElUX0JZVEVQT1MgKCppdCkgPCBaVl9CWVRFCQkJCVwKKwkgICAgICAmJiAoKkJZVEVfUE9TX0FE RFIgKElUX0JZVEVQT1MgKCppdCkpID09ICcgJwkJXAorCQkgIHx8ICpCWVRFX1BPU19BRERSIChJ VF9CWVRFUE9TICgqaXQpKSA9PSAnXHQnKSkpKQlcCisgICA6IGl0X2Rpc3BsYXlpbmdfd29yZF93 cmFwX2NoYXIoaXQpKQkJCQkJXAorCitzdGF0aWMgaW5saW5lIGJvb2wKK2NoYXJfaXNfd29yZF93 cmFwX2NoYXJfcCAoaW50IGMpIHsKKyAgcmV0dXJuICFOSUxQIChDSEFSX1RBQkxFX1JFRiAoVndv cmRfd3JhcF9jaGFycywgYykpOworfQorCitzdGF0aWMgaW5saW5lIGJvb2wKK2l0X2Rpc3BsYXlp bmdfd29yZF93cmFwX2NoYXIgKHN0cnVjdCBpdCAqaXQpIHsKKyAgICByZXR1cm4gKChpdC0+d2hh dCA9PSBJVF9DSEFSQUNURVIgJiYgY2hhcl9pc193b3JkX3dyYXBfY2hhcl9wIChpdC0+YykpCisJ ICAgIHx8IChTVFJJTkdQIChpdC0+c3RyaW5nKSAmJiBjaGFyX2lzX3dvcmRfd3JhcF9jaGFyX3AK KwkJKFNUUklOR19DSEFSCisJCSAoU0RBVEEgKGl0LT5zdHJpbmcpICsgSVRfU1RSSU5HX0JZVEVQ T1MgKCppdCkpKSkKKwkgICAgfHwgKGl0LT5zICYmIGNoYXJfaXNfd29yZF93cmFwX2NoYXJfcAor CQkoU1RSSU5HX0NIQVIoaXQtPnMgKyBJVF9CWVRFUE9TICgqaXQpKSkpCisJICAgIHx8IChJVF9C WVRFUE9TICgqaXQpIDwgWlZfQllURSAmJiBjaGFyX2lzX3dvcmRfd3JhcF9jaGFyX3AKKwkJKEZF VENIX0NIQVIgKElUX0JZVEVQT1MgKCppdCkpKSkpOworfQogCiAvKiBUcnVlIG1lYW5zIHByaW50 IG5ld2xpbmUgdG8gc3Rkb3V0IGJlZm9yZSBuZXh0IG1pbmktYnVmZmVyIG1lc3NhZ2UuICAqLwog CmRpZmYgLS1naXQgYS90ZXN0L21hbnVhbC93b3JkLXdyYXAtdGVzdC5lbCBiL3Rlc3QvbWFudWFs L3dvcmQtd3JhcC10ZXN0LmVsCm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLjJk ZjM4ODYKLS0tIC9kZXYvbnVsbAorKysgYi90ZXN0L21hbnVhbC93b3JkLXdyYXAtdGVzdC5lbApA QCAtMCwwICsxLDEyNyBAQAorOzs7IHdvcmQtd3JhcC10ZXN0LmVsIC0tIHRlc3RzIGZvciB3b3Jk LXdyYXAgLSotIGxleGljYWwtYmluZGluZzogdCAtKi0KKworOzsgQ29weXJpZ2h0IChDKSAyMDE3 IEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwgSW5jLgorCis7OyBUaGlzIGZpbGUgaXMgcGFydCBv ZiBHTlUgRW1hY3MuCisKKzs7IFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2Fu IHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5Cis7OyBpdCB1bmRlciB0aGUgdGVybXMgb2Yg dGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieQorOzsgdGhlIEZy ZWUgU29mdHdhcmUgRm91bmRhdGlvbiwgZWl0aGVyIHZlcnNpb24gMyBvZiB0aGUgTGljZW5zZSwg b3IKKzs7IChhdCB5b3VyIG9wdGlvbikgYW55IGxhdGVyIHZlcnNpb24uCisKKzs7IFRoaXMgcHJv Z3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLAor OzsgYnV0IFdJVEhPVVQgQU5ZIFdBUlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2Fy cmFudHkgb2YKKzs7IE1FUkNIQU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIg UFVSUE9TRS4gIFNlZSB0aGUKKzs7IEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3Jl IGRldGFpbHMuCisKKzs7IFlvdSBzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdO VSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCis7OyBhbG9uZyB3aXRoIHRoaXMgcHJvZ3JhbS4gIElm IG5vdCwgc2VlIDxodHRwczovL3d3dy5nbnUub3JnL2xpY2Vuc2VzLz4uCisKKzs7OyBDb21tZW50 YXJ5OgorCis7OyBSdW4gdGhlIHRlc3RzIE0teCB3b3JkLXdyYXAtdGVzdC1bMS00XSB3aGljaCBj b3JyZXNwb25kIHRvIHRoZSBmb3VyCis7OyBjb21iaW5hdGlvbnM6Cis7OworOzsgaSkgIHdoaXRl c3BhY2UtbW9kZSBiZWluZyBlbmFibGVkIGFuZCBkaXNhYmxlZCwKKzs7Cis7OyBpaSkgd29yZC13 cmFwLWNoYXJzIGJlaW5nIG5pbCBhbmQgZXF1YWwgdG8gYSBjaGFyLXRhYmxlIHRoYXQKKzs7IHNw ZWNpZmllcyBVLTIwMEIgYXMgdGhlIG9ubHkgd29yZC13cmFwIGNoYXJhY3Rlci4KKzs7Cis7OyBU aGUgdGVzdHMgd2l0aCB3aGl0ZXNwYWNlLW1vZGUgYXJlIG5lZWRlZCB0byBoZWxwIGF2b2lkIGEK Kzs7IHJlZ3Jlc3Npb24gb24gQnVnIzExMzQxLgorCis7OzsgQ29kZToKKworKHNldHEgd2hpdGVz cGFjZS1kaXNwbGF5LW1hcHBpbmdzLWZvci16ZXJvLXdpZHRoLXNwYWNlCisgICAgICAnKChzcGFj ZS1tYXJrIDMyCisgICAgICAgICAgICAgICAgICAgIFsxODNdCisgICAgICAgICAgICAgICAgICAg IFs0Nl0pCisgICAgICAgIChzcGFjZS1tYXJrIDE2MAorICAgICAgICAgICAgICAgICAgICBbMTY0 XQorICAgICAgICAgICAgICAgICAgICBbOTVdKQorICAgICAgICAoc3BhY2UtbWFyayA4MjAzCisg ICAgICAgICAgICAgICAgICAgIFsxNjRdCisgICAgICAgICAgICAgICAgICAgIFs5NV0pCisgICAg ICAgIChuZXdsaW5lLW1hcmsgMTAKKyAgICAgICAgICAgICAgICAgICAgICBbMzYgMTBdKQorICAg ICAgICAodGFiLW1hcmsgOQorICAgICAgICAgICAgICAgICAgWzE4NyA5XQorICAgICAgICAgICAg ICAgICAgWzkyIDldKSkpCisKKyhkZWZ1biB3b3JkLXdyYXAtdGVzdC0xICgpCisgICJDaGVjayB3 b3JkLXdyYXAgZm9yIG5pbCBgd29yZC13cmFwLWNoYXJzJy4iCisgIChpbnRlcmFjdGl2ZSkKKyAg KGxldCAoKGJ1ZiAoZ2V0LWJ1ZmZlci1jcmVhdGUgIipXb3JkLXdyYXAgVGVzdCAxKiIpKSkKKyAg ICAod2l0aC1jdXJyZW50LWJ1ZmZlciBidWYKKyAgICAgIChlcmFzZS1idWZmZXIpCisgICAgICAo aW5zZXJ0ICJXb3JkIHdyYXAgc2hvdWxkIG9jY3VyIGZvciBzcGFjZS5cblxuIikKKyAgICAgIChk b3RpbWVzIChpIDEwMCkKKyAgICAgICAgKGluc2VydCAiMTIzNDU2NyAiKSkgOyBTcGFjZQorICAg ICAgKGluc2VydCAiXG5cbldvcmQgd3JhcCBzaG91bGQgTk9UIG9jY3VyIGZvciBVLTIwMEIuXG5c biIpCisgICAgICAoZG90aW1lcyAoaSAxMDApCisgICAgICAgIChpbnNlcnQgIjEyMzQ1NjfigIsi KSkgOyBVLTIwMEIKKyAgICAgIChzZXRxIHdvcmQtd3JhcCB0KQorICAgICAgKHNldHEtbG9jYWwg d29yZC13cmFwLWNoYXJzIG5pbCkKKyAgICAgICh3aGl0ZXNwYWNlLW1vZGUgLTEpCisgICAgICAo ZGlzcGxheS1idWZmZXIgYnVmKSkpKQorCisoZGVmdW4gd29yZC13cmFwLXRlc3QtMiAoKQorICAi Q2hlY2sgd29yZC13cmFwIGZvciBuaWwgYHdvcmQtd3JhcC1jaGFycycgd2l0aCB3aGl0ZXNwYWNl LW1vZGUuIgorICAoaW50ZXJhY3RpdmUpCisgIChsZXQgKChidWYgKGdldC1idWZmZXItY3JlYXRl ICIqV29yZC13cmFwIFRlc3QgMioiKSkpCisgICAgKHdpdGgtY3VycmVudC1idWZmZXIgYnVmCisg ICAgICAoZXJhc2UtYnVmZmVyKQorICAgICAgKGluc2VydCAiV29yZCB3cmFwIHNob3VsZCBvY2N1 ciBmb3Igc3BhY2UgKGRpc3BsYXllZCBhcyBgwrcnKS5cblxuIikKKyAgICAgIChkb3RpbWVzIChp IDEwMCkKKyAgICAgICAgKGluc2VydCAiMTIzNDU2NyAiKSkgOyBTcGFjZQorICAgICAgKGluc2Vy dCAiXG5cbldvcmQgd3JhcCBzaG91bGQgTk9UIG9jY3VyIGZvciBVLTIwMEIgKGRpc3BsYXllZCBh cyBgwqQnKS5cblxuIikKKyAgICAgIChkb3RpbWVzIChpIDEwMCkKKyAgICAgICAgKGluc2VydCAi MTIzNDU2N+KAiyIpKSA7IFUtMjAwQgorICAgICAgKHNldHEgd29yZC13cmFwIHQpCisgICAgICAo c2V0cS1sb2NhbCB3b3JkLXdyYXAtY2hhcnMgbmlsKQorICAgICAgKHNldHEtbG9jYWwgd2hpdGVz cGFjZS1kaXNwbGF5LW1hcHBpbmdzCisgICAgICAgICAgICAgICAgICB3aGl0ZXNwYWNlLWRpc3Bs YXktbWFwcGluZ3MtZm9yLXplcm8td2lkdGgtc3BhY2UpCisgICAgICAod2hpdGVzcGFjZS1tb2Rl KQorICAgICAgKGRpc3BsYXktYnVmZmVyIGJ1ZikpKSkKKworKGRlZnVuIHdvcmQtd3JhcC10ZXN0 LTMgKCkKKyAgIkNoZWNrIHdvcmQtd3JhcCBpZiBgd29yZC13cmFwLWNoYXJzJyBpcyBhIGNoYXIt dGFibGUuIgorICAoaW50ZXJhY3RpdmUpCisgIChsZXQgKChidWYgKGdldC1idWZmZXItY3JlYXRl ICIqV29yZC13cmFwIFRlc3QgMyoiKSkpCisgICAgKHdpdGgtY3VycmVudC1idWZmZXIgYnVmCisg ICAgICAoZXJhc2UtYnVmZmVyKQorICAgICAgKGluc2VydCAiV29yZCB3cmFwIHNob3VsZCBOT1Qg b2NjdXIgZm9yIHNwYWNlLlxuXG4iKQorICAgICAgKGRvdGltZXMgKGkgMTAwKQorICAgICAgICAo aW5zZXJ0ICIxMjM0NTY3ICIpKSA7IFNwYWNlCisgICAgICAoaW5zZXJ0ICJcblxuV29yZCB3cmFw IHNob3VsZCBvY2N1ciBmb3IgVS0yMDBCLlxuXG4iKQorICAgICAgKGRvdGltZXMgKGkgMTAwKQor ICAgICAgICAoaW5zZXJ0ICIxMjM0NTY34oCLIikpIDsgVS0yMDBCCisgICAgICAoc2V0cSB3b3Jk LXdyYXAgdCkKKyAgICAgIChzZXRxLWxvY2FsIHdvcmQtd3JhcC1jaGFycworICAgICAgICAgICAg ICAgICAgKGxldCAoKGN0IChtYWtlLWNoYXItdGFibGUgbmlsIG5pbCkpKQorICAgICAgICAgICAg ICAgICAgICAoc2V0LWNoYXItdGFibGUtcmFuZ2UgY3QgODIwMyB0KQorICAgICAgICAgICAgICAg ICAgICBjdCkpCisgICAgICAod2hpdGVzcGFjZS1tb2RlIC0xKQorICAgICAgKGRpc3BsYXktYnVm ZmVyIGJ1ZikpKSkKKworKGRlZnVuIHdvcmQtd3JhcC10ZXN0LTQgKCkKKyAgIkNoZWNrIHdvcmQt d3JhcCBpZiBgd29yZC13cmFwLWNoYXJzJyBpcyBhIGNoYXItdGFibGUsIGZvciB3aGl0ZXNwYWNl LW1vZGUuIgorICAoaW50ZXJhY3RpdmUpCisgIChsZXQgKChidWYgKGdldC1idWZmZXItY3JlYXRl ICIqV29yZC13cmFwIFRlc3QgNCoiKSkpCisgICAgKHdpdGgtY3VycmVudC1idWZmZXIgYnVmCisg ICAgICAoZXJhc2UtYnVmZmVyKQorICAgICAgKGluc2VydCAiV29yZCB3cmFwIHNob3VsZCBOT1Qg b2NjdXIgZm9yIHNwYWNlIChkaXNwbGF5ZWQgYXMgYMK3JykuXG5cbiIpCisgICAgICAoZG90aW1l cyAoaSAxMDApCisgICAgICAgIChpbnNlcnQgIjEyMzQ1NjcgIikpIDsgU3BhY2UKKyAgICAgIChp bnNlcnQgIlxuXG5Xb3JkIHdyYXAgc2hvdWxkIG9jY3VyIGZvciBVLTIwMEIgKGRpc3BsYXllZCBh cyBgwqQnKS5cblxuIikKKyAgICAgIChkb3RpbWVzIChpIDEwMCkKKyAgICAgICAgKGluc2VydCAi MTIzNDU2N+KAiyIpKSA7IFUtMjAwQgorICAgICAgKHNldHEgd29yZC13cmFwIHQpCisgICAgICAo c2V0cS1sb2NhbCB3b3JkLXdyYXAtY2hhcnMKKyAgICAgICAgICAgICAgICAgIChsZXQgKChjdCAo bWFrZS1jaGFyLXRhYmxlIG5pbCBuaWwpKSkKKyAgICAgICAgICAgICAgICAgICAgKHNldC1jaGFy LXRhYmxlLXJhbmdlIGN0IDgyMDMgdCkKKyAgICAgICAgICAgICAgICAgICAgY3QpKQorICAgICAg KHNldHEtbG9jYWwgd2hpdGVzcGFjZS1kaXNwbGF5LW1hcHBpbmdzCisgICAgICAgICAgICAgICAg ICB3aGl0ZXNwYWNlLWRpc3BsYXktbWFwcGluZ3MtZm9yLXplcm8td2lkdGgtc3BhY2UpCisgICAg ICAod2hpdGVzcGFjZS1tb2RlKQorICAgICAgKGRpc3BsYXktYnVmZmVyIGJ1ZikpKSkKCg== --001a114915c8cd6a5605607fe6e9 Content-Type: text/plain; charset="US-ASCII"; name="lisp_interface.diff" Content-Disposition: attachment; filename="lisp_interface.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_jba58bis1 ZGlmZiAtLWdpdCBhL2RvYy9lbWFjcy9kaXNwbGF5LnRleGkgYi9kb2MvZW1hY3MvZGlzcGxheS50 ZXhpCmluZGV4IGU3YmQwNmUuLmY3ZTBlYmMgMTAwNjQ0Ci0tLSBhL2RvYy9lbWFjcy9kaXNwbGF5 LnRleGkKKysrIGIvZG9jL2VtYWNzL2Rpc3BsYXkudGV4aQpAQCAtMTcyMCwxMCArMTcyMCwxMiBA QCB3b3VsZCBiZSB2aXN1YWxseSBkaXN0cmFjdGluZy4gIFlvdSBjYW4gY2hhbmdlIHRoaXMgYnkg Y3VzdG9taXppbmcgdGhlCiB2YXJpYWJsZSBAY29kZXt2aXN1YWwtbGluZS1mcmluZ2UtaW5kaWNh dG9yc30uCiAKIEB2aW5kZXggd29yZC13cmFwLWNoYXJzCitAZmluZGV4IHdvcmQtd3JhcC1jaGFy cy1tb2RlCiAgIFdvcmQgYm91bmRhcmllcyBhbmQgaGVuY2UgcG9pbnRzIGF0IHdoaWNoIHdvcmQg d3JhcCBjYW4gb2NjdXIgYXJlLAogYnkgZGVmYXVsdCwgY29uc2lkZXJlZCB0byBvY2N1ciBvbiB0 aGUgc3BhY2UgYW5kIHRhYiBjaGFyYWN0ZXJzLiAgSWYKIHlvdSBwcmVmZXIgd29yZC13cmFwIHRv IGJlIHBlcm1pc3NpYmxlIGF0IG90aGVyIGNoYXJhY3RlcnMsIHlvdSBjYW4KLWNoYW5nZSB0aGUg dmFsdWUgb2YgdGhlIGNoYXItdGFibGUgQGNvZGV7d29yZC13cmFwLWNoYXJzfS4KK2NoYW5nZSB0 aGUgdmFsdWUgb2YgdGhlIGNoYXItdGFibGUgQGNvZGV7d29yZC13cmFwLWNoYXJzfSwgb3IgdXNl CitAY29kZXt3b3JkLXdyYXAtY2hhcnMtbW9kZX0sIHdoaWNoIGRvZXMgdGhpcyBmb3IgeW91Lgog CiBAbm9kZSBEaXNwbGF5IEN1c3RvbQogQHNlY3Rpb24gQ3VzdG9taXphdGlvbiBvZiBEaXNwbGF5 CmRpZmYgLS1naXQgYS9ldGMvTkVXUyBiL2V0Yy9ORVdTCmluZGV4IGE4N2VhYmMuLjkxODM4MGIg MTAwNjQ0Ci0tLSBhL2V0Yy9ORVdTCisrKyBiL2V0Yy9ORVdTCkBAIC02Niw2ICs2NiwxMyBAQCB1 c2luZyB0aGUgbmV3IGB3b3JkLXdyYXAtY2hhcnMnIGNoYXItdGFibGUuICBJZiBgd29yZC13cmFw LWNoYXJzJyBpcwogbmlsICh0aGUgZGVmYXVsdCksIHRoZW4gd29yZC13cmFwcGluZyB3aWxsIG9j Y3VyIG9ubHkgb24gdGhlIHNwYWNlIG9yCiB0YWIgY2hhcmFjdGVycywgYXMgaGFzIGJlZW4gdGhl IGNhc2UgdW50aWwgbm93LgogCitUaGUgbW9zdCBjb252ZW5pZW50IHdheSB0byBjaGFuZ2UgdGhl IGNoYXJhY3RlcnMgYXQgd2hpY2ggd3JhcCBvY2N1cnMKK2lzIGN1c3RvbWl6aW5nIHRoZSBuZXcg dmFyaWFibGUgYHdvcmQtd3JhcC10eXBlJyBhbmQgdXNpbmcgdGhlIG5ldworYHdvcmQtd3JhcC1j aGFycy1tb2RlJyBtaW5vciBtb2RlLCB3aGljaCBzZXRzIGB3b3JkLXdyYXAtY2hhcnMnIGJhc2Vk CitvbiBgd29yZC13cmFwLXR5cGUnLCBmb3IgeW91LiAgVGhlIG9wdGlvbnMgZm9yIGB3b3JkLXdy YXAtdHlwZScgYXJlCithc2NpaS13aGl0ZXNwYWNlLCB1bmljb2RlLXdoaXRlc3BhY2UgYW5kIGEg Y3VzdG9taXphYmxlIGxpc3Qgb2YKK2NoYXJhY3RlciBjb2RlcyBhbmQgY2hhcmFjdGVyIGNvZGUg cmFuZ2VzLgorCiAMCiAqIENoYW5nZXMgaW4gU3BlY2lhbGl6ZWQgTW9kZXMgYW5kIFBhY2thZ2Vz IGluIEVtYWNzIDI3LjEKIApkaWZmIC0tZ2l0IGEvbGlzcC9zaW1wbGUuZWwgYi9saXNwL3NpbXBs ZS5lbAppbmRleCAyNGVjZjY5Li5lOTdlZTEwIDEwMDY0NAotLS0gYS9saXNwL3NpbXBsZS5lbAor KysgYi9saXNwL3NpbXBsZS5lbApAQCAtNjg3OSw2ICs2ODc5LDExNyBAQCBNb2RlJyBmb3IgZGV0 YWlscy4iCiAgIHZpc3VhbC1saW5lLW1vZGUgdHVybi1vbi12aXN1YWwtbGluZS1tb2RlKQogCiAM CisoZGVmdmFyIHdvcmQtd3JhcC10eXBlKQorCisoZGVmdmFyIHdvcmQtd3JhcC1jaGFycy0tc2F2 ZWQgbmlsKQorCisoZGVmaW5lLW1pbm9yLW1vZGUgd29yZC13cmFwLWNoYXJzLW1vZGUKKyAgIlRv Z2dsZSB3cmFwcGluZyB1c2luZyBhIGxvb2stdXAgdG8gYHdvcmQtd3JhcC1jaGFycycuCitUaGUg ZXhhY3QgY2hvaWNlIG9mIGNoYXJhY3RlcnMgb24gd2hpY2ggd3JhcHBpbmcgb2NjdXJzLCBkZXBl bmRzCitvbiB0aGUgdmFsdWUgb2YgYHdvcmQtd3JhcC10eXBlJy4gIEJ5IGRlZmF1bHQsIGB3b3Jk LXdyYXAtdHlwZScKK2lzIHNldCB0byB1bmljb2RlLXdoaXRlLXNwYWNlLCB3aGljaCBhbGxvd3Mg d29yZCB3cmFwcGluZyBvbiBhbGwKK2JyZWFrYWJsZSB1bmljb2RlIHdoaXRlc3BhY2UsIG5vdCBv bmx5IHNwYWNlIGFuZCB0YXAuCisKK0ZvciBkZXRhaWxzIG9mIG90aGVyIGN1c3RvbWl6YXRpb24g b3B0aW9ucywgc2VlCitgd29yZC13cmFwLXR5cGUnLgorCitUaGlzIG1pbm9yIG1vZGUgaGFzIG5v IGVmZmVjdCB1bmxlc3MgYHZpc3VhbC1saW5lLW1vZGUnIGlzCitlbmFibGVkIG9yIGB3b3JkLXdy YXAnIGlzIHNldCB0byB0LgorCitUbyB0b2dnbGUgd3JhcHBpbmcgdXNpbmcgYSBsb29rLXVwLCBn bG9iYWxseSwgdXNlCitgZ2xvYmFsLXdvcmQtd3JhcC1jaGFycy1tb2RlJy4iCisgIDpncm91cCAn dmlzdWFsLWxpbmUKKyAgOmxpZ2h0ZXIgIiB3d2MiCisgIChpZiB3b3JkLXdyYXAtY2hhcnMtbW9k ZQorICAgICAgKHByb2duCisgICAgICAgIChpZiAobG9jYWwtdmFyaWFibGUtcCAnd29yZC13cmFw LWNoYXJzKQorICAgICAgICAgICAgKHNldHEtbG9jYWwgd29yZC13cmFwLWNoYXJzLS1zYXZlZAor ICAgICAgICAgICAgICAgICAgICAgICAgd29yZC13cmFwLWNoYXJzKSkKKyAgICAgICAgKHNldC13 b3JkLXdyYXAtY2hhcnMpKQorICAgIChzZXRxLWxvY2FsIHdvcmQtd3JhcC1jaGFycyB3b3JkLXdy YXAtY2hhcnMtLXNhdmVkKSkpCisKKyhkZWZ1biB0dXJuLW9uLXdvcmQtd3JhcC1jaGFycy1tb2Rl ICgpCisgICh2aXN1YWwtbGluZS1tb2RlIDEpKQorCisoZGVmaW5lLWdsb2JhbGl6ZWQtbWlub3It bW9kZSBnbG9iYWwtd29yZC13cmFwLWNoYXJzLW1vZGUKKyAgd29yZC13cmFwLWNoYXJzLW1vZGUg dHVybi1vbi13b3JkLXdyYXAtY2hhcnMtbW9kZSkKKworKGRlZnVuIHVwZGF0ZS13b3JkLXdyYXAt Y2hhcnMgKCkKKyAgIlVwZGF0ZSBgd29yZC13cmFwLWNoYXJzJyB1cG9uIEN1c3RvbWl6ZSBvZiBg d29yZC13cmFwLXR5cGUnLgorCitPbmx5IGJ1ZmZlcnMgd2hpY2ggdXNlIHRoZSBgd29yZC13cmFw LWNoYXJzLW1vZGUnIGFyZSBhZmZlY3RlZC4iCisgIChtYXBjYXIgIycobGFtYmRhIChidWYpCisJ ICAgICAgKHdpdGgtY3VycmVudC1idWZmZXIgYnVmCisJICAgICAgICAoaWYgd29yZC13cmFwLWNo YXJzLW1vZGUKKyAgICAgICAgICAgICAgICAgICAgKHNldC13b3JkLXdyYXAtY2hhcnMpKSkpCisJ ICAoYnVmZmVyLWxpc3QpKSkKKworKGRlZnVuIHNldC13b3JkLXdyYXAtY2hhcnMgKCkKKyAgIlNl dCBgd29yZC13cmFwLWNoYXJzJyBsb2NhbGx5LCBiYXNlZCBvbiBgd29yZC13cmFwLXR5cGUnLiIK KyAgKGNvbmQKKyAgICgoZXEgd29yZC13cmFwLXR5cGUgJ2FzY2lpLXdoaXRlc3BhY2UpCisgICAg KHNldHEtbG9jYWwgd29yZC13cmFwLWNoYXJzIG5pbCkpCisgICAoKGVxIHdvcmQtd3JhcC10eXBl ICd1bmljb2RlLXdoaXRlc3BhY2UpCisgICAgKHNldC13b3JkLXdyYXAtY2hhcnMtZnJvbS1saXN0 CisgICAgICcoOSAzMiA1NzYwICg4MTkyIC4gODE5OCkgKDgyMDAgLiA4MjAzKSA4Mjg3IDEyMjg4 KSkpCisgICAoKGxpc3RwIHdvcmQtd3JhcC10eXBlKQorICAgIChzZXQtd29yZC13cmFwLWNoYXJz LWZyb20tbGlzdCB3b3JkLXdyYXAtdHlwZSkpKSkKKworKGRlZnVuIHNldC13b3JkLXdyYXAtY2hh cnMtZnJvbS1saXN0IChsaXN0KQorICAiU2V0IGB3b3JkLXdyYXAtY2hhcnMnIGxvY2FsbHkgZnJv bSBhIGxpc3QuCitFYWNoIGVsZW1lbnQgb2YgdGhlIGxpc3QgY2FuIGJlIGEgY2hhcmFjdGVyIGNv ZGUgKGNvZGUgcG9pbnQpIG9yCithIGNvbnMgb2YgY2hhcmFjdGVyIGNvZGVzLCByZXByZXNlbnRp bmcgdGhlIHR3byAoaW5jbHVzaXZlKQorZW5kcG9pbnRzIG9mIHRoZSByYW5nZSBvZiBjaGFyYWN0 ZXJzLiIKKyAgKHNldHEtbG9jYWwKKyAgIHdvcmQtd3JhcC1jaGFycworICAgKGxldCAoKGNoYXIt dGFibGUgKG1ha2UtY2hhci10YWJsZSBuaWwgbmlsKSkpCisgICAgIChkb2xpc3QgKHJhbmdlIGxp c3QgY2hhci10YWJsZSkKKyAgICAgICAoc2V0LWNoYXItdGFibGUtcmFuZ2UgY2hhci10YWJsZSBy YW5nZSB0KSkpKSkKKworKGRlZmN1c3RvbSB3b3JkLXdyYXAtdHlwZQorICAndW5pY29kZS13aGl0 ZXNwYWNlCisgICJDaGFyYWN0ZXJzIG9uIHdoaWNoIHdvcmQtd3JhcCBvY2N1cnMuCitUaGlzIHZh cmlhYmxlIGNvbnRyb2xzIHRoZSB2YWx1ZSBvZiBgd29yZC13cmFwLWNoYXJzJyB0aGF0IGlzIHNl dAorYnkgYHdvcmQtd3JhcC1jaGFycy1tb2RlYC4gIGB3b3JkLXdyYXAtY2hhcnMnIGRldGVybWlu ZXMgb24gd2hhdAorY2hhcmFjdGVycyB3b3JkLXdyYXBwaW5nIGNhbiBvY2N1ciwgd2hlbiBgd29y ZC13cmFwJyBpcyB0IG9yCitgdmlzdWFsLWxpbmUtbW9kZScgaXMgZW5hYmxlZC4KKworUG9zc2li bGUgdmFsdWVzIGFyZSBhc2NpaS13aGl0ZXNwYWNlLCB1bmljb2RlLXdoaXRlc3BhY2Ugb3IgYQor Y3VzdG9tIGxpc3Qgb2YgY2hhcmFjdGVycyBhbmQgY2hhcmFjdGVyIHJhbmdlcy4KKworSWYgdGhl IHZhbHVlIGlzIGBhc2NpaS13aGl0ZXNwYWNlJywgd29yZC13cmFwIGlzIG9ubHkgb24gc3BhY2UK K2FuZCB0YWIuICBJZiB0aGUgdmFsdWUgaXMgYHVuaWNvZGUtd2hpdGVzcGFjZScsIHdvcmQtd3Jh cCBpcyBvbgorYWxsIHRoZSBVbmljb2RlIHdoaXRlc3BhY2UgY2hhcmFjdGVycyB0aGF0IHBlcm1p dCB3cmFwcGluZywKK2luY2x1ZGluZyBidXQgbm90IGxpbWl0ZWQgdG8gc3BhY2UgYW5kIHRhYi4K KworSWYgYSBjdXN0b20gbGlzdCBvZiBjaGFyYWN0ZXJzIGFuZCByYW5nZXMgaXMgdXNlZCwgd29y ZCB3cmFwIGlzCitvbiB0aGVzZSBjaGFyYWN0ZXJzIGFuZCBjaGFyYWN0ZXIgcmFuZ2VzLiAgVGhl IHJhbmdlcyBhcmUKK2luY2x1c2l2ZSBvZiBib3RoIGVuZHBvaW50cy4KKworV2hlbiB5b3UgY2hh bmdlIHRoaXMgd2l0aG91dCB1c2luZyBjdXN0b21pemUsIHlvdSBuZWVkIHRvIGNhbGwKK2B1cGRh dGUtd29yZC13cmFwLWNoYXJzJyB0byB1cGRhdGUgdGhlIHdvcmQgd3JhcCBpbiBjdXJyZW50Citi dWZmZXJzLiAgRm9yIGluc3RhbmNlOgorCisoc2V0cSB3b3JkLXdyYXAtdHlwZSBcXD0nKDkgMzIg P18pKQorKHVwZGF0ZS13b3JkLXdyYXAtY2hhcnMpCisKK3dpbGwgc2V0IHRoZSB3cmFwcGFibGUg Y2hhcmFjdGVycyB0byBzcGFjZSwgdGFiIGFuZCB1bmRlcnNjb3JlLAoraW4gYWxsIGJ1ZmZlcnMg aW4gYHdvcmQtd3JhcC1jaGFycy1tb2RlJyBhbmQgdXNpbmcgdGhlIGRlZmF1bHQKK3ZhbHVlIG9m IGB3b3JkLXdyYXAtdHlwZScuCisiCisgIDp0eXBlICcoY2hvaWNlIChjb25zdCA6dGFnICJTcGFj ZSBhbmQgdGFiIiBhc2NpaS13aGl0ZXNwYWNlKQorCQkgKGNvbnN0IDp0YWcgIkFsbCB1bmljb2Rl IHNwYWNlcyIgdW5pY29kZS13aGl0ZXNwYWNlKQorCQkgKHJlcGVhdCA6dGFnICJDdXN0b20gY2hh cmFjdGVycyBvciByYW5nZXMiCisJCQkgOnZhbHVlICg5IDMyKQorCQkJIChjaG9pY2UgKGNoYXJh Y3RlcikKKwkJCQkgKGNvbnMgOnRhZyAiUmFuZ2UiIGNoYXJhY3RlciBjaGFyYWN0ZXIpKSkpCisg IDpzZXQgKGxhbWJkYSAoc3ltYm9sIHZhbHVlKQorCSAoc2V0LWRlZmF1bHQgc3ltYm9sIHZhbHVl KQorCSAodXBkYXRlLXdvcmQtd3JhcC1jaGFycykpCisgIDpncm91cCAndmlzdWFsLWxpbmUKKyAg OnZlcnNpb24gMjcuMSkKKworDAogKGRlZnVuIHRyYW5zcG9zZS1jaGFycyAoYXJnKQogICAiSW50 ZXJjaGFuZ2UgY2hhcmFjdGVycyBhcm91bmQgcG9pbnQsIG1vdmluZyBmb3J3YXJkIG9uZSBjaGFy YWN0ZXIuCiBXaXRoIHByZWZpeCBhcmcgQVJHLCBlZmZlY3QgaXMgdG8gdGFrZSBjaGFyYWN0ZXIg YmVmb3JlIHBvaW50CmRpZmYgLS1naXQgYS9zcmMvYnVmZmVyLmMgYi9zcmMvYnVmZmVyLmMKaW5k ZXggM2UyNjBiYi4uNjYyZmM3MiAxMDA2NDQKLS0tIGEvc3JjL2J1ZmZlci5jCisrKyBiL3NyYy9i dWZmZXIuYwpAQCAtNTczNCw3ICs1NzM0LDggQEAgdmlzdWFsIGxpbmVzIHJhdGhlciB0aGFuIGxv Z2ljYWwgbGluZXMuICBTZWUgdGhlIGRvY3VtZW50YXRpb24gb2YKIAogSWYgYHdvcmQtd3JhcC1j aGFycycgaXMgbm9uLW5pbCBhbmQgYSBjaGFyLXRhYmxlLCBjb250aW51YXRpb24gbGluZXMKIGFy ZSB3cmFwcGVkIG9uIHRoZSBjaGFyYWN0ZXJzIGluIGB3b3JkLXdyYXAtY2hhcnMnIHdob3NlIHZh bHVlIGlzIHQsCi1yYXRoZXIgdGhhbiB0aGUgc3BhY2UgYW5kIHRhYiBjaGFyYWN0ZXJzLiAgKi8p OworcmF0aGVyIHRoYW4gdGhlIHNwYWNlIGFuZCB0YWIgY2hhcmFjdGVycy4gIGB3b3JkLXdyYXAt Y2hhcnMtbW9kZQorcHJvdmlkZXMgYSBjb252ZW5pZW50IGludGVyZmFjZSBmb3IgdXNpbmcgdGhp cy4gICovKTsKIAogICBERUZWQVJfUEVSX0JVRkZFUiAoImRlZmF1bHQtZGlyZWN0b3J5IiwgJkJW QVIgKGN1cnJlbnRfYnVmZmVyLCBkaXJlY3RvcnkpLAogCQkgICAgIFFzdHJpbmdwLApkaWZmIC0t Z2l0IGEvc3JjL2NoYXJhY3Rlci5jIGIvc3JjL2NoYXJhY3Rlci5jCmluZGV4IGZkMWE5ZDMuLmZm M2I2ZDMgMTAwNjQ0Ci0tLSBhL3NyYy9jaGFyYWN0ZXIuYworKysgYi9zcmMvY2hhcmFjdGVyLmMK QEAgLTExNDksNiArMTE0OSwxMCBAQCBTZWUgVGhlIFVuaWNvZGUgU3RhbmRhcmQgZm9yIHRoZSBt ZWFuaW5nIG9mIHRob3NlIHZhbHVlcy4gICovKTsKICAgREVGVkFSX0xJU1AgKCJ3b3JkLXdyYXAt Y2hhcnMiLCBWd29yZF93cmFwX2NoYXJzLAogCSAgICAgICBkb2M6IC8qIEEgY2hhci10YWJsZSBm b3IgY2hhcmFjdGVycyBhdCB3aGljaCB3b3JkLXdyYXAgb2NjdXJzLgogU3VjaCBjaGFyYWN0ZXJz IGhhdmUgdmFsdWUgdCBpbiB0aGlzIHRhYmxlLiAgSWYgdGhlIGNoYXItdGFibGUgaXMgbmlsLAot d29yZC13cmFwIG9jY3VycyBvbmx5IG9uIHNwYWNlIGFuZCB0YWIuICAqLyk7Cit3b3JkLXdyYXAg b2NjdXJzIG9ubHkgb24gc3BhY2UgYW5kIHRhYi4KKworRm9yIGEgbW9yZSB1c2VyLWZyaWVuZGx5 IHdheSBvZiBjaGFuZ2luZyB0aGUgY2hhcmFjdGVycyBhdCB3aGljaAord29yZC13cmFwIGNhbiBv Y2N1ciwgY29uc2lkZXIgdXNpbmcgYHdvcmQtd3JhcC1jaGFycy1tb2RlJyBhbmQKK2N1c3RvbWl6 aW5nIGB3b3JkLXdyYXAtdHlwZScuICovKTsKICAgVndvcmRfd3JhcF9jaGFycyA9IFFuaWw7CiB9 Cg== --001a114915c8cd6a5605607fe6e9-- From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 18 10:56:07 2020 Received: (at 13399) by debbugs.gnu.org; 18 Sep 2020 14:56:07 +0000 Received: from localhost ([127.0.0.1]:44062 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJHny-0008Gz-Cn for submit@debbugs.gnu.org; Fri, 18 Sep 2020 10:56:07 -0400 Received: from quimby.gnus.org ([95.216.78.240]:55466) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJHnm-0008Fx-A2 for 13399@debbugs.gnu.org; Fri, 18 Sep 2020 10:55:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=8A+m737R5WSzpNjSPtKjCyjnLfwIkibcABZyOmNUqFk=; b=WbLNzpmfrrJfA4r8t6cCO+KCCO 3yvY+lFYK8Iv64XB+RvXD704FjsyQ/i9aB4EWMNKXRQTf39rf11jowUrnt7a31KUdp5q2xzf/q8CG 6pphhyQsr61+PDmOboYzsQAg40islLWdd6hD1nDfFqA7THmiDMvOY0pkXPuEhBirb9h8=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kJHna-00071A-BM; Fri, 18 Sep 2020 16:55:47 +0200 From: Lars Ingebrigtsen To: Adam Tack Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B References: <50EE7BE5.2060806@gmx.at> <83609hw7pm.fsf@gnu.org> <83r2s5ugnd.fsf@gnu.org> <838te7swci.fsf@gnu.org> <83lgi6vccy.fsf@gnu.org> X-Now-Playing: Saito Koji's _433-1_: "433_080" Date: Fri, 18 Sep 2020 16:55:40 +0200 In-Reply-To: (Adam Tack's message of "Sun, 17 Dec 2017 02:22:12 +0000") Message-ID: <877dsrf82b.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Adam Tack writes: > I've split out the non-nil char-table case out into a function, as I > think that using a named function slightly improves readability, and > having a macro over 20 lines long, somehow feels "wrong" [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 13399 Cc: Eli Zaretskii , 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Adam Tack writes: > I've split out the non-nil char-table case out into a function, as I > think that using a named function slightly improves readability, and > having a macro over 20 lines long, somehow feels "wrong". If the > compiler does actually follow the inline directive, there should be no > additional performance hit. This was the last post in the thread, and the patch no longer applied, so I've respun it for Emacs 28. However, I can't find any copyright assignment on file -- Adam, did you go through with the assignment process? diff --git a/doc/emacs/display.texi b/doc/emacs/display.texi index e7b8745a04..9fcca8c6e6 100644 --- a/doc/emacs/display.texi +++ b/doc/emacs/display.texi @@ -1831,6 +1831,14 @@ Visual Line Mode report. You can add categories to a character using the command @code{modify-category-entry}. =20 +@vindex word-wrap-chars +@findex word-wrap-chars-mode + Word boundaries and hence points at which word wrap can occur are, +by default, considered to occur on the space and tab characters. If +you prefer word-wrap to be permissible at other characters, you can +change the value of the char-table @code{word-wrap-chars}, or use +@code{word-wrap-chars-mode}, which does this for you. + @node Display Custom @section Customization of Display =20 diff --git a/etc/NEWS b/etc/NEWS index 54bad068f8..f3216ed445 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -73,6 +73,19 @@ its implementation has been removed from the Linux kerne= l. OpenBSD 5.3 and older releases are no longer supported, as they lack proper pty support that Emacs needs. =20 ++++ +** The characters at which word-wrapping occurs can now be controlled +using the new `word-wrap-chars' char-table. If `word-wrap-chars' is +nil (the default), then word-wrapping will occur only on the space or +tab characters, as has been the case until now. + +The most convenient way to change the characters at which wrap occurs +is customizing the new variable `word-wrap-type' and using the new +`word-wrap-chars-mode' minor mode, which sets `word-wrap-chars' based +on `word-wrap-type', for you. The options for `word-wrap-type' are +ascii-whitespace, unicode-whitespace and a customizable list of +character codes and character code ranges. + * Startup Changes in Emacs 28.1 =20 diff --git a/lisp/simple.el b/lisp/simple.el index 7dc695848b..b881cbc23e 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -7269,6 +7269,117 @@ turn-on-visual-line-mode (define-globalized-minor-mode global-visual-line-mode visual-line-mode turn-on-visual-line-mode) =20 + +(defvar word-wrap-type) + +(defvar word-wrap-chars--saved nil) + +(define-minor-mode word-wrap-chars-mode + "Toggle wrapping using a look-up to `word-wrap-chars'. +The exact choice of characters on which wrapping occurs, depends +on the value of `word-wrap-type'. By default, `word-wrap-type' +is set to unicode-white-space, which allows word wrapping on all +breakable unicode whitespace, not only space and tap. + +For details of other customization options, see +`word-wrap-type'. + +This minor mode has no effect unless `visual-line-mode' is +enabled or `word-wrap' is set to t. + +To toggle wrapping using a look-up, globally, use +`global-word-wrap-chars-mode'." + :group 'visual-line + :lighter " wwc" + (if word-wrap-chars-mode + (progn + (if (local-variable-p 'word-wrap-chars) + (setq-local word-wrap-chars--saved + word-wrap-chars)) + (set-word-wrap-chars)) + (setq-local word-wrap-chars word-wrap-chars--saved))) + +(defun turn-on-word-wrap-chars-mode () + (visual-line-mode 1)) + +(define-globalized-minor-mode global-word-wrap-chars-mode + word-wrap-chars-mode turn-on-word-wrap-chars-mode) + +(defun update-word-wrap-chars () + "Update `word-wrap-chars' upon Customize of `word-wrap-type'. + +Only buffers which use the `word-wrap-chars-mode' are affected." + (mapcar #'(lambda (buf) + (with-current-buffer buf + (if word-wrap-chars-mode + (set-word-wrap-chars)))) + (buffer-list))) + +(defun set-word-wrap-chars () + "Set `word-wrap-chars' locally, based on `word-wrap-type'." + (cond + ((eq word-wrap-type 'ascii-whitespace) + (setq-local word-wrap-chars nil)) + ((eq word-wrap-type 'unicode-whitespace) + (set-word-wrap-chars-from-list + '(9 32 5760 (8192 . 8198) (8200 . 8203) 8287 12288))) + ((listp word-wrap-type) + (set-word-wrap-chars-from-list word-wrap-type)))) + +(defun set-word-wrap-chars-from-list (list) + "Set `word-wrap-chars' locally from a list. +Each element of the list can be a character code (code point) or +a cons of character codes, representing the two (inclusive) +endpoints of the range of characters." + (setq-local + word-wrap-chars + (let ((char-table (make-char-table nil nil))) + (dolist (range list char-table) + (set-char-table-range char-table range t))))) + +(defcustom word-wrap-type + 'unicode-whitespace + "Characters on which word-wrap occurs. +This variable controls the value of `word-wrap-chars' that is set +by `word-wrap-chars-mode`. `word-wrap-chars' determines on what +characters word-wrapping can occur, when `word-wrap' is t or +`visual-line-mode' is enabled. + +Possible values are ascii-whitespace, unicode-whitespace or a +custom list of characters and character ranges. + +If the value is `ascii-whitespace', word-wrap is only on space +and tab. If the value is `unicode-whitespace', word-wrap is on +all the Unicode whitespace characters that permit wrapping, +including but not limited to space and tab. + +If a custom list of characters and ranges is used, word wrap is +on these characters and character ranges. The ranges are +inclusive of both endpoints. + +When you change this without using customize, you need to call +`update-word-wrap-chars' to update the word wrap in current +buffers. For instance: + +(setq word-wrap-type \\=3D'(9 32 ?_)) +(update-word-wrap-chars) + +will set the wrappable characters to space, tab and underscore, +in all buffers in `word-wrap-chars-mode' and using the default +value of `word-wrap-type'. +" + :type '(choice (const :tag "Space and tab" ascii-whitespace) + (const :tag "All unicode spaces" unicode-whitespace) + (repeat :tag "Custom characters or ranges" + :value (9 32) + (choice (character) + (cons :tag "Range" character character)))) + :set (lambda (symbol value) + (set-default symbol value) + (update-word-wrap-chars)) + :group 'visual-line + :version 27.1) + (defun transpose-chars (arg) "Interchange characters around point, moving forward one character. diff --git a/src/buffer.c b/src/buffer.c index 241f2d43a9..5c26323d69 100644 --- a/src/buffer.c +++ b/src/buffer.c @@ -5786,7 +5786,12 @@ syms_of_buffer (void) Visual Line mode. Visual Line mode, when enabled, sets `word-wrap' to t, and additionally redefines simple editing commands to act on visual lines rather than logical lines. See the documentation of -`visual-line-mode'. */); +`visual-line-mode'. + +If `word-wrap-chars' is non-nil and a char-table, continuation lines +are wrapped on the characters in `word-wrap-chars' whose value is t, +rather than the space and tab characters. `word-wrap-chars-mode +provides a convenient interface for using this. */); =20 DEFVAR_PER_BUFFER ("default-directory", &BVAR (current_buffer, directory= ), Qstringp, diff --git a/src/character.c b/src/character.c index 5860f6a0c8..032f4fc12b 100644 --- a/src/character.c +++ b/src/character.c @@ -1084,4 +1084,14 @@ syms_of_character (void) See The Unicode Standard for the meaning of those values. */); /* The correct char-table is setup in characters.el. */ Vunicode_category_table =3D Qnil; + + DEFVAR_LISP ("word-wrap-chars", Vword_wrap_chars, + doc: /* A char-table for characters at which word-wrap occurs. +Such characters have value t in this table. If the char-table is nil, +word-wrap occurs only on space and tab. + +For a more user-friendly way of changing the characters at which +word-wrap can occur, consider using `word-wrap-chars-mode' and +customizing `word-wrap-type'. */); + Vword_wrap_chars =3D Qnil; } diff --git a/src/xdisp.c b/src/xdisp.c index 615f0ca7cf..744b9a52c7 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -494,20 +494,42 @@ #define IT_OVERFLOW_NEWLINE_INTO_FRINGE(it) false #endif /* HAVE_WINDOW_SYSTEM */ =20 /* Test if the display element loaded in IT, or the underlying buffer - or string character, is a space or a TAB character. This is used - to determine where word wrapping can occur. */ + or string character, is a space or tab (by default, to avoid the + unnecessary performance hit of char-table lookup). If + word-wrap-chars is a char-table, then instead check if the relevant + element or character belongs to the char-table. This is used to + determine where word wrapping can occur. */ =20 #define IT_DISPLAYING_WHITESPACE(it) \ - ((it->what =3D=3D IT_CHARACTER && (it->c =3D=3D ' ' || it->c =3D=3D '\t'= )) \ - || ((STRINGP (it->string) \ - && (SREF (it->string, IT_STRING_BYTEPOS (*it)) =3D=3D ' ' \ - || SREF (it->string, IT_STRING_BYTEPOS (*it)) =3D=3D '\t')) \ - || (it->s \ - && (it->s[IT_BYTEPOS (*it)] =3D=3D ' ' \ - || it->s[IT_BYTEPOS (*it)] =3D=3D '\t')) \ - || (IT_BYTEPOS (*it) < ZV_BYTE \ - && (*BYTE_POS_ADDR (IT_BYTEPOS (*it)) =3D=3D ' ' \ - || *BYTE_POS_ADDR (IT_BYTEPOS (*it)) =3D=3D '\t')))) + (!CHAR_TABLE_P (Vword_wrap_chars) \ + ? ((it->what =3D=3D IT_CHARACTER && (it->c =3D=3D ' ' || it->c =3D=3D '= \t')) \ + || ((STRINGP (it->string) \ + && (SREF (it->string, IT_STRING_BYTEPOS (*it)) =3D=3D ' ' \ + || SREF (it->string, IT_STRING_BYTEPOS (*it)) =3D=3D '\t')) \ + || (it->s \ + && (it->s[IT_BYTEPOS (*it)] =3D=3D ' ' \ + || it->s[IT_BYTEPOS (*it)] =3D=3D '\t')) \ + || (IT_BYTEPOS (*it) < ZV_BYTE \ + && (*BYTE_POS_ADDR (IT_BYTEPOS (*it)) =3D=3D ' ' \ + || *BYTE_POS_ADDR (IT_BYTEPOS (*it)) =3D=3D '\t')))) \ + : it_displaying_word_wrap_char(it)) \ + +static inline bool +char_is_word_wrap_char_p (int c) { + return !NILP (CHAR_TABLE_REF (Vword_wrap_chars, c)); +} + +static inline bool +it_displaying_word_wrap_char (struct it *it) { + return ((it->what =3D=3D IT_CHARACTER && char_is_word_wrap_char_p (it->c= )) + || (STRINGP (it->string) && char_is_word_wrap_char_p + (STRING_CHAR + (SDATA (it->string) + IT_STRING_BYTEPOS (*it)))) + || (it->s && char_is_word_wrap_char_p + (STRING_CHAR(it->s + IT_BYTEPOS (*it)))) + || (IT_BYTEPOS (*it) < ZV_BYTE && char_is_word_wrap_char_p + (FETCH_CHAR (IT_BYTEPOS (*it))))); +} =20 /* These are the category sets we use. They are defined by kinsoku.el and chracters.el. */ diff --git a/test/manual/word-wrap-test.el b/test/manual/word-wrap-test.el new file mode 100644 index 0000000000..593c2decc7 --- /dev/null +++ b/test/manual/word-wrap-test.el @@ -0,0 +1,127 @@ +;;; word-wrap-test.el -- tests for word-wrap -*- lexical-binding: t -*- + +;; Copyright (C) 2017 Free Software Foundation, Inc. + +;; This file is part of GNU Emacs. + +;; This program is free software; you can redistribute it and/or modify +;; it under the terms of the GNU General Public License as published by +;; the Free Software Foundation, either version 3 of the License, or +;; (at your option) any later version. + +;; This program is distributed in the hope that it will be useful, +;; but WITHOUT ANY WARRANTY; without even the implied warranty of +;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +;; GNU General Public License for more details. + +;; You should have received a copy of the GNU General Public License +;; along with this program. If not, see . + +;;; Commentary: + +;; Run the tests M-x word-wrap-test-[1-4] which correspond to the four +;; combinations: +;; +;; i) whitespace-mode being enabled and disabled, +;; +;; ii) word-wrap-chars being nil and equal to a char-table that +;; specifies U-200B as the only word-wrap character. +;; +;; The tests with whitespace-mode are needed to help avoid a +;; regression on Bug#11341. + +;;; Code: + +(setq whitespace-display-mappings-for-zero-width-space + '((space-mark 32 + [183] + [46]) + (space-mark 160 + [164] + [95]) + (space-mark 8203 + [164] + [95]) + (newline-mark 10 + [36 10]) + (tab-mark 9 + [187 9] + [92 9]))) + +(defun word-wrap-test-1 () + "Check word-wrap for nil `word-wrap-chars'." + (interactive) + (let ((buf (get-buffer-create "*Word-wrap Test 1*"))) + (with-current-buffer buf + (erase-buffer) + (insert "Word wrap should occur for space.\n\n") + (dotimes (i 100) + (insert "1234567 ")) ; Space + (insert "\n\nWord wrap should NOT occur for U-200B.\n\n") + (dotimes (i 100) + (insert "1234567=E2=80=8B")) ; U-200B + (setq word-wrap t) + (setq-local word-wrap-chars nil) + (whitespace-mode -1) + (display-buffer buf)))) + +(defun word-wrap-test-2 () + "Check word-wrap for nil `word-wrap-chars' with whitespace-mode." + (interactive) + (let ((buf (get-buffer-create "*Word-wrap Test 2*"))) + (with-current-buffer buf + (erase-buffer) + (insert "Word wrap should occur for space (displayed as `=C2=B7').\n= \n") + (dotimes (i 100) + (insert "1234567 ")) ; Space + (insert "\n\nWord wrap should NOT occur for U-200B (displayed as `= =C2=A4').\n\n") + (dotimes (i 100) + (insert "1234567=E2=80=8B")) ; U-200B + (setq word-wrap t) + (setq-local word-wrap-chars nil) + (setq-local whitespace-display-mappings + whitespace-display-mappings-for-zero-width-space) + (whitespace-mode) + (display-buffer buf)))) + +(defun word-wrap-test-3 () + "Check word-wrap if `word-wrap-chars' is a char-table." + (interactive) + (let ((buf (get-buffer-create "*Word-wrap Test 3*"))) + (with-current-buffer buf + (erase-buffer) + (insert "Word wrap should NOT occur for space.\n\n") + (dotimes (i 100) + (insert "1234567 ")) ; Space + (insert "\n\nWord wrap should occur for U-200B.\n\n") + (dotimes (i 100) + (insert "1234567=E2=80=8B")) ; U-200B + (setq word-wrap t) + (setq-local word-wrap-chars + (let ((ct (make-char-table nil nil))) + (set-char-table-range ct 8203 t) + ct)) + (whitespace-mode -1) + (display-buffer buf)))) + +(defun word-wrap-test-4 () + "Check word-wrap if `word-wrap-chars' is a char-table, for whitespace-mo= de." + (interactive) + (let ((buf (get-buffer-create "*Word-wrap Test 4*"))) + (with-current-buffer buf + (erase-buffer) + (insert "Word wrap should NOT occur for space (displayed as `=C2=B7'= ).\n\n") + (dotimes (i 100) + (insert "1234567 ")) ; Space + (insert "\n\nWord wrap should occur for U-200B (displayed as `=C2=A4= ').\n\n") + (dotimes (i 100) + (insert "1234567=E2=80=8B")) ; U-200B + (setq word-wrap t) + (setq-local word-wrap-chars + (let ((ct (make-char-table nil nil))) + (set-char-table-range ct 8203 t) + ct)) + (setq-local whitespace-display-mappings + whitespace-display-mappings-for-zero-width-space) + (whitespace-mode) + (display-buffer buf)))) --=20 (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 18 11:39:43 2020 Received: (at 13399) by debbugs.gnu.org; 18 Sep 2020 15:39:43 +0000 Received: from localhost ([127.0.0.1]:44199 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJIUB-00038Q-7p for submit@debbugs.gnu.org; Fri, 18 Sep 2020 11:39:43 -0400 Received: from eggs.gnu.org ([209.51.188.92]:49930) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJIU9-00038E-VT for 13399@debbugs.gnu.org; Fri, 18 Sep 2020 11:39:42 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49739) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kJIU4-0006Ih-Mq; Fri, 18 Sep 2020 11:39:36 -0400 Received: from [176.228.60.248] (port=4276 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kJIU2-0005GT-9H; Fri, 18 Sep 2020 11:39:35 -0400 Date: Fri, 18 Sep 2020 18:39:48 +0300 Message-Id: <83eemz3xh7.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <877dsrf82b.fsf@gnus.org> (message from Lars Ingebrigtsen on Fri, 18 Sep 2020 16:55:40 +0200) Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B References: <50EE7BE5.2060806@gmx.at> <83609hw7pm.fsf@gnu.org> <83r2s5ugnd.fsf@gnu.org> <838te7swci.fsf@gnu.org> <83lgi6vccy.fsf@gnu.org> <877dsrf82b.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 13399 Cc: adam.tack.513@gmail.com, 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: Eli Zaretskii , 13399@debbugs.gnu.org > Date: Fri, 18 Sep 2020 16:55:40 +0200 > > Adam Tack writes: > > > I've split out the non-nil char-table case out into a function, as I > > think that using a named function slightly improves readability, and > > having a macro over 20 lines long, somehow feels "wrong". If the > > compiler does actually follow the inline directive, there should be no > > additional performance hit. > > This was the last post in the thread, and the patch no longer applied, > so I've respun it for Emacs 28. Since we now have word-wrap-by-category, wouldn't that solve the problem, if we add the necessary category to the category set of zero-width space character? From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 19 09:15:49 2020 Received: (at 13399) by debbugs.gnu.org; 19 Sep 2020 13:15:49 +0000 Received: from localhost ([127.0.0.1]:45822 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJciT-0007QK-1V for submit@debbugs.gnu.org; Sat, 19 Sep 2020 09:15:49 -0400 Received: from quimby.gnus.org ([95.216.78.240]:37446) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJciP-0007Q4-Jx for 13399@debbugs.gnu.org; Sat, 19 Sep 2020 09:15:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=YT87bjMMtars3hxXQiMipMJ5wdJl4MXwb54XFYHfVYI=; b=rCyRwN17crj/Woa+321uk64QxW 7RXjik0FUQRxJ9SpZjKq/7HWSAfh+2coPlBZtG3NhOFXqsZagDBI9CavFWzX/yNnLk3iZn0nOms+J P+yR5aHjG+5f9m15enPSO1aycDUEH9WUBI2X6CrQw0oupSpJaHbFAEgkGzzQukoT9B8E=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kJciD-0002z7-VA; Sat, 19 Sep 2020 15:15:39 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B References: <50EE7BE5.2060806@gmx.at> <83609hw7pm.fsf@gnu.org> <83r2s5ugnd.fsf@gnu.org> <838te7swci.fsf@gnu.org> <83lgi6vccy.fsf@gnu.org> <877dsrf82b.fsf@gnus.org> <83eemz3xh7.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAgMAAAAqbBEUAAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAADFBMVEV5e4ers8I7O0H/ //+rgG9YAAAAAWJLR0QDEQxM8gAAAAd0SU1FB+QJEw0HLHv8AEMAAAFoSURBVCjPRc+/TuswFAbw U9Rc0U4ZWgkxtRVD8FMUdIuEJ8fyqVAn2FCeoq1ahJiuKtjjqL5yvqfEcRLw5J8+nz8mYp5ycwwb osQcw/WRtYqwzEnNOp00cGyqUaJTDshf1KYcOxOf5a+68gvLEbzUJ/hdj/UY+MojprnGEk61Sb7x pbBKDSPk/nhv227MsgzIf5AUvqth7FgHLHuYgGYdTuB4HaAaDHHkNZRKGvwJMGDVfGElYrKK3Vay Q9Ngdf/fsUa79Z2sLD8EcMTI8kWXjOTz7u+15zCGkkwWVbrIegg/E10yKD7K13EP+XTjqcVwt7ma zwe3HTR8ndUmbRO/LUVt/jU1Vm/pLGqdRpj9i1vYjWqByzNcBNEalyUc0YQEtgazE5wACMAEjydx QIspRnt8ouzgK8TEB3h/8YvMn3AouxqZvaFvMClqwsF3SVGfce4h3+kXIgtJP7TwsyyCBszC0tjy kr4BvSXNqHxyv0wAAAAldEVYdGRhdGU6Y3JlYXRlADIwMjAtMDktMTlUMTM6MDc6NDQrMDA6MDA6 HoKaAAAAJXRFWHRkYXRlOm1vZGlmeQAyMDIwLTA5LTE5VDEzOjA3OjQ0KzAwOjAwS0M6JgAAAABJ RU5ErkJggg== X-Now-Playing: Propaganda's _A Secret Wish (1)_: "The Murder Of Love" Date: Sat, 19 Sep 2020 15:15:32 +0200 In-Reply-To: <83eemz3xh7.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 18 Sep 2020 18:39:48 +0300") Message-ID: <87lfh5sya3.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > Since we now have word-wrap-by-category, wouldn't that solve the > problem, if we add the necessary category to the category set of > zero-width space character? Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 13399 Cc: adam.tack.513@gmail.com, 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > Since we now have word-wrap-by-category, wouldn't that solve the > problem, if we add the necessary category to the category set of > zero-width space character? Ah, right. So the solution here would be to use modify-category-entry on U-200B, but I guess whether to do so depends on the use case, and it's not something we would want to do by default? So there doesn't seem to be anything more to do in this bug report, and I'm closing it. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 19 09:15:59 2020 Received: (at control) by debbugs.gnu.org; 19 Sep 2020 13:15:59 +0000 Received: from localhost ([127.0.0.1]:45825 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJcid-0007Qi-C6 for submit@debbugs.gnu.org; Sat, 19 Sep 2020 09:15:59 -0400 Received: from quimby.gnus.org ([95.216.78.240]:37462) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJcib-0007QV-Qo for control@debbugs.gnu.org; Sat, 19 Sep 2020 09:15:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=3HXIOVIdKdY0u76qZVe2J/BQrxCguBn9kA1g2zFTMaw=; b=mYliglViHt89m6PDSNFP892j0q pvcoO1sQ07iJdG23ORAlLPTt0qAszItR/iWxQNNJPxUZ9SYqRQl9Fs1wOx0PyxpZhcfPKwOqpGxAw u/XQ3H8VU50ctd1fH5j3ymPA1xYVeCrJpnggByO1TEPK/XVJCJYQxpNDJ7EWET3Lh97I=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kJciT-0002zJ-Tg for control@debbugs.gnu.org; Sat, 19 Sep 2020 15:15:52 +0200 Date: Sat, 19 Sep 2020 15:15:48 +0200 Message-Id: <87k0wpsy9n.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #13399 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 13399 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) close 13399 quit From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 19 10:36:59 2020 Received: (at 13399) by debbugs.gnu.org; 19 Sep 2020 14:36:59 +0000 Received: from localhost ([127.0.0.1]:47744 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJdz1-0005ha-GS for submit@debbugs.gnu.org; Sat, 19 Sep 2020 10:36:59 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56454) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJdz0-0005hO-By for 13399@debbugs.gnu.org; Sat, 19 Sep 2020 10:36:58 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:45518) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kJdyv-0003zP-2P; Sat, 19 Sep 2020 10:36:53 -0400 Received: from [176.228.60.248] (port=2447 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kJdyr-0008K2-B3; Sat, 19 Sep 2020 10:36:50 -0400 Date: Sat, 19 Sep 2020 17:36:45 +0300 Message-Id: <83k0wp3kaq.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87lfh5sya3.fsf@gnus.org> (message from Lars Ingebrigtsen on Sat, 19 Sep 2020 15:15:32 +0200) Subject: Re: bug#13399: 24.3.50; Word-wrap can't wrap at zero-width space U-200B References: <50EE7BE5.2060806@gmx.at> <83609hw7pm.fsf@gnu.org> <83r2s5ugnd.fsf@gnu.org> <838te7swci.fsf@gnu.org> <83lgi6vccy.fsf@gnu.org> <877dsrf82b.fsf@gnus.org> <83eemz3xh7.fsf@gnu.org> <87lfh5sya3.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 13399 Cc: adam.tack.513@gmail.com, 13399@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: adam.tack.513@gmail.com, 13399@debbugs.gnu.org > Date: Sat, 19 Sep 2020 15:15:32 +0200 > > Eli Zaretskii writes: > > > Since we now have word-wrap-by-category, wouldn't that solve the > > problem, if we add the necessary category to the category set of > > zero-width space character? > > Ah, right. So the solution here would be to use modify-category-entry > on U-200B, but I guess whether to do so depends on the use case, and > it's not something we would want to do by default? Yes, I think so. From unknown Fri Jun 20 07:09:20 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 18 Oct 2020 11:24:13 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator