Re: [O] [ANN] Merge export-block type within special-block
Hi Nicolas, I like the thrust of your initial patch very much; I would like to help you make it happen. Here’s some discussion as you requested in a follow-up message. 2014ko abuztuak 31an, Nicolas Goaziou-ek idatzi zuen: Unfortunately, no, I cannot fix it. The problem is even deeper. Indeed, my approach is fundamentally wrong: it is impossible to postpone choosing between parsed or raw data at export time. This information must be obtained at parsing time. Yet, I think syntax should not depend on the libraries loaded. So the initial problem still needs a solution. Special blocks and export blocks are just too similar. We could make them slightly different. One solution is to mark explicitly blocks meant to insert raw code. E.g., #+BEGIN_SOMETHING :special t ... #+END_SOMETHING vs #+BEGIN_SOMETHING ... #+END_SOMETHING I have a hunch that this is backwards. It seems like the convention has been to allow arbitrary special blocks in org files. Sticking to what I know best, these create arbitrarily-named environments in Latex. Export blocks seem like the special case (e.g. the number of types is constrained by the available export modules), and so they should have to bear special marking. What if you used the convention that all export blocks had the form #+begin_export_latex, #+begin_export_html, etc.? This should be unambiguous to parse. (It’s possible to bikeshed about the name, of course: perhaps #+begin_literal_latex etc.) HTH, -- Aaron Ecay
Re: [O] [RFC] [PATCH] Warn about unexpanded macros on export
Hello, Aaron Ecay aarone...@gmail.com writes: Attached is a revised patch. WDYT? Looks good. Some small comments follow. + (if value + (progn + (push signature record) + (delete-region +begin +;; Preserve white spaces after the macro. +(progn (goto-char (org-element-property :end object)) + (skip-chars-backward \t) + (point))) + ;; Leave point before replacement in case of recursive + ;; expansions. + (save-excursion (insert value))) + (when finalize + (error Macro %s was undefined at line %s +(org-element-property :key object) +(line-number-at-pos Nitpick: I find the following more readable (cond (value (push signature record) ...) (finalize (error ...))) Also, don't provide error line as macro are replaced after include keywords are expanded. IOW, in some cases, the line number will be misleading. The key is sufficient, e.g., (error Undefined Org macro: %s. Aborting (org-element-property :key object)) You can commit it once this is fixed. Thank you for the patch. Regards, -- Nicolas Goaziou
Re: [O] [RFC] [PATCH] Warn about unexpanded macros on export
Hello, Aaron Ecay aarone...@gmail.com writes: This turned out to be very easy to change; attached is a patch. Thank you. Please apply it. The links issue (re-)raised by Jacob in http://mid.gmane.org/caa6uvufm-1nwd06a5o3hwsveqmgqljncfk_ptohsehcvdjt...@mail.gmail.com is a bit harder to deal with, since each backend currently does something a little different. It would be possible to make every backend’s org-X-link function error out at the end, but I’m not sure if that’s the right thing to do or not. A more workable solution would be to focus on internal links only and patch `org-export-resolve-id-link', `org-export-resolve-fuzzy-link', `org-export-resolve-coderef' (not needed for radio links). Regards, -- Nicolas Goaziou
Re: [O] [RFC] [PATCH] ox-latex: support :float no with caption for minted listings
Hello,
Aaron Ecay aarone...@gmail.com writes:
Done on master.
Thanks.
OK. I’ll think about this. One question is what type of caption this
should be. (i.e. \captionof{what?}{the caption}). Using the catch-all
figure caption type seems most sensible to me, but feedback from other
latex users is welcome.
FWIW, I think this is a good idea. However, as you suggest, more
feedback would be interesting, too.
Regards,
--
Nicolas Goaziou
Re: [O] [ANN] Merge export-block type within special-block
Hello, Aaron Ecay aarone...@gmail.com writes: I have a hunch that this is backwards. It seems like the convention has been to allow arbitrary special blocks in org files. Sticking to what I know best, these create arbitrarily-named environments in Latex. Export blocks seem like the special case (e.g. the number of types is constrained by the available export modules), and so they should have to bear special marking. Historically (i.e. pre-8.0), so-called export blocks were a core feature, whereas special blocks were defined in an optional library (IIRC org-special-blocks.el). That explains why my proposal was to optionally activate special blocks and not the other way round. We can instead use #+begin_latex :raw t ... #+end_latex to optionally activate an export block instead of a special block. I don't mind either way. What if you used the convention that all export blocks had the form #+begin_export_latex, #+begin_export_html, etc.? This should be unambiguous to parse. (It’s possible to bikeshed about the name, of course: perhaps #+begin_literal_latex etc.) One drawback, however, is that is prevents any special block name from starting with export (or any post-bikeshedding name that could be issued). Regards, -- Nicolas Goaziou
Re: [O] autosave in org-src buffer only works ones
Hi, no, the point is not moving. Its the view. The view shift frow the point in th middle of the view to the point at the last line in the view. It's only in opened src blocks. I should maybe also point out that I use prelude. I now very recently started to adopt a workflow with polymode in org with src block and have had no issues so far. Greetz 2014-09-27 23:10 GMT+02:00 Nicolas Goaziou m...@nicolasgoaziou.fr: Hello, Adriaan Sticker adriaan.stic...@gmail.com writes: Hi, is it possible that these function cause the buffer automatically scrolling when saving? When I save My buffer jumps/scrolls up so that my cursor is on the last row on my screen. I do not understand. Are you saying that auto-saving feature in src blocks moves point? If so, I cannot reproduce it. Regards, -- Nicolas Goaziou
Re: [O] Call speed-commands with prefix-arg?
Aaron Ecay aarone...@gmail.com writes: Hi Aaron, 2014ko irailak 23an, Aaron Ecay-ek idatzi zuen: 2. when not edebugging, C-u 4 : seems to work in both Org and Outshine - All tags realigned to column 0 Good. :) I pushed this patch to the master branch. Thanks for testing it out. Thank you for the patch, its nice that this works now. -- cheers, Thorsten
[O] [org-publish] Error exporting my project
Ciao a tutti, I have this error trying to publish my project that worked fine: Loading /home/leandro/.org-timestamps/Blog.cache...done Publishing file /home/leandro/Desktop/Documenti/org/blog.org using `org-html-publish-to-html' org-html-publish-to-html: Wrong number of arguments: #[(format plist filename pub-dir) ÆÇ!È!ÉÊ\Ë !Ì Í !!ÎÊ BBp`Ï Ð ÑÒ!ÓÔ!P!Õ Ö\ ÐÕ ×\% Ø !jÙ !j qÑÚ!Û eÜ Ý ! qÛ !Þ cÜ b ? Ý !. [pub-dir filename visiting plist init-buf init-point require org file-exists-p make-directory ...] 7 (/usr/share/emacs/24.3/lisp/org/org-publish.elc . 18806)], 5 The relevant part og my .emacs is: (setq org-publish-project-alist '((Blog :base-directory ~/Desktop/Documenti/org/ :publishing-directory ~/Desktop/Blog/ :base-extension org :section-numbers nil :table-of-contents nil :include (blog.org) :exclude .* :tasks nil :author Leandro Noferini :email lnofe...@cybervalley.org :link-up nil :convert-org-links t :publishing-function org-html-publish-to-html ) What's wrong? -- leandro http://6xukrlqedfabdjrb.onion pgp58Ob9gYBSl.pgp Description: PGP signature
Re: [O] [RFC] [PATCH] [babel] read description lists as lists of lists
Aaron Ecay aarone...@gmail.com writes: Hi Aaron, So the question is, how to provide a consistent language-agnostic view of org structure to other languages. well, that would be the parse-tree normally, its a nested list containing all info about org structure. I tried to make two Lisps talk to each other (Emacs Lisp and PicoLisp), and initially thought it would be easy - just send lists back and forth. But when these lists are parse-trees produced by the Org parser framework, its not that straight-forward anymore, because these lists are send as strings and then read again by the other side, and there are lots of peculiarities in the string representation of Org parse-trees that make other languages choke, even if they otherwise understand lists very well. As an example, this nested list representation of this created headline is simple enough, PicoLisp can read it as-is: #+NAME: hl1 #+BEGIN_SRC emacs-lisp :results verbatim (org-dp-create 'headline Hallo World 'data '(:name foo) :level 2 :title 2nd level :todo-keyword NEXT :tags '(office) :priority ?B) #+END_SRC #+results: hl1 : (headline (:level 2 :title 2nd level :todo-keyword NEXT :tags (office) :priority 66 :name foo) (section nil Hallo World)) #+BEGIN_SRC emacs-lisp :var lst=hl1 (length lst) #+END_SRC #+results: : 131 #+BEGIN_SRC picolisp :var lst=hl1 :results pp (in NIL (length lst)) #+END_SRC #+results: : 131 #+BEGIN_SRC picolisp :var lst=hl1 :results pp (in NIL (last (car (str lst #+END_SRC #+results: : (section nil Hallo World) So this can be read by PicoLisp (and probably many other list processing languages), except that nil is not NIL in PicoLisp. But when parsing this Org buffer its easy to see that syntax and semantics of Emacs Lisp circular lists as well as of strings with text-properties cannot easily be consumed by other languages (expecially when # is their comment-start character). Some post-processing is necessary, e.g. suppressing text properties, nil - NIL, \n - ^J, ^ - \^, # - \# etc., and I doubt this can be done in a language agnostic way. And then the circular relationships needs to be resolved to something the target language can understand... #+BEGIN_SRC emacs-lisp :results pp (org-element-parse-buffer) #+END_SRC #+results: (org-data nil (headline (:raw-value --text follows this line-- :begin 1 :end 17295 :pre-blank 0 :contents-begin 30 :contents-end 17295 :level 1 :priority nil :tags nil :todo-keyword nil :todo-type nil :post-blank 0 :footnote-section-p nil :archivedp nil :commentedp nil :post-affiliated 1 :title (#(--text follows this line-- 0 26 (:parent #1))) :parent #0) [...cut...] (paragraph (:begin 17274 :end 17295 :contents-begin 17274 :contents-end 17295 :post-blank 0 :post-affiliated 17274 :parent #3) #(-- \ncheers,\nThorsten\n 0 21 (:parent #4) -- cheers, Thorsten
Re: [O] [RFC] [PATCH] ox-latex: support :float no with caption for minted listings
Aaron Ecay aarone...@gmail.com writes:
Merging the functions might only be worth doing if there were any more
places where \captionof needed to be used.
That's the intent, yes. It would be a waste not to use a package now
residing in the default list. Among the transcoders where
`org-latex--wrap-label' is used, some could probably benefit from
a non-float caption, if requested by the user.
OK. I’ll think about this. One question is what type of caption this
should be. (i.e. \captionof{what?}{the caption}). Using the catch-all
figure caption type seems most sensible to me, but feedback from other
latex users is welcome.
One goal that should be archivable is to get rid of the (horrible)
float package in org-latex-default-packages-alist¹ . In other words
(I'm guessing here), reinterpret [H] placement instructions and do it
the capt-of way.
—Rasmus
Footnotes:
¹ float rewrites the float mechanism which can cause trouble. I
personally never use it.
--
Enough with the bla bla!
[O] org-export - was :input-buffer removed from the communication channel?
Hi Nicolas, for exporting a buffer w/o buffer-file, sometimes ago you added property :input-buffer to the communication channel (on my feature request), so this used to work (one of the two vars was always non-nil): #+BEGIN_SRC emacs-lisp (let ((input-file (plist-get info :input-file)) (input-buffer (plist-get info :input-buffer))) ...) #+END_SRC But now the :input-buffer property seems to have disappeared from the 'info' plist again. If so, its a real pity, since crucial info is missing whenever 'buffer-file-name' is nil. -- cheers, Thorsten
[O] org-mode
Hi, forgive me but have a newbie question I cannot figure out - spent several hours with documentation and searching the net... Don't see why the following buffer is not folded after running cntl-c / m AUTO (bound to org-sparse-tree command), the hits are only highlighted in yellow: What I expect would be: I tried this on two machines (with different file contents), one linux, one Windows-7 (shown here). I have org-mode v 8.2.7a and GNU emacs 24.3.1. my .emacs file: ;(cd C:/Users/hkalldin/Desktop) ;(setq default-directory C:/Documents and Settings/hkalldin/Desktop/) ;(global-set-key (kbd C-x C-f) (lambda () (interactive) ; (cd C:/Users/hkalldin/Desktop) ; (call-interactively 'find-file))) (package-initialize) ; basic ASCII printing to default printer: (setq printer-name //HANSKLTW7/sharedJ6400) ;; org-mode: The following lines are always needed. Choose your own keys. (require 'org-install) (require 'org-habit) (add-to-list 'auto-mode-alist '(\\.org\\' . org-mode)) (global-set-key \C-cl 'org-store-link) (global-set-key \C-ca 'org-agenda) (global-set-key \C-cb 'org-iswitchb) (global-set-key \C-cc 'org-capture) ;;(transient-mark-mode 1) (custom-set-variables ;; custom-set-variables was added by Custom. ;; If you edit it by hand, you could mess it up, so be careful. ;; Your init file should contain only one such instance. ;; If there is more than one, they won't work right. ;; '(org-agenda-files (quote (~/kal.org))) ;; '(safe-local-variable-values (quote ((eval org-display-inline-images ) (custom-set-faces ;; custom-set-faces was added by Custom. ;; If you edit it by hand, you could mess it up, so be careful. ;; Your init file should contain only one such instance. ;; If there is more than one, they won't work right. ) I've also attached the org file in question. What am I doing wrong?! Many thanks in advance /Hans ACRONYMS * ACC = Adaptive Cruise Control:AUTO: * AEB = Autonomous Emergency Breaking :AUTO: * AMF = Android Multimedia Framework (can be used on Linux too) Infrastructure for passing messages between a host and other cores (denoted as CEVA-Link in MM3K presentations) * BSD = Blind Spot Detection :AUTO: * FCW = Forward Collision Warning :AUTO: * ADAS = Advanced Driver Assistance Systems:AUTO: * ADK = Application Deveopment Kit (MM3K) * DVS = Digital Video Stabilizer * SR = Super-resolution * LDW = Lane Departure Warning :AUTO: * TSR = Traffic Sign Recognition :AUTO: * VDMA = Vector DMA (in CEVA-MM3K arch diagrams): access both ISDM and IVDM * VP = Vector Processor (in CEVA arch diagrams, IE the DSP core) * VPU = Vector Processor Unit in MM3K (in CEVA arch diagrams, cmp to VCU in XC*) * VLSU = Vector Processor Unit in MM3K (in CEVA arch diagrams) * VMEM = Vector MEMory (as opposed to SMEM) * SMEM = Sequancial? MEMory (as opposed to VMEM) * CISA = Configurable Instruction Set Architecture ( VGEN) * ISDM = Internal Sequential Data Memory (MM3K) * IVDM = Internal Vector Data Memory (MM3K) * MCMI = Multi Core Messaging Interface (MM3K) * ISP = Image Signal Processing (MM3K/CV applications) * CV = Computer Visiong * PC = Point Cloud A point cloud is a set of data points in some coordinate system. In a three-dimensional coordinate system, these points are usually defined by X, Y, and Z coordinates, and often are intended to represent the external surface of an object. Point clouds may be created by 3D scanners. These devices measure in an automatic way a large number of points on the surface of an object, and often output a point cloud as a data file. The point cloud represents the set of points that the device has measured. http://en.wikipedia.org/wiki/Point_cloud * PCL = Point Cloud Library (open source) http://en.wikipedia.org/wiki/Point_Cloud_Library * OOB = Out Of Box, usually referring to C source code without tweaks for target DSP. * LUT = Look-Up Table (a key-value kind of data structure) * SVM = * HDR = * TAM = * HOG : feature extraction for gesture recognition palm tracking :CV: * Hough : The Hough transform is a feature extraction technique used :CV: in image analysis, computer vision, and digital image processing. http://en.wikipedia.org/wiki/Hough_transform * HAAR Like ::CV: * Harris Corner ::CV: * Kalman filter : A Kalman filter is an optimal estimator - :CV: ie infers parameters of interest from indirect, inaccurate and uncertain observations. It is recursive so that new
Re: [O] How to export to S5 HTML presentation
On Sat, Sep 27, 2014 at 07:59:13AM -0700, Jay Iyer wrote: Hi, I would like to use the S5 backend for HTML presentations but I am not able to figure out how: (1) to set up headlines for incremental slide builds and (2) to add speaker notes.� I spent a lot of time on the mailing list archive and other places but couldn’t find clear instructions on what property values and/or tags are needed on the headlines and their subheadings.� Are there any additional exporter settings� needed in the buffer? � I am using Org 8.2.5h on Emacs 24.3.1 (Apple build) and the built in exporter engines. Documentation for ox-s5 is @ https://github.com/cybercode/org-slides#ox-s5el, although personally i use ox-deck (documented at the same location) now. rick
Re: [O] [org-publish] Error exporting my project
Hello, Leandro Noferini lnofe...@cybervalley.org writes: I have this error trying to publish my project that worked fine: Loading /home/leandro/.org-timestamps/Blog.cache...done Publishing file /home/leandro/Desktop/Documenti/org/blog.org using `org-html-publish-to-html' org-html-publish-to-html: Wrong number of arguments: #[(format plist filename pub-dir) ÆÇ!È!ÉÊ\Ë !Ì Í!!ÎÊ BBp`Ï Ð ÑÒ!ÓÔ!P!Õ Ö\ ÐÕ ×\% Ø !jÙ !j qÑÚ!Û eÜ Ý ! qÛ !Þ cÜ b ? Ý !. [pub-dir filename visiting plist init-buf init-point require org file-exists-p make-directory ...] 7 (/usr/share/emacs/24.3/lisp/org/org-publish.elc . 18806)], 5 ^^ It looks like you have a mixed installation: you're using org-publish.el from Org 7.x instead of 8.x. Regards, -- Nicolas Goaziou
Re: [O] Bug: CAPTION space after 70th character (8.2.7c-71-g60418c-elpa)
So in addition to this only appearing in the emacs-mac port, it is also only in recent Org version. I now think this is related to the new feature of allowing multiple #+CAPTION lines, instead of just one #+CAPTION line. -k. On Sun, Sep 28, 2014 at 12:41 AM, Ken Mankoff mank...@gmail.com wrote: * On 2014-09-28 at 00:27, Ken Mankoff wrote: * On 2014-09-27 at 23:45, Ken Mankoff wrote: I find it strange that y'all can't re-create this since I can do it with emacs -Q, although perhaps it is specific to the emacs-mac port. Just checked and it isn't in latest emacs HEAD. I'll submit a bug report to the emacs-mac project. For record-keeping purposes, google, Bing, other people, and future versions of me, this bug has been reported here: https://github.com/railwaycat/emacs-mac-port/issues/59 -k.
Re: [O] [patch, ox] #+INCLUDE resolves links
Hi,
Thanks for the comments. I hope I addressed the previous comments and
did not introduce new reasons bugs.
I added tests.
Comments on comments follow.
Nicolas Goaziou m...@nicolasgoaziou.fr writes:
Okay, I hope I got it now. It's a rather forgiving regexp in terms of
mistakes. Is that OK?
Please no :only-contents yes, :only-contents true, :only-contents
of_course! in the regexp. If :only-contents is followed by anything but
nil or another keyword, its value is non-nil. See below.
Good catch; I added explicit support for
¡?[oO][fF][-_]?[cC][Oo][uU][rR][sS][\.!¡]?
in the regexp! ¡Gotta catch 'em all!
The sentence is not complete. Also, it should be something like If you
set @code{:only-contents} property to a non-nil value, only
[...]
This is not true anymore about the drawers. This should be merged with
the previous phrase to avoid duplicating @code{:only-contents} (e.g.,
only the contents of the matched element are inserted, without any
planning line or property drawer).
Fixed this and other documentation bugs — hopefully. Let me know if
it's clear.
+(let ((matched (save-match-data
+ (org-split-string
+ (org-remove-double-quotes (match-string 1 value)) ::
There's no reason to use `org-split-string' here since you only want to
match the last ::. You can use the same regexp used by
org-element.el, i.e.
(when (string-match ::\\(.*\\)\\' value)
(setq location (match-string 1 value)
value (replace-match nil nil value)))
Custom_ID is very flexible. I've use a similar regexp.
+ (only-contents
+ (and (string-match
+ :only-?contents?[[:space:]]*\?\\(t\\|true\\|yes\\)?\?
+value)
+ (prog1 (and (match-string 1 value) t)
+ (setq value (replace-match nil nil value)
(only-contents
(and (string-match :only-contents +\\([^: \r\t\n]\\S-*\\) value)
(org-not-nil (match-string 1 value
I have removed flexibility in speling.
+ (narrow-to-region
+ (org-element-property
+(if only-contents :contents-begin :begin) (org-element-at-point))
+ (org-element-property (if only-contents :contents-end :end)
(org-element-at-point
(let ((element (org-element-at-point)))
(let ((contents-beg
(and only-contents
(org-element-property :contents-begin element
(narrow-to-region
(or contents-beg (org-element-property :begin element))
(org-element-property (if contents-beg :contents-end :end) element
Just out of curiosity, what is an example of a element that can be
named and does not have a :contents-begin?
+(when only-contents
+ ;; skip drawers and property-drawers
+ ;; these are removed as needed in `org-export--prepare-file-contents'
+ ;; TODO: How to actually do this? Only line numbers are send to
+ ;; `org-export--prepare-file-contents'. split in two?
+ (goto-char (point-min))
+ (org-skip-whitespace)
+ (beginning-of-line)
+ (let ((element (org-element-at-point)))
+(while (memq (org-element-type element) '(drawer property-drawer))
+ (goto-char (org-element-property :end element))
+ (setq element (org-element-at-point)
Regular drawers are not expected to be skipped. Also, the following
should be better
(when (and only-contents
(memq (org-element-type element) '(headline inlinetask)))
(goto-char (point-min))
(when (org-looking-at-p org-planning-line-re) (forward-line))
(when (looking-at org-property-drawer-re) (goto-char (match-end 0)))
(unless (bolp) (forward-line)))
This should be obviously included within the previous `let'.
Okay, there's a lot of improvements in that suggestion. However, it
misses this case which created using only official shortcuts
* head
SCHEDULED: 2014-09-28 sun
:LOGBOOK:
- Note taken on [2014-09-28 sat 12:21] \\
a drawer
:END:
:PROPERTIES:
:CUSTOM_ID: h
:END:
The patch handles something like this now cf. the last test.
+(apply (lambda (beg end) (format %s-%s beg end))
+ ;; `line-number-at-pos' returns the narrowed line-number
+ (mapcar 'line-number-at-pos (prog1 (list (point-min) (point-max))
(widen))
This is inefficient because `line-number-at-pos' will start counting
twice from line 1.
(goto-char beg)
(widen)
(let ((start-line (line-number-at-pos)))
(format %d-%d
start-line
(+ start-line
(let ((c 0)) (while ( (point) end) (incf c) (forward-line))
c
I didn't check, there may an off-by-one error. Anyway, all this needs
tests.
Fine with me. It's a bit less elegant IMO, but you are right. I had
to do it slightly differently since the line number needs to appear
irrespective of whether lines are included in the call
Re: [O] Bug (regression) in org-replace-disputed-keys. Bisected.
Hello, Teika Kazura te...@gmx.com writes: Hello, org-world. I experience a regression in org-replace-disputed-keys, and I git-bisected it. * Symptom: org-replace-disputed-keys doesn't work for me. Emacs version: GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.0.12) * How to reproduce it: 1. Put the org to /tmp/org-mode 2. Save the following lisp to foo.el --- (progn (setq org-replace-disputed-keys t) (setq org-disputed-keys '(([(shift up)] . [(ctrl up)]) ([(shift down)] . [(ctrl down)]) ([(shift left)] . [(ctrl left)]) ([(shift right)] . [(ctrl right)]) ([(shift meta right)] . [(shift control right)]) ([(shift meta left)] . [(shift control left)]) ([(shift meta up)] . [(shift control up)]) ([(shift meta down)] . [(shift control down)]) ([(shift control right)] . [(shift meta right)]) ([(shift control left)] . [(shift meta left)])) ) (add-to-list 'load-path (expand-file-name /tmp/org-mode/lisp)) (pop-to-buffer *scratch*) (insert * (org-version) ( (org-git-version) )\n ) (require 'org) (org-mode)) 3. Run emacs with $ emacs -Q -l foo.el 4. M-x org-schedule, and press ctrl+cursor. AFAICT, this is partly working. Combinations like [(shift control left)] are properly translated, but not [(shift up)]. Wouldn't this be related to some shift-translation Emacs does? Regards, -- Nicolas Goaziou
Re: [O] org-export - was :input-buffer removed from the communication channel?
Hello, Thorsten Jolitz tjol...@gmail.com writes: Hi Nicolas, for exporting a buffer w/o buffer-file, sometimes ago you added property :input-buffer to the communication channel (on my feature request), so this used to work (one of the two vars was always non-nil): #+BEGIN_SRC emacs-lisp (let ((input-file (plist-get info :input-file)) (input-buffer (plist-get info :input-buffer))) ...) #+END_SRC But now the :input-buffer property seems to have disappeared from the 'info' plist again. If so, its a real pity, since crucial info is missing whenever 'buffer-file-name' is nil. It should be back in 39f5f03. Regards, -- Nicolas Goaziou
Re: [O] Bug: LaTeX export produces no output; clobbering keybindings [8.2.7c (8.2.7c-64-g01f736-elpa @/home/tbg/.emacs.d/elpa/org-20140915/)]
Hello, Tobias Getzner tobias.getz...@gmx.de writes: When using LaTeX-based export targets that produce a .tex file as output (export to LaTeX file, PDF, PDF and open), I receive the message «Buffer foo.tex modified; kill anyway?». Irrespective of whether I answer y/n, no .tex file is produced, and «latexmk» fails with «no such file». Try killing foo.tex beforehand. Both after issuing the file-producing exports, and when issuing exports to buffer only (export to LaTeX buffer), the keybindings in the original org-mode buffer become garbled; e. g., issuing another «C-c C-e» after attempting a LaTeX export no longer invokes the export menu, but is now bound to the command «LaTeX-enviroment». Actions such as «fill-paragraph» also no longer work the way they usually work in org-mode. The mode-line still reports «Org» as the major mode, though. To get the expected commands back, I have to invoke «M-x org-mode». I cannot reproduce it. Did you find anything new? Regards, -- Nicolas Goaziou
Re: [O] [RFC] [PATCH] [babel] read description lists as lists of lists
Aaron Ecay aarone...@gmail.com writes: Let’s back up a step. The representation I am targeting with my change is what babel uses to ship a list off as input to code in a babel block. This code could be emacs lisp, but it could also be R, python, etc. So the question is, how to provide a consistent language-agnostic view of org structure to other languages. The resultant structure doesn’t hang around inside babel, it just gets handed off to a code block. I know. But another internal representation is an additional maintenance burden. It’s not work that I’m afraid of: I offered to rewrite both babel and radio lists in terms of org-elements. Maybe I am insane, as you imply. I never wrote, implied or even thought you were insane. What if I rewrote org-babel-read-list in terms of org-elements? That would satisfy me wrt. babel, and wouldn’t necessitate disturbing org-list-parse-list, radio lists, or indeed anything outside of babel. That is even better. Regards, -- Nicolas Goaziou
Re: [O] working with tables freezes emacs
Hello, Rasmus ras...@gmx.us writes: Xebar Saram zelt...@gmail.com writes: i was wondering if anyone else have had these problems (using latest emacs and org-mode from git): whenever i start working with tables and start editing a cell emacs starts freezing, all emacscleint instances are frozen and i have to kill emacs to get things back to work anyone else encountered this? is there a way i can try to debug this (im not technically savvy at all) Yes, I experience it as well. I have not found a clear receipt to reproduce yet (in particular not in with emacs -q), though, but in my case key components are: emacsclient, tables and TAB to realign. Do you have any update on this? Do you still encounter the bug? Regards, -- Nicolas Goaziou
[O] odd/unexpected behavior with Python src blocks
* Odd behavior in python src-blocks in org-mode I found that some code blocks in Python execute due to apparently silent errors! here is how to reproduce it with a vanilla emacs -q. #+BEGIN_SRC emacs-lisp (org-babel-do-load-languages 'org-babel-load-languages '((emacs-lisp . t) (python . t))) (setq org-confirm-babel-evaluate nil) #+END_SRC #+RESULTS: This block should raise an error (and does) because k is not defined. #+BEGIN_SRC python def f(y, x): return k * y print(f(1, 0)) #+END_SRC #+RESULTS: It raises this error. #+BEGIN_EXAMPLE Traceback (most recent call last): File stdin, line 4, in module File stdin, line 2, in f NameError: global name 'k' is not defined #+END_EXAMPLE However, this code block actually executes, and gives the wrong answer! If I open the source block in Python mode, it does not run without error. #+BEGIN_SRC python :results output from scipy.integrate import odeint def f(y, x): return k * y print(odeint(f, 1, [0, 1])) #+END_SRC #+RESULTS: : [[ 1.] : [ 1.]] Here is the correct answer. #+BEGIN_SRC python :results output from scipy.integrate import odeint k = -1 def f(y, x): return k * y print(odeint(f, 1, [0, 1])) #+END_SRC #+RESULTS: : [[ 1.] : [ 0.36787947]] I am not sure why this happens, but it seems like incorrect behavior to me. -- --- John Kitchin http://kitchingroup.cheme.cmu.edu
Re: [O] working with tables freezes emacs
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, Rasmus ras...@gmx.us writes: Xebar Saram zelt...@gmail.com writes: i was wondering if anyone else have had these problems (using latest emacs and org-mode from git): whenever i start working with tables and start editing a cell emacs starts freezing, all emacscleint instances are frozen and i have to kill emacs to get things back to work anyone else encountered this? is there a way i can try to debug this (im not technically savvy at all) Yes, I experience it as well. I have not found a clear receipt to reproduce yet (in particular not in with emacs -q), though, but in my case key components are: emacsclient, tables and TAB to realign. Do you have any update on this? Do you still encounter the bug? I haven't experienced it recently, but also haven't been working much with tables, I guess. . . —Rasmus -- . . . It begins of course with The Internet. A Net of Peers
[O] How to optionally export source blocks to HTML as only black-and-white?
Good evening, It is great being able to export documents either to ASCII or HTML or PDF. When I want to export to HTML, sometimes I want code blocks to be black and white and sometimes I want the syntax highlighting to be the same as in Emacs. For the latter, `htmlize' does all of the work. For the former, I am stuck. I am not sure how to do it. It looks like coming up with a custom style-sheet might do it, but that is probably wrong. One option I've been considering is to change the color theme before exporting, and I will try that. Question: what is the best way to produce black and white pre blocks for source code in export to HTML? Kind regards, -- Grant Rettke g...@wisdomandwonder.com | http://www.wisdomandwonder.com/ “Wisdom begins in wonder.” --Socrates ((λ (x) (x x)) (λ (x) (x x))) “Life has become immeasurably better since I have been forced to stop taking it seriously.” --Thompson
Re: [O] Babel evaluation of Calc block not working, bug in Calc?
die...@duenenhof-wilhelm.de (H. Dieter Wilhelm) writes: But now we are getting: byte-code: Symbol's function definition is void: v! #+BEGIN_SRC calc :var v=3 v + 4 #+END_SRC Hello Dieter, I think I got it! 1) I see the same error message as you see, for variables with name v or var 2) diagnosys: I see that Calc tries to avoid name collisions by adding a var- prefix to variable names, and by removing it when it needs to. (see code in functions calc-read-var-name and calc-var-name) 3) temporary workaround: try to change :var v=3 into :var var-v=3, it works for me, does it work for you too? 4) proposed correction (untested, and makes sense only if workaround actually works): in ob-calc.el, function org-babel-execute:calc, the invocation of calc-store-into could prepend 'var- to its argument 5) warning: if one applies correction 4), then workaround 3) doesn't work anymore Hope it helps and makes sense for you too, kindest regards. Andrea
Re: [O] odd/unexpected behavior with Python src blocks
Hi John, 2014ko irailak 28an, John Kitchin-ek idatzi zuen: [...] I am not sure why this happens, but it seems like incorrect behavior to me. In the first case, python exits with a non-zero exit code, whereas in the second it exits with a zero code (i.e. successful exit), and prints the matrix-thing [[1.], [1.]] to stdout. It looks like scipy traps the NameErrors and prints them to stderr, but continues its computation regardless. I’d say babel is performing as desired here, but scipy sadly isn’t reporting its errors in the standard way (by a nonzero exit, which I think would happen automatically if the NameErrors made it to the top level of the stack without being caught). -- Aaron Ecay
Re: [O] Changed behaviours of LaTeX exporter in version 8.0+
Hi Nicolas,
On Sun, Sep 28, 2014 at 6:01 AM, Nicolas Goaziou m...@nicolasgoaziou.fr
wrote:
You can use a link filter. Also, `org-export-latex-hyperref-format'
doesn't exist in Org 8.0+.
- By name (using C-c l C-c C-l): Sec. [[*Two%20Words][Two Words]]
[...]
[[*With%20%20in%20the%20Title][With in the Title]]
This is the problem. The path isn't expected to be url-encoded. AFAICT,
C-c l doesn't encoded headlines. I don't know how yours generates such
a link.
Regards,
--
Nicolas Goaziou
The real problem is that, except for using the custom id, the current
export engine cannot refer to the correct label (e.g., \label{se-1})
which is automatically generated during the export process.
See the case of section title with only one word in the ECM (e.g.,
\hyperref[sec-1]{OneWord}), where the export engine still cannot properly
refer to the automatically generated label. This has nothing to do with the
URL-encoding.
Note that the issue of URL-encoding has gone once I cleared up my org-mode
configurations (i.e., commented all out for testing). Still, however, the
issue of wrong cross-referencing is there.
Regards,
Joseph
