bug#48676: Arbitrary code execution in Org export macros
Package: emacs,org-mode
Version: 28.0.50
Severity: important
Tags: security
emacs -Q hello.org, where hello.org contains:
#+macro: hello (eval (shell-command-to-string "touch /tmp/HELLO"))
Hello. {{{hello}}}
Then:
M-x org-export-dispatch
t A
-> now /tmp/HELLO exist, with no prompting.
This seems contrary to normal Emacs practice for risky local variables,
and to the section "Code Evaluation and Security Issues" in the Org manual
(which does not mention macros).
bug#44824: 27.1; Org export as pdf and open file does not open it
Ref eg https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25234#8 https://bugzilla.gnome.org/show_bug.cgi?id=652262 https://gitlab.gnome.org/GNOME/glib/-/issues/1208 and others going back over a decade. I think Emacs should have a PROBLEMS entry about this.
bug#44935: Emacs inserts hardwired org-agenda-files variable, overwriting user options
Eli Zaretskii wrote: > In rare cases that users become confused, we gently tell them to > report to the Org developers. I think it's better all round to just reassign the bug to the "org-mode" package. > There is no manager here that forwards bugs. And yet, all the messages in this thread (save the first) are already on the Org mailing list...
[O] bug#34323: reproducibility: absolute file names in ox-odt.elc
It's due to the eval-when-compile sections in org-odt-schema-dir-list and org-odt-styles-dir-list. These don't make sense to me. All they do is add the build directory. There is a comment "see make install", but I cannot see what this refers to. No similar variable initializes itself in this way AFAIK. If those sections are removed, does anything stop working?
[O] bug#34323: reproducibility: absolute file names in ox-odt.elc
Package: emacs,org-mode Version: 26.1.91 Severity: minor The compiled file ox-odt.elc contains strings that refer to the absolute location of the build directory, through org-odt-schema-dir-list and org-odt-styles-dir-list. For example, in the Emacs 26.1.91 pretest tarfile, it contains "/home/nico/work/emacs-26/etc/schema/" and "/home/nico/work/emacs-26/etc/styles/". This means the generated elc file is non-reproducible (ie, the contents change depending on the build directory). (Like https://debbugs.gnu.org/34321, issued spotted in https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/emacs.html )
[O] bug#32722: 26.1; Org-publish depend on non-free platform ?
I think (or rather assume) that the issue is that GitHub receives
a grade F ("unacceptable") evaluation acccording to the GNU Ethical Repository
Criteria; https://www.gnu.org/software/repo-criteria-evaluation.html.
So does SourceForge, by the way. While there are numerous references
to GitHub and SourceForge in Emacs (and some components even nominally
live there, by the way, eg CEDET, cc-mode...), it's rare (unique?) for
running a GNU Emacs command to actually print "hey, go install
something from this non-ethical repository to finish doing what you
wanted to do". It's a different level of referencing.
[O] bug#32722: 26.1; Org-publish depend on non-free platform ?
Richard Stallman wrote: > If htmlize is useful, we should put it into Emacs. > Is there some obstacle to that? Emacs already includes htmlfontify, since 23.2. Is there some obstacle to Org using that? (bug#7506)
Re: [O] [RFC] Moving "manual.org" into core
I'm sure this is an impressive technical achievement, but can I urge you to raise this on emacs-devel first, because I think it's potentially problematic. I'm not entirely sure what you are proposing here. If the .org version will become the "preferred form" for modification, it would eg need to be in the Emacs repository (when the time comes), with suitable Makefile rules for generating the final products from it, and distributed correctly in releases. Emacs has got into trouble before in this area. Bastien Guerry wrote: > One of my worries was that moving toward editing a manual in .org > does not match GNU developers good practices and habits, which are > to edit .texi files. But as long as the .texi file exists I guess > we can shake the habits by allowing to edit .org files, which are > more convenient to read and write. Speaking for myself, I don't want to learn yet another markup syntax for one single Emacs manual. I find it unlikely that GNU projects will start requiring Emacs to build their documentation. Although the GNU coding standards do say: https://www.gnu.org/prep/standards/html_node/GNU-Manuals.html#GNU-Manuals Nowadays some other formats such as Docbook and Sgmltexi can be converted automatically into Texinfo. It is ok to produce the Texinfo documentation by conversion this way, as long as it gives good results. so there's no problem from that aspect. > But still: RMS recently raised the question on emacs-devel of > whether using .rst for the GNU documentation would be better, > so using .org for this purpose is not entirely hypothetical. On the subject of rst, I can only find a topic two years ago that went nowhere, and note in particular this: http://lists.gnu.org/archive/html/emacs-devel/2016-02/msg00667.html "We don't want to replace Texinfo as the source language" Maybe I'm worried about nothing, but I do suggest asking on emacs-devel.
[O] bug#30321: 25.3; Melpa ox- packages listed as incompatible
Stefan, can you shed any light as to why Org is no longer on elpa.gnu.org? (BTW, I think it would be good if elpa.gnu.org listed a contact email for these kinds of questions.) Nicolas Goaziou wrote: > Note that there is no intent to remove Org from GNU ELPA. Alas, at the > moment, I have no clue (apart the fact we changed servers and moved to > https) about why Org disappeared.
[O] bug#30321: 25.3; Melpa ox- packages listed as incompatible
Version: 26.1 Glenn Morris wrote: > I would guess this is because Org is not recognized as a built-in > package (see https://debbugs.gnu.org/30310), This is now fixed for the next release of Emacs. > and no longer available from any of the standard elpas. If it's no longer to be on elpa.gnu.org, I guess you will have to add https://orgmode.org/elpa to your packages-archives.
[O] bug#30310: Built-in Org mode not listed as installed package
Version: 26.1 Addressed in Emacs e1a9dc0.
[O] bug#30321: 25.3; Melpa ox- packages listed as incompatible
Luis Roca wrote: > Installing ox-rst returns the following error in *Messages*: > >`Incompatible because it depends on uninstallable packages.` > > Reviewing other Org export packages reveals the same note for each. I would guess this is because Org is not recognized as a built-in package (see https://debbugs.gnu.org/30310), and no longer available from any of the standard elpas.
[O] bug#30310: Built-in Org mode not listed as installed package
Package: emacs,org-mode Version: 25.3 emacs -Q -f list-packages The built-in Org mode is not listed. (This eg causes org-edna to be listed as uninstallable.) Adding a Version: header comment to lisp/org/org.el would fix this. (There was one prior to Emacs rev 8223b1d233.) Obviously it would need to be kept in sync with org-version.el. Ref: http://lists.gnu.org/r/emacs-devel/2018-01/msg00813.html
[O] bug#29722: issues with some function declarations
Thanks. I think that will have introduced a compilation warning: In end of data: org-duration.el:448:1:Warning: the function 'org-trim' is not known to be defined.
[O] bug#29722: issues with some function declarations
Package: org-mode Severity: minor "make check-declare" reports the following issues: org/org-compat.el:40:Warning (check-declare): said 'org-table-end' was defined in unknown file: Malformed declaration org/org-footnote.el:48:Warning (check-declare): said 'org-fill-paragraph' was defined in org/org.el: arglist mismatch org/org-compat.el:35:Warning (check-declare): said 'org-at-table.el-p' was defined in org/org.el: arglist mismatch org/ob-core.el:77:Warning (check-declare): said 'org-number-sequence' was defined in org/org-compat.el: obsolete alias org/ob-core.el:85:Warning (check-declare): said 'org-src-coderef-format' was defined in org/org-src.el: arglist mismatch org/org-duration.el:54:Warning (check-declare): said 'org-trim' was defined in org/org-trim.el: file not found
[O] bug#29698: missing/empty custom groups
Package: org-mode Severity: minor ox-publish.el defines an "org-publish" group, but nothing uses it. org-pcomplete.el defines an "org-complete" group, but nothing uses it. org-structure-template-alist uses an "org-completion" group, but nothing defines it.
[O] bug#29695: Mistakes in custom :types
Package: org-mode The following user options have :types that do not match their defaults: org-babel-stan-cmdstan-directory org-latex-default-packages-alist org-odt-with-latex As a result, customizing them displays "mismatch".
[O] bug#29694: Quoting of consts in org-agenda-custom-commands-local-options
Package: org-mode In code like (defcustom ... :type '(const some-constant)) it's a mistake to write 'some-constant. So I'm guessing that various instances of quoted consts in org-agenda-custom-commands-local-options are a mistake. Eg (const :tag "scheduled" 'scheduled) etc
[O] bug#29329: 27.0.50; Missing requirement in org-gnus.el
Speaking for the version in Emacs, apart from org-gnus the warnings are: In end of data: org-irc.el:255:1:Warning: the following functions are not known to be defined: erc-save-buffer-in-logs, erc-logging-enabled (I haven't looked at the code.)
[O] bug#18870: bug#18870: \emsp and alignment in org clock report
Nicolas Goaziou wrote: > Could this bug be marked as done? Thank you. Anyone can close any bug by sending mail to eg 18870-done at debbugs. (Thanks for looking at these reports.)
[O] bug#29329: 27.0.50; Missing requirement in org-gnus.el
In org-gnus-store-link: org-gnus.el:121:49:Warning: reference to free variable ‘gnus-newsgroup-name’ org-gnus.el:127:42:Warning: reference to free variable ‘gnus-summary-buffer’ In org-gnus-follow-link: org-gnus.el:203:9:Warning: reference to free variable ‘gnus-other-frame-object’ In end of data: org-gnus.el:243:1:Warning: the following functions are not known to be defined: gnus-group-group-name, gnus-find-method-for-group, gnus-summary-article-number, nnir-article-group, gnus-summary-article-header, mail-header-from, mail-header-id, mail-header-date, mail-header-subject, mail-header-extra, gnus-summary-select-article, message-narrow-to-headers, message-generate-headers, message-unquote-tokens, message-tokenize-header, gnus-activate-group, gnus-group-read-group, gnus-summary-goto-article, gnus-group-jump-to-group (These issues are all hidden if org-gnus.elc is created before org.elc.) PS hey emacs-orgmode: https://debbugs.gnu.org/org-mode
[O] bug#26467: 25.2; [Org mode] Call dot babel from elisp generate invalid image
Reassigned to org-mode.
wang jinjian wrote:
> Use case is call dot babel from elisp code block. refer to
> http://orgmode.org/worg/org-tutorials/org-dot-diagrams.html
>
> Below is a more minimal example:
>
> #+NAME: nodes
> | From | To | Weight |
> |--++|
> | A| B | 3 |
> | A| C | 2 |
> | B| D | 4 |
> | B| E | 5 |
> | C| F | 10 |
>
> #+BEGIN_SRC elisp :file a.png :var nodes=nodes
> (defun rowfun(x)
> (format "%s -> %s [label=%s];" (nth 0 x) (nth 1 x) (nth 2 x))
> )
> (defun dotgen(nodes)
> (let ((dotbegin "digraph {\nnode [shape=circle]\n")
> (dotend "\n}"))
> (concat dotbegin
> (mapconcat #'rowfun nodes "\n")
> dotend)))
> (setq params (nth 2 (org-babel-get-src-block-info)))
> (org-babel-execute:dot (dotgen nodes) params)
> #+END_SRC
>
> If run this block with C-c C-c, it will generate a image a.png with
> "nil" string in it. so it's a invalid image file.
>
> The issue is introduced by below commit:
>
> 041ca4b6f ob-core: Do not return results on writing to file
>
> After revert this commit, it works fine. Sounds like this change will
> cause the function return "nil" string but not nil variable.
>
> Another probelm is the params variable is void in org 9.0.5. but we can
> replace it with (nth 2 (org-babel-get-src-block-info)) as my example
> code.
>
> BRs
> J.J. Wang
>
> In GNU Emacs 25.2.1 (x86_64-apple-darwin16.0.0, NS appkit-1504.00 Version
> 10.12 (Build 16A323))
> of 2017-04-03 built on e12714-mac01
> Windowing system distributor 'Apple', version 10.3.1504
> Configured using:
> 'configure --disable-dependency-tracking --disable-silent-rules
> --enable-locallisppath=/usr/local/share/emacs/site-lisp
> --infodir=/usr/local/Cellar/emacs/25.2-rc2/share/info/emacs
> --prefix=/usr/local/Cellar/emacs/25.2-rc2 --without-x --with-xml2
> --with-dbus --with-gnutls --with-imagemagick --with-rsvg --without-pop
> --with-ns --disable-ns-self-contained'
>
> Configured features:
> JPEG RSVG IMAGEMAGICK DBUS NOTIFY ACL GNUTLS LIBXML2 ZLIB
> TOOLKIT_SCROLL_BARS NS
>
> Important settings:
> value of $LC_CTYPE: en_US.UTF-8
> value of $LANG: en_US.UTF-8
> locale-coding-system: utf-8-unix
>
> Major mode: Org
>
> Minor modes in effect:
> diff-auto-refine-mode: t
> org-indent-mode: t
> helm-mode: t
> shell-dirtrack-mode: t
> async-bytecomp-package-mode: t
> yas-global-mode: t
> yas-minor-mode: t
> global-company-mode: t
> company-mode: t
> override-global-mode: t
> show-paren-mode: t
> tooltip-mode: t
> global-eldoc-mode: t
> electric-indent-mode: t
> mouse-wheel-mode: t
> file-name-shadow-mode: t
> global-font-lock-mode: t
> font-lock-mode: t
> blink-cursor-mode: t
> auto-composition-mode: t
> auto-encryption-mode: t
> auto-compression-mode: t
> line-number-mode: t
> auto-fill-function: yas--auto-fill
> transient-mark-mode: t
>
> Recent messages:
> Code block evaluation complete.
> Edebug: org-babel-result-cond
> org-babel-result-cond
> executing Elisp code block...
>
> (nodes (quote (("A" "B" 3) ("A" "C" 2) ("B" "D" 4) ("B" "E" 5) ("C" "F"
> 10
>
> Wrote
> /var/folders/r0/58rd7gbs3pz3gsj48zdv8pwn00n31m/T/babel-30327L5l/ob-input-30327wiQ
> Code block evaluation complete.
> Mark set [2 times]
> Quit
>
> Load-path shadows:
> ~/.emacs.d/modules/org-mode/lisp/ox hides
> /usr/local/Cellar/emacs/25.2-rc2/share/emacs/25.2/lisp/org/ox
> ~/.emacs.d/modules/org-mode/lisp/ox-texinfo hides
> /usr/local/Cellar/emacs/25.2-rc2/share/emacs/25.2/lisp/org/ox-texinfo
> ~/.emacs.d/modules/org-mode/lisp/ox-publish hides
> /usr/local/Cellar/emacs/25.2-rc2/share/emacs/25.2/lisp/org/ox-publish
> ~/.emacs.d/modules/org-mode/lisp/ox-org hides
> /usr/local/Cellar/emacs/25.2-rc2/share/emacs/25.2/lisp/org/ox-org
> ~/.emacs.d/modules/org-mode/lisp/ox-odt hides
> /usr/local/Cellar/emacs/25.2-rc2/share/emacs/25.2/lisp/org/ox-odt
> ~/.emacs.d/modules/org-mode/lisp/ox-md hides
> /usr/local/Cellar/emacs/25.2-rc2/share/emacs/25.2/lisp/org/ox-md
> ~/.emacs.d/modules/org-mode/lisp/ox-man hides
> /usr/local/Cellar/emacs/25.2-rc2/share/emacs/25.2/lisp/org/ox-man
> ~/.emacs.d/modules/org-mode/lisp/ox-latex hides
> /usr/local/Cellar/emacs/25.2-rc2/share/emacs/25.2/lisp/org/ox-latex
> ~/.emacs.d/modules/org-mode/lisp/ox-icalendar hides
> /usr/local/Cellar/emacs/25.2-rc2/share/emacs/25.2/lisp/org/ox-icalendar
> ~/.emacs.d/modules/org-mode/lisp/ox-html hides
> /usr/local/Cellar/emacs/25.2-rc2/share/emacs/25.2/lisp/org/ox-html
> ~/.emacs.d/modules/org-mode/lisp/ox-beamer hides
> /usr/local/Cellar/emacs/25.2-rc2/share/emacs/25.2/lisp/org/ox-beamer
> ~/.emacs.d/modules/org-mode/lisp/ox-ascii hides
> /usr/local/Cellar/emacs/25.2-rc2/share/emacs/25.2/lisp/org/ox-ascii
> ~/.emacs.d/modules/org-mode/lisp/org hides
> /usr/local/Cellar/emacs/25.2-rc2/share/emacs/25.2/lisp/org/org
> ~/.emacs.d/modules/org-mode/lisp/org-w3m hides
>
[O] bug#25473: 26.0.50; org-agenda tries to invoke insert-diary-entry, which does not exist
Kyle Meyer wrote: > 685d3ba4a (Replace obsolete aliases of calendar functions, 2014-11-15) > in the Org mode repo switched the commands over to the diary prefix. There is a clear problem if Org changes aren't being synced to Emacs for over 2 years.
[O] bug#25466: 25.1.91; hs-show-all broken
Andreas Röhler wrote: > With org-mode, hs-minor-mode: hs-show-all has no effect, but"Showing > all blocks ... done" is messaged. > > BTW M-x show-all RET works as expected. I don't think hideshow has ever done anything useful in Org mode, which is Outline-based. Perhaps you are asking for a new feature of some kind.
[O] bug#25132: 26.0.50; emacs hangs when loading org file with python source blocks
David Dynerman wrote: > The bug does NOT occur with org 8.2.10. Since that's the version included with Emacs, I'm confused as to why you've been encouraged to report this to bug-gnu-emacs.
[O] bug#19606: 24.4; Emacs hangs when editing a 5-line Org file
Eli Zaretskii wrote: > Yes, thanks. Unfortunately, it doesn't say more than the previous > backtrace: Emacs is displaying some display string with invisible > property. Why that would lead to an infloop, I don't see. > > My suggestion at this point would be to ask on the Org list whether > your Org-related setup that triggers this (somehow related to flyspell > mode) might be the problem. It could be that the infloop is actually > on the Lisp level in some code that is part of Org or your > customizations. > > Failing that, I suggest to try to present a minimal reproduction > recipe and post it here. Closing after 2 years with no further progress.
[O] bug#23890: 25.0.94; Org-mode Table does not copy time interval correctly
Eli Zaretskii wrote: > Thanks, but I think you should first report this to the Org > developers. Come back here if they say this is a problem in core > Emacs, not in Org code. You can just reassign the bug to org-mode, as I did. (Isn't it weird to have a component of Emacs for which we effectively don't accept bug reports?)
[O] bug#23725: 25.0.94; Org mode uses removed aliases to scroll the calendar
Kyle Meyer wrote: > Ari Roponen <ari.ropo...@gmail.com> writes: > >> Org mode uses aliases that were removed by this commit: >> >> commit 3f65970414538063e38ada2a47cb4ef4f35b630e >> Author: Glenn Morris <r...@gnu.org> >> Date: Sun Oct 5 19:02:04 2014 -0700 >> >> Remove calendar code obsolete since at least version 23.1 > > This was fixed in the upstream Org repo with 8b63dc9 (org.el: Fix > bindings of < and > for calendar scrolling, 2014-10-20), which is > included in version 8.3. But not included in the version included with Emacs. Please could someone port that fix to the emacs-25 branch. (If simple fixes don't get propagated for over a year, the system isn't working.)
[O] bug#21818: 24.5; org-set-tags-to indentation problems when called programmatically
Eli Zaretskii wrote: > Org mode has its own bug tracker, AFAIR. Nope, just a mailing list AFAIK. Assigning something to the debbugs org-mode package (which I already did for this report) sends stuff there.
[O] bug#19606: 24.4; Emacs hangs when editing a 5-line Org file
The alternative is to supply a minimum reproducible recipe starting with emacs -Q, then someone else can debug it. BTW, it's a nice gesture to provide screencasts, but I don't think anyone developing Emacs finds them particularly useful for debugging, so no need to keep providing those AFAICS.
[O] bug#19606: 24.4; Emacs hangs when editing a 5-line Org file
I just want to note that there seems to be a tendency to try and use gdb to debug Org problems, when debug-on-quit and ctrl-g might work.
[O] bug#18785: 24.4.1; Emacs hangs with Org mode when point is in LOGBOOK
Eli Zaretskii wrote: sp-show--pair-function (0x88f14c) [...] Maybe. This backtrace looks very different from the last one. It indeed appears to be from smartparens, which is not part of Emacs.
[O] bug#18785: 24.4.1; Emacs hangs with Org mode when point is in LOGBOOK
Just to mention the obvious thing; has anyone tried M-x toggle-debug-on-quit followed by ctrl-g?
[O] etc/ORG-NEWS not updated for one year
etc/ORG-NEWS in emacs-24 has not been updated for ~ one year. If you are going to update it, please do so before thie Friday.
[O] bug#18401: 24.4.50; emerge-files fails for org files
Detlev Zundel wrote: problem and lingers for a while now. Who can merge the org repository? Is there something that an outsider like me can do to help? Thanks for asking! :) Anyone with a copy of the Org repo and the Emacs repo can generate the diff that needs to be applied from the former to the latter. Anyone with write access to the Org repo can get write access to the Emacs repo and apply that diff. (This is a generalization, but I think it is true. E.g. I assume all people with Org write access have FSF assignments.) However, I think this is wasted effort, so I have suggested not doing it any more; http://lists.gnu.org/archive/html/emacs-devel/2014-08/msg00298.html .
[O] bug#18430: 24.4.50; org-mode: File mode specification error: (error `recenter'ing a window that does not display current-buffer.)
Leo Liu wrote: In a recent build of emacs trunk, I constantly getting this error whenever I open a .org file. Could this be fixed? Thanks, Leo See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18401#10
[O] bug#18401: 24.4.50; emerge-files fails for org files
Detlev Zundel wrote: org-overview: `recenter'ing a window that does not display current-buffer. This was apparently fixed in the Org repository months ago, but still not in the Emacs one. Ref: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17724#26 (We now have 4 separate Emacs reports for this.)
[O] bug#18104: 24.3.92.1; Infloop when capturing Org note
Experience shows that issues with Org are best reported to the Org list. I have reassigned the bug accordingly.
[O] bug#18104: 24.3.92.1; Infloop when capturing Org note
PS perhaps this is related to your earlier http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17651 Both seem to involve the cache.
Re: [O] Translations
Carlos Sosa wrote: Who do I send my notes to regarding Guía Compacta de Org Mode? The address was given in rms's initial message: http://lists.gnu.org/archive/html/emacs-devel/2014-07/msg00237.html David Arroyo Menéndez davi...@es.gnu.org has translated into Spanish two manuals pertaining to Emacs [...] Would some Spanish speakers like to check them for correctness and readability? Please write to him if you want to do this.
[O] bug#17724: 24.4.50; regression: error `recenter'ing a window that does not display current-buffer. when opening org-mode file
Eli Zaretskii wrote: Bastien, could you please look into this? This is like forwarding every Emacs bug to Stefan. I suggest instead reassigning the bug to org-mode (or emacs,org-mode), then simply posting a reply in the normal way. It will then go to the emacs-orgmode mailing list (which is where Org bugs are supposed to go). (I reassigned it before sending this reply.)
[O] bug#17651: 24.3.91; Emacs hangs in Org
Sebastien Vauban wrote: Emacs 24.3.91.1 (of 2014-05-12) regularly hangs with Org-mode version 8.2.6 (release_8.2.6-1010-g1ca86f). Well I guess this is an Org bug, which will get more attention on the Org list. (See eg http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17484)
[O] bug#17416: bug#17416: insecure temp files in ob-screen.el
Eric Schulte wrote: org-babel-screen-session-write-temp-file and org-babel-screen-test seem to use predictable temp-file names, which is a security issue. Using `make-temp-file', or if the file names really need to be predictable, something equivalent to `doc-view-make-safe-dir' (there should really be a general utility function for this IMO) to first create a /tmp subdirectory would avoid this. I just pushed up a fix for this issue. Thanks, If you mean http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=fea672d30ef4701721c0d4aa70462760a6b21be7 then's there still org-babel-screen-test. (These are definitely fixes that need merging into the emacs-24 branch. IIUC this means they need to be in your maint branch?)
[O] bug#17416: insecure temp files in ob-screen.el
Package: emacs,org-mode Version: 24.3.90 Severity: important Tags: security org-babel-screen-session-write-temp-file and org-babel-screen-test seem to use predictable temp-file names, which is a security issue. Using `make-temp-file', or if the file names really need to be predictable, something equivalent to `doc-view-make-safe-dir' (there should really be a general utility function for this IMO) to first create a /tmp subdirectory would avoid this.
[O] bug#16832: 24.3.50; Emacs hangs in Org mode file
Glenn Morris wrote: Perhaps this is fixed now, according to comments at: http://lists.gnu.org/archive/html/emacs-orgmode/2014-03/msg01176.html (It would be great if someone would keep an eye on these Org bugs that get reported to Emacs and update them when appropriate. Although it seems better to report Org bugs to the Org-mode list rather than to Emacs.) No comments in two weeks so closed, presumed fixed.
[O] bug#17055: 24.3.50; Emacs hangs in Org mode file
Perhaps this is fixed now, according to comments at: http://lists.gnu.org/archive/html/emacs-orgmode/2014-03/msg01176.html (It would be great if someone would keep an eye on these Org bugs that get reported to Emacs and update them when appropriate. Although it seems better to report Org bugs to the Org-mode list rather than to Emacs.)
[O] bug#16751: 24.3.50; Export during Org export to HTML
Eli Zaretskii wrote: file:path is a valid file link type in Org. Therefore, [...] But that's exactly the problem: producing a file name from a file:// URL requires to remove the file:// prefix. It is invalid to leave the 2 extra slashes and remove only file:. Why does Org do that? Presumably because Org decided to use file: rather than standard file:// URI, hence leading to exactly this confusion.
[O] bug#4249: CUA + shift-select-mode; org-mode and CUA
Version: 24.4 David Reitter wrote: CUA mode and shift-select-mode don't seem to be aware of each other. If I turn on CUA first, and then shift-select-mode, shifted selection fails (e.g. shift-right marks only one character as region). Emacs -Q (cua-mode 1) (setq shift-select-mode t) This is fixed in current trunk.
[O] bug#16734: Default value org-odt-data-dir (in Emacs) makes no sense
Package: emacs,org-mode Version: 24.3.50 This refers to the version of Org mode in Emacs trunk. ./src/emacs -Q -l ox-odt C-h v org-odt-data-dir - Its value is /usr/share/emacs/etc/org This value is hard-coded (and autoloaded; why?) in org-version.el. This value makes no sense. For Emacs, it should be something based on data-directory. This was pointed out before in some moderately lengthy discussion: http://lists.gnu.org/archive/html/emacs-devel/2012-10/msg2.html http://lists.gnu.org/archive/html/emacs-devel/2012-10/msg00070.html (In general, the setting of directory-related variables in ox-odt seems rather over-engineered.)
[O] bug#16270: Incorrect custom types
Bastien wrote: org-babel-lob-files Not sure what's wrong with the one above. Can you tell me? emacs -Q -l ob-lob M-x customize-variable RET org-babel-lob-files RET - State: STANDARD. (mismatch) The specification for a list custom object is as follows: `(list ELEMENT-TYPES...)' The value must be a list with exactly as many elements as the ELEMENT-TYPES given; and each element must fit the corresponding ELEMENT-TYPE. You cannot just write 'list. Perhaps you wanted '(repeat file). From the doc, it also sounds like this should have a :set function. BTW, the first line of org-babel-lob-ingest's doc is not a complete sentence.
[O] bug#16270: Incorrect custom types
Also, the following have no :type at all: org-babel-maxima-command org-texinfo-def-table-markup org-inlinetask-show-first-star
[O] bug#16270: Incorrect custom types
Package: org-mode This refers to the version of Org mode in Emacs trunk. The following variables have incorrect custom types: org-babel-latex-htlatex-packages ; prob. you want repeat, not list org-export-with-creator ; const should not be quoted org-babel-lob-files There are many other places where the argument of a const is quoted. This is probably not what you want. org-agenda.el: (choice (const :tag Day 'day) org-agenda.el: (const :tag Week 'week) org-agenda.el: (const :tag Fortnight 'fortnight) org-agenda.el: (const :tag Month 'month) org-agenda.el: (const :tag Year 'year) org-agenda.el: (list :tag Regexp matches :inline t (const :format 'regexp) (regexp)) org-agenda.el: (list :tag Regexp does not match :inline t (const :format 'notregexp) (regexp)) org-agenda.el:(const 'todo) org-agenda.el: (const :tag any not-done state 'todo) org-agenda.el: (const :tag any done state 'done) org-agenda.el: (const :tag any state 'any) org-agenda.el:(const 'nottodo) org-agenda.el: (const :tag any not-done state 'todo) org-agenda.el: (const :tag any done state 'done) org-agenda.el: (const :tag any state 'any) org-agenda.el: (const :tag scheduled 'scheduled) org-agenda.el: (const :tag not scheduled 'notscheduled) org-agenda.el: (const :tag deadline 'deadline) org-agenda.el: (const :tag no deadline 'notdeadline) org-agenda.el: (const :tag timestamp 'timestamp) org-agenda.el: (const :tag no timestamp 'nottimestamp)) org-agenda.el: (const :tag Show only log items 'only) org-agenda.el: (const :tag Show all possible log items 'clockcheck) org-agenda.el: (choice (const :tag Show closed log items 'closed) org-agenda.el: (const :tag Show clocked log items 'clock) org-agenda.el: (const :tag Show all logged state changes 'state) org-agenda.el:(const :tag Always show inherited tags 'always) org.el: (const :tag In active region, headlines at the same level than the first one 'start-level) org.el: (const :tag A double click follows the link 'double) org.el: (const :tag Yes, including all entries 'all-headlines) ox.el:(const :tag Sentence as a comment 'comment)
[O] bug#15888: 24.3.50; Eval-after-load eval'ed twice
Apparently this is fixed: http://lists.gnu.org/archive/html/emacs-orgmode/2013-11/msg00682.html Sadly the relevant messages were not sent to this tracker. In case people do not know: you can think of ###@debbugs as an alias to the bug-gnu-emacs@gnu list for bugs in package emacs, to emacs-orgmode@gnu for bugs in package org-mode, and to both lists for bugs in both packages. This is the whole reason why you see bug#123 messages appearing on your lists.
[O] bug#15888: 24.3.50; Eval-after-load eval'ed twice
Sebastien Vauban wrote: But I wonder: how can you now reproduce it (and not before)? Because I downloaded a snapshot of Org. Your problem is not with code that is in Emacs current trunk.
[O] bug#15887: Possibly incorrect custom :types
I glanced at the diff. I'm not sure the :set changes are correct. Won't this make it impossible to customize these options? Those cases may have been some of the false positives I mentioned. Eg (if (or (featurep 'xemacs) (featurep 'python-mode)) 'python-mode 'python) is fine for :type 'function, but cus-test is simple-minded and doesn't realize that the result of the expression will always be a function, so it gives a bogus warning.
[O] bug#15888: 24.3.50; Eval-after-load eval'ed twice
Sebastien Vauban wrote: Where is the black magic? Somewhere in the labyrinthine depths of Org, so I suggest you ask the Org maintainers to figure out why: emacs -Q -L /path/to/git/org-mode/lisp (with-eval-after-load org (message Eval this when Org is loaded) (sit-for 3) (message )) (require 'org) ends up loading org twice.
[O] bug#15888: 24.3.50; Eval-after-load eval'ed twice
It's nothing to do with eval-after-load. Same result with: emacs -Q -L /path/to/org/git/lisp \ --eval '(setq org-load-hook (lambda () (message LOADED) (sit-for 3) (message )))' Then (require 'org). It is some peculiarity of Org trunk.
[O] bug#15887: Possibly incorrect custom :types
Package: org-mode cus-test.el suggests the following variables may have incorrect custom :types. (There may be some false positives.) This refers to Org mode in current Emacs trunk. Eg, org-texinfo-filename does not have nil as an option. org-agenda-deadline-leaders org-agenda-search-view-max-outline-level org-ascii-format-drawer-function org-ascii-format-inlinetask-function org-babel-latex-htlatex org-babel-latex-htlatex-packages org-babel-lob-files org-babel-python-None-to org-babel-python-mode org-babel-ruby-nil-to org-export-async-init-file org-export-with-creator org-html-format-drawer-function org-html-format-headline-function org-html-format-inlinetask-function org-html-with-latex org-latex-format-drawer-function org-latex-format-inlinetask-function org-log-note-headings org-mouse-1-follows-link org-odt-format-drawer-function org-odt-format-headline-function org-odt-format-inlinetask-function org-odt-with-latex org-plantuml-jar-path org-texinfo-filename org-texinfo-format-drawer-function org-texinfo-format-headline-function org-texinfo-format-inlinetask-function orgstruct-heading-prefix-regexp
[O] bug#15080: Period in Texinfo node name in org.texi
Package: org-mode In org.texi in Emacs trunk, there is an Info node named org-crypt.el. Periods are not allowed in Texinfo node names, so please could you rename this to something else (sadly makeinfo does not warn about such things). (You might also want to let Texinfo figure out all the node pointers automatically, ie everywhere replace @node Name, Prev, Next, Up with just @node Name This makes it much easier to rename nodes.)
[O] bug#14975: 24.3; org-mode's `org-clock-notify-once-if-expired' doesn't respect `org-clock-sound'
Bastien wrote: Please send those patches to the org-mode list first. PS: Maybe it's just me and I did not see the initial bug report on this list -- ignore the heads up if that's so! If by this list you mean the org-mode list: It was initially reported to bug-gnu-emacs. Then I assigned it to the emacs,org-mode package, so that subsequent emails went to the org-mode list as well as the bug-gnu-emacs list. This would have happened with the initial report if it had specified a Package: emacs,org-mode line. (Though there seems no point in having emacs in there really.)
[O] bug#14975: 24.3; org-mode's `org-clock-notify-once-if-expired' doesn't respect `org-clock-sound'
Bastien wrote: It was initially reported to bug-gnu-emacs. Then I assigned it to the emacs,org-mode package, so that subsequent emails went to the org-mode list as well as the bug-gnu-emacs list. This would have happened with the initial report if it had specified a Package: emacs,org-mode line. (Though there seems no point in having emacs in there really.) Thanks for the explanations. This is what I expected, but I don't find the bug in the org-mode mailing list. That's what I'm saying. It was sent to bug-gnu-emacs ONLY. Because that list is coupled to debbugs.gnu.org, and because I reassigned the bug after it was received, subsequent replies went to both lists. But the initial report is only on bug-gnu-emacs.
[O] bug#14586: 23.3; void-variable calendar-view-diary-initially-flag
Version: 24.1 Mike Kupfer wrote: 1. visit an org-mode file. 2. insert a date (C-c ! RET) 3. M-x calendar RET This gives me (from *Messages*): calendar: Symbol's value as variable is void: calendar-view-diary-initially-flag [...] This is with the stock Emacs that comes with Ubuntu 12.04. In GNU Emacs 23.3.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.10) Thanks for the report. This was fixed in Emacs 24.1. Please upgrade (latest is 24.3) and/or encourage your distribution to do so. You can work around the problem by simply using (require 'calendar) before using Org.
[O] bug#14379: Several Org source files cannot be loaded in isolation
(Please keep the debbugs address included. It is basically an alias for the org-mode list in this instance.) Achim Gratz wrote: Reimplementation with pcase should fix that unless this is then resolved at compile-time? pcase probably doesn't exist in all the ancient Emacs versions that you want to support? In any case, it will case cause needless loading of pcase at run-time. I'd use good old `cond' if I were you. Actually, `if' will suffice in this case. Actually actually, why not (if (executable-find ctags-exuberant) ctags-exuberant ctags) ?
[O] bug#14379: Several Org source files cannot be loaded in isolation
Package: org-mode (This report refers to the version of Org in the Emacs trunk.) Several Org files cannot be loaded in isolation, by which I mean that eg emacs -batch -l ob-C fails. This may have no practical consequences, but seems like bad form (eg it causes problems for automated testing). The list is: ob-C.el ob-asymptote.el ob-awk.el ob-clojure.el ob-fortran.el ob-haskell.el ob-io.el ob-java.el ob-latex.el ob-lisp.el ob-maxima.el ob-ocaml.el ob-perl.el ob-picolisp.el ob-python.el ob-ruby.el ob-scala.el org-ctags.el For all but the last, the problem is: Symbol's value as variable is void: org-babel-tangle-lang-exts For org-ctags, the problem is: Symbol's function definition is void: case (because the `case' macro from cl is used in the default value of a defcustom, which is not evaluated till load time.). This one is probably a real bug.
[O] bug#14374: bug#14374: Possibly incorrect custom :types
Carsten Dominik wrote: I would like to leave things in Emacs as they are and fix this with the following sync, is that acceptable? Sure, no rush. (cus-test.el is in the admin/ directory in the Emacs repo. It needs some updating, it's not checking everything at present, so there could be more of these. I will send them along if I find them.)
[O] bug#14374: Possibly incorrect custom :types
Package: org-mode cus-test.el suggests the following variables may have incorrect custom :types. (There may be some false positives.) This refers to Org mode in current Emacs trunk. Eg, org-footnote-auto-adjust does not have nil as an option. org-refile-target-verify-function org-icalendar-combined-description org-link-frame-setup org-export-with-archived-trees org-bibtex-prefix org-log-note-headings org-structure-template-alist org-export-html-postamble-format org-get-priority-function org-export-odt-content-template-file org-export-latex-quotes org-export-html-toplevel-hlevel org-agenda-ndays org-export-initial-scope org-plantuml-jar-path org-export-blocks-witheld org-make-link-description-function org-export-html-postamble org-babel-lob-files org-agenda-export-html-style org-clock-heading-function org-show-notification-handler org-agenda-custom-commands org-beamer-outline-frame-options org-agenda-day-face-function org-use-fast-tag-selection org-export-docbook-xsl-fo-proc-command org-link-translation-function org-export-docbook-xslt-stylesheet org-export-docbook-xslt-proc-command org-columns-modify-value-for-display-function org-export-html-preamble-format org-agenda-auto-exclude-function org-export-docbook-doctype org-wl-namazu-default-index org-agenda-inactive-leader org-export-ascii-underline org-sparse-tree-default-date-type org-footnote-auto-adjust org-protocol-default-template-key
Re: [O] org-export raises stringp nil error
Assuming this is a recent regression, then if anyone from Org wants this fixed in Emacs 24.3, they should investigate this very quickly and suggest the _minimum_ change. See also the possibly related, unanswered http://lists.gnu.org/archive/html/emacs-orgmode/2013-03/msg00028.html Lele Gaifax wrote: Using current emacs-snapshot[1], trying to export even the following very simple file: # -*- mode: org; coding: utf-8 -*- * hi http://www.gnu.org/ to HTML results in this error: org-export-protect-sub-super: Wrong type argument: stringp, nil with the following traceback: string-match(\\([^]\\)\\([_^]\\) nil) org-export-protect-sub-super(nil) org-export-normalize-links() org-export-preprocess-string(#(# -*- mode: org; coding: utf-8 -*-\n\n* hi\n\n http://www.gnu.org/\n; 0 34 (fontified t font-lock-fontified t face font-lock-comment-face) 34 36 (fontified t) 36 38 (fontified t face org-level-1) 38 40 (fontified t face org-level-1) 40 44 (fontified t) 44 62 (fontified t org-no-flyspell t mouse-face highlight face org-link keymap (keymap (follow-link . mouse-face) (mouse-3 . org-find-file-at-mouse) (mouse-2 . org-open-at-mouse))) 62 63 (fontified t org-no-flyspell t mouse-face highlight face org-link keymap (keymap (follow-link . mouse-face) (mouse-3 . org-find-file-at-mouse) (mouse-2 . org-open-at-mouse)) rear-nonsticky (mouse-face highlight keymap invisible intangible help-echo org-linked-text htmlize-link)) 63 64 (fontified t)) :emph-multiline t :for-backend html :skip-before-1st-heading nil :drawers nil :todo-keywords t :tasks t :tags not-in-toc :priority nil :footnotes t :timestamps t :archived-trees headline :select-tags (export) :exclude-tags (noexport) :add-text nil :LaTeX-fragments t) org-export-as-html(nil) call-interactively(org-export-as-html) org-export(nil) call-interactively(org-export nil nil) command-execute(org-export) If this isn't already known/fixed, should I report it as a bug? And eventually, on Emacs itself or on org-mode? thanks in advance, bye, lele. [1] GNU Emacs 24.3.50.1 (x86_64-pc-linux-gnu, GTK+ Version 3.4.2) of 2013-03-04 on dex, modified by Debian
Re: [O] org-export raises stringp nil error
Bastien wrote: Glenn Morris r...@gnu.org writes: Assuming this is a recent regression, then if anyone from Org wants this fixed in Emacs 24.3, they should investigate this very quickly and suggest the _minimum_ change. The minimal fix is attached. The other attachment is the full patch I wanted to apply to merge Org 7.9.4 into Emacs 24.3. The changes are all safe bugfixes. I assumed it was okay to fix bugs after the last pretest, is it so? No, it is not ok, and I don't know why you would think it is. Release candidate means this IS the release unless something CRITICAL occurs. I hoped my various posts to this list had made this clear. It's also been the traditional policy of at least the more recent Emacs releases as far as I know. I should have been stricter in insisting that Org follow the same policy as everybody else during pretesting, in only installing regression bug fixes. I'm pretty sure this has not been happening, given the size and nature of the changes that keep landing. The reason for this policy is (obviously) to prevent inadvertently introducing mistakes. This seems to be exactly what has bitten us in this case, where your patch just reverts the change from http://lists.gnu.org/archive/html/emacs-diffs/2013-02/msg00058.html Was that fixing a regression? I doubt it. Please apply the first patch as soon as possible. The second includes stuff like deleting comments, declaring functions, and changing autoload for org-autoload. No, you may not apply this. If there were any fixes in there for important regression bugs against Emacs 24.2, please make a separate patch with just those items.
[O] bug#10125: RFE: require and load-path-shadowing
Stefan Monnier wrote: IOW, do you expect the byte-compile instances to be different in any way from a fresh Emacs session invoked from the shell as emacs -Q? Yes, because the current Emacs may be a different executable than the one the shell would run in response to emacs -Q. http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10125#50 Turns out I was looking for invocation-directory and invocation-name. If you want to worry about wacky things like a new Emacs having been installed on top of the old in the meantime, more power to you.
[O] bug#13254: org-odt: Batch exports creates data loss, deletes original org file
Please can we have the relevant patch installed in emacs-24.
[O] bug#12702: 24.2; Orgmode Refile complains Not bookmark format
Jonathan Schaeffer wrote: Maybe Glenn could tell how he was able to corrupt his bookmarks file ? I intentionally added junk to it.
[O] bug#12702: 24.2; Orgmode Refile complains Not bookmark format
Jonathan Schaeffer wrote: (I made a reply all, is that alright ?) Yes, that's the right thing to do. with emacs -Q, I can not reproduce the bug. But refile does not work at all, (Complains : wrong type argument arrayp,nil). I do : 1. emacs -Q 2. C-x C-f refiletest.org 3. Fill the buffer with : * Entry One * Entry Two ** Refile Me 4. Hit C-c C-w 5. The entry is duplicated and I can read the error message Not bookmark format) Sorry, this works fine for me with Emacs 24.2. Maybe someone who actually uses Org will step in and help... If, instead of visiting a file, I open just a new buffer with C-x b test.org, the behaviour is different : On refile (C-c C-w) nothing happens but the error message shows: wrong type argument: arrayp, nil This doesn't make sense to me; because just doing `C-x b test.org' creates a buffer in fundamental mode, where C-c C-w is not bound to any key. It seems like your Emacs must be customized in some way, even with `emacs -Q'... I hope this helps. I have the archlinux build of emacs, so maybe the error is on the packaging side ?
[O] bug#12702: 24.2; Orgmode Refile complains Not bookmark format
Bastien wrote: You can also try reporting your problem to the emacs-orgmode mailing list: https://lists.gnu.org/mailman/listinfo/emacs-orgmode It's already there, since I reassigned this bug. http://lists.gnu.org/archive/html/emacs-orgmode/2012-10/msg00563.html
[O] bug#12702: 24.2; Orgmode Refile complains Not bookmark format
Jonathan Schaeffer wrote: Sorry, I missed a step : I manualy load the org-mode mode (Alt-x org-mode) before doing anything in the buffer. This might be an orgmode bug, from what I read on the internet. I can reproduce that in Emacs 24.2 and current trunk. Debugger entered--Lisp error: (wrong-type-argument arrayp nil) file-truename(nil) find-buffer-visiting(nil) org-refile-check-position((#(Entry One 0 9 (face org-level-1 fontified t)) org-refile-get-location(Refile subtree \Refile Me\ to nil nil nil) org-refile(nil) call-interactively(org-refile nil nil) org-refile-check-position does not handle being called from a buffer not visiting a file. (Still no idea about the original issue.)
[O] bug#12702: 24.2; Orgmode Refile complains Not bookmark format
Jonathan Schaeffer wrote: To reproduce : Create a .org file, create 2 level-1 entries. Create one level-2 entry and hit C-c C-w to refile it into the other level-1 entry. Like this : * Entry One * Entry Two ** Refile Me The level-2 entry is copied in the correct location but is not removed from original location. Minibuffer shows message Not Bookmark Format. And the file looks like : * Entry One ** Refile Me * Entry Two ** Refile Me I found a way to reproduce this: have a corrupt bookmarks file. Check the contents of your bookmark-default-file. Try (re)moving it. Perhaps Org could trap and report such errors more gracefully.
[O] bug#12702: 24.2; Orgmode Refile complains Not bookmark format
Jonathan Schaeffer wrote: To reproduce : Create a .org file, create 2 level-1 entries. Create one level-2 entry and hit C-c C-w to refile it into the other level-1 entry. Like this : * Entry One * Entry Two ** Refile Me The level-2 entry is copied in the correct location but is not removed from original location. Minibuffer shows message Not Bookmark Format. And the file looks like : Thanks for the report, but it works fine for me with Emacs 24.2. Can you give a complete recipe starting from emacs -Q?
[O] bug#11491: 24.0.96 instead of 23.0.96
Albert wrote: The version string has an typo in the original report. I guess it is better to send it again with the correct version in the subject. Should/Can I close this bug-report? No, please don't close/resend it for such a reason. I doubt anyone cares about the title, but I will retitle it.
[O] bug#9809: 24.0.90; flyspell-auto-correct-word hard to access in org-mode
Eric Hanchrow wrote: I started emacs with emacs -Q. Then I typed M-x o r g - m o d e return M-x f l y s p e l l - m o d e return C-h c M-tab C-h c M-TAB C-h c M-tab showed me M-tab runs the command pcomplete. C-h c M-TAB (which I typed via Ctrl+Alt+i) showed me M-TAB runs the command flyspell-auto-correct-word. I expected _both_ key events -- M-tab and M-TAB -- to show me flyspell-auto-correct-word. This occurs because org.el for some reason tries to define the M-TAB key 3 different ways: (org-defkey org-mode-map [(meta tab)] 'pcomplete) (org-defkey org-mode-map \M-\t 'pcomplete) (org-defkey org-mode-map \M-\C-i 'pcomplete) Removing all but the second definition would fix this. Ref Named ASCII Control Characters in the lispref. If you do not want to distinguish between (for example) TAB and `C-i', make just one binding, for the ASCII character TAB (octal code 011). If you do want to distinguish, make one binding for this ASCII character, and another for the function key `tab'.
[O] bug#9695: allowed date range
Version: 24.1 Seems to have been fixed, but this bug was never closed, nor included on the discussion. Ref thread http://lists.gnu.org/archive/html/emacs-orgmode/2011-10/msg00439.html
Re: [O] Defcustoms new in Emacs 24.1 missing :version tags
Bastien wrote (on Mon, 13 Feb 2012 at 16:25 +0100): I added the version tags in git: http://orgmode.org/w/?p=org-mode.git;a=commit;h=04971de4b9321becfc2f6f1d0fc78f53726abcc6 Thanks, but if it does not get merged to the Emacs repository before 24.1 is released it won't be too useful.
[O] Defcustoms new in Emacs 24.1 missing :version tags
The following defcustoms seem to be new in Emacs 24.1 (compared to 23.4) but do not have :version tags, so maybe you want to add them. Some of these could be false alarms; eg if a variable was just renamed, or if the containing defgroup has a :version tag ob-ditaa.el: org-ditaa-jar-option org-faces.el: org-faces-easy-properties org-faces.el: org-fontify-quote-and-verse-blocks org-faces.el: org-cycle-level-faces org-ascii.el: org-export-ascii-table-widen-columns org-latex.el: org-export-latex-inputenc-alist org-latex.el: org-export-latex-tag-markup org-latex.el: org-export-latex-timestamp-inactive-markup org-latex.el: org-export-latex-href-format org-latex.el: org-export-latex-hyperref-format org-latex.el: org-export-latex-footnote-separator org-latex.el: org-export-latex-quotes org-latex.el: org-export-latex-table-caption-above org-latex.el: org-export-latex-listings-w-names org-latex.el: org-export-latex-minted-langs org-latex.el: org-export-latex-listings-options org-latex.el: org-export-latex-minted-options org-latex.el: org-latex-default-figure-position org-latex.el: org-export-latex-tabular-environment org-latex.el: org-export-pdf-logfiles org-agenda.el: org-agenda-persistent-filter org-agenda.el: org-agenda-skip-function-global org-agenda.el: org-agenda-todo-ignore-timestamp org-agenda.el: org-agenda-skip-deadline-prewarning-if-scheduled org-agenda.el: org-agenda-menu-show-matcher org-agenda.el: org-agenda-menu-two-column org-agenda.el: org-agenda-follow-indirect org-agenda.el: org-agenda-time-leading-zero org-agenda.el: org-agenda-timegrid-use-ampm org-agenda.el: org-agenda-move-date-from-past-immediately-to-today org-agenda.el: org-agenda-include-deadlines org-agenda.el: org-agenda-clock-consistency-checks org-agenda.el: org-agenda-search-view-always-boolean org-agenda.el: org-agenda-search-view-force-full-words org-agenda.el: org-agenda-show-current-time-in-grid org-agenda.el: org-agenda-current-time-string org-agenda.el: org-agenda-inactive-leader org-agenda.el: org-agenda-remove-timeranges-from-blocks org-agenda.el: org-agenda-day-face-function org-agenda.el: org-agenda-category-icon-alist org-agenda.el: org-agenda-bulk-custom-functions org-agenda.el: org-agenda-insert-diary-extract-time org-capture.el: org-capture-templates org-capture.el: org-capture-before-finalize-hook org-capture.el: org-capture-after-finalize-hook org-attach.el: org-attach-store-link-p ob-lisp.el: org-babel-lisp-dir-fmt ob-scheme.el: org-babel-scheme-cmd org-inlinetask.el: org-inlinetask-default-state org-crypt.el: org-crypt-disable-auto-save org-gnus.el: org-gnus-nnimap-query-article-no-from-file ob-tangle.el: org-babel-tangle-lang-exts ob-tangle.el: org-babel-post-tangle-hook ob-tangle.el: org-babel-pre-tangle-hook ob-tangle.el: org-babel-tangle-body-hook ob-tangle.el: org-babel-tangle-comment-format-beg ob-tangle.el: org-babel-tangle-comment-format-end ob-tangle.el: org-babel-process-comment-text ob.el: org-confirm-babel-evaluate ob.el: org-babel-no-eval-on-ctrl-c-ctrl-c org-entities.el: org-entities-ascii-explanatory org-entities.el: org-entities-user org-docbook.el: org-export-docbook-footnote-separator org-docbook.el: org-export-docbook-xslt-stylesheet ob-js.el: org-babel-js-cmd ob-sh.el: org-babel-sh-var-quote-fmt org-publish.el: org-publish-sitemap-sort-files org-publish.el: org-publish-sitemap-sort-folders org-publish.el: org-publish-sitemap-sort-ignore-case org-publish.el: org-publish-sitemap-date-format org-publish.el: org-publish-sitemap-file-entry-format org-table.el: org-table-exit-follow-field-mode-when-leaving-table org-table.el: org-table-fix-formulas-confirm org-table.el: org-table-duration-custom-format org-table.el: org-table-formula-field-format org-exp-blocks.el: org-export-blocks-postblock-hook org-src.el: org-src-tab-acts-natively org-icalendar.el: org-icalendar-alarm-time org-icalendar.el: org-icalendar-combined-description org-icalendar.el: org-icalendar-honor-noexport-tag org-icalendar.el: org-icalendar-date-time-format org-odt.el: org-export-odt-schema-dir org-odt.el: org-export-odt-content-template-file org-odt.el: org-export-odt-styles-file org-odt.el: org-export-odt-inline-image-extensions org-odt.el: org-export-odt-pixels-per-inch org-odt.el: org-export-odt-create-custom-styles-for-srcblocks org-odt.el: org-export-odt-preferred-output-format org-odt.el: org-export-odt-table-styles org-odt.el: org-export-odt-fontify-srcblocks org-odt.el: org-export-odt-prettify-xml org-odt.el: org-export-odt-convert-processes org-odt.el: org-export-odt-convert-process org-odt.el: org-export-odt-convert-capabilities ob-picolisp.el: org-babel-picolisp-cmd org-list.el: org-alphabetical-lists org-list.el: org-list-ending-method org-list.el: org-list-end-regexp org-list.el: org-list-automatic-rules org-list.el: org-list-use-circular-motion org-list.el: org-list-indent-offset org-habit.el: org-habit-today-glyph org-habit.el: org-habit-completed-glyph org-lparse.el: org-lparse-use-flashy-warning org-lparse.el:
[O] bug#10767: 24.0.93; Customize does not set org-blank-before-new-entry
This is the same issue as http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10745
[O] bug#9584: (void-variable outline-regexp) when visiting article
Lars Magne Ingebrigtsen wrote: Debugger entered--Lisp error: (void-variable outline-regexp) outline-mode() org-mode() This seems like an org-mode bug. Perhaps it needs to require outline-mode? It does, so it is very hard to see how this error could occur.
[O] bug#9584: (void-variable outline-regexp) when visiting article
Lars Ingebrigtsen wrote: Perhaps something had bound outline-regexp while loading stuff earlier, leaving the variable unbound? I bet you are right.
[O] bug#10745: 24.0.93; Regression: org-meta-return does not honor vertical spacing in lists
Steve Revilak wrote: Perhaps the value of org-blank-before-new-entry is getting clobbered? For a start, this: org-footnote.el:(defvar org-blank-before-new-entry nil) ; silence byte-compiler is bogus (the relevant syntax is (defvar foo)). Probably so are these: org-footnote.el:(defvar org-export-footnotes-seen nil) ; silence byte-compiler org-footnote.el:(defvar org-export-footnotes-data nil) ; silence byte-compiler
[O] bug#9913: 24.0.91; ELPA: OpenDocument Text exporter for Org
In light of the following, can this be closed? http://lists.gnu.org/archive/html/emacs-orgmode/2011-12/msg00155.html Subject: The Org-ODT exporter is now in Org's core (latest git)
[O] bug#10125: 24.0.91; package.el (org): Macros in tar packages order of byte compilation
Chong Yidong wrote: This uses the Emacs executable on the exec path, which might not be the correct one. Yes; I wondered if (car command-line-args) was a reliable way to find the actual name of the running Emacs binary?
[O] bug#10125: 24.0.91; package.el (org): Macros in tar packages order of byte compilation
Eli Zaretskii wrote: I think package.el should test with featurep whether a version of a package is already loaded, and refuse to load it into a running session, or at least display a warning to that effect, suggesting to restart Emacs. Yes, that might be better.
[O] bug#10125: 24.0.91; package.el (org): Macros in tar packages order of byte compilation
Glenn Morris wrote: This uses the Emacs executable on the exec path, which might not be the correct one. Yes; I wondered if (car command-line-args) was a reliable way to find the actual name of the running Emacs binary? Turns out I was looking for invocation-directory and invocation-name.
[O] bug#10125: 24.0.91; package.el (org): Macros in tar packages order of byte compilation
Stefan Monnier wrote: E.g. we could add to bytecomp.el the ability to force `require' to reload a package if it's not already loaded from the file that locate-library returns. That will probably work fine most of the time, but what if a package is restructed so that the feature names are different? Or a feature is removed? Simply starting a fresh Emacs seems fine to me. Though there is the issue of should it be a `-Q' one or not. BTW, I was also thinking that rather than simply byte-recompiling, package.el ought to check for a Makefile in the package directory, and if it finds one, call make to build the package according to the rules the package has defined. Though you would have to trust the package not to do anything nasty.
[O] bug#10125: 24.0.91; package.el (org): Macros in tar packages order of byte compilation
Glenn Morris wrote: the package has defined. Though you would have to trust the package not to do anything nasty. Of course, you already have to trust it since byte-compiling can run arbitrary code.
[O] bug#10125: 24.0.91; package.el (org): Macros in tar packages order of byte compilation
Jambunathan K wrote: When compiling with package manager, the compilation happens from within a running Emacs session and very likely the old Org files are already loaded in to the runtime inadvertently by the user either by looking at the org agenda for the day or may be by just viewing an Org file or by the plain old (require 'org-whatever) out of habit in .emacs. There's your problem. The only way to reliably compile, especially something where an old version might already be loaded, is to use a fresh Emacs instance. There's no reason the package manager could not spawn a separate Emacs in batch-mode as a sub-job to do the compilation. cc-mode tries to have some voodoo to get around this, but please, please don't go down that road. I guess nobody ever expected the package manager to be used to load a different version of something that was already in Emacs.
[O] bug#10125: 24.0.91; package.el (org): Macros in tar packages order of byte compilation
Glenn Morris wrote: fresh Emacs instance. There's no reason the package manager could not spawn a separate Emacs in batch-mode as a sub-job to do the compilation. Very lightly tested version: *** lisp/emacs-lisp/package.el 2011-11-20 03:48:53 + --- lisp/emacs-lisp/package.el 2011-11-24 19:48:49 + *** *** 595,600 --- 595,612 (error Package does not untar cleanly into directory %s/ dir (tar-untar-buffer)) + (defun package-compile (directory) + Compile the Lisp files in DIRECTORY. + (with-current-buffer (get-buffer-create *package-compile*) + (goto-char (point-max)) + (pop-to-buffer (current-buffer)) + (or (zerop (call-process emacs nil t t --batch --eval +(format + (progn (setq load-path (cons \%s\ load-path)) + (batch-byte-recompile-directory 0)) directory) +directory)) + (error Compiling the package gave an error + (defun package-unpack (name version) (let* ((dirname (concat (symbol-name name) - version)) (pkg-dir (expand-file-name dirname package-user-dir))) *** *** 603,610 (let* ((default-directory (file-name-as-directory package-user-dir))) (package-untar-buffer dirname) (package-generate-autoloads (symbol-name name) pkg-dir) ! (let ((load-path (cons pkg-dir load-path))) ! (byte-recompile-directory pkg-dir 0 t) (defun package--write-file-no-coding (file-name) (let ((buffer-file-coding-system 'no-conversion)) --- 615,621 (let* ((default-directory (file-name-as-directory package-user-dir))) (package-untar-buffer dirname) (package-generate-autoloads (symbol-name name) pkg-dir) ! (package-compile pkg-dir (defun package--write-file-no-coding (file-name) (let ((buffer-file-coding-system 'no-conversion)) *** *** 645,652 pkg-file nil nil nil 'excl)) (package-generate-autoloads file-name pkg-dir) ! (let ((load-path (cons pkg-dir load-path))) ! (byte-recompile-directory pkg-dir 0 t) (defmacro package--with-work-buffer (location file rest body) Run BODY in a buffer containing the contents of FILE at LOCATION. --- 656,662 pkg-file nil nil nil 'excl)) (package-generate-autoloads file-name pkg-dir) ! (package-compile pkg-dir (defmacro package--with-work-buffer (location file rest body) Run BODY in a buffer containing the contents of FILE at LOCATION.
[O] bug#10125: 24.0.91; package.el (org): Macros in tar packages order of byte compilation
Stelian Iancu wrote: I am sorry to be asking a stupid question, but then, wouldn't restart Emacs fix the issue and have the new compiled org files loaded? No, because the files get compiled with a mix of old and new code loaded, so the compiled files are probably messed up. Restarting Emacs would not help with that. (You'll definitely need to restart Emacs if you had one version of Org loaded and want to switch to another.)
[O] bug#9913: 24.0.91; ELPA: OpenDocument Text exporter for Org
Jambunathan K wrote: I would like to submit my OpenDocument Text exporter for Org to GNU ELPA. Org is already in GNU ELPA (with daily snapshots IIUC), so if your package is accepted into Org it will automatically be in GNU ELPA.
[O] Org-mode bugs reported to Emacs
Hello Org-mode, There are some Org-mode bugs at http://debbugs.gnu.org/org-mode that were reported to Emacs. Maybe someone could take a look at them. Thanks.
[O] bug#9180: 24.0.50; Org-agenda window splitting does not use full frame when fraction set to 1.0
This report is a literal duplicate of http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9179 and will be deleted soon. Please direct any future correspondence on this issue to 9179@debbugs.
[O] bug#3597: 23.0.94; [PATCH] org-store-link broken within kbd macros
Version: 23.2 Looks like this patch was in 23.2.
[Orgmode] bug#7459: 23.2; Salutation should not actually be included in bug mails
Robin Green wrote: I didn't intentionally defeat it. I use wanderlust - that's probably why. Definitely - only the built-in mail clients are supported. Maybe you could propose a patch for report-emacs-bug. This is the relevant section: (cond ((memq mail-user-agent '(message-user-agent gnus-user-agent)) (setq report-emacs-bug-send-command message-send-and-exit report-emacs-bug-send-hook 'message-send-hook)) ((eq mail-user-agent 'sendmail-user-agent) (setq report-emacs-bug-send-command mail-send-and-exit report-emacs-bug-send-hook 'mail-send-hook)) ((eq mail-user-agent 'mh-e-user-agent) (setq report-emacs-bug-send-command mh-send-letter report-emacs-bug-send-hook 'mh-before-send-letter-hook))) Though I'm not actually sure whether it would be appropriate and/or worth it to handle other mail clients here. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] bug#7459: 23.2; Salutation should not actually be included in bug mails
Robin Green wrote: This bug report will be sent to the Free Software Foundation, not to your local site managers! Please write in English if possible, because the Emacs maintainers usually do not have translators to read other languages for them. [...] I submitted a bug report using M-x org-submit-bug-report. The so-called salutation of a bug report sent via reporter-submit-bug-report is - in this case - not useful to those who read the email - it is only intended to be read by the person *writing* the email. So, it should not be included in the email. Are you asking for the addition of a general, optional feature to reporter.el, or asking specifically about Org mode? (Presumably the former else you would have used... M-x org-submit-bug-report.) Either way, it is a very low priority request. M-x report-emacs-bug has supposedly had this feature for a long time, yet people often defeat it somehow (as you did in this report). It's never seemed very important. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
