Re: [O] Problem exporting to PDF (and viewing)
Achim Gratz writes > Richard Stanton writes: > > While this seems to have something to do with the bash shell I'm > > using, this works fine for everything else, so I'm pretty sure there's > > no fundamental problem in my setup, and it would be nice to find a way > > around this problem. > > I am pretty sure there is some fundamental problem, but you never told > us what exactly your setup is. > > FWIW, I sometimes get these doubled up prefix paths since I installed > cygwin-setup and cygwin-mount from the EmacsWiki in operations that are > completely unrelated to org (I haven't had time to investigate), but > then it works for the same path if I try the same thing a bit later. > Also, as has been mentioned before, you might want to check where the > string "c:\dropbox\org" comes from, since Emacs would normally expand it > as "c:/dropbox/org", so it seems likely that you pull it in via a > Windows environment variable or it is quoted once too many. Lastly, it > is not a good idea to give such DOS paths with "\" to bash, as bash has > totally different quoting rules than DOS cmd. Thanks. I'm using Cygwin bash under Windows Vista, and suspect you may have a point about the directory separator, though nowhere in my init.el do I use a backslash. Anyway, I'll give it a check and see what I can find.
[O] one line fix for org-publish-get-project-from-filename when filename has regexp chars in it
Found a bug when a project's base directory has regexp characters in it.
This probably happens often for `.' but nobody cares because that likely
returns the correct result. But I had a `+' in my project's base
directory name.
I've included the revised function below with my change "subtly" marked by:
!HERE
This being my first time creating an org project, I kept thinking it was
something with my project config. Finally I decided it was a bug as I
got a test project to work.
In order to file a coherent bug report, I tried to narrow the bug down
to an easy test case. It was when I got it down to a bug in
`string-match' that I started to think there might be another problem.
It still took me some trial and error with the filenames before -thwap-
I realized that the `+' in the filename was causing the problem.
Without making a promise about my accuracy, I did search for other calls
to `string-match' in org-publish.el and thought that they all looked
good. I think the problem can only occur when a regexp is being created
from a non-regexp string passed in by the user. In this case, a file path.
I did not search in any other org source files.
Neil
(defun org-publish-get-project-from-filename (filename &optional up)
"Return the project that FILENAME belongs to."
(let* ((filename (expand-file-name filename))
project-name)
(catch 'p-found
(dolist (prj org-publish-project-alist)
(unless (plist-get (cdr prj) :components)
;; [[info:org:Selecting%20files]] shows how this is supposed to work:
(let* ((r (plist-get (cdr prj) :recursive))
(b (regexp-quote <-- !HERE!
(expand-file-name (file-name-as-directory
(plist-get (cdr prj)
:base-directory)
(x (or (plist-get (cdr prj) :base-extension) "org"))
(e (plist-get (cdr prj) :exclude))
(i (plist-get (cdr prj) :include))
(xm (concat "^" b (if r ".+" "[^/]+") "\\.\\(" x "\\)$")))
(when
(or
(and
i (member filename
(mapcar
(lambda (file) (expand-file-name file b))
i)))
(and
(not (and e (string-match e filename)))
(string-match xm filename)))
(setq project-name (car prj))
(throw 'p-found project-name))
(when up
(dolist (prj org-publish-project-alist)
(if (member project-name (plist-get (cdr prj) :components))
(setq project-name (car prj)
(assoc project-name org-publish-project-alist)))
--
Neil Smithline
http://www.neilsmithline.com
Proud GNU Emacs user since 1986, v. 18.24.
Re: [O] Patch: option to not hide brackets in org links
NP in 22. These changes fix warnings: (defface orgl-target-face '((t (:foreground "cyan" :background "royalblue4" :weight normal))) ;; '((t (:weight bold :box (:line-width 1 :color "red" "The face used to emphasise org-mode <>." :group 'orgl) (make-face 'orgl-target-face) (defvar orgl-target-face 'orgl-target-face) -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com
Re: [O] Patch: option to not hide brackets in org links
Sean O'Halpin gmail.com> writes: > Thanks! I just noticed that the main function, orgl-enable, sets the buffer's modification status to true when it runs. This is because altering text properties is considered a modification of the buffer. Fixed by wrapping the offending line in a 'with-silent-modifications' macro. Some older Emacsen may not have this macro -- alternative solutions are given at: http://stackoverflow.com/questions/2699857/emacs-how-to-intelligently-handle- buffer-modified-when-setting-text-properties (defun orgl-enable () "Enable fontification of org-style hyperlinks in the current buffer." (interactive) ;; The following variable has to be bound to a string, or following links ;; will not work. ;; There is probably a more elegant solution. (unless org-todo-line-tags-regexp (set (make-local-variable 'org-todo-line-tags-regexp) "XYZ_THIS@SHOULD_NEVER~MATCH_ZYX")) (orgl-do-font-lock 'font-lock-add-keywords) ;; Stop org links from having invisible [[ brackets ]]. (with-silent-modifications (remove-text-properties (point-min) (point-max) '(invisible nil))) (font-lock-fontify-buffer) ;; Add special link abbreviations. (unless org-link-abbrev-alist-local (make-local-variable 'org-link-abbrev-alist-local)) (dolist (pair (cdr (assoc major-mode *orgl-link-abbrevs*))) (pushnew pair org-link-abbrev-alist-local)))
Re: [O] Babel, gnuplot, post processing
On Sat, May 12, 2012 at 12:58 AM, Eric Fraga wrote: > #+begin_src gnuplot :file xxx.pdf > reset > clear > set output 'xxx.eps' > set terminal postscript eps enhanced 18 > ... > plot ... > ! epstopdf xxx.eps > #+end_src That is a better solution that what I was struggling with. Thanks.
Re: [O] Possible bug in parsing / clarification of syntax
On 05/13/2012 07:54 PM, Bastien wrote: Hi Simon, Simon Thum writes: I have not checked master but on maint it still exists. Do you need any more details to reproduce? The fix is on master, not on maint. Please check the fix is okay for you. Also, if Charles can check if the fix does break is local use of `org-map-entries', I'd appreciate this. If both of you confirm, I'll apply the fix on maint. Confirmed ;) Thanks a lot & Cheers, Simon
Re: [O] [BUG] LaTeX-isms in tables
Hi Bastien,
thanks for looking into this!
Bastien writes:
> Hi Andreas,
>
> Andreas Leha writes:
>
>> there seems to be a bug in LaTeX tables:
>>
>> I can not properly export a file with 2 [\mu{}] in a table to pdf.
>
> I assume this is with the official LaTeX exporter, right?
Yes. Sorry, that I did not state that.
>
>> | parameter | unit|
>> |---+-|
>> | some | [\mu] |
>
> There is only one [\mu] and it is not [\mu{}] here. But anyway,
> I tested the table above and it exports correctly to this
>
> \begin{center}
> \begin{tabular}{ll}
> parameter & unit \\
> \hline
> some & [\mu] \\
> \end{tabular}
> \end{center}
>
> Am I missing something?
In my opinion, this should rather be "... [$\mu$] \\"
The \mu outside of the table is correctly exported as $\mu$.
Thanks,
Andreas
Re: [O] Possible bug in parsing / clarification of syntax
Bastien wrote: > Hi Nick, > > Nick Dokos writes: > > > so I think you'd better check master: main seems way out of date - is it > > even used at this point? > > Maint is used to keep a version of Org that is sync'ed with the next > stable Emacs version (currently Emacs 24.1). > > The Emacs 24.1 branch is in feature freeze, and only major bug fixes > should be sync'ed. That's why we try to be very conservative wrt what > goes in maint. > Ah, OK - I got confused. Thanks for clarifying! Nick
Re: [O] [BUG] LaTeX-isms in tables
Hi Andreas,
Andreas Leha writes:
> there seems to be a bug in LaTeX tables:
>
> I can not properly export a file with 2 [\mu{}] in a table to pdf.
I assume this is with the official LaTeX exporter, right?
> | parameter | unit|
> |---+-|
> | some | [\mu] |
There is only one [\mu] and it is not [\mu{}] here. But anyway,
I tested the table above and it exports correctly to this
\begin{center}
\begin{tabular}{ll}
parameter & unit \\
\hline
some & [\mu] \\
\end{tabular}
\end{center}
Am I missing something?
Thanks,
--
Bastien
Re: [O] Possible bug in parsing / clarification of syntax
Hi Nick, Nick Dokos writes: > so I think you'd better check master: main seems way out of date - is it > even used at this point? Maint is used to keep a version of Org that is sync'ed with the next stable Emacs version (currently Emacs 24.1). The Emacs 24.1 branch is in feature freeze, and only major bug fixes should be sync'ed. That's why we try to be very conservative wrt what goes in maint. -- Bastien
Re: [O] Inline LaTeX fragments in emacs buffer
org-preview-latex-fragment is really great but what is even better is that
it also works outside org-mode! This makes my life a lot easier.
I set "C-c P" as a global key-binding for org-preview-latex-fragment and
"C-c p" to org-ctrl-c-ctrl-c. Then I can preview equations all equations in
ANY buffer with "C-u C-u C-c P". It's great to write equations in comments
of some programming buffer (no matter which programming language) and being
able to render the equations right there.
--
Darlan
At Sun, 13 May 2012 00:46:51 +0200,
Daimrod wrote:
>
> Dov Grobgeld writes:
>
> > Is there any way of getting org-mode to display inline LaTeX fragments
> > in the emacs buffer? E.g. I would like to be able to type:
> >
> > The size of the hypotenuse is $\sqrt{a^2+b^2}$
> >
> > and then the buffer immediately shows:
> >
> > The size of the hypotenuse is √a²+b²
> >
> > where √a²+b² is a png image rendered via dvipng.
> >
> > I assume a toggle would switch between either seeing the formula or
> > seeing the source of the formula, just like for the display of inline
> > images. Also, pressing a backspace when the cursor is at the end of
> > the formula should erase the trailing $ sign, and turn off image
> > display of the formula, just like for [[links][name]].
> >
> > Has anything like this been implemented?
> >
> > Thanks!
> > Dov
>
> Yes, you can produce a preview image with C-c C-x C-l.
>
> See
> (info "(org) Previewing LaTeX fragments")
> and
> (info "(org) Embedded LaTeX")
>
>
>
Re: [O] Possible bug in parsing / clarification of syntax
Hi Simon, Simon Thum writes: > I have not checked master but on maint it still exists. Do you need any > more details to reproduce? The fix is on master, not on maint. Please check the fix is okay for you. Also, if Charles can check if the fix does break is local use of `org-map-entries', I'd appreciate this. If both of you confirm, I'll apply the fix on maint. Thanks! -- Bastien
Re: [O] Possible bug in parsing / clarification of syntax
Simon Thum wrote: > Hi Bastien, > > I have not checked master but on maint it still exists. Do you need > any more details to reproduce? > AFAICT, origin/maint is behind origin/master by 512 commits (ymmv depending on when the last update happened): $ git log --oneline origin/maint --not origin/master $ git log --oneline origin/master --not origin/maint | wc -l 512 so I think you'd better check master: main seems way out of date - is it even used at this point? Nick > Cheers, > > Simon > > > On 05/08/2012 02:13 PM, Bastien wrote: > > Hi Simon, > > > > Simon Thum writes: > > > >> I have to revoke my earlier statement. The patch does _not_ remove the > >> TODO_ line from the agenda. I see no change at all. > > > > This should be fixed now. > > > > Thanks, > > > >
Re: [O] Possible bug in parsing / clarification of syntax
Hi Bastien, I have not checked master but on maint it still exists. Do you need any more details to reproduce? Cheers, Simon On 05/08/2012 02:13 PM, Bastien wrote: Hi Simon, Simon Thum writes: I have to revoke my earlier statement. The patch does _not_ remove the TODO_ line from the agenda. I see no change at all. This should be fixed now. Thanks,
