bug#24041: 25.1.50; xwidget + -nw mode gives segfault

[Robert Cochran <robert-emacs@cochranmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Cochran <robert-emacs@cochranmail.com>
>> Date: Fri, 19 Aug 2016 11:36:30 -0700
>> Cc: 24041@debbugs.gnu.org
>> 
>> Anyways, so the fix here is conceptually pretty simple: have a check in
>> place to ensure (display-graphic-p) returns non-nil before doing any
>> xwidgets stuff. Easy enough.
>
> display-graphic-p accepts argument, so if a function displays on
> another frame or display, it should be passed that frame or display.

I guess I don't quite understand what you're trying to say here. In the
particular case of `xwidget-webkit-browse-url`, the current frame
is reused. I don't think it would be a particularly good idea to
automatically redirect widget requests to a graphical frame. (Is that
even possible? Start a graphical frame from a tty Emacs?)

Again, I'm having trouble understanding what you mean. Apologies about
my confusion.

>> What I want to solicit feedback on before I write a patch is this: who
>> should be responsible for this check? Should the function provider (the
>> xwidget C 'library') check for the proper support? Or should that be
>> left to the user (the Lisp that calls the xwidget functions, in this
>> case `xwidget-webkit-browse-url`)?
>
> IMO, the check should be on the C level where the xwidget primitives
> are implemented.  One such place is make-xwidget; maybe there are
> more.  (The proper way of testing this on the C level is not by
> calling display-graphic-p, but rather with check_x_display_info.)

That's what my feeling was too. I'll go ahead and do it on the C level
then.

> Thanks.

No problem.

-- 
~Robert Cochran

GPG Fingerprint - E778 2DD4 FEA6 6A68 6F26  AD2D E5C3 EB36 4886 8871