From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Ricardo Wurmus Newsgroups: gmane.emacs.devel Subject: Re: interactive closure =?utf-8?Q?=E2=80=94?= variables not bound Date: Wed, 28 Sep 2016 23:12:08 +0200 Message-ID: <87eg43u3tj.fsf@elephly.net> References: <87y42ch7e1.fsf@elephly.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1475097205 11609 195.159.176.226 (28 Sep 2016 21:13:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Sep 2016 21:13:25 +0000 (UTC) User-Agent: mu4e 0.9.16; emacs 25.1.1 Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 28 23:13:21 2016 Return-path: Envelope-to: ged-emacs-devel@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 1bpMAK-0002NJ-CR for ged-emacs-devel@m.gmane.org; Wed, 28 Sep 2016 23:13:20 +0200 Original-Received: from localhost ([::1]:33197 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bpMAI-0003pc-Nt for ged-emacs-devel@m.gmane.org; Wed, 28 Sep 2016 17:13:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44635) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bpM9O-0003oI-HO for emacs-devel@gnu.org; Wed, 28 Sep 2016 17:12:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bpM9L-0006Sx-Aw for emacs-devel@gnu.org; Wed, 28 Sep 2016 17:12:22 -0400 Original-Received: from sender163-mail.zoho.com ([74.201.84.163]:21332) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bpM9L-0006Sb-3B for emacs-devel@gnu.org; Wed, 28 Sep 2016 17:12:19 -0400 Original-Received: from localhost (x4d0cda12.dyn.telefonica.de [77.12.218.18]) by mx.zohomail.com with SMTPS id 1475097134179377.7818532088519; Wed, 28 Sep 2016 14:12:14 -0700 (PDT) In-reply-to: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 74.201.84.163 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:207883 Archived-At: Stefan Monnier writes: >> The problem with this definition is that it doesn’t work (the other >> problem is that I’m replacing one ugly hack with another). At runtime >> Emacs says that “field-type” is undefined. At compile time Emacs says >> that in the callback “xww”, “field-value”, and “field-type” are >> references to free variables. > > Indeed, currently, the `interactive' spec can't be re-created > individually for every closure. IOW the spec is built once and forall > for a given lambda expression and hence can't refer to surrounding > non-global variables. > > I suggest you M-x report-emacs-bug. Okay, I will report a bug. > This said, in your example, I don't see what benefit you expect to get > from writing > > (call-interactively > (lambda (str) > (interactive > (list (cond ((equal "text" field-type) > (read-string "Text: " field-value)) > ((equal "password" field-type) > (read-passwd "Password: " nil field-value)) > ((equal "textarea" field-type) > (xwidget-webkit-begin-edit-textarea xww field-value))))) > (xwidget-webkit-execute-script > xww > (format "findactiveelement(document).value='%s'" str))))))))) > > instead of > > (let ((str (cond ((equal "text" field-type) > (read-string "Text: " field-value)) > ((equal "password" field-type) > (read-passwd "Password: " nil field-value)) > ((equal "textarea" field-type) > (xwidget-webkit-begin-edit-textarea xww field-value))))) > (xwidget-webkit-execute-script > xww > (format "findactiveelement(document).value='%s'" str))))))))) I’ve tried this first and I’m getting unexpected behaviour. Emacs prompts for a string in the minibuffer as expected, but the process becomes *very* busy, stays at 100% CPU usage, grows in memory, and key presses are registered extremely slowly. Emacs becomes unusable at this point. I cannot even abort this with C-g and have to kill Emacs. The C code is pretty straight forward: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ DEFUN ("xwidget-webkit-execute-script", …) (Lisp_Object xwidget, Lisp_Object script, Lisp_Object fun) { … CHECK_STRING (script); if (!NILP (fun) && (!FUNCTIONP (fun))) wrong_type_argument (Qinvalid_function, fun); … // This runs the JavaScript SCRIPT and then calls the C procedure // `webkit_javascript_finished_cb', passing FUN. webkit_web_view_run_javascript (WEBKIT_WEB_VIEW (xw->widget_osr), SSDATA (script), NULL, &webkit_javascript_finished_cb, (gpointer) fun); return Qnil; } … static void webkit_javascript_finished_cb (GObject *webview, GAsyncResult *result, gpointer lisp_callback) { … Lisp_Object lisp_value = … /* JavaScript return value */ … // Run the Lisp callback, passing the converted JavaScript return value call1 ((Lisp_Object)lisp_callback, lisp_value); } ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I.e., a user calls `xwidget-webkit-execute-script' with a script and a lisp callback, the script is executed. When the script is done, a C callback will be invoked with a reference to the Lisp_Object holding the lisp callback. All that does is retrieve the JS return value and pass it to the lisp callback. I guessed that this odd behaviour must be a result of calling the callback procedure from C with “call1”. I thought that maybe this is expected behaviour when calling a procedure that interacts with the user through the mini-buffer (as read-string does) when it is not using the “interactive” form. Is this a bug? (It looks and buzzes like one…) Or am I doing something stupid? > [ Oh, and while I'm here, let me advertize pcase: > > (let ((str (pcase field-type > ("text" (read-string "Text: " field-value)) > ("password" (read-passwd "Password: " nil field-value)) > ("textarea" ... > > ] Nice! I’ll keep it in mind. ~~ Ricardo