Re: [O] Tag completion for ":a_tag:" fails if string "a_tag:" is in headline
Hello, alain.coch...@unistra.fr writes: > Specifically, I have the simple org file: > > * a header :foo: > * blah foo: blah :f > > If, after typing the last 'f' above, I type 'M-x pcomplete', I get the > message "No completions of f". > > Clearly, the problem is in the "foo:" of the 2nd headline. Without > it, or with "foo" (or even with ":foo:") in place of "foo:", the > completion is performed to ":foo:" as expected. Fixed. Thank you. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] don't always restore previous window configuration?
On Sat, Nov 24, 2018 at 5:55 AM Nicolas Goaziou wrote: > Hello, > > Matt Price writes: > > > OH man, that was a little harder than I thought it would be. Does `make > > test` randomly checkout a new branch or something? > > No, it doesn't. > Then I'm sorry for the noise (and also for this aside!). Magit, or git, or some other tool was doing something quite strange and disturbing, and I am now seeing these remotes in my repo: dup /tmp/tmp-orgtest/org-annex-testoRSq4r/ (fetch) dup /tmp/tmp-orgtest/org-annex-testoRSq4r/ (push) origin https://code.orgmode.org/bzg/org-mode.git (fetch) origin https://code.orgmode.org/bzg/org-mode.git (push) original/tmp/tmp-orgtest/org-annex-testrgbPft/ (fetch) original/tmp/tmp-orgtest/org-annex-testrgbPft/ (push) > > * org-srce.el (org-src-restore-window-config, org-exit-from-src): New > > variable org-src-restore-window-config allows user to opt out of > > restoring window config when exiting from source buffer with > > org-exit-from-src. > > Thank you. > > Should it be a variable, though? Is there any strong reason, e.g., > a valid use-case, to preserve window configuration? > I'm not sure. Until now only Eric and I had commented on this feature. I will say that I will probably never go back to the old behavior, but maybe there are people who prefer it. I believe there are 6 possible options for org-src-window-setup (though only 5 are listed in the defcustom definition, I think that org-src-switch-to-buffer also recognizes 'silently). It may be that some of those options only make sense if the window config is restored after closing the src buffer. ~org-src--saved-window-config~ is only used in this function, so instead of adding a new variable we could just get rid of an old one :-). > * org-srce.el (org-src-restore-window-config, org-exit-from-src): New > ^^^ > typo > > > +(defcustom org-src-restore-saved-window-config t > > + "Whether to restore windows to previous configuration. > > Non-nil means preserve window configuration after editing a source block. > > > +When non-nil (default), on exit from a source buffer, org will > > org -> Org > > > +try to restore the window configuration that was active when > > +the source buffer was created." > > + :group 'org-edit-structure > > + :type 'boolean) > > You need to specify :version and :safe keyword. > > + > > (defvar org-src-mode-hook nil > >"Hook run after Org switched a source code snippet to its Emacs mode. > > \\ > > @@ -1173,8 +1181,8 @@ Throw an error if there is no such buffer." > > ;; Clean up left-over markers and restore window configuration. > > (set-marker beg nil) > > (set-marker end nil) > > -(when org-src--saved-temp-window-config > > - (set-window-configuration org-src--saved-temp-window-config) > > +(when (and org-src--saved-temp-window-config > org-src-restore-saved-window-config) > ^^^ > spurious space > thank you for the improvements. I'll wait to see what is decided about the other issue above.
Re: [O] FW: [RFC] Link-type for attachments, more attach options
Hi, > -Original Message- > From: Ihor Radchenko > Sent: den 20 november 2018 15:01 > To: Gustav Wikström > Cc: emacs-orgmode > Subject: RE: [O] FW: [RFC] Link-type for attachments, more attach options > > Hi, > > >Generalize org-agenda by allowing us to have multiple ones, and make > them more general by thinking of them as a set of views that works on sets > of files. Maybe this is not for all, but I would appreciate to create > multiple "agendas" (even though I'd call them "libraries" in instead), and > possibly also an aggregate agenda consisting of other agendas. > > Isn't this already in org? You can use custom agendas with multiple > "agendas" (custom commands) and set the files they operate on with org- > agenda-files within custom commands. No, it's not there. I know of the custom agendas and use it currently. But I cannot anywhere specify more than one org-agenda-files parameter, for example. > > >If two org-mode files exist in the same folder with different names, it > would be awesome to think of (and work with) them as two top-level headings > inside one org-mode buffer. Similar to two level-1 headings inside an org- > mode file. For this to work all properties we can define for regular > headings should be possible to define for these "level-0 headings". For > example an attachment-folder or ID, a deadline, scheduled date, or TODO- > keyword should in that case be configurable on the whole file. I guess some > new conventions regarding syntax and existing properties would have to be > created as well. > > You can do something like below. It is pretty much what you want, except I > am not sure how to update the headings from local org files. Current org > version does not allow `:results replace` on raw org output. > > * Main heading > > #+name: org-files-here > #+begin_src bash > ls *.org > #+end_src > > #+begin_src emacs-lisp :var files=org-files-here() :var stars=(make-string > (car (org-heading-components)) ?*) :results raw replace drawer (let ((files > (mapcar #'car files))) > (cl-loop for file in files > concat (with-current-buffer (find-file-noselect file) > (concat (format "* %s\n" (buffer-file-name)) > (replace-regexp-in-string "^\\*" (concat "*" stars) > (buffer-string)) #+end_src No, that's not what I want. What I'm talking about is extending org-mode conceptually with the concept of 0-level headlines, where the body of that "headline" would be everything before the first headline in a file, and where I could specify (for example) an attachment-directory and be able to use it with this new syntax to link to attached files. I guess I took it a bit far with the example of visualizing multiple files from a folder as separate headlines inside a single emacs-buffer though. It would be cool to be able to do that but my intention was more about introducing the 0-level headline concept. Thanks for your idea and suggestion though! > > Best, > Ihor Kind Regards, Gustav
Re: [O] Bug: Link given to gnuplot-mode is out of date [9.1.9 (release_9.1.9-65-g5e4542 @ /nix/store/x7b40y4pxp69h343akhaj4fb9fspacdq-emacs-26.1.50/share/emacs/26.1.50/lisp/org/)]
Dear Nicolas > Nicolas Goaziou writes: > Hello, Colin Baxter writes: >> Hi, >>> Gemini Lasswell writes: >> >> > In the "Requirements" section of ob-gnuplot.el's header >> comment, > the link given for gnuplot-mode no longer works. The >> same broken > link is also present in org-manual.org. >> >> > Since gnuplot-mode is available on MELPA, I think the most >> helpful > advice for people trying to set up org-babel-gnuplot >> would be to > install it from there. >> >> > Emacs : GNU Emacs 26.1.50 (build 1, x86_64-pc-linux-gnu, GTK+ > >> Version 3.22.30) of 2018-10-11 Package: Org mode version 9.1.9 > >> (release_9.1.9-65-g5e4542 @ > >> /nix/store/x7b40y4pxp69h343akhaj4fb9fspacdq-emacs-26.1.50/share/emacs/26.1.50/lisp/org/) >> >> I recommend the gnuplot-mode from git: >> http://github.com/bruceravel/gnuplot-mode/. I found the MELPA >> version unsatisfactory in that it seemed to have missing >> functionality. > This is complicated. The FSF frowns upon referencing Github in a > GNU manual, or even MELPA. More precisely, no feature in Emacs > proper — Org ships with it — should necessitate to direct user > towards a non-free platform. No feature should require a library > that should be included in Emacs either. See, for example > bug#32722 or "Dependencies of Org" in Emacs-devel ML. I understand the FSF's position from reading about their issue with html-ize. It's not my position - but that's a different matter. > At this point, I think the only way to stay in Emacs is to move > ob-gnuplot (and other similar libraries that require non-Emacs > libraries) in GNU ELPA or some such. > I'm Cc'ing Bastien for his opinion about it. > Regards, > -- Nicolas Goaziou Best of luck. Colin Baxter m43...@yandex.com
[O] [PATCH] Add support for Brave to org-mac-link
Hi all, Brave is a chromium-based browser, so the existing Chrome code works with slight modifications. By the way, I’ve signed FSF papers though https://orgmode.org/worg/org-contribute.html currently has me listed in the wrong place. Best, Aaron 0001-org-mac-link-Add-support-for-Brave.patch Description: Binary data
Re: [O] [PATCH] don't always restore previous window configuration?
Hello, Matt Price writes: > OH man, that was a little harder than I thought it would be. Does `make > test` randomly checkout a new branch or something? No, it doesn't. > This patch adds a new long-winded variable `org-src-restore-window-config`, > t by default, which if set to `nil` will inhibit restoration of previous > window config in `org-edit-src-exit`. > I'm afraid I don't really understand the tests and I learn so slowly that I > don't have time to keep trying today. But hopefully this simple patch is > adequate. I also wrote a changelog entry in my git commit msg, which is > here: > > Make restoration of window config optional on exit from src buffer > > * org-srce.el (org-src-restore-window-config, org-exit-from-src): New > variable org-src-restore-window-config allows user to opt out of > restoring window config when exiting from source buffer with > org-exit-from-src. Thank you. Should it be a variable, though? Is there any strong reason, e.g., a valid use-case, to preserve window configuration? > * org-srce.el (org-src-restore-window-config, org-exit-from-src): New ^^^ typo > +(defcustom org-src-restore-saved-window-config t > + "Whether to restore windows to previous configuration. Non-nil means preserve window configuration after editing a source block. > +When non-nil (default), on exit from a source buffer, org will org -> Org > +try to restore the window configuration that was active when > +the source buffer was created." > + :group 'org-edit-structure > + :type 'boolean) You need to specify :version and :safe keyword. > + > (defvar org-src-mode-hook nil >"Hook run after Org switched a source code snippet to its Emacs mode. > \\ > @@ -1173,8 +1181,8 @@ Throw an error if there is no such buffer." > ;; Clean up left-over markers and restore window configuration. > (set-marker beg nil) > (set-marker end nil) > -(when org-src--saved-temp-window-config > - (set-window-configuration org-src--saved-temp-window-config) > +(when (and org-src--saved-temp-window-config > org-src-restore-saved-window-config) ^^^ spurious space Regards, -- Nicolas Goaziou
Re: [O] Bug: Link given to gnuplot-mode is out of date [9.1.9 (release_9.1.9-65-g5e4542 @ /nix/store/x7b40y4pxp69h343akhaj4fb9fspacdq-emacs-26.1.50/share/emacs/26.1.50/lisp/org/)]
Hello, Colin Baxter writes: > Hi, >> Gemini Lasswell writes: > > > In the "Requirements" section of ob-gnuplot.el's header comment, > > the link given for gnuplot-mode no longer works. The same broken > > link is also present in org-manual.org. > > > Since gnuplot-mode is available on MELPA, I think the most helpful > > advice for people trying to set up org-babel-gnuplot would be to > > install it from there. > > > Emacs : GNU Emacs 26.1.50 (build 1, x86_64-pc-linux-gnu, GTK+ > > Version 3.22.30) of 2018-10-11 Package: Org mode version 9.1.9 > > (release_9.1.9-65-g5e4542 @ > > > /nix/store/x7b40y4pxp69h343akhaj4fb9fspacdq-emacs-26.1.50/share/emacs/26.1.50/lisp/org/) > > I recommend the gnuplot-mode from git: > http://github.com/bruceravel/gnuplot-mode/. I found the MELPA version > unsatisfactory in that it seemed to have missing functionality. This is complicated. The FSF frowns upon referencing Github in a GNU manual, or even MELPA. More precisely, no feature in Emacs proper — Org ships with it — should necessitate to direct user towards a non-free platform. No feature should require a library that should be included in Emacs either. See, for example bug#32722 or "Dependencies of Org" in Emacs-devel ML. At this point, I think the only way to stay in Emacs is to move ob-gnuplot (and other similar libraries that require non-Emacs libraries) in GNU ELPA or some such. I'm Cc'ing Bastien for his opinion about it. Regards, -- Nicolas Goaziou
Re: [O] Request on modification of org-element.el
Hello, Qiang Fang writes: > Hello Nicolas, > The complete diff is: > > $ ~/src$ git clone https://code.orgmode.org/bzg/org-mode.git > $ cd org-mode > $ git merge origin/wip-cite > > Auto-merging testing/lisp/test-org-element.el > Auto-merging lisp/org-element.el > CONFLICT (content): Merge conflict in lisp/org-element.el > Automatic merge failed; fix conflicts and then commit the result. As I said, I merged "wip-cite" with master two days ago, fixing merge conflicts along the way. The command above poses no problem here. Regards, -- Nicolas Goaziou
Re: [O] Bug: org export table.el [9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/26.1/lisp/org/)]
Hello, "Ulrich G. Wortmann" writes: > the following problem occurs reproducibly with GNU Emacs 26.1 (see below > for details), even when starting emacs with -Q > > If I use a table in my org file and convert that table to table.el the > caption is not exported into either the HTML or Latex File. Export to ASCII > works as expected. If I convert the table back to org-table format, the > Latex and HTML export of the caption work as expected. As a side note, any > other #+ expressions (e.g., Latex-Attr, Labels etc) won't be exported > either if the table is in table.el format > > Expected behavior: #+CAPTION: is being exported regardless what table > format has been selected. > > #+CAPTION: Test caption on top of table.el > +---+---+---+ > > | 1 | 2 | 3 | > +---+---+---+ > | 4 | 5 | 6 | > +---+---+---+ > | 6 | 7 | 8 | > +---+---+---+ Export of table.el tables is not handled by Org, but by "table.el" library. In other words, Org keywords are expected to work only on Org tables. Regards, -- Nicolas Goaziou
Re: [O] Standard Format for Org Outlines?
Hello, Neil Jerram writes: > On 23 November 2018 23:23:27 GMT, David Masterson > wrote: >>Probably a dumb question, but is there a standard format for Org >>outlines. I'm particularly wondering about the use of blank lines. I >>prefer to have blank lines before my headings for readability, but I >>think a lot of other people work without the blank lines. I recently >>ran into a case with BeOrg where it, in fact, removed the blank lines >>when it synced my change back to my original file. That led me to >>think >>what is the standard format for an Org outline. Should I expect the >>tools to adjust to me or should I adjust to them? >>-- >>David > > Great question; I've seen and wondered the same thing. In my case it's > Orgzly that seems to like removing some blank lines - although happily > it doesn't seem to mind when I add some of them back again. Blank lines before a headline are not significant in Org syntax. Regards, -- Nicolas Goaziou
Re: [O] Standard Format for Org Outlines?
On 23 November 2018 23:23:27 GMT, David Masterson wrote: >Probably a dumb question, but is there a standard format for Org >outlines. I'm particularly wondering about the use of blank lines. I >prefer to have blank lines before my headings for readability, but I >think a lot of other people work without the blank lines. I recently >ran into a case with BeOrg where it, in fact, removed the blank lines >when it synced my change back to my original file. That led me to >think >what is the standard format for an Org outline. Should I expect the >tools to adjust to me or should I adjust to them? >-- >David Great question; I've seen and wondered the same thing. In my case it's Orgzly that seems to like removing some blank lines - although happily it doesn't seem to mind when I add some of them back again. Best wishes, Neil
Re: [O] Bug: Link given to gnuplot-mode is out of date [9.1.9 (release_9.1.9-65-g5e4542 @ /nix/store/x7b40y4pxp69h343akhaj4fb9fspacdq-emacs-26.1.50/share/emacs/26.1.50/lisp/org/)]
Hi, > Gemini Lasswell writes: > In the "Requirements" section of ob-gnuplot.el's header comment, > the link given for gnuplot-mode no longer works. The same broken > link is also present in org-manual.org. > Since gnuplot-mode is available on MELPA, I think the most helpful > advice for people trying to set up org-babel-gnuplot would be to > install it from there. > Emacs : GNU Emacs 26.1.50 (build 1, x86_64-pc-linux-gnu, GTK+ > Version 3.22.30) of 2018-10-11 Package: Org mode version 9.1.9 > (release_9.1.9-65-g5e4542 @ > /nix/store/x7b40y4pxp69h343akhaj4fb9fspacdq-emacs-26.1.50/share/emacs/26.1.50/lisp/org/) I recommend the gnuplot-mode from git: http://github.com/bruceravel/gnuplot-mode/. I found the MELPA version unsatisfactory in that it seemed to have missing functionality. Best wishes,
