Re: [O] FW: [RFC] Link-type for attachments, more attach options
stardiviner writes: > I found another problem, =[C-c C-a d]= does not give out delete available > attachment files. Maybe other places is affected, suggest you check out other > places. Ehh, sorry, today I found I can use this again. Weird that yesterday I got nothing. -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
Re: [PATCH] org-screen.el: replace obsolete function
Gregor Zattler writes: > * contrib/lisp/org-screen.el (org-screen): replace obsolete function > `insert-string' with `insert'. Thanks. Applied in 86c7a22ce (with small capitalization tweaks to fit project conventions).
Re: [Idea] Org Collections
On 14 December 2019, Gustav Wikström wrote: 2 Idea == I propose to introduce `Collection' as a concept in the realm of Org mode. [1] This is very interesting, and I think I have some cases where I could use this. When there's something to test, I'll certainly try it. It's a good idea, and I hope your work on it goes well. Bill -- William Denton :: Toronto, Canada --- Listening to Art: https://listeningtoart.org/ https://www.miskatonic.org/ --- GHG.EARTH: https://ghg.earth/ Caveat lector. --- STAPLR: https://staplr.org/
Re: restore window configuration after org-edit-src-exit
Nicolas Goaziou writes: > However, it doesn't mean the inconvenience shouldn't be fixed. I cannot > remember why 819e98afd018cad3c13fd58bfcbd979ab36dfbc7 was necessary. I'm > Cc'ing Matt Price. Here's the related thread: https://lists.gnu.org/archive/html/emacs-orgmode/2018-11/msg00253.html Summary: Matt had a case where he didn't want the window configuration to be restored, so he proposed hiding the behavior behind an option. You wondered whether we should just remove support for restoring the window configuration and not bother with the option. Nobody offered a defense for restoring the window configuration or complained... until now :]
Re: Emacs bug 37890; killing capture buffer
Michael Heerdegen writes: > - kill-buffer-hook in the capture buffer could be used to prevent the > user from killing such a buffer by accident. Or it could be made > configurable what to do (e.g. undo the change with or without user > prompting, ask for what to do, etc.) > > - kill-emacs-hook could be used to register a function that warns when > any capture buffers are left when Emacs is to be killed. That would > make a difference if you have captured more stuff after having > forgotten about a former capture buffer. The user would be guided to > finish what he would otherwise have forgotten. That doesn't seem to be hard to implement: #+begin_src emacs-lisp (add-hook 'org-capture-mode-hook (defun my-org-capture-mode-hook-fun () (add-hook 'kill-buffer-hook (defun my-org-capture-inhibit-accidental-kill () (user-error "Please don't just kill org capture buffers")) nil 'local) (add-hook 'kill-emacs-hook (defun my-org-capture-barf-for-left-capture-buffers () (dolist (b (buffer-list)) (when (with-current-buffer b (bound-and-true-p org-capture-mode)) (user-error "Please care about org capture buffer %s" (buffer-name b (add-hook 'org-capture-prepare-finalize-hook (defun my-org-capture-prepare-finalize-hook-fun () (remove-hook 'kill-buffer-hook 'my-org-capture-inhibit-accidental-kill 'local))) #+end_src Would you consider to do something like this by default? BTW, what about my question whether my original bug report can be closed? TIA, Michael.
RE: [Idea] Org Collections
Hi! > -Original Message- > From: Emacs-orgmode On Behalf > Of Roland Everaert > Sent: den 16 december 2019 12:26 > To: emacs-orgmode@gnu.org > Subject: Re: [Idea] Org Collections > > +1 for this idea. > > You speak about one document used by multiple collections, how do you > plan to manage that from a file system point of view? The idea was to let the user define the scope of each collection herself. Similar to how an agenda is defined today (Maybe in the same way even?). Most simple configuration would be to let a collection be one folder. But in the end it would be up to the imagination of and usefulness for the user. Having one document in multiple collections wouldn't be any issue because the collections are only pointing to locations of files in the filesystem. And if creating overlap between collections sounds dumb then it's a simple choice by the user to not do it! > How will be organized a collection, still from the FS point of view? Maybe the comments above answer that as well? > As some are delving into the abyss of sementic, I propose aspects > instead of collections or contexts. Ultimately we are trying to manage > various aspects of our life, by splitting those aspects into files or > diretories and what not. So, if it is the intent of your idea, the term > aspect seems more appropriate than collection or context IMHO. Many words could work. Context, Project, Group, Aspect, Areas, etc. I first thought of the name "project" to match the Projectile package. But I think collection is a better concept here. It lets the user think not of how it should be used but rather of what it consists. Which is a collection of files (and settings). That collection can ofc. be used for project, as aspects, or be seen as contexts or areas. So in my mind collection is the broader, more applicable term. It has less subjective meaning attached to how this functionality could be used. It IS a collection but can be USED as aspects, for projects, etc. What do you say? > > Did you think about the specific UI of aspects management? > Proposal of UI I particularly like: > - Mu4E > - forge/magit Not really.. Except I agree with you on magit. The other I haven't used. > > How to keep track of all those aspects? My first thought was to define them in a simple list. > > I will surely have more to say, but, as of know I am at work. > > Regards, > > Roland. Thanks for your comments! Regards Gustav
Listings and dialects
My org files typically include source blocks from several different languages. I'm using the listings package for export to LaTeX. I'd like to give each language a distinctive look (by changing the background or border colour). I can do this manually by inserting a bit of LaTeX before each block, but I'd like to avoid having to do that. As far as I can tell, I can't easily tell the listings package to change just one aspect of one language. I *can*, however, create a dialect of the language, with a different appearance. If the language has a named dialect I can use as a basis (such as awk, which has gnu and posix dialects), I can then set the default dialect to my new dialect, and awk blocks are formatted as I like. Unfortunately, most of the languages I use (bash, sqlite, R), don't have a name dialect. When I define a new dialect in terms of the default, unnamed dialect, then set the default dialect to my version, listings throws a wobbly. My idea to work around this is to specify a dialect to the source block, and, if that is present, have org include it in the language is passes to listings. So far, though, I haven't been able to puzzle out how to do this. I could see it being done as a new switch to the code block (similiar to -n to control line numbering), or as an argument to the block (such as :exports). Which way would be most 'org-like'? Any pointers on where to start poking around in the code? Thanks for any assistance, Mike
Re: Babel: Store script in external file
I've just started playing with #+INCLUDE, so I may not be using it correctly, but this works for me. I have a file 'sh_test', which looks like: for i in $(seq 10); do echo $i done My org file: #+HEADER: :exports both #+INCLUDE: "sh_test" src sh And the results: , | for i in $(seq 10); do | echo $i | done ` 1 2 3 4 5 6 7 8 9 10 Hope that helps. Kind regards, Mike On Mon, Dec 16, 2019 at 2:22 PM Nathan Neff wrote: > Hello all, > > I think I'm missing something basic: I'd like to have something like this: > > #+begin_src python > #+filename: foo.py > > Instead of storing my Python code in the current org file, I would like > Babel to read foo.py and execute it, as if it was inside the .org file. > > The foo.py mentioned above is fairly large, and I would like the code > to be stored in a different file than my .org file, for brevity. > > Any ideas? I feel like I'm missing something obvious. > > Thanks, > --Nate >
Re: Babel: Store script in external file
> On Dec 15, 2019, at 5:21 PM, Nathan Neff wrote: > > Hello all, > > I think I'm missing something basic: I'd like to have something like this: > > #+begin_src python > #+filename: foo.py > > Instead of storing my Python code in the current org file, I would like > Babel to read foo.py and execute it, as if it was inside the .org file. > > The foo.py mentioned above is fairly large, and I would like the code > to be stored in a different file than my .org file, for brevity. > > Any ideas? I feel like I'm missing something obvious. Two things: 1. Library-of-Babel :: lets you store src blocks of code in an external file 2. noweb chunks :: let you insert code into src blocks See https://orgmode.org/worg/library-of-babel.html and (info "(org) Noweb Reference Syntax") For your example, a file `my-lob.org' with a src-block named foo-py that contains what foo.py contains will do it. Then you eval `(org-babel-lob-ingest "my-lob.org")' any time before executing the file that contains this: #+begin_src python :noweb yes <> ... HTH, Chuck
Re: Babel: Set org-babel-min-lines-for-block-output for single code block?
> On Dec 15, 2019, at 1:55 PM, Nathan Neff wrote:
>
> Hello all,
>
> I just found the org-babel-min-lines-for-block-output variable.
>
> I have a table like this:
>
> #+RESULTS: people-table
> | User | ID | Homepage |
> |---++--|
> | Bob | 1 | http://example.com/bob |
> | Steve | 2 | http://example.com/steve |
>
> And a code block like this:
>
> #+begin_src python :var people=people-table :results output
> for i, person in enumerate(people):
> print('- ' + person[0])
> print(" " + person[2])
> #+end_src
>
> I would like to set org-babel-min-lines-for-block-output variable for
> only the above code block. Is this possible using #+property or something
> like that?
> Or do I need to have a "wrapper" elisp block around my python code?
Use the `:wrap example' header.
HTH,
CCB
Help me secure some free time for org-mode in 2020
Dear all, I have been involved in Org-mode development when Carsten offered me to take over maintainance, back in 2010. I still feel grateful for the opportunity he gave me: his dedication to make Org a useful tool for Emacs users was examplary and I did my very best to give to the community as much as I received from it. Over the last years, Nicolas de facto took over maintainance and it was a real relief for me: I was struggling with my finances and this was eating up all my free time. Nicolas steadily played the role I played for years, reassuring users that someone was on board, that bugs would be fixed and new features discussed on this mailing list. My plan for 2020 is to ensure a smooth transition while I step down as the maintainer---at least by the end of 2020, probably by July. As my timetable (and family life) has become more stable, I am more confident I can dedicate some of my free time again to maintaining until the transition is done: also because there are many ideas I would like to try, discuss and implement---Org possibilities still feel endless! If you want to help me secure some free time, please go ahead! I recommend using https://liberapay.com/bzg If you cannot, there are also these services: https://github.com/sponsors/bzg https://www.paypal.me/bzg You can also help by sharing the messages I sent: https://mastodon.etalab.gouv.fr/@bzg/103318485790068452 https://twitter.com/bzg2/status/1206617096462983169 I would love stepping down while releasing Org 10 and making this one of the best release ever. Thanks! -- Bastien
Re: Bug: xxx [9.3 (9.3-8-geab7c4-elpa @ c:/Users/Scott/.emacs.d/elpa/org-20191209/)]
Hi Nicolas, Thanks for the help. Scott On Mon, Dec 16, 2019 at 8:22 AM Nicolas Goaziou wrote: > Hello, > > Scott Otterson writes: > > > A function I wrote a few months ago is now failing because it's unable > > to find the org function "org-at-target-p". I think this was > > originally in org.el but I can't find it there now. > > It was removed because its implementation was buggy and not necessary. > > > If this function was removed intentionally could someone suggest a new > > function that can do the same thing? org-at-target-p used to return > > true if the cursor is on a dedicated target. > > You can use Org parser: > > (memq (org-element-type (org-element-context)) '(target radio-target)) > > or > > (org-element-lineage (org-element-context) '(target radio-target) t) > > Regards, > > -- > Nicolas Goaziou >
Re: Bug: xxx [9.3 (9.3-8-geab7c4-elpa @ c:/Users/Scott/.emacs.d/elpa/org-20191209/)]
Scott Otterson writes: > A function I wrote a few months ago is now failing because it's > unable to find the org function "org-at-target-p". I think this was > originally in org.el but I can't find it there now. > > If this function was removed intentionally could someone suggest a > new function that can do the same thing? org-at-target-p used to > return true if the cursor is on a dedicated target. > This happened with commit , | commit a486d9cbd7491741554944a116f81b02f6b35e4b (HEAD, refs/bisect/bad) | Author: Nicolas Goaziou | Date: Tue Nov 27 00:04:41 2018 +0100 | | Move link-related core functions out of "org.el" ` The fact that the function disappears with no mention in the commit message (where about 60 other functions are mentioned) leads me to believe that it was unintentional, but of course, Nicolas will have to confirm one way or the other. -- Nick "There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors." -Martin Fowler
Re: restore window configuration after org-edit-src-exit
Hello, Richard Kim writes: > About a year ago change 819e98afd018cad3c13fd58bfcbd979ab36dfbc7 was checked > in > to remove code that restored window configuration when =org-edit-src-exit= > finished. The net result is af if =C-x 1= is called to remove all windows > except > the org buffer just edited. This is very inconvenient. > > Why not call =winner-undo= to restore window configuration as shown > here? I'd rather not add another dependency just for this. However, it doesn't mean the inconvenience shouldn't be fixed. I cannot remember why 819e98afd018cad3c13fd58bfcbd979ab36dfbc7 was necessary. I'm Cc'ing Matt Price. Regards, -- Nicolas Goaziou
Re: Bug: Macros are not replaced in table.el tables. [9.3 (9.3-elpa @ /Users/jlizarraga/.emacs.d/elpa/org-20191203/)]
Hello, Juan Lizarraga Cubillos writes: > I am writing looking for help on something that I think is a bug. I am > working on a document with table.el tables instead of org-tables > because I need to work with merged cells. Inside the table I have > a macro that should generate the table ID. Unfortunately, I have > noticed that macros are not replaced inside table.el tables as they > are in org-tables when I export to HTML. Since the manual says "Org > recognizes macro references in following Org markup areas: paragraphs, > headlines, verse blocks, tables cells and lists." without being > specific, I assume this behavior is a bug. It isn't. Table.el tables are opaque to Org. IOW, Org doesn't handle table.el tables at all. In the manual, unless it is specified otherwise, "table" refers to Org tables, not table.el tables. Regards, -- Nicolas Goaziou
Re: Include lines in setupfile are not evaluated: bug or feature?
Hello, Jarmo Hurri writes: > I have such documents regularly. > 1. One type is a handout containing common contents at the beginning >(included) and settings (setup). > 2. The other case is a set of files sharing setup info and code (babel >blocks, included). Then I suggest to unravel what is needed at runtime and what is required at export time. Regards, -- Nicolas Goaziou
Re: Bug: xxx [9.3 (9.3-8-geab7c4-elpa @ c:/Users/Scott/.emacs.d/elpa/org-20191209/)]
Hello, Scott Otterson writes: > A function I wrote a few months ago is now failing because it's unable > to find the org function "org-at-target-p". I think this was > originally in org.el but I can't find it there now. It was removed because its implementation was buggy and not necessary. > If this function was removed intentionally could someone suggest a new > function that can do the same thing? org-at-target-p used to return > true if the cursor is on a dedicated target. You can use Org parser: (memq (org-element-type (org-element-context)) '(target radio-target)) or (org-element-lineage (org-element-context) '(target radio-target) t) Regards, -- Nicolas Goaziou
Re: [Idea] Org Collections
I do agree that "aspect" is a very abstract term and all depends on the scope of this proposal, I suppose. Reading the proposal again, it seems that my proposal could apply, as the intent seems to define a per "aspect" configuration. On the other end as aspects are quite abstract, an aspect can be part of another one and aspects can have different "implementations" (collections, documents, headlines and TODOs???, ...). Tim Cross writes: > I would have to say the hardest thing I ever have to do as a developer > is naming things. It is hard enough to do within a context of a single > group, even harder when speaking about something with a global user base > (language, social/cultural differences etc). Despite this, it is so very > important as it defines expectations, which will in turn determine > satisfaction. > > As an example, 'aspects' for me is more like a different view into a > 'thing' while collections are more like distinct, separate collections of > 'things'. To some extent, aspects feels like a 'virtual collection' > where collection is more like a concrete separation. I can see pros > and cons with both. > > Roland Everaert writes: > >> +1 for this idea. >> >> You speak about one document used by multiple collections, how do you >> plan to manage that from a file system point of view? >> >> How will be organized a collection, still from the FS point of view? >> >> As some are delving into the abyss of sementic, I propose aspects >> instead of collections or contexts. Ultimately we are trying to manage >> various aspects of our life, by splitting those aspects into files or >> diretories and what not. So, if it is the intent of your idea, the term >> aspect seems more appropriate than collection or context IMHO. >> >> Did you think about the specific UI of aspects management? >> Proposal of UI I particularly like: >> - Mu4E >> - forge/magit >> >> How to keep track of all those aspects? >> >> I will surely have more to say, but, as of know I am at work. >> >> Regards, >> >> Roland. >> >> Gustav Wikström writes: >> >>> Hi list and all honored readers! >>> >>> I have an idea. One that I've mentioned before in side notes. And I want to >>> emphasize that this still only is an idea. But I want to present this idea >>> to you. As a way to gather feedback and get input. Maybe the idea is >>> stupid!? Maybe you think it's already solved? Or maybe it's not, and lots >>> of you resonate with it as well. In any case, please let me know what you >>> think on the piece below! >>> >>> >>> >>> ORG MODE: COLLECTIONS/PROJECTS >>> >>> Gustav Wikström >>> >>> >>> >>> Table of Contents >>> _ >>> >>> 1. Motivation >>> 2. Idea >>> 3. Benefit >>> .. 1. For the user >>> .. 2. For the developer >>> 4. Example use cases >>> .. 1. Separate actions from reference >>> .. 2. Work / Personal separation >>> .. 3. Separated book library >>> .. 4. More? >>> 5. Risks and challenges >>> .. 1. Which configuration to use? >>> .. 2. Should project config allow local variables? >>> . 1. How to initialize the local variables? >>> .. 3. Conflict with other customizations >>> .. 4. Files that belong to multiple collections >>> .. 5. Dynamic lists of files and folders for a collection? >>> 6. Alternatives >>> 7. References >>> >>> >>> 1 Motivation >>> >>> >>> Org mode is more than a major mode for emacs buffers. That has been >>> clear for quite some time. Org mode can operate on sets of files. >>> Consolidate TODO's and calendar information into custom views. Publish >>> sets of files. To do this Org mode assumes that the user has a >>> configuration for each of those features. Each feature is responsible >>> for maintaining its own context. And almost all of that context has >>> to be set globally. So even though Org mode has commands and features >>> that operate on sets of files and folders it has not yet developed >>> that in a congruent, extensible and composable way. Thus, for the >>> sanity of our users and developers I think it's time to ... introduce >>> another concept! One that hopefully can simplify things both for users >>> and developers. >>> >>> >>> 2 Idea >>> == >>> >>> I propose to introduce `Collection' as a concept in the realm of Org >>> mode. [1] >>> >>> An Org mode collection is defined as the combination of: >>> 1. A short name and description >>> 2. A collection of Org mode documents >>> 3. A collection of files and/or folders called attachments and >>> attachment-locations for the project >>> 4. A collection of configurations for the given project >>> >>> Globally available collections are defined in a list, >>> `org-collections'. Org mode should include a safe parameter that can >>> be set as a folder customization to the local active project, >>>
Manual Typo in Table Section
Hello org mode mods! I'm starting to get into org mode and have been going through the manual to understand it better. I got to section 3.5.1 and got a little confused: https://orgmode.org/manual/References.html#References Specifically with this example formula: ‘@3 = 2 * remote(FOO, @@1$$#)’ As I've been playing around with tables and formulas I've come to the conclusion that '@@1' must be a typo, and that what was intended was just '@1'. I have a few qualms about this table section in general, but felt that this particular typo was an important one to highlight. Thanks so much for your work! I hope to get more involved once I've made my way through the manual. Sincerely, Ben
restore window configuration after org-edit-src-exit
About a year ago change 819e98afd018cad3c13fd58bfcbd979ab36dfbc7 was checked in to remove code that restored window configuration when =org-edit-src-exit= finished. The net result is af if =C-x 1= is called to remove all windows except the org buffer just edited. This is very inconvenient. Why not call =winner-undo= to restore window configuration as shown here? #+begin_src diff >From bd0a2abaa8097338d7f33c7ca9a1d45f5da67e7a Mon Sep 17 00:00:00 2001 From: kimr Date: Sat, 14 Dec 2019 10:59:00 -0800 Subject: [PATCH] restore window config by calling winner-undo --- lisp/org-src.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lisp/org-src.el b/lisp/org-src.el index 5e50a1b4..c8c30889 100644 --- a/lisp/org-src.el +++ b/lisp/org-src.el @@ -1182,7 +1182,8 @@ Throw an error if there is no such buffer." (write-back (org-src--goto-coordinates coordinates beg end ;; Clean up left-over markers and restore window configuration. (set-marker beg nil) -(set-marker end nil))) +(set-marker end nil) +(winner-undo))) (provide 'org-src) -- 2.22.1 #+end_src For now I'm using the following advice do the same thing. #+begin_src elisp (defadvice org-edit-src-exit (after restore-window-config activate) (winner-undo)) #+end_src
Bug: Macros are not replaced in table.el tables. [9.3 (9.3-elpa @ /Users/jlizarraga/.emacs.d/elpa/org-20191203/)]
Hello
I am writing looking for help on something that I think is a bug. I am working
on a document with table.el tables instead of org-tables because I need to work
with merged cells. Inside the table I have a macro that should generate the
table ID. Unfortunately, I have noticed that macros are not replaced inside
table.el tables as they are in org-tables when I export to HTML. Since the
manual says "Org recognizes macro references in following Org markup areas:
paragraphs, headlines, verse blocks, tables cells and lists." without being
specific, I assume this behavior is a bug.
Here under you have an example of what I am trying to do:
+-+-+
| ID | {{{n(Id)}}}
|
+-+-+
| Name| Some name
|
+-+-+
| Description:
|
+-+-+
| Some description Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed
do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad ...
|
+-+-+
Many thanks
Juan
Emacs : GNU Emacs 26.3 (build 1, x86_64-apple-darwin18.2.0, NS appkit-1671.20
Version 10.14.3 (Build 18D109))
of 2019-09-02
Package: Org mode version 9.3 (9.3-elpa @
/Users/jlizarraga/.emacs.d/elpa/org-20191203/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-link-shell-confirm-function 'yes-or-no-p
org-tempo-keywords-alist '(("H" . "html") ("A" . "ascii") ("i" . "index"))
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-refile-targets '((org-agenda-files :maxlevel . 2))
org-html-format-inlinetask-function 'org-html-format-inlinetask-default-function
org-src-tab-acts-natively t
org-odt-format-headline-function 'org-odt-format-headline-default-function
org-agenda-files '("~/Documents/Work.org")
org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
org-modules '(org-tempo ol-w3m ol-bbdb ol-bibtex ol-docview ol-gnus ol-info
ol-irc ol-mhe ol-rmail ol-eww)
org-mode-hook '(#[0 "\301\211\207" [imenu-create-index-function
org-imenu-get-tree] 2] org-tempo-setup er/add-org-mode-expansions
visual-line-mode org-indent-mode org-bullets-mode
#[0 "\300\301\302\303\304$\207" [add-hook change-major-mode-hook org-show-all
append local] 5] #[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-babel-show-result-all append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes)
org-export-with-smart-quotes t
org-odt-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
org-startup-indented t
org-startup-with-inline-images t
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 "\n\n(fn
ENTRY)"]
org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
org-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-babel-load-languages '((emacs-lisp . t) (mermaid . t) (gnuplot . t))
org-log-done 'note
org-ascii-format-drawer-function #[771 "\207" [] 4 "\n\n(fn NAME CONTENTS
WIDTH)"]
org-ellipsis " "
org-occur-hook '(org-first-headline-recenter)
org-log-into-drawer t
org-structure-template-alist '(("a" . "export ascii") ("c" . "center") ("C" .
"comment") ("e" . "example") ("E" . "export") ("h" . "export html") ("l" .
"export latex") ("q" . "quote") ("s" . "src") ("v" . "verse") ("L" . "src
emacs-lisp"))
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-speed-command-hook
Duplicate items in agenda-todo-list
Hi, newbie emacs and org-mode user here. I get duplicate results when listing agenda TODO items. Any ideas on what may be causing this? I'm using Spacemacs with Emacs 26.3 (9.0) on OSX 10.10.5 and . Cheers,
[Nicolò Balzarotti] [bug#38616] emacs: fix odt export
Hello Org Mode people! This is my first bug-report :) I found a problem on org-odt-export-to-odt function. The export fails with 'OpenDocument export failed: Buffer is read-only: #'. The problem happens on ox-odt, when the file OrgOdtStyles.xml permissions are read-only (this is true especially for Guix and Nix where all the "store" is readonly). The file gets copied to /tmp/ob-*/ directory, and is then modified. However, the file is assumed to be read/write. When the file is not, the export fails. I've sent a one-line patch (simply change permissions to the newly-copied file): > (set-file-modes (concat org-odt-zip-dir "styles.xml") #o600) to guix-patches (here in CC, I'm also forwarding my original patch submission here), but I've been suggested to send the patch upstream. What do you think? I can submit a proper patch if needed (but feel free to patch it yourself) I want to thank everybody for how wonderful Org Mode is :) Nicolò --- Begin Message --- Hello Guix! Neither on NixOS or in guix I've ever been able to export an org file to otd. The error was 'OpenDocument export failed: Buffer is read-only: #'. I've seen some report of this error on the web, like: - https://lists.gnu.org/archive/html/emacs-orgmode/2018-05/msg00545.html - https://github.com/syl20bnr/spacemacs/issues/1482 but also on our IRC: - http://logs.guix.gnu.org/guix/2019-05-07.log - http://logs.guix.gnu.org/guix/2019-07-25.log but I was not able to find a fix for it. Today I checked the source and figured it out. The explanation, as written in the patch, is the following > Files inside the guix store are read only. "styles.xml" is copied from the > store (/share/emacs/26.3/etc/org/OrgOdtStyles.xml), so it's read only too. > ox-odt needs this file, so if it's not writable it will fail. This patch > adjust the permissions. So, this patches fixes the permissions on the file. I've two questions: 1. Is it fine to have a .patch, or should I add a phase where I fix the file? this seemed to be easier 2. If the same error happens for other programs, might it make sense to "fake" rw permissions in the store (by using a virtual fs or something) so that files are copied as rw, but files in the store are still ro? Thanks! Nicolò >From c1ad3fff9bda5935651f26e460907a77d1b3d003 Mon Sep 17 00:00:00 2001 From: nixo Date: Sat, 14 Dec 2019 15:17:11 +0100 Subject: [PATCH] * gnu/packages/emascs.scm (emacs)[patches]: Fix odt export. ox-odt copyes the file /share/emacs/26.3/etc/org/OrgOdtStyles.xml under /tmp/odt-*/styles.xml and tries to modify it. Since files in the guix store are read-only, it will fail. This patch fixes the export by adjusting permissions during the export. --- gnu/packages/emacs.scm| 1 + .../patches/emacs-fix-odt-export.patch| 25 +++ 2 files changed, 26 insertions(+) create mode 100644 gnu/packages/patches/emacs-fix-odt-export.patch diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm index eba7f88551..8183b69eb3 100644 --- a/gnu/packages/emacs.scm +++ b/gnu/packages/emacs.scm @@ -80,6 +80,7 @@ "119ldpk7sgn9jlpyngv5y4z3i7bb8q3xp4p0qqi7i5nq39syd42d")) (patches (search-patches "emacs-exec-path.patch" "emacs-fix-scheme-indent-function.patch" + "emacs-fix-odt-export.patch" "emacs-source-date-epoch.patch")) (modules '((guix build utils))) (snippet diff --git a/gnu/packages/patches/emacs-fix-odt-export.patch b/gnu/packages/patches/emacs-fix-odt-export.patch new file mode 100644 index 00..0c3c44a2e3 --- /dev/null +++ b/gnu/packages/patches/emacs-fix-odt-export.patch @@ -0,0 +1,25 @@ +Files inside the guix store are read only. "styles.xml" is copied from the +store (/share/emacs/26.3/etc/org/OrgOdtStyles.xml), so it's read only too. +ox-odt needs this file, so if it's not writable it will fail. This patch +adjust the permissions. + +--- + lisp/org/ox-odt.el | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/lisp/org/ox-odt.el b/lisp/org/ox-odt.el +index f9c4a93cc8..61988ffcc4 100644 +--- a/lisp/org/ox-odt.el b/lisp/org/ox-odt.el +@@ -1384,6 +1384,8 @@ original parsed data. INFO is a plist holding export options." + ;; create a manifest entry for styles.xml + (org-odt-create-manifest-file-entry "text/xml" "styles.xml") + ++;; guix store files are ro. This file need to be modified, make it rw ++(set-file-modes (concat org-odt-zip-dir "styles.xml") #o600) + ;; FIXME: Who is opening an empty styles.xml before this point? + (with-current-buffer + (find-file-noselect (concat org-odt-zip-dir "styles.xml") t) +-- +2.24.0 + -- 2.24.0 --- End Message ---
Re: [Idea] Org Collections
I would have to say the hardest thing I ever have to do as a developer is naming things. It is hard enough to do within a context of a single group, even harder when speaking about something with a global user base (language, social/cultural differences etc). Despite this, it is so very important as it defines expectations, which will in turn determine satisfaction. As an example, 'aspects' for me is more like a different view into a 'thing' while collections are more like distinct, separate collections of 'things'. To some extent, aspects feels like a 'virtual collection' where collection is more like a concrete separation. I can see pros and cons with both. Roland Everaert writes: > +1 for this idea. > > You speak about one document used by multiple collections, how do you > plan to manage that from a file system point of view? > > How will be organized a collection, still from the FS point of view? > > As some are delving into the abyss of sementic, I propose aspects > instead of collections or contexts. Ultimately we are trying to manage > various aspects of our life, by splitting those aspects into files or > diretories and what not. So, if it is the intent of your idea, the term > aspect seems more appropriate than collection or context IMHO. > > Did you think about the specific UI of aspects management? > Proposal of UI I particularly like: > - Mu4E > - forge/magit > > How to keep track of all those aspects? > > I will surely have more to say, but, as of know I am at work. > > Regards, > > Roland. > > Gustav Wikström writes: > >> Hi list and all honored readers! >> >> I have an idea. One that I've mentioned before in side notes. And I want to >> emphasize that this still only is an idea. But I want to present this idea >> to you. As a way to gather feedback and get input. Maybe the idea is >> stupid!? Maybe you think it's already solved? Or maybe it's not, and lots of >> you resonate with it as well. In any case, please let me know what you think >> on the piece below! >> >> >> >> ORG MODE: COLLECTIONS/PROJECTS >> >> Gustav Wikström >> >> >> >> Table of Contents >> _ >> >> 1. Motivation >> 2. Idea >> 3. Benefit >> .. 1. For the user >> .. 2. For the developer >> 4. Example use cases >> .. 1. Separate actions from reference >> .. 2. Work / Personal separation >> .. 3. Separated book library >> .. 4. More? >> 5. Risks and challenges >> .. 1. Which configuration to use? >> .. 2. Should project config allow local variables? >> . 1. How to initialize the local variables? >> .. 3. Conflict with other customizations >> .. 4. Files that belong to multiple collections >> .. 5. Dynamic lists of files and folders for a collection? >> 6. Alternatives >> 7. References >> >> >> 1 Motivation >> >> >> Org mode is more than a major mode for emacs buffers. That has been >> clear for quite some time. Org mode can operate on sets of files. >> Consolidate TODO's and calendar information into custom views. Publish >> sets of files. To do this Org mode assumes that the user has a >> configuration for each of those features. Each feature is responsible >> for maintaining its own context. And almost all of that context has >> to be set globally. So even though Org mode has commands and features >> that operate on sets of files and folders it has not yet developed >> that in a congruent, extensible and composable way. Thus, for the >> sanity of our users and developers I think it's time to ... introduce >> another concept! One that hopefully can simplify things both for users >> and developers. >> >> >> 2 Idea >> == >> >> I propose to introduce `Collection' as a concept in the realm of Org >> mode. [1] >> >> An Org mode collection is defined as the combination of: >> 1. A short name and description >> 2. A collection of Org mode documents >> 3. A collection of files and/or folders called attachments and >> attachment-locations for the project >> 4. A collection of configurations for the given project >> >> Globally available collections are defined in a list, >> `org-collections'. Org mode should include a safe parameter that can >> be set as a folder customization to the local active project, >> `org-collections-active'. The default should be to the first entry in >> `org-collections' unless customized. This local parameter would be >> used to instruct Emacs and Org mode on which collection is active. >> Only one collection at a time can be active. >> >> Org agenda should use `org-collections-active' as default for the >> collection of Org mode documents to operate on. Org agenda should get >> a new command to switch between active projects. >> >> I'm thinking that there could be a special Emacs major mode for the >> collection as well, called "Org
Bug: org-element-at-point on headline does not contain :parent property [9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/)]
Recipe: 1. Create an org file with the following contents: * 1 ** 2 2. emacs -Q 3. Open the file 4. Put the point at the end of the second headline 5. M-: (message "%s" (org-element-at-point)) Expected behaviour: According to org-element-at-point docstring, "Properties depend on element or object type, but always include :begin, :end, :parent and :post-blank properties.". Hence, it is expected to have :parent property set to the first headline. Observed behaviour: (headline (:raw-value 2 :begin 6 :end 13 :pre-blank 0 :contents-begin nil :contents-end nil :level 2 :priority nil :tags nil :todo-keyword nil :todo-type nil :post-blank 2 :footnote-section-p nil :archivedp nil :commentedp nil :post-affiliated 6 :title 2)) No :parent property is returned. Best, Ihor Emacs : GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0) of 2019-12-16 Package: Org mode version 9.3 (release_9.3 @ /home/yantar92/.emacs.d/straight/build/org/)
Re: [O] FW: [RFC] Link-type for attachments, more attach options
I found another problem, =[C-c C-a d]= does not give out delete available attachment files. Maybe other places is affected, suggest you check out other places. -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
Re: [Idea] Org Collections
+1 for this idea. You speak about one document used by multiple collections, how do you plan to manage that from a file system point of view? How will be organized a collection, still from the FS point of view? As some are delving into the abyss of sementic, I propose aspects instead of collections or contexts. Ultimately we are trying to manage various aspects of our life, by splitting those aspects into files or diretories and what not. So, if it is the intent of your idea, the term aspect seems more appropriate than collection or context IMHO. Did you think about the specific UI of aspects management? Proposal of UI I particularly like: - Mu4E - forge/magit How to keep track of all those aspects? I will surely have more to say, but, as of know I am at work. Regards, Roland. Gustav Wikström writes: > Hi list and all honored readers! > > I have an idea. One that I've mentioned before in side notes. And I want to > emphasize that this still only is an idea. But I want to present this idea to > you. As a way to gather feedback and get input. Maybe the idea is stupid!? > Maybe you think it's already solved? Or maybe it's not, and lots of you > resonate with it as well. In any case, please let me know what you think on > the piece below! > > > > ORG MODE: COLLECTIONS/PROJECTS > > Gustav Wikström > > > > Table of Contents > _ > > 1. Motivation > 2. Idea > 3. Benefit > .. 1. For the user > .. 2. For the developer > 4. Example use cases > .. 1. Separate actions from reference > .. 2. Work / Personal separation > .. 3. Separated book library > .. 4. More? > 5. Risks and challenges > .. 1. Which configuration to use? > .. 2. Should project config allow local variables? > . 1. How to initialize the local variables? > .. 3. Conflict with other customizations > .. 4. Files that belong to multiple collections > .. 5. Dynamic lists of files and folders for a collection? > 6. Alternatives > 7. References > > > 1 Motivation > > > Org mode is more than a major mode for emacs buffers. That has been > clear for quite some time. Org mode can operate on sets of files. > Consolidate TODO's and calendar information into custom views. Publish > sets of files. To do this Org mode assumes that the user has a > configuration for each of those features. Each feature is responsible > for maintaining its own context. And almost all of that context has > to be set globally. So even though Org mode has commands and features > that operate on sets of files and folders it has not yet developed > that in a congruent, extensible and composable way. Thus, for the > sanity of our users and developers I think it's time to ... introduce > another concept! One that hopefully can simplify things both for users > and developers. > > > 2 Idea > == > > I propose to introduce `Collection' as a concept in the realm of Org > mode. [1] > > An Org mode collection is defined as the combination of: > 1. A short name and description > 2. A collection of Org mode documents > 3. A collection of files and/or folders called attachments and > attachment-locations for the project > 4. A collection of configurations for the given project > > Globally available collections are defined in a list, > `org-collections'. Org mode should include a safe parameter that can > be set as a folder customization to the local active project, > `org-collections-active'. The default should be to the first entry in > `org-collections' unless customized. This local parameter would be > used to instruct Emacs and Org mode on which collection is active. > Only one collection at a time can be active. > > Org agenda should use `org-collections-active' as default for the > collection of Org mode documents to operate on. Org agenda should get > a new command to switch between active projects. > > I'm thinking that there could be a special Emacs major mode for the > collection as well, called "Org collections mode". Not sure exactly > what to display and how to represent the project there... But > certainly some kind of list of included documents and attachments. > When in that mode there should possibly be single key > keyboard-shortcuts to the most important features that operate on the > collection. And switch between them. > > > 3 Benefit > = > > 3.1 For the user > > > A user would gain mainly two benefits as I can see right now: > 1. The ability to clearly define (multiple) collections of files that > belong together across org mode, with unique configurations. > 2. Less global configuration state to manage and worry about! > > The second point might not look like much but is sooo important! Most > programmers know that global state should be avoided. Putting things
Re: Asynchronous org-agenda-redo
Ihor Radchenko writes: >> So, of course, you can call custom functions in queries, even your >> own skip functions (with `not', of course), but in most cases, they >> can be covered with built-in predicates. > > Unfortunately, it does not seem to be the case for me. My main agenda > view needs to take into account multiple properties, which cannot be > handled within framework of built-in org-ql predicates (AFAIK): > > - =:SHOWFROMTIME:= (always inheriting) :: The purpose of this is to be > able to assign specific projects for different days of week or, > say, show the home items only in the evening of weekdays and not > annoy me at work when I cannot do it any way. Hence, I can focus on > the items I really need to do now in this agenda. Additionally, the > time of the day after midnight is treated specially here. If > =org-extend-today-until= is not 0 and the current time is before > its value, the current time is still considered to be yesterday. > - =:SHOWFROMDATE:= :: The purpose of this is to be able to postpone the > scheduled tasks for future if I cannot do it. The property is > formatted as an org date. This property is especially useful if > there is something more pressing, so that there is a temptation to > reschedule less pressing event to another day. If the more pressing > task is done earlier than expected, the postponed tasks can be > still find in normal agenda view (not in the > [[id:ff70b03f-3876-4b2b-9aab-c3209bd31cb8][focused]] one). > - =:SHOWDATES:= (always inheriting) :: It contains dairy =sexps= to set > when the project should be shown. For example, I may want to work on > Saturday once or twice, but the working items should not be shown on > weekend normally. Hence, I can define it. Or some things can only be > done on specific dates (say, going to some shop, which is open few > days a week only) There may still be some performance improvement available for these kind of queries. For example, assuming that a function `yantar/showfromdate' is a predicate which accepts the value of property SHOWFROMDATE as its argument and returns non-nil when an entry matches a query, an org-ql query like this could work: (and (property "SHOWFROMDATE") (yantar/showfromdate (property "SHOWFROMDATE"))) The first (property "SHOWFROMDATE") clause allows org-ql to optimize the query using a regexp preamble that jumps directly to entries having that property, while the second clause passes the value of the property to the custom predicate using the built-in predicate (property "SHOWFROMDATE") to retrieve the property from the org-ql node-value cache, which reduces the number of calls to org-entry-get. (That the `property' predicate returns the value of the property when called with only a property argument is a helpful feature that I should document...) > Thanks for the info! I did not know about this optimisation in org-ql. > org-entry-get consumes most of cpu time while building my agenda views. > Though I don't think that there will be much difference for me since > most of my property conditions in agenda involve inherited properties. For properties using inheritance, the preamble regexp can't be used to optimize the query across the buffer (I have some ideas about how to do that, maybe someday...), but the node-value cache can improve performance of retrieving the values of inherited properties within a buffer, because it avoids repeated calls to org-entry-get going up an outline tree. For example, see the benchmark here: https://github.com/alphapapa/org-ql/blob/master/notes.org#caching-of-inherited-tags The node-value cache, which is used for properties, uses essentially the same code as the tag cache benchmarked here (I haven't yet converted the tag cache to use the generic node-value cache), and it provides about a 6x speedup, so property-inheritance-based queries should benefit similarly. So it sounds like your custom agendas would benefit from being written as org-ql queries. Please let me know if you try it, as your examples would give the code a good workout and might reveal some improvements to be made.
Re: [Idea] Org Collections
+1, that is: This is an interesting idea, there have been times when I might have found something like this handy, and I might well use if it's developed, though I'm not sure if it will ease my cognitive load or add to it. :-) Yours, Christian Moe Gustav Wikström writes: [...] > > ORG MODE: COLLECTIONS/PROJECTS > > Gustav Wikström > > [...]
Re: Babel: Store script in external file
Hello, Nathan Neff writes: > Hello all, > > I think I'm missing something basic: I'd like to have something like this: > > #+begin_src python > #+filename: foo.py > > Instead of storing my Python code in the current org file, I would like > Babel to read foo.py and execute it, as if it was inside the .org file. > > The foo.py mentioned above is fairly large, and I would like the code > to be stored in a different file than my .org file, for brevity. > > Any ideas? I feel like I'm missing something obvious. either put some Python code into your Python src block that executes your external script. Or use a shell|elisp|whatever src block that executes your script. Regards hmw
Re: Issues with nested begin..end blocks in inline math environments
Nicolas Goaziou writes: > I don't think this patch is a good idea, as it mixes elements from > different types: LaTeX fragment (inline), and LaTeX environment (block). > For example, the regexp you modify is used as a paragraph separator, > which doesn't make sense for inline LaTeX. No worries. Thanks for taking a look at this anyway. Matt
