From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] xwidget updated (1d8b8a2 -> 5f46725) Date: Mon, 29 Dec 2014 18:03:36 +0200 Message-ID: <83k31ajvdz.fsf@gnu.org> References: <20141226164113.11620.38682@vcs.savannah.gnu.org> <831tnjlpts.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1419869059 10586 80.91.229.3 (29 Dec 2014 16:04:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Dec 2014 16:04:19 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: joakim@verona.se Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 29 17:04:12 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Y5cnk-00041t-Ek for ged-emacs-devel@m.gmane.org; Mon, 29 Dec 2014 17:04:12 +0100 Original-Received: from localhost ([::1]:33824 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y5cnj-0002EX-Ue for ged-emacs-devel@m.gmane.org; Mon, 29 Dec 2014 11:04:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50170) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y5cnU-0002E6-EG for emacs-devel@gnu.org; Mon, 29 Dec 2014 11:04:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y5cnP-0003nN-Py for emacs-devel@gnu.org; Mon, 29 Dec 2014 11:03:56 -0500 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:48277) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y5cnP-0003mq-Du for emacs-devel@gnu.org; Mon, 29 Dec 2014 11:03:51 -0500 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NHC00A00PGN1100@mtaout25.012.net.il> for emacs-devel@gnu.org; Mon, 29 Dec 2014 17:59:42 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NHC008QUPRHXC20@mtaout25.012.net.il>; Mon, 29 Dec 2014 17:59:42 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:180838 Archived-At: > From: joakim@verona.se > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > Date: Mon, 29 Dec 2014 10:48:00 +0100 > > I'm extatic that you found time to review it! Thanks Eli! That's the least we could do to help you finish the job. > > 5) xdisp.c:produce_xwidget_glyph needs to account for bidirectional > > display in the same way produce_image_glyph does: swao the left and > > right box edges, and populate the bidi members of struct glyph. > I havent thought about bidi at all. Just look at what produce_image_glyph does, it should tell you enough. > Do you have a simple test case [for bidi]? Type a few Arabic or Hebrew characters, then insert a widget, then type some more Arabic or Hebrew. Try this both in a buffer that has bidi-paragraph-direction set to nil and in a buffer that has it set to left-to-right or right-to-left. > > 6) Did you test what happens with xwidgets when the lines are > > truncated, and only part of the xwidget fits on the line? Are the > > results reasonable? I see that produce_xwidget_glyph does attempt > > to crop the xwidget to fit in the line, but then display_line > > should handle xwidget glyphs the same as it does with image glyphs, > > when it decides how to go about truncation/continuation. > > Truncation works same as for an image, which I think is reasonable. Or > did you mean something else? No, this is what I meant. > I dont understand your comment about display_line. My comment has to deal with truncation marks, when the lines are truncated and the widget gets truncated as result. Around line 20690 in xdisp.c (this is from master; the number could be different on your branch), you will see this code fragment: /* If we truncate lines, we are done when the last displayed glyphs reach past the right margin of the window. */ if (it->line_wrap == TRUNCATE && ((FRAME_WINDOW_P (it->f) /* Images are preprocessed in produce_image_glyph such that they are cropped at the right edge of the window, so an image glyph will always end exactly at last_visible_x, even if there's no right fringe. */ && ((row->reversed_p ? WINDOW_LEFT_FRINGE_WIDTH (it->w) : WINDOW_RIGHT_FRINGE_WIDTH (it->w)) || it->what == IT_IMAGE)) ? (it->current_x >= it->last_visible_x) : (it->current_x > it->last_visible_x))) { /* Maybe add truncation glyphs. */ It currently treats specially only image glyphs, for the reasons explained in the comment. Based on your response and on what I saw in the code, the xwidget glyphs should be handled in the same manner there. To see this code in action, turn on truncate-lines, disable the fringes, and see if you get the truncation glyph when the line ends in an xwidget (you shouldn't). > Eli, how difficult do you suppose it would be to get a GTK3 emacs > running on Windows? I don't know. A Windows port of GTK3 does exist (see http://www.gtk.org/download/win32_tutorial.php), but the GTK related code in Emacs was never tried on Windows, so Someone(TM) will have to get their hands dirty before it will work. I'm guessing that the event loop will give that Someone the most grief, unless the GTK folks already solved that. Alternatively, Someone Else(TM) could port your xwidget code to the corresponding Windows features, but it will take a Windows GUI expert to do that, and I don't think we have such a person on board. > And thanks again for the review! You are welcome.