From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrew De Angelis Newsgroups: gmane.emacs.devel Subject: Re: Volunteering to help on etc/TODO item: Improved xwidgets support Date: Wed, 19 Oct 2022 22:23:43 -0400 Message-ID: References: <87k04wa97f.fsf@yahoo.com> <5E2D44D4-1D11-4531-9F0E-FD46F2B86FE1@stanford.edu> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000058484105eb6e0420" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30772"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Po Lu , "emacs-devel@gnu.org" To: Qiantan Hong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Oct 20 07:10:31 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1olNp9-0007lQ-7l for ged-emacs-devel@m.gmane-mx.org; Thu, 20 Oct 2022 07:10:31 +0200 Original-Received: from localhost ([::1]:47362 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1olNp8-0004FY-7u for ged-emacs-devel@m.gmane-mx.org; Thu, 20 Oct 2022 01:10:30 -0400 Original-Received: from [::1] (port=35866 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1olNp8-0003i3-1l for ged-emacs-devel@m.gmane-mx.org; Thu, 20 Oct 2022 01:10:30 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59702) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1olLE0-0000wp-A1 for emacs-devel@gnu.org; Wed, 19 Oct 2022 22:24:00 -0400 Original-Received: from mail-vs1-xe2b.google.com ([2607:f8b0:4864:20::e2b]:38622) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1olLDx-0005Le-MB for emacs-devel@gnu.org; Wed, 19 Oct 2022 22:24:00 -0400 Original-Received: by mail-vs1-xe2b.google.com with SMTP id 3so19430154vsh.5 for ; Wed, 19 Oct 2022 19:23:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=PKrvcXhgeEV7esWxNKlnf5+mrafCQMZoDgJjSzW3TEE=; b=TfDkIABTMzYJTY8DpEgf66xHQslJHcgn/P2aKgfU16d9flHiLE9+PF5o76Z/sdWdE/ Vw3NfFrA+66ry/+asWtZx6P91ZCcXwYTT1rqTLVIXT1DwT0q2BRGuWiKylzR4yfvcJGs rVC7aXWgZAFV6X9YZF7kpM0Bu/JkQ7iAiUoICKfhMUmVv9HlqXy7TcIPSUNeMsIghq2D f6M68kdiiqKt6egfpoo9nIzHA9Lvua0TmgF4E/KWSs5eRU96Oyk2RoL/dxkiXOaDRBrT tUI+7esrUKQe4D5hy0hMlV/qRb8UJ8SkH7YBX6TYvnktT0UChFONDDIhSPXHvZTzuTWq ZS8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=PKrvcXhgeEV7esWxNKlnf5+mrafCQMZoDgJjSzW3TEE=; b=AsUzJtMQ6Ei7t1IjwFSR8+oPZaTYlpu+9qPcA1QqXZl9DWdFkAOc7xuE9AyAXzlR/L 0EzwZw+BhbNF0G6Ji8fiZq6m/MNzrX643pIm4mmi4wt0squS0dd3gCPF1ZIYrVIernmb 5uhO1WEk6hyhIuRAYKXYC1tFRaDvJ2qSvlvq5c2IoX2nFO/LIvuOyVOi/N57QNHiGXbc GkNBmS3GJWj2IUrPs9tmxM5nquQOgS07CuO4C7ggkRMeqrWuZ53zbvzRRd+TeAXanR0T fAiluDEd23uFkk86P/9MN90TYLV9+LdxV3wbxrQKMJt2lbtl7k1gk+QL9b5TRthajHv4 kBBQ== X-Gm-Message-State: ACrzQf15b45j9HKvBB8S3I/ILhd0/RFyVUxH9ocYDEjckXC342T2Jhi2 ThaQ+KIuK0wbadnBZgbozS8FtyPVqRjIRzqkYM33g65F X-Google-Smtp-Source: AMsMyM6lMvo7cZEjwNzSbOIvfw6GSn2CmpG/DEIIz6EMP61BV7GCiRNaM1tsJQmrH0bLcs79I0rtl/fM4Bus0voW64I= X-Received: by 2002:a05:6102:3c90:b0:3a7:d1d3:10d3 with SMTP id c16-20020a0561023c9000b003a7d1d310d3mr5170783vsv.50.1666232635376; Wed, 19 Oct 2022 19:23:55 -0700 (PDT) In-Reply-To: <5E2D44D4-1D11-4531-9F0E-FD46F2B86FE1@stanford.edu> Received-SPF: pass client-ip=2607:f8b0:4864:20::e2b; envelope-from=bobodeangelis@gmail.com; helo=mail-vs1-xe2b.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Thu, 20 Oct 2022 01:08:12 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:298135 Archived-At: --00000000000058484105eb6e0420 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Great, thanks Qiantian for the info. I'm looking into ways to adapt the Objective C code to use manual reference counting rather than ARC. Is this a problem that other Objective-C Emacs files have? Maybe I can also come up with some general rules/approaches to help people fix the problem in other files. One thing that would be very helpful is if you (or anyone else) is aware of somebody making this fix (ARC -> MRC in Objective C) before: most of the tutorials/documentation I'm finding on the topic is on how to go in the opposite direction, which is helpful information but I'm stuck "reverse engineering" the whole approach. On Wed, Oct 19, 2022 at 2:54 PM Qiantan Hong wrote: > Hi Andrew, > > Nice to meet you! Yes I was working on adding user content API to xwidget= s. > > You can find a version of my patch at > https://lists.gnu.org/archive/html/emacs-devel/2022-10/msg01212.html > The patch has many issues and I=E2=80=99m currently working on fixing it = (I can > only work > on weekends unfortunately), but that=E2=80=99s mostly on the common/gtk p= art. The > NS part > is mostly finalized. However, it does share the exact same issue as all > other NS code > -- it's written in ARC style so it leaks memory. I'm not familiar with NS > without ARC, so > it will be nice if you can help fixing it! > > Feel free to make patch to any existing NS code -- I'm not touching them > that much. > > Best, > Qiantan > > > > > On Oct 18, 2022, at 8:43 PM, Andrew De Angelis > wrote: > > > > Great, thanks for the informative reply! > > > > It would be good if you coordinated your efforts with Qiantian > > Hong (copied), who is also making changes in that area. > > > > Nice to meet you both. @Qiantian Hong let me know about your progress o= n > this, and if there's a specific area I should focus on, so we can combine > forces and avoid duplicate work. > > > > Thanks. It would be nice if someone resolved the more crucial issues > > first, though > > > > I wasn't aware of these, but I will prioritize them. > > > > Unless you can complete this work before November > > > > Yeah, that's a tight deadline. I am going to try to fix the biggest > issues by then, but we'll probably have to wait until the next release to > have this included > > > > I think the timer stops by itself, the variable is not all that > > important. > > > > This is probably another NS-specific issue, but the timer doesn't alway= s > stop in my build. The issue starts in `xwidget-webkit-callback'; it looks > like the "load-finished" event sometimes (most of the times) doesn't > happen or is not received. I will add this to the list of things to fix. > > > > One other possible Lisp bug: currently, `xwidget-webkit-current-url' > always returns "URL: nil" for me. This shouldn't depend on other xwidget > code: the issue is caused by the fact that `kill-new' doesn't return the > string it just added to the kill-ring. (If it does work in your builds le= t > me know, as I'd have to investigate what's causing such different behavio= r.) > > This is my fix for this: > > > > (defun xwidget-webkit-current-url () > > "Display the current xwidget webkit URL and place it on the > `kill-ring'." > > (interactive nil xwidget-webkit-mode) > > (let ((url (or (xwidget-webkit-uri (xwidget-webkit-current-session)) > ""))) > > (kill-new url) > > (message "URL: %s" url))) > > > > > > > > > > On Tue, Oct 18, 2022 at 9:33 PM Po Lu wrote: > > Andrew De Angelis writes: > > > > > Hello everyone and thanks for all your work! > > > > Hello, thanks for working on Emacs. > > > > > This is regarding TODO item: "Things to be done for specific packages > > > or features/NeXTstep port/Missing features/Improved xwidgets support" > > > > > > I've started working on the NS code for xwidget-webkit, with the aim > > > of bringing it up-to-date with the changes to the X11 and GTK code > > > (you can check my as-yet-still-very-minor changes at this fork). I'm > > > sending the email to: 1) check if someone is already working on this > > > 2) make sure I'm going about it the right way 3) inquire about the > > > current X11/GTK implementation. > > > > > > Regarding 1: I haven't found many recent matches for 'xwidget' in the > > > mailing list, but if you're aware of someone already working on this > > > effort, please let me know > > > > Sure. It would be good if you coordinated your efforts with Qiantian > > Hong (copied), who is also making changes in that area. > > > > > Regarding 2: As noted in the Contributing node of the manual, I'm > > > making you aware of my planned improvements and I'd like to know if > > > you have any suggestions/advice. My current plan is to go through the > > > xwidget.c code, take note of any functions/subroutines that are > > > defined for GTK but not NS, and add an NS implementation in xwidget.m= . > > > > Thanks. It would be nice if someone resolved the more crucial issues > > first, though: > > > > - many procedures in nsxwidget.m crash when encountering killed > > xwidgets (see the doc string of `kill-xwidget' for more details.) > > - nsxwidget.m has apparently been written with Objective-C Automatic > > Reference Counting in mind, and thus leak memory, as Emacs cannot > > use ARC. > > > > > I will do my best to complete this so that the NS code will be fully > > > up-to-date. If there are any planned changes to xwidget.c or > > > xwidget.el for the upcoming 29.1 release, please let me know. > > > > I think it will probably be too late for Emacs 29.1, which will start > > the pre-release process soon, at which point changes that don't only fi= x > > regressions (and possibly the MS-DOS build) will not be allowed. Unles= s > > you can complete this work before November, that is. > > > > > Regarding 3: I do not have a Linux machine available at the moment, > > > which would be valuable to get a better sense of the current GTK > > > implementation (I'm working on finding additional volunteers to help > > > on this). Is there a standard-procedure I can follow to ask question= s > > > here about the GTK implementation? > > > > Just send an email to this list, with me copied in. BTW, the canonical > > implementation is not a "GTK implementation", but rather two > > implementations combined in a single file through ifdefs: one for the > > regular X11 build, and the other for a GTK build that does not use any = X > > Windows specific interfaces. > > > > > Is there a point person I should contact specifically? > > > > Me. > > > > > I would like to keep the two different implementations as consistent > > > as possible, while also making sure that common bugs are addressed. > > > One question I have regarding this is on the > > > `xwidget-webkit--loading-p' variable: in my build, I see that this is > > > set to true when creating a new session, but it is then never updated > > > to nil (even long after the web page has fully loaded). Since this > > > variable is not present in the C code, I'm not sure if this is a > > > limitation of the Lisp code (and therefore common regardless of the > > > underlying framework, GTK or NS), or if it's handled correctly in > > > other builds. > > > > I think the timer stops by itself, the variable is not all that > > important. > > --00000000000058484105eb6e0420 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Great, thanks Qiantian for the info.
I'm looking i= nto ways to adapt the Objective C code to use manual reference counting rat= her than ARC. Is this a problem that other Objective-C Emacs files have? Ma= ybe I can also come up with some general rules/approaches to help people fi= x the problem in other files.
One thing that would be very helpfu= l is if you (or anyone else) is aware of somebody making this fix (ARC ->= ; MRC in Objective C) before: most of the tutorials/documentation I'm f= inding on the topic is on how to go in the opposite direction, which is hel= pful information but I'm stuck "reverse engineering" the whol= e approach.

On Wed, Oct 19, 2022 at 2:54 PM Qiantan Hong <qthong@stanford.edu> wrote:
Hi Andrew,

Nice to meet you! Yes I was working on adding user content API to xwidgets.=

You can find a version of my patch at https://lists.gnu.org/archive/html/emacs-devel/2022-10/msg01212.html<= /a>
The patch has many issues and I=E2=80=99m currently working on fixing it (I= can only work
on weekends unfortunately), but that=E2=80=99s mostly on the common/gtk par= t. The NS part
is mostly finalized. However, it does share the exact same issue as all oth= er NS code
-- it's written in ARC style so it leaks memory. I'm not familiar w= ith NS without ARC, so
it will be nice if you can help fixing it!

Feel free to make patch to any existing NS code -- I'm not touching the= m that much.

Best,
Qiantan



> On Oct 18, 2022, at 8:43 PM, Andrew De Angelis <bobodeangelis@gmail.com> w= rote:
>
> Great, thanks for the informative reply!
>
> It would be good if you coordinated your efforts with Qiantian
> Hong (copied), who is also making changes in that area.
>
> Nice to meet you both. @Qiantian Hong let me know about your progress = on this, and if there's a specific area I should focus on, so we can co= mbine forces and avoid duplicate work.
>
> Thanks.=C2=A0 It would be nice if someone resolved the more crucial is= sues
> first, though
>
> I wasn't aware of these, but I will prioritize them.
>
> Unless you can complete this work before November
>
> Yeah, that's a tight deadline. I am going to try to fix the bigges= t issues by then, but we'll probably have to wait until the next releas= e to have this included
>
> I think the timer stops by itself, the variable is not all that
> important.
>
> This is probably another NS-specific issue, but the timer doesn't = always stop in my build. The issue starts in `xwidget-webkit-callback';= it looks like the=C2=A0 "load-finished" event sometimes (most of= the times) doesn't happen or is not received. I will add this to the l= ist of things to fix.
>
> One other possible Lisp bug: currently, `xwidget-webkit-current-url= 9; always returns "URL: nil" for me. This shouldn't depend on= other xwidget code: the issue is caused by the fact that `kill-new' do= esn't return the string it just added to the kill-ring. (If it does wor= k in your builds let me know, as I'd have to investigate what's cau= sing such different behavior.)
> This is my fix for this:
>
> (defun xwidget-webkit-current-url ()
>=C2=A0 =C2=A0"Display the current xwidget webkit URL and place it = on the `kill-ring'."
>=C2=A0 =C2=A0(interactive nil xwidget-webkit-mode)
>=C2=A0 =C2=A0(let ((url (or (xwidget-webkit-uri (xwidget-webkit-current= -session)) "")))
>=C2=A0 =C2=A0 =C2=A0(kill-new url)
>=C2=A0 =C2=A0 =C2=A0(message "URL: %s" url)))
>
>=C2=A0
>=C2=A0
>
> On Tue, Oct 18, 2022 at 9:33 PM Po Lu <luangruo@yahoo.com> wrote:
> Andrew De Angelis <bobodeangelis@gmail.com> writes:
>
> > Hello everyone and thanks for all your work!
>
> Hello, thanks for working on Emacs.
>
> > This is regarding TODO item: "Things to be done for specific= packages
> > or features/NeXTstep port/Missing features/Improved xwidgets supp= ort"
> >
> > I've started working on the NS code for xwidget-webkit, with = the aim
> > of bringing it up-to-date with the changes to the X11 and GTK cod= e
> > (you can check my as-yet-still-very-minor changes at this fork).= =C2=A0 I'm
> > sending the email to: 1) check if someone is already working on t= his
> > 2) make sure I'm going about it the right way 3) inquire abou= t the
> > current X11/GTK implementation.
> >
> > Regarding 1: I haven't found many recent matches for 'xwi= dget' in the
> > mailing list, but if you're aware of someone already working = on this
> > effort, please let me know
>
> Sure.=C2=A0 It would be good if you coordinated your efforts with Qian= tian
> Hong (copied), who is also making changes in that area.
>
> > Regarding 2: As noted in the Contributing node of the manual, I&#= 39;m
> > making you aware of my planned improvements and I'd like to k= now if
> > you have any suggestions/advice. My current plan is to go through= the
> > xwidget.c code, take note of any functions/subroutines that are > > defined for GTK but not NS, and add an NS implementation in xwidg= et.m.
>
> Thanks.=C2=A0 It would be nice if someone resolved the more crucial is= sues
> first, though:
>
>=C2=A0 =C2=A0- many procedures in nsxwidget.m crash when encountering k= illed
>=C2=A0 =C2=A0 =C2=A0xwidgets (see the doc string of `kill-xwidget' = for more details.)
>=C2=A0 =C2=A0- nsxwidget.m has apparently been written with Objective-C= Automatic
>=C2=A0 =C2=A0 =C2=A0Reference Counting in mind, and thus leak memory, a= s Emacs cannot
>=C2=A0 =C2=A0 =C2=A0use ARC.
>
> > I will do my best to complete this so that the NS code will be fu= lly
> > up-to-date. If there are any planned changes to xwidget.c or
> > xwidget.el for the upcoming 29.1 release, please let me know.
>
> I think it will probably be too late for Emacs 29.1, which will start<= br> > the pre-release process soon, at which point changes that don't on= ly fix
> regressions (and possibly the MS-DOS build) will not be allowed.=C2=A0= Unless
> you can complete this work before November, that is.
>
> > Regarding 3: I do not have a Linux machine available at the momen= t,
> > which would be valuable to get a better sense of the current GTK<= br> > > implementation (I'm working on finding additional volunteers = to help
> > on this).=C2=A0 Is there a standard-procedure I can follow to ask= questions
> > here about the GTK implementation?
>
> Just send an email to this list, with me copied in.=C2=A0 BTW, the can= onical
> implementation is not a "GTK implementation", but rather two=
> implementations combined in a single file through ifdefs: one for the<= br> > regular X11 build, and the other for a GTK build that does not use any= X
> Windows specific interfaces.
>
> > Is there a point person I should contact specifically?
>
> Me.
>
> > I would like to keep the two different implementations as consist= ent
> > as possible, while also making sure that common bugs are addresse= d.
> > One question I have regarding this is on the
> > `xwidget-webkit--loading-p' variable: in my build, I see that= this is
> > set to true when creating a new session, but it is then never upd= ated
> > to nil (even long after the web page has fully loaded). Since thi= s
> > variable is not present in the C code, I'm not sure if this i= s a
> > limitation of the Lisp code (and therefore common regardless of t= he
> > underlying framework, GTK or NS), or if it's handled correctl= y in
> > other builds.
>
> I think the timer stops by itself, the variable is not all that
> important.

--00000000000058484105eb6e0420--