From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Robert Cochran Newsgroups: gmane.emacs.bugs Subject: bug#24041: 25.1.50; xwidget + -nw mode gives segfault Date: Mon, 22 Aug 2016 13:28:51 -0700 Message-ID: <87lgzoeef0.fsf@cochranmail.com> References: <8760qwtxld.fsf@cochranmail.com> <83oa4ndhfw.fsf@gnu.org> <87lgzrm8ft.fsf@cochranmail.com> <8360qudeuj.fsf@gnu.org> <878tvpa6w6.fsf@cochranmail.com> <83k2f8c1cd.fsf@gnu.org> <87k2f87j2g.fsf@cochranmail.com> <83vaysfxk8.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1471898601 4843 195.159.176.226 (22 Aug 2016 20:43:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 22 Aug 2016 20:43:21 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cc: 24041@debbugs.gnu.org, shanemhansen@gmail.com To: joakim@verona.se Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Aug 22 22:43:17 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bbw3r-0008GI-VQ for geb-bug-gnu-emacs@m.gmane.org; Mon, 22 Aug 2016 22:43:12 +0200 Original-Received: from localhost ([::1]:43058 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bbvrc-0000aU-VT for geb-bug-gnu-emacs@m.gmane.org; Mon, 22 Aug 2016 16:30:32 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50778) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bbvrS-0000ZF-Na for bug-gnu-emacs@gnu.org; Mon, 22 Aug 2016 16:30:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bbvr9-0001yx-LJ for bug-gnu-emacs@gnu.org; Mon, 22 Aug 2016 16:30:21 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:39495) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bbvr9-0001yt-Ha for bug-gnu-emacs@gnu.org; Mon, 22 Aug 2016 16:30:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bbvr9-0001qP-3Y for bug-gnu-emacs@gnu.org; Mon, 22 Aug 2016 16:30:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Robert Cochran Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 22 Aug 2016 20:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24041 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 24041-submit@debbugs.gnu.org id=B24041.14718977446994 (code B ref 24041); Mon, 22 Aug 2016 20:30:02 +0000 Original-Received: (at 24041) by debbugs.gnu.org; 22 Aug 2016 20:29:04 +0000 Original-Received: from localhost ([127.0.0.1]:37207 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bbvqC-0001ok-2r for submit@debbugs.gnu.org; Mon, 22 Aug 2016 16:29:04 -0400 Original-Received: from mail.workgrouplinux.net ([207.195.177.82]:35956) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bbvq9-0001oJ-TO for 24041@debbugs.gnu.org; Mon, 22 Aug 2016 16:29:03 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=simple; d=cochranmail.com; h=from:to :cc:subject:references:date:in-reply-to:message-id:mime-version :content-type; s=dkim1; bh=oV07uP5Bcgv1zNA03yJOZFb9k64=; b=eO21P qGGleoWtQiELUYXVy+mUF9AHZRRlK1MVxqCYGE9z1vr0/c3bakmTJOxY+tEP1IlT 25loLyt26BxIkn/FVpJHI6+WqZvyHlVmymRp+fnSARiIQAhX6yQ1zgViF3AwdmJ3 Uuv3LyXbcJp6QQxfGjaoI9eby17JMaWE1H8X0rmRg+8R/bSEh+kmZnJC+UEOzcWL upTVOvR+2fHcmC4ov6pjJBN9VTRphfj7lswxqpUpqMYBEOGrMldmaony8y5NteY7 uHQ7Fv905Zy/PSk/VxWA/SJJDVRUx85QW29EnlzTOEraQsesfZhyDm79oLtTrf6l 37SxGYGaU4Rb8L+hg== Original-Received: (qmail 6761 invoked by uid 0); 22 Aug 2016 20:28:57 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=private; d=cochranmail.com; b=eJUwfa3ZBBUsVrTmRwoWsDvBH2bkGy0I9E7nLx/g6XQUHDjJwOSp9hqMpQH1DWtkkuWKVIa8deVVMhJH5HkdJw==; Original-Received: from 131-191-86-130.as.clicknet.org (HELO SoraLaptop) (robert@cochranmail.com@131.191.86.130) by mail.cochrantribe.org with ESMTPA; 22 Aug 2016 20:28:57 -0000 In-Reply-To: (joakim's message of "Mon, 22 Aug 2016 21:52:58 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:122525 Archived-At: joakim@verona.se writes: > Eli Zaretskii writes: > >>> From: Robert Cochran >>> Cc: Robert Cochran , shanemhansen@gmail.com, 24041@debbugs.gnu.org >>> Date: Mon, 22 Aug 2016 11:30:15 -0700 >>> >>> > My only comment is that you could call check_x_display_info with Qnil >>> > as its argument. >>> >>> I did think about that. But then it arguably does the wrong thing: >>> `check_x_display_info` with `Qnil` only signals an error when there have >>> never been X windows, eg, opening and closing an X window satisfies the >>> check from then on. It no longer crashes in that instance, but I >>> personally don't think that's the right behavior; if my starting frame >>> isn't capable of displaying an xwidget, say so! Hence checking with the >>> current frame. >> >> Joakim, is it certain that the xwidget will always be shown in the >> frame that is the selected one at the time make-xwidget is called? > > make-xwidget doesnt actualy show the widget. > > There is code like this in xwidget-insert: > (put-text-property (point) (+ 1 (point)) > 'display (list 'xwidget ':xwidget id)) I'm having trouble figuring out a workable compromise on this. While calling code can just be aware that the frame must be graphical, it probably isn't the optimal solution. I suppose I'm at a loss for a situation where you are using a tty and yet want a mode with xwidgets, although I have things set up in such a way that I never open a tty emacsclient unless I've logged in remotely or have chosen to forgo an X session (neither of which happen often in practice); I have fairly convenient ways across DE/WMs to open a graphical emacsclient. >>> Thanks for your reassurance! My one gripe about this patch is that I >>> didn't figure out how to kill the buffer after xwidget creation failure >>> (leaving it seems rather ugly IMO), but I just now realized what I can >>> do. As long as it's not considered wrong to kill a mode's buffer on >>> error, would you also consider this patch to go along with it? >> >> I'm not sure if this is TRT. I'd rather erase-buffer at the beginning >> of xwidget-webkit-new-session, and leave the buffer alone if we signal >> an error. The buffer might have contents that the user will hate >> losing, for diagnostic purposes if nothing else. >> >> Joakim, WDYT? > > I tried to model the code originaly after what the various emacs image > modes did, mostly along the principle of least surprise. I think emacs > normally works like Eli describes above, so I'd go with that yes. Fair enough. Again, merely my opinion that leaving dead buffers is ugly. If I'm deviating from Emacs standard practice in killing the buffer, then we're done here. Patch doesn't go in, life continues on. -- ~Robert Cochran GPG Fingerprint - E778 2DD4 FEA6 6A68 6F26 AD2D E5C3 EB36 4886 8871