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 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 always 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 let me know, as I'd have to investigate what's causing such different behavior.) 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 fix > regressions (and possibly the MS-DOS build) will not be allowed. Unless > 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 questions > > 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. >