From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.devel Subject: Re: Error in post-command-hook (completion-in-region--postch): (wrong-type-argument stringp nil) Date: Fri, 24 Aug 2012 13:23:05 +0200 Message-ID: <87txvsbkkm.fsf@thinkpad.tsdh.de> References: <87393cd7cu.fsf@thinkpad.tsdh.de> <87393c4oah.fsf@zigzag.favinet> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1345807402 8144 80.91.229.3 (24 Aug 2012 11:23:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 24 Aug 2012 11:23:22 +0000 (UTC) Cc: emacs-devel@gnu.org To: Thien-Thi Nguyen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 24 13:23:21 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1T4ryx-0006tK-Gp for ged-emacs-devel@m.gmane.org; Fri, 24 Aug 2012 13:23:19 +0200 Original-Received: from localhost ([::1]:35435 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T4ryv-0003ft-RM for ged-emacs-devel@m.gmane.org; Fri, 24 Aug 2012 07:23:17 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:54213) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T4ryn-0003fg-Qn for emacs-devel@gnu.org; Fri, 24 Aug 2012 07:23:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T4rym-00048X-O8 for emacs-devel@gnu.org; Fri, 24 Aug 2012 07:23:09 -0400 Original-Received: from deliver.uni-koblenz.de ([141.26.64.15]:37622) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T4rym-00048L-I2 for emacs-devel@gnu.org; Fri, 24 Aug 2012 07:23:08 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by deliver.uni-koblenz.de (Postfix) with ESMTP id ACE70D255C; Fri, 24 Aug 2012 13:23:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at uni-koblenz.de Original-Received: from deliver.uni-koblenz.de ([127.0.0.1]) by localhost (deliver.uni-koblenz.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsKrrMFXWwiX; Fri, 24 Aug 2012 13:23:07 +0200 (CEST) X-CHKRCPT: Envelopesender noch tsdh@gnu.org Original-Received: from thinkpad.tsdh.de (tsdh.uni-koblenz.de [141.26.67.142]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTPSA id 00C7ED255A; Fri, 24 Aug 2012 13:23:06 +0200 (CEST) Mail-Followup-To: Thien-Thi Nguyen , emacs-devel@gnu.org In-Reply-To: <87393c4oah.fsf@zigzag.favinet> (Thien-Thi Nguyen's message of "Fri, 24 Aug 2012 11:44:38 +0200") User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 141.26.64.15 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:152801 Archived-At: Thien-Thi Nguyen writes: > (defun nrepl-complete-at-point () > (interactive) > (let ((sap (symbol-at-point))) > (when (and sap (not (in-string-p))) > (nrepl-send-string [...]) > [...] > ))) > > I'm happy for any pointers! > > Many times, the value of a variable depends on the current buffer. > (This is the beauty and curse of Emacs.) > > Does =E2=80=98nrepl-send-string=E2=80=99 change the current buffer? No. > The same questions could apply to any of the functions involved. > > To find out, i would add some calls to =E2=80=98message=E2=80=99, not tru= sting builtin > debug, Edebug (or, more to the point, my fumblings w/ these facilities) > to not distort the state under study. I tried that, and message always said I'm in the buffer I was supposed to be in, even though the next message was the error. To be super-safe I added (assert (eq major-mode 'clojure-mode)) before every single form of my function! Right now, I only have one clojure-mode buffer open. The original post-command-hook error still occurs, but the assertions are always true anyhow. So it doesn't seem to be caused by being in the wrong buffer... Bye, Tassilo