From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: Help with new exporter Date: Fri, 12 Jul 2013 10:59:46 -0400 Message-ID: <87ehb34ye5.fsf@gmail.com> References: <51DFEC7B.7050504@mpip-mainz.mpg.de> <51DFECE9.6010209@mpip-mainz.mpg.de> <87ip0f520a.fsf@gmail.com> <871u73eujy.fsf@gmx.us> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:43910) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UxepF-00086X-BM for emacs-orgmode@gnu.org; Fri, 12 Jul 2013 11:00:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UxepD-0007tX-EM for emacs-orgmode@gnu.org; Fri, 12 Jul 2013 11:00:01 -0400 Received: from plane.gmane.org ([80.91.229.3]:39792) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UxepD-0007tM-5H for emacs-orgmode@gnu.org; Fri, 12 Jul 2013 10:59:59 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UxepB-0005w8-Ro for emacs-orgmode@gnu.org; Fri, 12 Jul 2013 16:59:57 +0200 Received: from pool-108-7-96-134.bstnma.fios.verizon.net ([108.7.96.134]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 12 Jul 2013 16:59:57 +0200 Received: from ndokos by pool-108-7-96-134.bstnma.fios.verizon.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 12 Jul 2013 16:59:57 +0200 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: emacs-orgmode@gnu.org Rasmus writes: > Nick. Robert, > > Disclaimer: I didn't follow this thread closely. . . > > Nick Dokos writes: > >>> (sorry, this should've gone to the list the first time) >>> >>> Hi John, >>> >>> sorry, I can't help you with the filters. >>> >>> On the other hand, I don't see any reason why you gt whose square brackets. >>> >>> I tried different versions of org-mode, and never got *empty* square >>> brackets. >> >> That was my experience as well... > > If one desires empty squares why not use [\mbox{}]? In LaTeX terms I > think [\mbox{}] is equivalent or almost equivalent o [], and to Org > they are different. . . > I think you misunderstood here: John Rakestraw seems to get empty sets of square brackets in the latex file that he produces from his org file. What Robert pointed out (and what I concurred with) was that when he runs John's org file through the exporter, he does not get these empty square brackets. The question is why John on one hand and Robert (and I) on the other hand see such different behavior from the exporter. > Otherwise add a (regexp) filter to > org-export-filter-final-output-functions inserting the missing []s. > > Here's an example of a filer I use. Notice that ox keeps everything > in a string and in property lists (← just an indexed dictionary). > > #+BEGIN_SRC emacs-lisp > (defun org-latex-filter-nobreaks-double-space (text backend info) > "Tries to export \"S1. S2\" as \"S1.~S2\", > while letting \"S1. S2\" be exported without tilde" > (when (org-export-derived-backend-p backend 'latex) > (replace-regexp-in-string "\\(\\. \\)\\{1\\}\\([^ ]\\)" ".~\\2" text))) > > (add-to-list 'org-export-filter-final-output-functions > 'org-latex-filter-nobreaks-double-space) > #+END_SRC > > (This may not be a great example as one probably should implement it > at org-export-before-processing-hook and insert NO-BREAK SPACEs and > tell LaTeX how to handle these). > >> Rasmus's derived backend idea might work perhaps - I for one wouldn't >> know how to implement it at this point. But trying to edit artifacts out >> after the backend is more or less finished seems to me to be a fruitless >> approach. > > I'm not claiming it's easy (Lisp can be pretty daunting, yes?), but > it's definitely doable. > The "fruitless" label was *not* meant for your derived-backend idea: au contraire. John is trying to write filters to edit out all the artifacts that he is getting. That's what I thought was the fruitless approach. The derived backend approach seems to me to be the *only* (or at least the best) one for mapping org files to the exam class. I'm sure it is doable: knowing *how* to do it is another matter though - and it's not so much the Lisp, it's figuring out how everything has to go together, given the framework (and all the supporting infrastructure) that Nicolas has provided. I can deal with the Lisp but I just don't know enough about the new exporter framework to even do a trivial backend at this point. > 1. You start by thinking about how you want your layout to be. This > is particularly the case if you don't want to (mis)use the *s for > everything. For instance the Org file Robert posted had a lot of > repeated things that might as well be handeled by the computer. > 2. Then you write functions that translate the elements that you want > to work differently into LaTeX code and put 'em into > the :translate-alist. All functions that you're not adding will > come from the LaTeX class. > > Here's some documentations (somewhat heavy) > > http://orgmode.org/manual/Adding-export-back_002dends.html > http://orgmode.org/worg/dev/org-export-reference.html > > and an not-so-enlightening example > > http://orgmode.org/worg/exporters/filter-markup.html > > > Further: I'm working on a section for the manual on ways of adding new > backends, but alas I must spend my time on other activities at the > moment. Of course, the present discussion of implementing an exam > class is a much more interesting example than the cookbook I'm working > on at the moment :) > More tutorials is exactly what's needed, so thanks for the pointers - and any future tutorials you provide as well :-) > –Rasmus -- Nick