From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: [babel] using #+call for inline results Date: Wed, 29 Jun 2011 10:25:59 -0700 Message-ID: <87sjqs5z2w.fsf@gmail.com> References: <87mxhaunsi.fsf@ucl.ac.uk> <87mxh9omwb.fsf@gmail.com> <87mxh9pvz8.fsf@ucl.ac.uk> <87sjr1i040.fsf@gmail.com> <4E030676.3070504@christianmoe.com> <87hb7ej1pu.fsf@gmail.com> <4E071E71.4060804@christianmoe.com> <87vcvsruzs.fsf@gmail.com> <4E082041.6080709@christianmoe.com> <87y60n5fvx.fsf@counsyl.com> <80vcvqidqm.fsf@somewhere.org> <874o39d7ew.fsf@gmail.com> <80hb79dr0i.fsf@somewhere.org> <87wrg45zpg.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Return-path: Received: from eggs.gnu.org ([140.186.70.92]:42142) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbyWd-00020I-3Q for emacs-orgmode@gnu.org; Wed, 29 Jun 2011 13:26:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QbyWb-0007ib-2h for emacs-orgmode@gnu.org; Wed, 29 Jun 2011 13:26:06 -0400 Received: from mail-pv0-f169.google.com ([74.125.83.169]:39993) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbyWa-0007iT-DF for emacs-orgmode@gnu.org; Wed, 29 Jun 2011 13:26:04 -0400 Received: by pvc12 with SMTP id 12so1184237pvc.0 for ; Wed, 29 Jun 2011 10:26:03 -0700 (PDT) In-Reply-To: <87wrg45zpg.fsf@gmail.com> (Eric Schulte's message of "Wed, 29 Jun 2011 10:12:27 -0700") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Sebastien Vauban Cc: emacs-orgmode@gnu.org --=-=-= Content-Type: text/plain Hi Seb, I have attempted to reproduce the two problems I've seen mentioned, specifically 1. repeated prompts to evaluate code when `org-confirm-babel-evaluate' is set to nil 2. Org-mode files not being seen with Org set as the major mode I've used the following minimal configuration --=-=-= Content-Type: application/emacs-lisp Content-Disposition: attachment; filename=seb.el Content-Transfer-Encoding: quoted-printable (add-to-list 'load-path "~/.emacs.d/src/org/lisp/") ; <- path to latest Org= -mode (load "~/.emacs.d/src/org/lisp/org.el") (org-reload) (org-version) (setq org-confirm-babel-evaluate nil) (setq org-agenda-files '("~/Desktop/seb.org")) --=-=-= Content-Type: text/plain which adds the problematic Org-mode file you included in a recent email (attached) into the list of org-agenda-files. --=-=-= Content-Type: text/x-org Content-Disposition: attachment; filename=seb.org #+TITLE: Babel ECM #+DATE: 2011-06-28 #+DESCRIPTION: #+KEYWORDS: #+LANGUAGE: en_US #+LaTeX_CLASS: mcreport #+LaTeX_CLASS_OPTIONS: (final) #+BABEL: :eval never :engine msosql :cmdline -S cauchy -U sa -P LpmdlP -d pfi-paiestag -n -w 700 :results output :exports both :noweb yes * Introduction This library is an extensible *collection of* ready-made *code blocks* for handling common tasks. * "Generic" Transact-SQL ** Add a column into a table #+srcname: add-column-in-table[table, column, type, nullability] #+begin_src sql -- add column `$column' [if column does not exist yet] IF NOT EXISTS [SELECT * FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = '$table' AND COLUMN_NAME = '$column'] BEGIN ALTER TABLE $table ADD $column $type $nullability END #+end_src --=-=-= Content-Type: text/plain I have been unable to reproduce either of the problems you described. Could you start with these two files and build a minimal example demonstrating the bug which can be started with something along the lines of : emacs -Q -l seb.el Once I can observer the behavior then I should have a chance to fix it. Thanks -- Eric Eric Schulte writes: > "Sebastien Vauban" writes: > >> Hi Eric, >> >> Eric Schulte wrote: >>>> Well, I have many other problems with this version (such as speed commands >>>> not working anymore, yasnippet expansion not working anymore on TAB, some >>>> files which say they're not in Org-agenda-files, etc.) but that's another >>>> story. >>> >>> I don't understand, are you saying that all of the above problems are caused >>> by the introduction of inline call lines? I have not experienced any of >>> these problems. >> >> No, I just said I had many other little problems since the last git update. >> Though, I did not know where they come from. Now, I am positive that it comes >> from the LOB. See the ECM I sent yesterday, and the similar report done >> yesterday by Darlan. >> > > Hi Seb, > > I don't know what you are referencing above, but if the new LOB behavior > is causing problems then I certainly want to help resolve them. Can you > link me to the "ECM" you mentioned, and to Darlan's report? > >> >>>> About this, my only weirdness is that I had to confirm 12 times (yes, 12!) >>>> that I wanted to execute the calls. >>>> >>>> I have this in my emacs config file for months >>>> >>>> ;; don't be prompted on every code block evaluation >>>> (setq org-confirm-babel-evaluate nil) >>>> >>>> ... has this var become a local file variable? >>> >>> This has not become a buffer local variable and I can not reproduce your >>> problem, could you please submit a minimal configuration with which I >>> can reproduce this problem. >> >> When removing the Org file with the SQL code from my org-agenda-files, and >> relaunching Emacs (on an updated git), I don't see that problem anymore... >> Maybe related to the above problem, then. >> > > Hmm, could you send me a copy (or minimal subset) of this offending > Org-mode file that causes the multiple prompts? Are you loading this > file using `org-babel-lob-ingest'? > >> >>>> Last thing: the questions in the echo area sometimes display the block name >>>> in parentheses, sometimes not... >>>> >>>> - "Evaluate this emacs-lisp code block (square) on your system? (yes or no)" >>>> - "Evaluate this emacs-lisp code block on your system? (yes or no)" >>> >>> When the code block has a name, the name is shown in parens, when the code >>> block is not named no name is shown. >> >> What I did not understand, is that these messages appeared when running the >> example file I took, where only one block is defined, and that block is named. >> Hence, I'd expect to always see the same message, with the block name in >> parentheses. >> >> Though, as I don't have to confirm anymore (the symptom disappeared), we can >> put this in the fridge... but for the problem with the LOB file (see >> thtp://www.mail-archive.com/emacs-orgmode@gnu.org/msg43083.html). >> > > Oh, I see, the file in question is mentioned in this linked email. I > will take a look and see if I can reproduce locally. Expect more from > me on this today. > > Cheers -- Eric > >> >> Best regards, >> Seb -- Eric Schulte http://cs.unm.edu/~eschulte/ --=-=-=--