Re: [O] Cannot load org after updating to 9.0
2016-11-07 14:11 GMT+01:00 Thibaut Verron : > 2016-11-07 12:44 GMT+01:00 Thibaut Verron : > >> Hello, >> >> I updated my emacs packages this morning, including org 9.0, from GNU >> elpa. Apparently (based on other folders in my elpa installation folder), >> my last previous update was on april 11, 2016, so the problem may not come >> from the very latest version. Nonetheless, I didn't find any other mention >> of it online. >> >> So, how does the problem appear? When I start emacs, I get the following >> "warnings": >> >> > WARNING: No org-loaddefs.el file could be found from where org.el is >> loaded. >> > You need to run "make" or "make autoloads" from Org lisp directory >> > Warning (initialization): An error occurred while loading >> `(...)/.emacs.d/init.el': >> >> > Symbol's function definition is void: org-element-update-syntax >> >> For the first warning, I tried looking in the >> ~/.emacs.d/elpa/org-20161102 folder (which is where the loaded org.el file >> is), and it does contain org-loaddefs.el. There is no makefile, but I guess >> that it is normal for an installation using elpa. >> >> The second warning is an error and blocks further evaluation of my init >> file. For some reason though, --debug-init doesn't give any stacktrace. >> >> I'm using emacs 24.3.1 on linux (ubuntu 14.04). >> > > When I try to evaluate org-loaddefs manually, I get an error "Symbol's > function definition is void: function-put". > > Apparently, based on this thread [1], it can happen if I installed org > using a more recent version of emacs than the one I am using currently. It > was certainly the case until this morning, but I installed the update from > this computer, and after the problem appeared, I uninstalled and > reinstalled org, again from this computer. > > Replacing occurrences of function-put with put got rid of the first > warning (the warning message could have been more helpful), but not of the > second one. > > org-element-update-syntax is defined in org-element.el, so I guess it is > another compilation problem. How can I make sure that the package is > compiled for my version of emacs? > > Thibaut Verron > > [1] https://lists.gnu.org/archive/html/emacs-orgmode/2014-05/msg00336.html > The problem is now fixed for me. I uninstalled the package, restarted emacs with -Q, initialized package and reinstalled from there. I had to remove the occurrences of function-put again though. Without -Q, it seems that there was a compilation error in org-attach.el at line 42 (require 'org-id), related to an undefined function "org-link-set-parameter". Thibaut
Re: [O] Cannot load org after updating to 9.0
2016-11-07 12:44 GMT+01:00 Thibaut Verron : > Hello, > > I updated my emacs packages this morning, including org 9.0, from GNU > elpa. Apparently (based on other folders in my elpa installation folder), > my last previous update was on april 11, 2016, so the problem may not come > from the very latest version. Nonetheless, I didn't find any other mention > of it online. > > So, how does the problem appear? When I start emacs, I get the following > "warnings": > > > WARNING: No org-loaddefs.el file could be found from where org.el is > loaded. > > You need to run "make" or "make autoloads" from Org lisp directory > > Warning (initialization): An error occurred while loading > `(...)/.emacs.d/init.el': > > > Symbol's function definition is void: org-element-update-syntax > > For the first warning, I tried looking in the ~/.emacs.d/elpa/org-20161102 > folder (which is where the loaded org.el file is), and it does contain > org-loaddefs.el. There is no makefile, but I guess that it is normal for an > installation using elpa. > > The second warning is an error and blocks further evaluation of my init > file. For some reason though, --debug-init doesn't give any stacktrace. > > I'm using emacs 24.3.1 on linux (ubuntu 14.04). > When I try to evaluate org-loaddefs manually, I get an error "Symbol's function definition is void: function-put". Apparently, based on this thread [1], it can happen if I installed org using a more recent version of emacs than the one I am using currently. It was certainly the case until this morning, but I installed the update from this computer, and after the problem appeared, I uninstalled and reinstalled org, again from this computer. Replacing occurrences of function-put with put got rid of the first warning (the warning message could have been more helpful), but not of the second one. org-element-update-syntax is defined in org-element.el, so I guess it is another compilation problem. How can I make sure that the package is compiled for my version of emacs? Thibaut Verron [1] https://lists.gnu.org/archive/html/emacs-orgmode/2014-05/msg00336.html
[O] Cannot load org after updating to 9.0
Hello, I updated my emacs packages this morning, including org 9.0, from GNU elpa. Apparently (based on other folders in my elpa installation folder), my last previous update was on april 11, 2016, so the problem may not come from the very latest version. Nonetheless, I didn't find any other mention of it online. So, how does the problem appear? When I start emacs, I get the following "warnings": > WARNING: No org-loaddefs.el file could be found from where org.el is loaded. > You need to run "make" or "make autoloads" from Org lisp directory > Warning (initialization): An error occurred while loading `(...)/.emacs.d/init.el': > Symbol's function definition is void: org-element-update-syntax For the first warning, I tried looking in the ~/.emacs.d/elpa/org-20161102 folder (which is where the loaded org.el file is), and it does contain org-loaddefs.el. There is no makefile, but I guess that it is normal for an installation using elpa. The second warning is an error and blocks further evaluation of my init file. For some reason though, --debug-init doesn't give any stacktrace. I'm using emacs 24.3.1 on linux (ubuntu 14.04). What should I do? Thanks, Thibaut Verron
Re: [O] Dependency on gnus?
Rasmus gmx.us> writes: > > Hi, > > Thibaut Verron gmail.com> writes: > > > After installing the latest snapshot of orgmode (20141208 or 8.2.10-23), it > > fails loading, stating that gnus is not provided. Commenting out the > > "(require 'gnus-sum)" line in org.el seems to fix it (I mean that at least > > it loads). > > You should already have Gnus. It comes with Emacs. Did you do something > to actively remove it? > Ok, figured it out. Never tried to remove it, but I tried to use it once. During this, I created a file named "gnus.el" supposed to hold my config, and (this shouldn't have happened) dropped it in my load-path instead of the folder where all my config files are. Nevermind, sorry. And thanks for the help! Thibaut
[O] Dependency on gnus?
Hello, After installing the latest snapshot of orgmode (20141208 or 8.2.10-23), it fails loading, stating that gnus is not provided. Commenting out the "(require 'gnus-sum)" line in org.el seems to fix it (I mean that at least it loads). Is it a real dependency? And in that case, why didn't elpa install it by itself? Thanks, Thibaut Verron
Re: [O] Orgtbl-mode in latex: escaped braces and dollars, and other arbitrary transformations
2014-06-26 15:17 GMT+02:00 Nicolas Goaziou :
> Thibaut Verron writes:
>
> >> Now, are these "limitations of Org" really preventing it from exporting
> a
> >> string verbatim? That would seem like the most logical default in this
> >> situation, wouldn't it?
>
> I disagree in the general case. The most logical default for Org is to
> treat contents as plain text and ensure that the export conforms to what
> appears in the buffer. As a bonus, it can leave LaTeX code as-is when it
> recognizes some, which depends on Org's understanding of LaTeX syntax
> (hence the limitations I'm talking about).
>
Of course, I did not mean it for org-mode buffers! ;)
>
> Now, in the context of a LaTeX buffer using orgtbl minor mode, it could
> make sense in some situations to treat cell contents verbatim. I don't
> think it should be the default, but there could be an option for that.
> Anyway, there's a solution, see below.
>
> > Apparently not, the following quick attempt seems to be doing the job
> fine
> > enough:
> >
> > (defun tv/orgtbl-to-latex-verbatim (table params)
> > (flet ((org-export-string-as
> > (string backend &optional b e)
> > string))
> > (orgtbl-to-latex table params)))
> >
> > However, it is extra dirty, and ignoring so many parameters in a function
> > is probably not safe. :-)
>
> I think defining your own translator function is the way to go. For
> example, the following (untested) could work:
>
> (defun my-orgtbl-to-latex-verbatim (table params)
> (let* ((alignment (mapconcat (lambda (x) (if x "r" "l"))
>org-table-last-alignment ""))
> (params2
> (list
>:tstart (concat "\\begin{tabular}{" alignment "}")
>:tend "\\end{tabular}"
>:lstart "" :lend " " :sep " & "
>:efmt "%s\\,(%s)" :hline "\\hline")))
> (orgtbl-to-generic table (org-combine-plists params2 params
>
>
Indeed it does work.
But, unless I am mistaken, this is exactly the definition given here:
http://orgmode.org/manual/Translator-functions.html#Translator-functions
and so I was not wrong, this used to work as I expected.
I suspect that this change (regression?) will cause problems to a lot of
other users when they will upgrade their org to the current version.
Would changing the last lines of `orgtbl-to-latex` to something like this
work as a long-term solution?
(require 'ox-latex)
(let* ((*orgtbl-verbatim* (plist-get params :verbatim))
(backend (if *orgtbl-verbatim* nil 'latex)))
(orgtbl-to-generic table (org-combine-plists params2 params)
backend
Thanks for your time,
Thibaut verron
Re: [O] Orgtbl-mode in latex: escaped braces and dollars, and other arbitrary transformations
2014-06-26 12:38 GMT+02:00 Nicolas Goaziou :
> Hello,
>
> Thibaut Verron writes:
>
> > I'm forwarding this question asked on stackexchange:
> > http://tex.stackexchange.com/questions/186605/with-orgtbl-how-to-ensure-
> > that-braces-and-dollars-are-not-escaped
> >
> > After some investigation, it seems that the behavior is hidden deep in
> the
> > export routines, and I was wisely suggested to ask the question on this
> list
> > instead.
> >
> > I have given some tex-related details in the linked question, including
> some
> > motivations and an example, the tl;dr is that in some conditions, the
> > orgtbl-to-latex exporter will perform arbitrary escape of some
> characters in
> > the cells, or other kind of transformations:
> >
> > $\text{test}$
> > is exported verbatim (OK).
> >
> > But
> > \pbox{test}
> > becomes
> > \pbox\{test\}
>
> You should upgrade to Org 8.
>
> > {test}
> > becomes
> > \{test\}
>
> This is intended.
>
> > {$test$}
> > becomes
> > \{\$test\$\}
>
> This is to be expected as matching single dollar math snippets is
> fragile. I suggest to use \(...\) instead: {\(test\)}
>
> > And the exporter seems to be trying to be smart, because it will still
> > ensure that the result is correct:
> >
> > {$\infty$}
> > becomes
> > \{\$$\infty$\$\}
>
> Ditto. Use \(...\). Or, better, {\infty} as \infty is an Org entity
> which will properly translated into LaTeX code.
>
> > The weirdest of all might be this one:
> > \pbox{Foo: \\${bar= (2^{3},1)}$, ${baz= (8^{4})}$}
> > becomes
> > \pbox\{Foo: \\${bar= (2^{3},1)}$, \$\{baz= (8$^{\text{4}}$)\}\$\}
>
> You cannot write raw LaTeX macros with complicated arguments (e.g.,
> containing braces) in an Org buffer. In this case, you have to tell the
> exporter it is LaTeX code and don't expect it to find it out:
>
> @@latex:\pbox{Foo: \\${bar= (2^{3},1)}$, ${baz= (8^{4})}$}@@
>
> This will be ignored in any exporter but latex (and beamer).
>
> > The option `:no-export`, as expected, has no effect, since it only
> controls
> > whether `#_^&%` are escaped or not.
>
> This option doesn't exist anymore in Org 8.
>
> > Is this a known feature, or a bug? And is there a known workaround?
>
> Actually, this is consistent if you understand the limitations of Org.
> As a rule of thumb, avoid using $..$ constructs and macros with
> convoluted arguments (but "\hfill{}" and "\vspace{1cm}" are fine) when
> writing raw LaTeX in an Org buffer.
>
> For anything more complicated, use @@latex:...@@
> or #+BEGIN_LATEX...#+END_LATEX (inline and non-inline version).
>
> Again, all this assumes you are using Org 8.
>
> HTH,
>
>
> Regards,
>
> --
> Nicolas Goaziou
>
Thank you for your answer,
I forgot to repeat the information about my environment I gave on
stackexchange. In particular, this is Org 8.2.6.
Also, this is not an org buffer, but a latex buffer with the orgtbl minor
mode. Indeed I should have mentioned it in the body of the question, it's
easily missed in the title.
However, I understand that the underlying mechanism is the same as the one
used to export an org buffer to latex, and that it probably suffers from
the same limitations.
Now, are these "limitations of Org" really preventing it from exporting a
string verbatim? That would seem like the most logical default in this
situation, wouldn't it? (Disclaimer: I don't "understand the limitations of
Org", so these last questions may be ridiculous to someone who does)
Thanks,
Thibaut Verron
PS. Indeed \(..\) does work for the dollars, thank you for the tip. I
should have pointed out that \bgroup ... \egroup works as a replacement for
outermost pairs of braces too. However, I do not have any solution for the
\pbox{...} thing. And I would prefer a more robust solution which would not
require me to change the way I write the tables, because otherwise, I'd
still risk facing new unexportable constructs at random times.
Re: [O] Orgtbl-mode in latex: escaped braces and dollars, and other arbitrary transformations
> > Now, are these "limitations of Org" really preventing it from exporting a > string verbatim? That would seem like the most logical default in this > situation, wouldn't it? (Disclaimer: I don't "understand the limitations of > Org", so these last questions may be ridiculous to someone who does) > > > Apparently not, the following quick attempt seems to be doing the job fine enough: (defun tv/orgtbl-to-latex-verbatim (table params) (flet ((org-export-string-as (string backend &optional b e) string)) (orgtbl-to-latex table params))) However, it is extra dirty, and ignoring so many parameters in a function is probably not safe. :-) Is there really no similar mechanism built-in org? Should I polish this function and submit a patch? Or am I running into a wall? Thanks, Thibaut Verron
[O] Orgtbl-mode in latex: escaped braces and dollars, and other arbitrary transformations
Hello,
I'm forwarding this question asked on stackexchange:
http://tex.stackexchange.com/questions/186605/with-orgtbl-how-to-ensure-
that-braces-and-dollars-are-not-escaped
After some investigation, it seems that the behavior is hidden deep in the
export routines, and I was wisely suggested to ask the question on this list
instead.
I have given some tex-related details in the linked question, including some
motivations and an example, the tl;dr is that in some conditions, the
orgtbl-to-latex exporter will perform arbitrary escape of some characters in
the cells, or other kind of transformations:
$\text{test}$
is exported verbatim (OK).
But
\pbox{test}
becomes
\pbox\{test\}
{test}
becomes
\{test\}
{$test$}
becomes
\{\$test\$\}
And the exporter seems to be trying to be smart, because it will still
ensure that the result is correct:
{$\infty$}
becomes
\{\$$\infty$\$\}
The weirdest of all might be this one:
\pbox{Foo: \\${bar= (2^{3},1)}$, ${baz= (8^{4})}$}
becomes
\pbox\{Foo: \\${bar= (2^{3},1)}$, \$\{baz= (8$^{\text{4}}$)\}\$\}
(Note how the two mathematical expressions recieve different treatment, and
the decision to insert "\text" around the exponent!)
The option `:no-export`, as expected, has no effect, since it only controls
whether `#_^&%` are escaped or not.
Is this a known feature, or a bug? And is there a known workaround?
Thanks,
Thibaut Verron
Re: [O] Org-mode Tables not showing correctly in graphical emacs
David Rose jeppesen.com> writes: > > Hi, > > I am not sure if this is an actual bug or if I am just missing some > new setting/configuration option, but when in a graphical emacs window > org-mode table alignments are way off, yet when in a 'terminal' window > emacs session tables are shown as expected. > > Just as I am not sure if this is a bug, I am not sure if it is in > org-mode or emacs itself, so I apologise if this is not the right list > for this. I have tried searching on-line for an answer but have nto > been able to find this which is why I believe I might just be missing > a setting somewhere that I did not need before. > > I am attaching my .emacs file as well as a screen shot showing the > issue I am speaking of. In the screen shot the window on the left is > a graphical instance of emacs, and the one on the right is started > from a terminal window (emacs -nw --no-desktop). Both are using the > same file. > > My emacs version is: 24.3.1 (x86_64-slackware-linux-gnu with GTK+ > version 2.24.17 > > I am currently using an older version of org-mode as I try to > reconfigure my custom latex document classes over to the newer > version. Org mode version is: 7.8.11 > > I have tested this with the newest org-mode version as well though and > received the same results as I currently get. > > Thank you in advance for any assistance, and I again apologise if this > is not the correct list for this. > > Sincerely, > Hello, It seems that you are using a proportional font (different width for each character) as opposed to a monospace one. For example, compare the width of '<' on line 2 with the 'J' below. Table alignment usually works by ensuring all cells in a column contain the same number of characters, but that only works for monospace fonts. The terminal is using monospace fonts by default. --- Thibaut Verron
