Thanks, Nick. Here are the details. Emacs version 24.2.1 on Debian Wheezy (with emacs24 from Sid) Org org-plus-contrib-20130114 I started emacs with the min org file as explained in Section 1.4 C-U M
I got the same thing, so it's probably not a setup problem. Here's a backtrace - looks like a babel problem. Nick Org-mode version 7.8.03 (release_7.8.03.241.g043d) GNU Emacs 24.0.92.1 (x86_64-unknow
Hi Matt, Hi Carsten, The word/regexp agenda search to work with more than one word or regexp unless the first word or regexp is also preceded by a "+" or "-". I've investigated this further and beg y
Hello, I have some questions concerning the search function in org-mode: (1) I have several files in listed in the variable /org-agenda-text-search-extra-files/. At lease one file is definitely not s
So, I found a hang in org-link-search... (In what I think is an Emacs bug, but posting this here certainly can't hurt.) When you have a headline with a tag (For example "Mawile" with ":something:" as
Hello everybody, Org-mode version 7.8.11 (c8acf8d6957 @ GNU Emacs 24.1.1 (i386-mingw-nt6.1.7601) of 2012-06-10 on MARVIN while killing/yanking text from text files to my org file I found this limitat
Nicolas: This example demonstrates the problem caused when `org-capture` damages the line numbers in the `org-agenda-files`, making it impossible to go to the bottom of the buffer with (goto-char (po
Thanks Nicolas. Yes, it now works with multi-line searches that do not contain blank lines. I think there are some instances in which one might want to search across blank lines, such as when one cap
As far as I know, this is a limitation of the mailing list software. It affects all GNU-hosted lists, not just the Org list, so you should probably talk to the FSF list admins.
The search box gets results that have nothing to do with the search terms I entered. hesiii said the same thing on https://www.reddit.com/r/orgmode/comments/69omn5/how_to_search_mailing_list_archive
The problem, I think, is the regexp construction in org-link-search. This was introduced back in August of 2015 with commit cfe5bc97f8b18ccbf49d0764746c7563ce8d29da. The problematic line in org.el is
Following links fails to locate the appropriate location in text files if the search string in the link contains new lines. Steps to reproduce: /usr/bin/emacs -Q ~/config/minimal.el where minimal.el
Can somebody please update http://orgmode.org/community.html so that the ML search is using the GNU server? -- mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode: https://github.com/
Thanks for your patches. They look good. I applied them with very minor tweaks, explained below. "Fix" needs to be capitalized. Emacs uses American spelling: "behavior". No full stop at the end of th
Yes, the issue has indeed been resolved in the latest version of Emacs Trunk that I built today. I used my example to conduct the test, and it works now with `cache-long-scans` enabled. Great job --
Unlikely to happen. I think I fixed this in trunk revision 115826, please try the latest version of the code. (I only verified that the simplified test case works after the fix.) Thanks.
Nicolas: Yes, `(setq-default cache-long-scans nil)` does indeed fix the problem. In a version of Emacs Trunk built on October 5, 2013, the default value for `cache-long-scans` is `nil`. In the recent
Le 28/12/2013 21:44, Keith David Bershatsky a écrit : Thanks for the recipe, I can indeed reproduce problems, but they are different from what you describe. I suspect they are tied, but I'm not sure