unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Sungbin Jo <goranmoomin@daum.net>
To: Po Lu <luangruo@yahoo.com>
Cc: Emacs developers <emacs-devel@gnu.org>
Subject: Re: [PATCH] Handle sharing Cocoa xwidgets more gracefully
Date: Tue, 4 Oct 2022 16:48:42 +0900	[thread overview]
Message-ID: <6185E1EB-BA35-4553-B97F-990EE3AB7CA9@daum.net> (raw)
In-Reply-To: <871qro1fa7.fsf@yahoo.com>

2022. 10. 4. 오전 11:41, Po Lu <luangruo@yahoo.com> 작성:

> Sungbin Jo <goranmoomin@daum.net> writes:
> 
>> Are you mentioning the case when the xwidget view is deleted via
>> ‘delete-xwidget-view’? If that’s the case, the patch on bug#58271 will
>> automatically recreate the xwidget view. Can the xwidget itself get
>> deleted when a referencing xwidget view still exists in a buffer?
> 
> Yes, the xwidget will be marked as "killed", and the xwidget views
> created for killed xwidgets should be empty and not reference the native
> widget.

Ah, I’ve only now realized the existence of ‘kill-xwidget’, and can
reproduce the mentioned problem. I’ll probably be able to work on a fix
soon.

I do find it awkward that (if my understanding is correct) xwidget views
can only be created by displaying an xwidget, and can’t change the
xwidget it is showing, but the xwidget views get left over when the
xwidget is killed. Am I understanding this correctly, or is there a way
to create an empty xwidget view that is not connected to an xwidget at
all, and then connect the view to an xwidget separately (and possibly
change the xwidget)?

>> I found that documentation on various parts of xwidgets were very light;
>> while the functions related to xwidget views are exposed in elisp, seems
>> like documentation on them were non-existent. I’m still having a hard
>> time understanding on how the xwidget system is designed to interact
>> (e.g. it seems from the code that one window cannot contain two xwidget
>> views pointing the same xwidget – is this a bug or is it working as
>> designed?); do you have any pointers on this?
> 
> That's a known limitation of the current xwidget code, which I intend to
> resolve at some point.

Ah, thanks for the confirmation. I still feel that pointers (if they
exist) to information on how the end-users are expected to use the
xwidget system will be immensely helpful, so that I can gain a better
mental model and work on the implementation. (e.g., are xwidget views
something that the user is expected to play around with? I’m assuming
yes since they are exposed to elisp, but they don’t have any
documentation on info.)

I’m currently just gleaming on the individual function names and
docstrings, guessing on how they should work. I couldn’t get xwidgets
working properly on my Linux machine as well; as such I can’t
experiment on the ‘canonical’ implementation either.

Sorry if this feels like an entitled request, my English skills aren’t
the best and that’s not the case here.

Thanks.




  reply	other threads:[~2022-10-04  7:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-03 14:16 [PATCH] Handle sharing Cocoa xwidgets more gracefully 조성빈
2022-10-04  0:26 ` Po Lu
2022-10-04  2:03   ` Sungbin Jo
2022-10-04  2:41     ` Po Lu
2022-10-04  7:48       ` Sungbin Jo [this message]
2022-10-04  8:34         ` Po Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6185E1EB-BA35-4553-B97F-990EE3AB7CA9@daum.net \
    --to=goranmoomin@daum.net \
    --cc=emacs-devel@gnu.org \
    --cc=luangruo@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).