Re: add linked files to agenda files
Hello Nick, On 2020-11-16 16:33, Nick Dokos writes: > Just guessing at this point, I would imagine you'd want something like > this: > > --8<---cut here---start->8--- > (defun path-from-link (link) >(org-element-property :path link)) > > (setq org-agenda-files (with-current-buffer > (find-file-noselect "master.org") > (org-element-map (org-element-parse-buffer) > '(link) > #'path-from-link))) > --8<---cut here---end--->8--- Thanks a lot, this is most useful! I did not think it could be this simple. Best, Alan signature.asc Description: PGP signature
Re: Changed list indentation behavior: how to revert?
On Mon, 16 Nov 2020 16:24:45 -0700, T.F. Torrey wrote: [...] > The proper fix for this is one of two choices: > > 1. If keeping electric-indent-mode on is really important, the easiest >way to restore intuitive behavior is to change the default of >org-adapt-indentation to nil. Yes, this changes a longstanding >default, but it is necessitated because of the change of another >longstanding default: electric-indent-mode. Before, anyone who >wanted text indented by default needed to specify that in their init >file, so this should not inconvenience anyone who wasn't >inconvenienced before. > > or > > 2. More involved would be to change the default behavior of Org's >electric indentation so that typing at the end of a heading >takes you back to column 0 by default. In many contexts, the >indentation provided by org-auto-indent is useful, but not this >one. Or maybe? 3. Pair the electric indentation + org-adapt-indentation with electric asterisk (actually more of an electric space) so that "* " removes the indentation. So this is similar to conditional option 2. I do not think I really understand the benefits of option 2. as is. Wouldn't it be doing a lot of work to just unconditionally undo the work of electric indentation and o-a-i without actually turning them off? Finally, given how few people seem to have benefitted from or even noticed org-adapt-indentation, option 1. does seem reasonable to this casual user (who has o-a-i turned off almost accidentally, via org-indent-mode). -- Michał Politowski Talking has been known to lead to communication if practiced carelessly.
Re: export and import github issues
>>> "TC" == Toon Claes writes: > On Mon, Nov 16 2020, Uwe Brauer wrote: >> Hi >> >> Lately I have deal a lot in github issues, so I thought it would be >> nice to use org for this however the only package I could find seems >> org-sync which is from 2012 but does not allow me to connect. >> >> Anybody knows about a working package? > It's not for GitHub, but for GitLab, I've written org-gitlab [1] to fill > me own needs. It's build to fit my workflow, but it might help you to > build something for GitHub that works for you. > At the moment it only does one-way syncing (from GitLab to org). Thanks I will have a look smime.p7s Description: S/MIME cryptographic signature
Re: Changed list indentation behavior: how to revert?
Tom Gillespie writes: > with upstream, but it is clear that upstream has done zero testing on > the impact of that change on org-mode (or any other mode for that matter). I think this statement is too hard. If you use org purely for the example usecase (headings with a single content-line) and use CTRL-RET to create new headings, you won’t notice the change. And I’m pretty sure they tested that. The change hurts for those who use org-mode as plain text with superpowers, or as general source-format that can export to plain text, LaTeX, html, and many more. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Re: More on design of org-contacts.el - Re: [UPDATED PATCH] Re: add new link type "contact:" for org-contacts.el
* stardiviner [2020-11-16 13:21]: :PROPERTIES: :ID: e2c30814-b983-4391-869a-3c700d041467 :END: > > First, thank your very much for suggestion. > > What really I have not found your email in my Gmail (in web > browser), Maybe because it went to Spam/Junk folder. For privacy and safety reasons I do not recommend using Gmail at all. I may recommend using your own email address, requires some money, or https://posteo.de/ https://tutanota.de/ or https://protonmail.ch/ > I found it in mu4e (Emacs). Which I can't reply because I'm in > China, sendmail to Gmail SMTP server is blocked. So I'm replying you > in mu4e. Don't know whether you can receive my message. I wish I could understand, mu4e is only local system that searches emails on your computer. How you send emails depends on your email provider. Maybe you fetch mailing list to search for emails? > Using unique ID is the only solution to identity contact. I already thought > about this. But integrating org-id is hard for me. Have not spent that time on > it yet. But I will, if I want to improve this org-contacts. If I may just give idea. I am using this below function to automatically get ID numbers for headings. Normally it is by saving. Maybe you can do something to automatically insert such number. I do not know if heading is contact, but if it is, it becomes all easier. (defun rcd-org-add-ids-to-headlines-in-file () "Add ID properties to all headlines in the current file which do not already have one." (interactive) (org-map-entries 'org-id-get-create)) > > Each hyperdocument (within or without Emacs) that allows back linking > > to its specifical parts should have a function or key binding to > > quickly obtain the link reference. Once you have decided how is contact referenced as now is referenced by query, I could maybe figure how to obtain the reference. It should not be that hard: - find the current heading - find current ID number - how link should look like could be customizable, maybe heading as visible part. That requires discussion. - prepare link into memory for pasting in other window or document. - it should also be possible to insert such into register. - the option to obtain link by query should be kept intact Maybe two keybindings or functions can be made: ** Proposal :PROPERTIES: :ID: a566d476-f478-44d8-8d91-53f6eccca10b :END: 1. One that finds the current heading and obtains the link (defun capture-contact-by-query-to-heading () (let* ((heading (org-get-heading)) (link (format "[[org-contact:query#%s][%s]]" heading heading))) (kill-new link))) (capture-contact-by-query-to-heading) => [[org-contact:query#Proposal][Proposal]] And such function should be expanded and be customizable: - maybe user wish to provide format string as maybe user wish to know visually that link leads to contact like: => [[org-contact:query#John Doe][Contact: John Doe]] 2. One that finds currentheading by its ID and obtains the link: (defun capture-contact-by-id-to-heading-1 () (let* ((heading (org-get-heading)) (id (org-id-get)) (link (format "[[org-contact:id#%s][%s]]" id heading))) link)) (defun capture-contact-by-id-to-heading () (kill-new (capture-contact-by-id-to-heading-1))) (capture-contact-by-id-to-heading) => [[org-contact:id#a566d476-f478-44d8-8d91-53f6eccca10b][Proposal]] These are design ideas only. You may expand and make checks on these functions that such work properly. Additional functions that may be very usable is to quickly send links to other window. User is collecting the database of contacts in one file and one window and wishes to insert links into other window that references such contacts. In that file where you need a link you would arrive with cursor. Then you go to database of contacts and invoke a key that sends the yanked org link into other window. (defun contact-yank-link-in-other-window () (let ((link (capture-contact-by-id-to-heading-1))) (kill-new link) (other-window 1) (yank) (other-window 1) (message "Yanked link: %s to other window" link))) It is up to you to expand or think on this as it is design proposal. Not finalized function or feature. When we wish to reference things we need it quick and fast. Org mode in general needs these types of functions: - to automatically obtain ANY link from Org mode to the heading and not just for users to write the link by hand. Examples are: - link to specific line - link to query, when text is marked, that link may be constructed, and also if necessary quickly inserted in other window (we use links to reference from same buffer to same buffer or from other buffer and file to other files). Such query could be automatically minimized that it does not carry all the marked words. Few words could be enough. - link to any heading or subheading by its name - link to any heading by its ID or CUSTOM_ID - and so on, there shall be
Re: Bug: Can't toggle off archived tasks in agenda with "v A" [9.4 (9.4-41-g9bb930-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20201116/)]
Gustavo Barros writes: > Hi All, > > The toggling of Archives mode in the agenda, the one which includes > archive files, called with "v A", can be turned on, but turning it off > with "v A" does not currently work. > > > An ECM to reproduce the issue is: Thanks for the report and reproducer. Should be fixed by 104d92199.
Re: Changed list indentation behavior: how to revert?
Good work Greg.
My only comment is about the tests in src blocks. I'm not sure about these
as I always use the special editing mode for source blocks and I would
expect that when you do this, the editing buffer would adopt the semantics
of the native mode for the source language being edited. (I have
org-src-tab-acts-natively t in my init). Were your tests just inside a src
block in an org buffer or inside the special editing buffer?
>From that table and what others have posted, I suspect many would be best
off with org-adapt-indentation set to nil or possible 'heading-data.
Personally, I've not found the change an issue, but I rarely go more than 3
or 4 levels deep in my headlines and am use to C-j to add a non-indented
line. However, I'm thinking about giving heading-data a spin as I like the
indentation for planning lines and have less of a preference for the entry
content.
Tim
On Tue, 17 Nov 2020 at 15:03, Greg Minshall wrote:
> hi, Tim, et al.
>
> i started feeling guilty yesterday, partly for being party to prolonging
> this discussion (though i do think it may be important?). but also for
> realizing i had *not* explored the alternatives Tim, Gustavo, and others
> have suggested.
>
> the following is *clearly* the department of irreproducible results.
> but, i've tried to document the effects of 'electric-indent-mode' and
> 'org-adapt-indentation' on a number of scenarios. i present the results
> with some explanation, but without much analysis.
>
> the irreproducibility is just (afaict) a function of my not being able
> to type the same thing over and over again, and/or transcribe the
> results correctly. the results here are, for the most part, the result
> of several runs, trying to eliminate disparities, and add new forms of
> results (such as, "two , then third returns to column one"). but,
> if anyone wants to try on their own, or automate further (the
> possibilities are endless! :), please, lütfen!
>
> there's an e-lisp function, and the shell double for loop towards the
> end of this e-mail.
>
> first, here's the *transposed* table, as i think it is more readable.
> (the word "transpose" should show up in the info pages!). at the end of
> the e-mail, though, i'll put the non-transposed -- maybe one sees
> some things there easier.
>
> | | t,t | t,headline-data | t,nil | nil,t |
> nil,headline-data | nil,nil |
>
> |---+-+-+-+---+---+---|
> | head | n | n,nbl,1 | 1 | 1 |
> 1 | 1 |
> | head | 1 | 1 | 1 | n |
> n,nbl,1 | 1 |
> | src{ | n | n+2 | n+2 | 1 |
> 1 | 1 |
> | src{ | 1 | 1 | 1 | n+2 [t-2] |
> n+2 [t-2] | n+2 [t-2] |
> | src; | n-4 | n-2 | n-2 | 1 |
> 1 | 1 |
> | src; | 1 | 1 | 1 | n-2 [t+2] |
> n-2 [t+2] | n-2 [t+2] |
> | list | n+2*2,1 | 1 | n+2*2,1 | 1 |
> 1 | 1 |
> | list | 1 | 1 | 1 | n+2*2,1 |
> 1 | n+2*2,1 |
> | line | n | 1 | n | 1 |
> 1 | 1 |
> | line | 1 | 1 | 1 | n |
> 1 | n |
>
> the columns are (electric-indent,org-adapt-indentation) pairs.
>
> here are the cases (rows) and results (contents of cells). the
> ""-suffixed cases use C-j rather than .
>
> - head :: from a headline
> - n :: stays indented for "infinite" blank
> - n,nbl,1 :: n, then after first non-blank line, goes
> to 1
> - 1 :: goes
> - src{ :: from, e.g., 'if (x) {'
> - n-2 :: undents by 2
> - n+2 :: indents
> - n+2 [t-2] :: goes to n+2 (but, of non-blank line goes to
> n+4)
> - n-2 [t+2] :: goes to n-2 (but, that 2 past the previous
> indentation level)
> - src; :: from a regular program statement
> - list :: from item in list
> - n+2 :: indents once
> - n+2*2,1 :: indents once, stays on next , then 1 on next
> (three total)
> - 1 :: column 1
> - line :: from an indented line
> - n :: never goes to 1
> - 1 :: goes to 1
>
>
> brute force lisp code
> #+begin_src elisp
> (defun feorge (el oai fname)
> (progn
> (add-hook 'org-mode-hook (electric-indent-mode (if el 1 0)))
> (find-file fname)
> (setq org-adapt-indentation oai)
> (let
> ((header "| |head | head | src{ | src{ | src; |
> src; | list | list | line | line|")
> (hline "|-+-+-+-+-+-+-+-+-+-+-|")
> (results (format "| %s,%s | ||" electric-indent-mode
> org-adapt-indentation)))
> (goto-char (point-max))
> (insert (format "el %s; oai %s" el oai))
> (goto-char (point-max))
> (newline)
> (insert (version))
> (goto-char (point-max))
> (newline)
> (insert (org-version))
> (goto-char (point-max))
>
Re:Re: Agenda follow mode + indirect window settings
At 2020-11-17 12:52:06, "Kyle Meyer" wrote: >Gerardo Moro writes: > >> Hi, >> >> I want my agenda to have follow-mode active when starting Emacs. >> I suppose this would do the trick? >> >> (setq org-agenda-start-with-follow-mode t) >> (setq org-agenda-follow-indirect t) >> >> 1) Do I need both? I have observed that having only the second one does not >> work. > >The first one causes new agenda buffers to start with >org-agenda-follow-mode enabled. Even if it's not enabled initially, you >can toggle it with F. > >The second is in effect when org-agenda-follow-mode is enabled. > >> 2) Is there a way to make the "indirect" window populate the vertically >> existing window (I always work with the frame split in two vertically). >> Right now it shows in a very small window beneath the agenda. > >I think with the way things are written at the moment you're best bet >would be to try to rearrange afterwards (say with advice after >org-agenda-tree-to-indirect-buffer). Ideally the current behavior would >be achieved in a way that would allow the user to control the result >with things like display-buffer-overriding-action and >display-buffer-alist, but I suspect that'd take a substantial rework. I use the below config, maybe useful... (define-key org-agenda-mode-map (kbd "SPC") 'eh-org-agenda-show-and-scroll-up) (define-key org-agenda-mode-map (kbd "") 'eh-org-agenda-show-and-scroll-up) (defvar eh-org-agenda-show-window-point nil) (defun eh-org-agenda-show-and-scroll-up ( arg) (interactive "P") (let ((win (selected-window))) (if (and (window-live-p org-agenda-show-window) (eq this-command last-command)) (progn (select-window org-agenda-show-window) (if (eq eh-org-agenda-show-window-point (window-point)) (progn (goto-char (point-min)) (message "已经滚动到底，返回第一行！")) (ignore-errors (scroll-up)) (setq eh-org-agenda-show-window-point (window-point (org-agenda-goto t) (org-show-entry) (let ((org-indirect-buffer-display 'current-window)) (org-tree-to-indirect-buffer) ;; 隐藏 indirect buffer (rename-buffer (concat " " (buffer-name (if arg (org-cycle-hide-drawers 'children) (org-with-wide-buffer (narrow-to-region (org-entry-beginning-position) (org-entry-end-position)) (org-show-all '(drawers (setq org-agenda-show-window (selected-window))) (select-window win)))
Re: Agenda follow mode + indirect window settings
Gerardo Moro writes: > Hi, > > I want my agenda to have follow-mode active when starting Emacs. > I suppose this would do the trick? > > (setq org-agenda-start-with-follow-mode t) > (setq org-agenda-follow-indirect t) > > 1) Do I need both? I have observed that having only the second one does not > work. The first one causes new agenda buffers to start with org-agenda-follow-mode enabled. Even if it's not enabled initially, you can toggle it with F. The second is in effect when org-agenda-follow-mode is enabled. > 2) Is there a way to make the "indirect" window populate the vertically > existing window (I always work with the frame split in two vertically). > Right now it shows in a very small window beneath the agenda. I think with the way things are written at the moment you're best bet would be to try to rearrange afterwards (say with advice after org-agenda-tree-to-indirect-buffer). Ideally the current behavior would be achieved in a way that would allow the user to control the result with things like display-buffer-overriding-action and display-buffer-alist, but I suspect that'd take a substantial rework.
Re: [PATCH] lisp/org.el: Allow hiding #+SUBTITLE: keyword via `org-hidden-keywords'
Titus von der Malsburg writes: > Updated patch attached. Thanks. Applied (8bade78ce).
Re: Changed list indentation behavior: how to revert?
hi, Tim, et al.
i started feeling guilty yesterday, partly for being party to prolonging
this discussion (though i do think it may be important?). but also for
realizing i had *not* explored the alternatives Tim, Gustavo, and others
have suggested.
the following is *clearly* the department of irreproducible results.
but, i've tried to document the effects of 'electric-indent-mode' and
'org-adapt-indentation' on a number of scenarios. i present the results
with some explanation, but without much analysis.
the irreproducibility is just (afaict) a function of my not being able
to type the same thing over and over again, and/or transcribe the
results correctly. the results here are, for the most part, the result
of several runs, trying to eliminate disparities, and add new forms of
results (such as, "two , then third returns to column one"). but,
if anyone wants to try on their own, or automate further (the
possibilities are endless! :), please, lütfen!
there's an e-lisp function, and the shell double for loop towards the
end of this e-mail.
first, here's the *transposed* table, as i think it is more readable.
(the word "transpose" should show up in the info pages!). at the end of
the e-mail, though, i'll put the non-transposed -- maybe one sees
some things there easier.
| | t,t | t,headline-data | t,nil | nil,t |
nil,headline-data | nil,nil |
|---+-+-+-+---+---+---|
| head | n | n,nbl,1 | 1 | 1 |
1 | 1 |
| head | 1 | 1 | 1 | n |
n,nbl,1 | 1 |
| src{ | n | n+2 | n+2 | 1 |
1 | 1 |
| src{ | 1 | 1 | 1 | n+2 [t-2] | n+2
[t-2] | n+2 [t-2] |
| src; | n-4 | n-2 | n-2 | 1 |
1 | 1 |
| src; | 1 | 1 | 1 | n-2 [t+2] | n-2
[t+2] | n-2 [t+2] |
| list | n+2*2,1 | 1 | n+2*2,1 | 1 |
1 | 1 |
| list | 1 | 1 | 1 | n+2*2,1 |
1 | n+2*2,1 |
| line | n | 1 | n | 1 |
1 | 1 |
| line | 1 | 1 | 1 | n |
1 | n |
the columns are (electric-indent,org-adapt-indentation) pairs.
here are the cases (rows) and results (contents of cells). the
""-suffixed cases use C-j rather than .
- head :: from a headline
- n :: stays indented for "infinite" blank
- n,nbl,1 :: n, then after first non-blank line, goes
to 1
- 1 :: goes
- src{ :: from, e.g., 'if (x) {'
- n-2 :: undents by 2
- n+2 :: indents
- n+2 [t-2] :: goes to n+2 (but, of non-blank line goes to
n+4)
- n-2 [t+2] :: goes to n-2 (but, that 2 past the previous
indentation level)
- src; :: from a regular program statement
- list :: from item in list
- n+2 :: indents once
- n+2*2,1 :: indents once, stays on next , then 1 on next
(three total)
- 1 :: column 1
- line :: from an indented line
- n :: never goes to 1
- 1 :: goes to 1
brute force lisp code
#+begin_src elisp
(defun feorge (el oai fname)
(progn
(add-hook 'org-mode-hook (electric-indent-mode (if el 1 0)))
(find-file fname)
(setq org-adapt-indentation oai)
(let
((header "| |head | head | src{ | src{ | src; | src; |
list | list | line | line|")
(hline "|-+-+-+-+-+-+-+-+-+-+-|")
(results (format "| %s,%s | ||" electric-indent-mode
org-adapt-indentation)))
(goto-char (point-max))
(insert (format "el %s; oai %s" el oai))
(goto-char (point-max))
(newline)
(insert (version))
(goto-char (point-max))
(newline)
(insert (org-version))
(goto-char (point-max))
(newline)
(insert header)
(goto-char (point-max))
(newline)
(insert hline)
(goto-char (point-max))
(newline)
(insert results)
(goto-char (point-max))
(newline)
(goto-char (point-max))
(newline
#+end_src
and, the shell loop-de-loop
#+begin_src sh
for el in t nil; do
for oai in t \'headline-data nil; do
rm -f *x.org*;
emacs -l ~/tmp/feorge.el --eval "(feorge ${el} ${oai} \"x.org\")";
done;
done
#+end_src
untransposed table:
| |head | head | src{ | src{ | src; | src;
| list | list | line | line |
|---+-+---+--+---+--+---+---+---+--+---|
| t,t | n | 1 | n| 1 | n-4 | 1
| n+2*2,1 | 1 |n | 1 |
| t,headline-data | n,nbl,1 | 1 | n+2 | 1 | n-2 | 1
| 1 | 1 |1 | 1 |
| t,nil
Re: Changed list indentation behavior: how to revert?
Terry, Thank you very much for the clear articulation of the problem, it enable me to see what the issue is and find more and deeper issues with the change. Speaking as someone who was not affected by this change due to the peculiarities of my config, let me say as a fairly impartial participant, this change is completely broken and it is clear upstream Emacs did zero due diligence on the impact it would have for org-mode. The current implementation of elastic-indent-mode is obviously broken for use in org. What do I mean? Currently, electric-intent-mode t is actively destructive in certain cases. Consider a headline created by *-space or M-ret. If you then hit return (because you don't know what to call that headline but have the idea you want to type) electric-intent-mode will delete the trailing space making it no longer a headline WHAT?! This is horrible broken behavior in org mode! At the very least this must be fixed if electric-indent-mode is to be on by default in org-mode. It is clear that electric-indent-mode as implemented, is unsuitable for use in org-mode since it actively ignores significant trailing whitespace. The sane thing to do is to revert to electric-indent-mode nil at least until the obvious brokeness is fixed, and even then, why make people undo a stupid computer decision by typing backspace when they can just as easily do what they mean by typing tab!??! We don't even have to poll the community to figure out who is going to be forced to type more. I don't mean to sound ungrateful to the folks who have worked to match with upstream, but it is clear that upstream has done zero testing on the impact of that change on org-mode (or any other mode for that matter). Until the upstream behavior can be fixed or org can patch the brokenness this needs to be reverted. Even then, why is the "smart" option that changes the meaning of the bloody return key enabled by default? I will point back to https://orgmode.org/list/87ees6fp8r@nicolasgoaziou.fr/ and state that had I spotted this thread at the time, I would have spoken up to point out that it would likely not be a welcome change, as this thread shows. The good news is that all is not lost and now when users want electric-indent-mode in org it will be consistent with upstream. Best, Tom
Re: Changed list indentation behavior: how to revert?
Tim Cross writes: > There are only two mechanisms by which org-mode is upgraded and as far > as I know, both require that the user either initiates the update or > turns on automatic updates. Your argument would be more compelling for > me if we were talking about updates which occur without user > intervention or control. In my case org is updated automatically. I use rolling release distros. There’s never a time when I say “now I get all the new versions, let’s look for breakage”. > Change is inevitable and such changes will from time to time, break > things. Is breakage truly inevitable? Do fundamentals of org have to change? If some small detail changes in a convoluted setup I have, that’s something I can cope with. That there are packages that almost never break and packages that almost always break on update, but little in-between sounds like most breakage isn’t inevitable. Here’s the source for the statement: https://stevelosh.com/blog/2012/04/volatile-software/ It makes my point much more succintly: -- -- -- -- -- -- When I'm updating a piece of software there's a good chance it's not because I'm specifically updating that program. I might be: - Moving to a new computer. - Running a "$PACKAGE_MANAGER update" command. - Moving a website to a bigger VPS and reinstalling all the libraries. In those cases (and many others) I'm not reading the release notes for a specific program or library. I'm not going to find out about the brokenness until I try to use the program the next time. -- -- -- -- -- -- and a second point: -- -- -- -- -- -- This may just be an artifact of how my brain is wired, but I actually get a sense of satisfaction from writing code that bridges the gap between older versions and new. I can almost hear a little voice in my head saying: "Mwahaha, I'll slip this refactoring past them and they'll never even know it happened!" Maybe it's just me, but I think that "glue" code can be clever and beautiful in its own right. It may not bring a smile to anyone's face like a shiny new feature, but it prevents many frowns instead, and preventing a frown makes the world a happier place just as much as creating a smile! -- -- -- -- -- -- > With respect to the current issue about line indentation. I think the > key question here is was communication of this change sufficient and if > not, what can be done to make such communication more effective. It cannot be made effective enough. If you make it effective enough, the other gazillion packages on the system will use the same mechanism and that will make it ineffective again. The only way that works is to avoid breakage on update — except for the few cases where it is truly unavoidable. We have the discussion here, because many people disagree with the notion that the current breakage was unavoidable. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Re: Changed list indentation behavior: how to revert?
Tim Cross writes: > At the same time, us users also need to take on some of the > responsibility and recognise that major version upgrades may break or > change their workflow. If you have a situation where stability of your > environment is critical to your work and your strapped for time so that > any change will be unacceptably disruptive, you need to adopt an upgrade > workflow which mitigates that risk. I had that on an OLPC where I had everything working and avoided any changes that weren’t necessary, because I used it for writing. It was perfect. There was a catch, though: It used a custom kernel and the config did not work with newer versions. And I did not manage to change that with some 20 hours of trying. But that did not hurt me, I had my emacs and could play music for writing and roleplaying games. Then the config for the new Emacs version on the desktop and the version on the OLPC became incompatible, so I upgraded the OLPC to be able to transfer the changes (I needed them so I could use the config in the repository to be able to run the exporter for the writing — I also had a full texlive on there). That was right around the time udev got introduced as mandatory dependency. And that needed a newer kernel to avoid breaking the audio. I have not been able to restore sound output to the OLPC in the past half decade. And all ways I tried to fix the problem — including other distros — failed in some ways. Sad story short: Having to update is a fact of life. Stuff that breaks on update is a liability. Most of the times org-mode has been pretty good at it, but the few breakages it had did actually cost me quite some time (one example is that lecture-slides did not export cleanly anymore after the exporter updates). Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Re: Changed list indentation behavior: how to revert?
Tom Gillespie writes: > Would it help if major releases maintained a mini-config that if added > to init.el would allow users to retain old behavior? That way they > wouldn't have to read the NEWS but could just add the relevant lines, > or maybe even just call the org-old-default-behavior-9.1 or > org-old-default-behavior-9.4. The workflow during development would be > to account for any change to defaults in those functions. Thoughts? > Tom This would ease the pain temporarily but not fix the problem. The next time you sit down with a colleague to show org-mode you’ll be searching in your config for the change to go back to the old default. The problem is that you have to do stuff after an update to undo breakage. This is a conservative stance — I have gotten more conservative in what I want from my software over the years. I want to learn tools that just keep working because I can only become really good in those. It’s only there that investing much time into learning them actually pays off. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Re: Changed list indentation behavior: how to revert?
Hello all, I apologize in advance that this is so long. I've been following this thread closely, because I've been using Org mode daily for well over a decade, and this behavior affects me in several important ways. I think this summary might be helpful. Forever, it has been possible to start a heading in Org by typing a return one or more times, then typing an asterisk and a space and the heading text. To add a series of headings, just keep hitting return at the end of the current one, type an asterisk and a space and the next one, then repeat. If you want subheadings, it is as simple as typing more asterisks. Easy. This worked because electric-indent-mode defaulted to off, and although org-adapt-indentation defaulted to t, it didn't affect this situation. The default behavior here matters because Org is a killer feature of Emacs, enticing many people to give it a try, including my nine-year-old daughter. For them, it should behave by default the way it looks like it should. That means, typing asterisks and text for headings, followed by returns, and text, and more asterisks, should just work by default. #+NAME: Old Defaults: electric-indent-mode OFF and org-adapt-indent t #+begin_example org ,* Testing out Org, type here once or twice I get it! I'll type once or twice again and start a subheading. ,** Headings are easy! Now another or two for subhead content This is awesome! It works just as I expect, and I don't have to memorize a bunch of key chords just to get started. And folding is awesome! I love Org! I will stick with it and learn it all! #+end_example I have probably typed close to a million headings like this all by myself, and collectively we have probably typed billions or more. The last release, as everyone knows, turned on electric-indent-mode by default. So, right now, typing an Org document with default settings does not work like it looks like it should. This is the new experience for people used to the old defaults, and beginners like my daughter: #+NAME: New Defaults: electric-indent-mode ON and org-adapt-indent t #+begin_example org ,* I typed an asterisk for this heading, how about here once or twice Okay. This is indented. Since I'm new, I don't realize it isn't useful yet, or that it makes a difference at all. How about a subheading? I'll hit a couple times, they type two asterisks. ,** Is this a subheading? It looks like one. again here ... Okay, the indentation isn't the same, but maybe it's okay? I probably didn't even notice. ,*** I think I'm organizing my document with *'s and 's I'm going to try folding my stuff, becaue I saw that and it looks awesome. Wait! The instructions say will cycle the folding, but it only works on the top level. What? Okay, some searching said I have to modify init, or something, or type some weird key combinations. What? This looked like it was going to be easy. Nerds are liars. I can't figure this out, and I don't have time to mess with this. I'm going back to Word. Maybe I'll try Markdown tomorrow. #+end_example For new users, step one is either to start changing default settings, start learning key chords and/or arcane (to beginners) commands---or go back to Word or Markdown. Turning on electric-indent-mode, all by itself, shouldn't break the useful or customary indentation that the users of Org expect, but it has. Instead of starting a new heading by typing one or more times, then typing an asterisk and a space and a new heading, a user has to either hit some control characters with returns, or backspace to column zero, or something else. The manual shows heading and body formatting as this: #+NAME: Org Manual Sample: electric-indent-mode on, org-adapt-indent t #+begin_example org ,* Top level headline ,** Second level ,*** Third level some text ,*** Third level more text ,* Another top level headline #+end_example I don't recall ever seeing an Org document in real life with the body indented at the level of each heading, and I haven't seen anyone argue for that behavior on this thread. I've tried it, and the text body width rapidly becomes too narrow to be useful. As several people have noted, even the Org repositories turn this off, which suggests even the developers don't find it useful. Why this is set as the default, I have no idea, but it didn't really matter until now. An Org document looks like you can create it by typing asterisks, text, and returns, but you can't, not by default, anyway. That's the root of the problem: the longstanding default *behavior* has been changed. The only people unaffected are people who already had compensatory settings in their init files. As far as I can tell, turning on electric-indent-mode by default was done for no reason other than other Emacs modes have it as a default. The proper fix for this is one of two choices: 1. If keeping electric-indent-mode on is really important, the easiest way to
Re: Changed list indentation behavior: how to revert?
> > Ugh, I update my emacs package pretty infrequently and I usually have 30 or > > more packages updating at a time -- I can't see wading through 30 NEWS > > files searching for landmines... > > > > Yes, this I think is a problem. Most of those packages probably only > have minor changes and bug fixes. We really need some way to be able to > sort or grade those packages based on whether they are minor or major > upgrades. Some sort of metric which would let you gauge the amount of > change and decide if checking the NEWS file would be advisable. An aside. This is one of the reasons that I generally oppose breaking up repositories into smaller projects. Some users want more frequent updates to some parts of a codebase, but they are usually outliers. The end result is that splitting the repo pushes more and more work onto the users, most of whom receive no benefit since they are not bleeding edgers, because now it is up to them to determine compatibility, read the NEWS, etc. Sometimes deeper coupling can actually help. For example in this thread if Emacs and Org were more tightly coupled in their releases then the changes to electric indent mode might not have gone through at all, or might have been delayed until Org could coordinate the change so that users only had to deal with it once. Do we actually want Org and Emacs development to be more coupled? Probably not, but I suspect there is a systematic bias on the part of more frequent participants to want greater decoupling because they are often engaged in the development process and thus have a skewed perspective on what is important --- namely to make development easier.
Re: Changed list indentation behavior: how to revert?
> If people don't have time to read the NEWS file, I also doubt they would > be aware of the mini config file or have the time to add it to their > setup. There would be an additional burden on developers to maintain the > mini-config which might not actually result in any real benefit. I would > also be concerned this might setup an expectation which is difficult to > meet. It may not always be straight-forward to provide such a > mini-config and sometimes, it may actually be in the best interests of > the user to force a change on them because it brings other benefits that > outweigh the initial 'change pain'. Clearly this would not work for all types of changes. However there are numerous cases where a variable is changed from t to nil or similar where such functionality would be straightforward to implement and might be able to cover 80% of these kinds of issues. It should be entirely possible to teach users that as part of their upgrade process there is an option that they can set or command they can invoke which will automatically make changes to their config to preserve old default behavior. M-x org-post-update-restore-old-defaults or something. There are also intermediate changes such as the addition of the :extend keyword for faces which was given a default value that changed existing behavior by defaulting to nil instead of t. This kind of change is a combination of useful, annoying, and hard to fix without reading the NEWS if it is something that breaks your workflow. Emacs is usually pretty good about avoiding these kinds of major changes in behavior but sometimes the slip through and sometimes a change does need to be made and the best time to do so is as soon as possible. I suspect that this might be an area where org could benefit from more extensive testing coverage. There was a change between 9.1 and 9.3 that completely broke org babel edit src functionality because it did not correctly restore the window layout on exit. Now we just need to find people willing to write the tests in addition to notifying the mailing list :D. Best, Tom
Re: Changed list indentation behavior: how to revert?
Bill Burdick writes: > Ugh, I update my emacs package pretty infrequently and I usually have 30 or > more packages updating at a time -- I can't see wading through 30 NEWS > files searching for landmines... > Yes, this I think is a problem. Most of those packages probably only have minor changes and bug fixes. We really need some way to be able to sort or grade those packages based on whether they are minor or major upgrades. Some sort of metric which would let you gauge the amount of change and decide if checking the NEWS file would be advisable. -- Tim Cross
How to avoid additional blank lines in html export of list
Hi, exporting the list example in chapter 2.6 of orgmode manual 1. The attack of the Rohirrim 2. Eowyn's fight with the witch king + this was already my favorite scene in the book + I really like Miranda Otto. 3. Peter Jackson being shot by Legolas - on DVD only He makes a really funny face when it happens. to html the browser shows the output: 1. The attack of the Rohirrim 2. Eowyn's fight with the witch king * this was already my favorite scene in the book * I really like Miranda Otto. 3. Peter Jackson being shot by Legolas * on DVD only He makes a really funny face when it happens. Is it possible to avoid the ugly blank lines? Removing the last line of the source, the output looks like 1. The attack of the Rohirrim 2. Eowyn's fight with the witch king * this was already my favorite scene in the book * I really like Miranda Otto. 3. Peter Jackson being shot by Legolas * on DVD only That’s fine. Johannes
Re: Changed list indentation behavior: how to revert?
Tom Gillespie writes: > Semver is unlikely to help because the question is what is "broken" by > a change in version. Semver would likely be about breaking changes to > internal org apis, not changes to default behavior that affect users, > so you have two different "semantics" which put us right back where we > are now -- to know what really changed you have to read the NEWS. > Bastien has also talked about hear-ye versioning, which says when a > version changes users need to read the news. Best, > Tom > The 'hard' part of me says that if you upgrade org to a new major version, don't read the NEWS file and are then surprised by changes, you get what you deserve. Perhaps a tad too hard, but I do think users need to take more responsibility here. At the same time, I do think there are some things we could do to help them. I've mentioned in another message that the way MELPA and other repositories report versions is not helpful. All I get from the package names now is that a new version has arrived and the date it was released. There is no indication whether the new version is just bug fixes, new functionality or a major new version. I only know this by following this list. What can we do to encourage users to read the NEWS file? Would it be feasible to add code so that the first time someone opens an org file after a major version upgrade the NEWS file is displayed? Would it be useful to document ways of pinning package versions or implementing package rollback functionality? -- Tim Cross
Re: Changed list indentation behavior: how to revert?
Heh, I had time to read EMACS NEWS when I used it in 1985 (and still do for new EMACS versions). Now there are s many packages, each with their own news... -- Bill On Mon, Nov 16, 2020 at 10:59 PM Tim Cross wrote: > > Tom Gillespie writes: > > > Would it help if major releases maintained a mini-config that if added > > to init.el would allow users to retain old behavior? That way they > > wouldn't have to read the NEWS but could just add the relevant lines, > > or maybe even just call the org-old-default-behavior-9.1 or > > org-old-default-behavior-9.4. The workflow during development would be > > to account for any change to defaults in those functions. Thoughts? > > Tom > > If people don't have time to read the NEWS file, I also doubt they would > be aware of the mini config file or have the time to add it to their > setup. There would be an additional burden on developers to maintain the > mini-config which might not actually result in any real benefit. I would > also be concerned this might setup an expectation which is difficult to > meet. It may not always be straight-forward to provide such a > mini-config and sometimes, it may actually be in the best interests of > the user to force a change on them because it brings other benefits that > outweigh the initial 'change pain'. > > I do wonder if Org would benefit from adopting semantic versioning? This > could provide a way to convey more information to the user in the > version number e.g x.y.z => MAJOR.MINOR.PATCH where > > - PATCH = bug fix only. No changes to API or interface > - MINOR = extensions (additions) to API or interface, but no change to > existing API and interface > - MAJOR = breaking change - either API or interface has changed > > In general, my experience has been that the org developers have worked > hard to keep things stable in a very complex environment. The challenge > is when there is a breaking change, how to effectively communicate this > and minimise surprises for the user and how to accurately gauge the > impact from a change. > > At the same time, us users also need to take on some of the > responsibility and recognise that major version upgrades may break or > change their workflow. If you have a situation where stability of your > environment is critical to your work and your strapped for time so that > any change will be unacceptably disruptive, you need to adopt an upgrade > workflow which mitigates that risk. For example, my workflow allows me > to roll back any package which I upgrade. If I upgrade a package and it > breaks things and I don't have time to troubleshoot, I can roll it back. > Some distributions also include this feature. This is one area where I > feel the ELPA system could be improved. Right now, if you use the > org-plus-contrib package (or the org package) from either the org or > melpa package, it reports as something like org-plus-contrib-20201118, > which tells me very little apart from there is an update. I cannot tell > from this name if it is a major, minor or bug fix update. Not a big deal > for me as I can always roll back, but not everyone has that ability. > > Change is inevitable and if we focus too much on not changing existing > behaviour or API, we run the risk of overly constraining development. > Communication of change is a challenge, but critically important. I feel > we would get the most benefit by focusing on how to communicate breaking > changes effectively and ensure when such change is introduced, as far as > possible, details on how to restore the previous behaviour are provided. > > > -- > Tim Cross > >
Re: Changed list indentation behavior: how to revert?
Dr. Arne Babenhauserheide writes: > Tim Cross writes: >> I can completely understand your position. However, I wanted to point >> out that this change was documented in the org NEWS file, where all >> version changes are documented. When upgrading to a new version of org, >> everyone should look there, ideally before the upgrade or soon >> afterwards and definitely when you notice some changed behaviour. It >> will save hours of trouble shooting and often tells you how to restore >> previous behaviour. A very under appreciated piece of valuable >> documentation. > > I would like to agree, because I wish people would also read NEWS for my > projects, but since I use at least 10-20 programs daily which depend on > hundreds of libraries that might change their behavior, that’s > unrealistic. > > I cannot read NEWS entries whenever my distro updates org-mode, > therefore I depend on org-mode not breaking during updates. > > If an update changes behavior in a way that requires people to read up > on stuff to find out how to continue working, that means that the > program breaks with that update. > > I’ve been more liberal on that point before I saw the problems that > arose from the Python2->Python3 transition. Many changes that each seem > small on their own can cause significant damage, because there will > always be some people that get hit by them during a period in their life > when they cannot follow them, because they are fully occupied by work > (mentally or because of little time) so the tools they trained with must > just keep working. > I understand where your coming from, but feel you are over stating the problem. The Python version change is an extreme example. The maintainers of Python made the decision that such a fundamental change was critically important for the long-term viability of the language and there was no way to implement that change which was not going to be extremely disruptive. I don't know enough about the internals of Python to have an opinion on whether it was a good or bad decision. There are only two mechanisms by which org-mode is upgraded and as far as I know, both require that the user either initiates the update or turns on automatic updates. Your argument would be more compelling for me if we were talking about updates which occur without user intervention or control. Org is only updated if you update your OS distribution to a new major version and the version of Emacs is updated (or you manually update Emacs) or you use the MELPA or org repositories and request an upgrade. The ELPA system also includes the ability to 'pin' a package to a specific version to prevent upgrades. Change is inevitable and such changes will from time to time, break things. If stability in an environment is the priority, then it is up to the user who maintains that environment to manage things in such a way as to preserve that stability. Developers of tools and libraries cannot bare that responsibility because they cannot accurately assess how change will impact all users in all environments. Their responsibility is to effectively communicate what has changed to enable the user/maintainer to make the appropriate decisions regarding what to upgrade and when and to not introduce arbitrary changes that are not justified. To expect things to never change is unrealistic. With respect to the current issue about line indentation. I think the key question here is was communication of this change sufficient and if not, what can be done to make such communication more effective. It would seem, for whatever reason, few people read the NEWS file, so perhaps other mechanisms need to be introduced. I have mentioned in another message that semantic versioning might be one way to help users manage updates, but I'm sure there are other and likely more effective ideas out there that could help. Perhaps some documentation on what people can do to improve stability in their environments e.g. pinning ELPA packages to specific versions, implementing package rollback functionality, etc. Tim -- Tim Cross
Re: add linked files to agenda files
Alan Schmitt writes: > Hello, > > I'm experimenting with a setup where each project is its own org file, > and where I have a master file linking to active projects. How can I > configure org to add every linked file of that master file to the > org-agenda-files? > You'll probably have to write a custom function to do that, but it depends on how exactly your master file is set-up, so providing some details on that would help. Just guessing at this point, I would imagine you'd want something like this: --8<---cut here---start->8--- (defun path-from-link (link) (org-element-property :path link)) (setq org-agenda-files (with-current-buffer (find-file-noselect "master.org") (org-element-map (org-element-parse-buffer) '(link) #'path-from-link))) --8<---cut here---end--->8--- but the details might make a difference. -- Nick "There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors." -Martin Fowler
Re: Changed list indentation behavior: how to revert?
Tom Gillespie writes: > Would it help if major releases maintained a mini-config that if added > to init.el would allow users to retain old behavior? That way they > wouldn't have to read the NEWS but could just add the relevant lines, > or maybe even just call the org-old-default-behavior-9.1 or > org-old-default-behavior-9.4. The workflow during development would be > to account for any change to defaults in those functions. Thoughts? > Tom If people don't have time to read the NEWS file, I also doubt they would be aware of the mini config file or have the time to add it to their setup. There would be an additional burden on developers to maintain the mini-config which might not actually result in any real benefit. I would also be concerned this might setup an expectation which is difficult to meet. It may not always be straight-forward to provide such a mini-config and sometimes, it may actually be in the best interests of the user to force a change on them because it brings other benefits that outweigh the initial 'change pain'. I do wonder if Org would benefit from adopting semantic versioning? This could provide a way to convey more information to the user in the version number e.g x.y.z => MAJOR.MINOR.PATCH where - PATCH = bug fix only. No changes to API or interface - MINOR = extensions (additions) to API or interface, but no change to existing API and interface - MAJOR = breaking change - either API or interface has changed In general, my experience has been that the org developers have worked hard to keep things stable in a very complex environment. The challenge is when there is a breaking change, how to effectively communicate this and minimise surprises for the user and how to accurately gauge the impact from a change. At the same time, us users also need to take on some of the responsibility and recognise that major version upgrades may break or change their workflow. If you have a situation where stability of your environment is critical to your work and your strapped for time so that any change will be unacceptably disruptive, you need to adopt an upgrade workflow which mitigates that risk. For example, my workflow allows me to roll back any package which I upgrade. If I upgrade a package and it breaks things and I don't have time to troubleshoot, I can roll it back. Some distributions also include this feature. This is one area where I feel the ELPA system could be improved. Right now, if you use the org-plus-contrib package (or the org package) from either the org or melpa package, it reports as something like org-plus-contrib-20201118, which tells me very little apart from there is an update. I cannot tell from this name if it is a major, minor or bug fix update. Not a big deal for me as I can always roll back, but not everyone has that ability. Change is inevitable and if we focus too much on not changing existing behaviour or API, we run the risk of overly constraining development. Communication of change is a challenge, but critically important. I feel we would get the most benefit by focusing on how to communicate breaking changes effectively and ensure when such change is introduced, as far as possible, details on how to restore the previous behaviour are provided. -- Tim Cross
Re: Changed list indentation behavior: how to revert?
Right there with you. My primary org file has a section filled with rage when some default gets changed in org or some other part of Emacs. The vast majority of the time the underlying change was in the NEWS. Since there is already a habit of updating the NEWS it doesn't seem unreasonable to put all those changes somewhere in an elisp file that could restore old default behavior. On Mon, Nov 16, 2020 at 2:41 PM Bill Burdick wrote: > > Ugh, I update my emacs package pretty infrequently and I usually have 30 or > more packages updating at a time -- I can't see wading through 30 NEWS files > searching for landmines... > > > -- Bill > > > On Mon, Nov 16, 2020 at 9:10 PM Tom Gillespie wrote: >> >> Semver is unlikely to help because the question is what is "broken" by >> a change in version. Semver would likely be about breaking changes to >> internal org apis, not changes to default behavior that affect users, >> so you have two different "semantics" which put us right back where we >> are now -- to know what really changed you have to read the NEWS. >> Bastien has also talked about hear-ye versioning, which says when a >> version changes users need to read the news. Best, >> Tom >> >> >> On Mon, Nov 16, 2020 at 1:15 PM gyro funch wrote: >> > >> > On 11/16/2020 9:26 AM, Tom Gillespie wrote: >> > > Would it help if major releases maintained a mini-config that if added >> > > to init.el would allow users to retain old behavior? That way they >> > > wouldn't have to read the NEWS but could just add the relevant lines, >> > > or maybe even just call the org-old-default-behavior-9.1 or >> > > org-old-default-behavior-9.4. The workflow during development would be >> > > to account for any change to defaults in those functions. Thoughts? >> > > Tom >> > > >> > > >> > >> > I hate to open a new can of worms, but could semantic versioning be used >> > such that it is obvious when there are changes that are not backwards >> > compatible? >> > >> > -gyro >> > >> > >>
Re: Changed list indentation behavior: how to revert?
Ugh, I update my emacs package pretty infrequently and I usually have 30 or more packages updating at a time -- I can't see wading through 30 NEWS files searching for landmines... -- Bill On Mon, Nov 16, 2020 at 9:10 PM Tom Gillespie wrote: > Semver is unlikely to help because the question is what is "broken" by > a change in version. Semver would likely be about breaking changes to > internal org apis, not changes to default behavior that affect users, > so you have two different "semantics" which put us right back where we > are now -- to know what really changed you have to read the NEWS. > Bastien has also talked about hear-ye versioning, which says when a > version changes users need to read the news. Best, > Tom > > > On Mon, Nov 16, 2020 at 1:15 PM gyro funch wrote: > > > > On 11/16/2020 9:26 AM, Tom Gillespie wrote: > > > Would it help if major releases maintained a mini-config that if added > > > to init.el would allow users to retain old behavior? That way they > > > wouldn't have to read the NEWS but could just add the relevant lines, > > > or maybe even just call the org-old-default-behavior-9.1 or > > > org-old-default-behavior-9.4. The workflow during development would be > > > to account for any change to defaults in those functions. Thoughts? > > > Tom > > > > > > > > > > I hate to open a new can of worms, but could semantic versioning be used > > such that it is obvious when there are changes that are not backwards > > compatible? > > > > -gyro > > > > > >
Re: Changed list indentation behavior: how to revert?
Semver is unlikely to help because the question is what is "broken" by a change in version. Semver would likely be about breaking changes to internal org apis, not changes to default behavior that affect users, so you have two different "semantics" which put us right back where we are now -- to know what really changed you have to read the NEWS. Bastien has also talked about hear-ye versioning, which says when a version changes users need to read the news. Best, Tom On Mon, Nov 16, 2020 at 1:15 PM gyro funch wrote: > > On 11/16/2020 9:26 AM, Tom Gillespie wrote: > > Would it help if major releases maintained a mini-config that if added > > to init.el would allow users to retain old behavior? That way they > > wouldn't have to read the NEWS but could just add the relevant lines, > > or maybe even just call the org-old-default-behavior-9.1 or > > org-old-default-behavior-9.4. The workflow during development would be > > to account for any change to defaults in those functions. Thoughts? > > Tom > > > > > > I hate to open a new can of worms, but could semantic versioning be used > such that it is obvious when there are changes that are not backwards > compatible? > > -gyro > >
Re: S-RET
Juri Linkov writes: >> you can find a lot of functions like the ones in jupyter at >> https://github.com/jkitchin/scimax/blob/master/scimax-ob.el. I setup my >> ipython like this: >> https://github.com/jkitchin/scimax/blob/master/scimax-org-babel-ipython-upstream.el#L89 >> >> although I will note there are several setups in that file, e.g. this >> hydra: >> https://github.com/jkitchin/scimax/blob/master/scimax-org-babel-ipython-upstream.el#L271 >> … >> I don't use them all, but leave them to remind me sometimes. > > Thanks, the number of supported features is impressive! > > I see that the file name contains the word 'upstream'. This implies a set > of patches to upstream modules. Are there any plans to submit upstream > at least some of the most often used commands that correspond to > basic Jupyter shortcuts? The upstream refers to org-babel-ipython. These libraries build on and extend that. I don't have any plans to push them upstream, I think the future will be with emacs-jupyter instead, but I haven't had time to transition to it. > > For example, it would make sense to bring scimax-execute-and-next-block > under the org-babel namespace as e.g. > org-babel-execute-src-block-and-next-block > in the upstream ob-core.el. Then S-RET will be available to other ob backends > (such as ob-ruby.el that I use often too.) I alot of these make sense for general babel use I think. My time for development work has mostly vanished now, and it is not clear when it will come back. If anyone wants to push these into ob-core.el, I have no objections. -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: Changed list indentation behavior: how to revert?
On 11/16/2020 9:26 AM, Tom Gillespie wrote: > Would it help if major releases maintained a mini-config that if added > to init.el would allow users to retain old behavior? That way they > wouldn't have to read the NEWS but could just add the relevant lines, > or maybe even just call the org-old-default-behavior-9.1 or > org-old-default-behavior-9.4. The workflow during development would be > to account for any change to defaults in those functions. Thoughts? > Tom > > I hate to open a new can of worms, but could semantic versioning be used such that it is obvious when there are changes that are not backwards compatible? -gyro
Re: Changed list indentation behavior: how to revert?
On 11/16/2020 9:26 AM, Tom Gillespie wrote: > Would it help if major releases maintained a mini-config that if added > to init.el would allow users to retain old behavior? That way they > wouldn't have to read the NEWS but could just add the relevant lines, > or maybe even just call the org-old-default-behavior-9.1 or > org-old-default-behavior-9.4. The workflow during development would be > to account for any change to defaults in those functions. Thoughts? > Tom > > I hate to open a new can of worms, but could semantic versioning be used such that it is obvious when there are changes that are not backwards compatible? -gyro
Re: TEC: update the new website ML page?
Here is a patch that might serve for the purpose. Best,
Tom
On Mon, Nov 16, 2020 at 5:47 AM Russell Adams wrote:
>
> https://orgmode.org/community.html
>
> This really needs to state that the Org-mode mailing list is
> subscriber only. Membership is open, but that users should subscribe
> prior to posting. The Worg page for the ML says that.
>
> As a second request, can we get a link to Worg on the top level bar?
>
> --
> Russell Adamsrlad...@adamsinfoserv.com
>
> PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/
>
> Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
>
From 98057ee1b0c008d38fe7b725bc03c4d9af01ee25 Mon Sep 17 00:00:00 2001
From: Tom Gillespie
Date: Mon, 16 Nov 2020 12:02:42 -0500
Subject: [PATCH] add Worg to preamble and note about mailing list
---
community.org | 3 +++
resources/preamble.html | 1 +
2 files changed, 4 insertions(+)
diff --git a/community.org b/community.org
index 846abca..427fa06 100644
--- a/community.org
+++ b/community.org
@@ -15,6 +15,9 @@ community.
You can [[https://lists.gnu.org/mailman/listinfo/emacs-orgmode][subscribe to the list]] and [[https://orgmode.org/list][browse the archive]] here at
=orgmode.org= or via the [[https://lists.gnu.org/archive/html/emacs-orgmode/][GNU mailman archive]].
+If you are not subscribed to the mailing list your message may be
+delayed because it will need to be approved by the moderators.
+
You can also check this page for more [[https://orgmode.org/worg/org-web-social.html][Org news on the social web]].
* Chatting about Org
diff --git a/resources/preamble.html b/resources/preamble.html
index 8a952d1..43024e7 100644
--- a/resources/preamble.html
+++ b/resources/preamble.html
@@ -30,6 +30,7 @@ fathom('trackPageview');
https://updates.orgmode.org;>Updates
Install
Manual
+Worg
Community
Contribute
Re: Changed list indentation behavior: how to revert?
Would it help if major releases maintained a mini-config that if added to init.el would allow users to retain old behavior? That way they wouldn't have to read the NEWS but could just add the relevant lines, or maybe even just call the org-old-default-behavior-9.1 or org-old-default-behavior-9.4. The workflow during development would be to account for any change to defaults in those functions. Thoughts? Tom
Re: Changed list indentation behavior: how to revert?
Uwe Brauer writes: >> PS: I started to donate to org-mode a few weeks ago when I realized just >> how central it is to my workflows. If it’s the same for you, please >> join up: https://liberapay.com/bzg >> Creating reliable funding for development of essential Free Software >> tools is one of the critical tasks for spreading Free Software. > > Done. You are right! \o/ :-) Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Re: Changed list indentation behavior: how to revert?
Tim Cross writes: > I can completely understand your position. However, I wanted to point > out that this change was documented in the org NEWS file, where all > version changes are documented. When upgrading to a new version of org, > everyone should look there, ideally before the upgrade or soon > afterwards and definitely when you notice some changed behaviour. It > will save hours of trouble shooting and often tells you how to restore > previous behaviour. A very under appreciated piece of valuable > documentation. I would like to agree, because I wish people would also read NEWS for my projects, but since I use at least 10-20 programs daily which depend on hundreds of libraries that might change their behavior, that’s unrealistic. I cannot read NEWS entries whenever my distro updates org-mode, therefore I depend on org-mode not breaking during updates. If an update changes behavior in a way that requires people to read up on stuff to find out how to continue working, that means that the program breaks with that update. I’ve been more liberal on that point before I saw the problems that arose from the Python2->Python3 transition. Many changes that each seem small on their own can cause significant damage, because there will always be some people that get hit by them during a period in their life when they cannot follow them, because they are fully occupied by work (mentally or because of little time) so the tools they trained with must just keep working. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Bug: Can't toggle off archived tasks in agenda with "v A" [9.4 (9.4-41-g9bb930-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20201116/)]
Hi All,
The toggling of Archives mode in the agenda, the one which includes
archive files, called with "v A", can be turned on, but turning it off
with "v A" does not currently work.
An ECM to reproduce the issue is:
- Start `emacs -Q'
- Do an initial setup:
#+begin_src emacs-lisp
(add-to-list 'load-path "~/.emacs.d/elpa/org-plus-contrib-20201116")
(setq org-agenda-files '("~/test/agenda.org"))
#+end_src
- We have two files in =~/test/=: =agenda.org= and =agenda.org_archive=,
which is, as you presume, the default archive file of the first one.
The contents of =agenda.org= are:
#+begin_src org
,* TODO Task
SCHEDULED: <2020-11-16 Mon>
,* TODO Archived tree
:ARCHIVE:
SCHEDULED: <2020-11-16 Mon>
#+end_src
- And those of =agenda.org_archive= are:
#+begin_src org
#-*- mode: org -*-
Archived entries from file /home/gustavo/test/agenda.org
,* TODO Archived task
SCHEDULED: <2020-11-16 Mon>
:PROPERTIES:
:ARCHIVE_TIME: 2020-11-16 Mon 11:52
:ARCHIVE_FILE: ~/test/agenda.org
:ARCHIVE_TODO: TODO
:ARCHIVE_CATEGORY: agenda
:END:
#+end_src
Which was actually produced by archiving this task from =agenda.org=.
- From this setup, lets call `org-agenda': "M-x org-agenda RET a".
- At this point, the agenda only shows "Task", which is as expected.
Call "v a" to also show "Archived tree", locally archived by tagging.
Call "v a" again to disable it, and it goes away as expected.
- Call "v A" (uppercase "A"), to enable display of archived tasks
including those of archive files. "Archived task" is also shown, as
expected. So far, so good.
- Now call "v A" again to toggle (off) the display of archived tasks.
The minibuffer echoes the message "Trees with :ARCHIVE: tag and all
active archive files are included", and the archived items are still
shown. Considering the manual describes the binding "v A" as "Toggle
Archives mode. Include all archive files as well.", this is not
expected behavior.
- Using "v a" to toggle it off does work as expected though, even when
we enabled `org-agenda-archives-mode' with "v A".
Best regards,
Gustavo.
Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0)
of 2020-08-11
Package: Org mode version 9.4 (9.4-41-g9bb930-elpaplus @
/home/gustavo/.emacs.d/elpa/org-plus-contrib-20201116/)
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-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-agenda-files '("~/test/agenda.org")
org-mode-hook '(#[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-eldoc-load)
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
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-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-agenda-loop-over-headlines-in-active-region nil
org-src-lang-modes '(("redis" . redis) ("php" . php) ("arduino"
. arduino) ("C" . c) ("C++" . c++)
("asymptote" . asy) ("bash" . sh) ("beamer"
. latex) ("calc" . fundamental) ("cpp" . c++)
("ditaa" . artist) ("dot" . fundamental) ("elisp"
. emacs-lisp) ("ocaml" . tuareg)
("screen" . shell-script) ("shell" . sh) ("sqlite"
. sql))
org-occur-hook '(org-first-headline-recenter)
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-hide-drawers org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-export-before-parsing-hook '(org-attach-expand-links)
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link)
("id" :follow org-id-open) ("eww" :follow
org-eww-open :store org-eww-store-link)
("rmail" :follow org-rmail-open :stor
Re: Archiving repeated tasks under corresponding date tree for each repeated item
Wow, I’m impressed by your help, you are very kind! I am also impressed by your researching skills, I gave a long go at trying to find some code online unsuccessfully. Yes, I agree that the agenda is a nice way to go to visualize my past events (with v A). My idea of not relying on the agenda interface is just to be free and have an archive org file with all my entries, easier to scroll from any device without the need of Emacs. As for the function to archive the individual repeated tasks into their corresponding tree: I’m not an emacs lisp programmer (or any kind of!). As I see, this function works only “at point”. The way I work is I mark tasks as DONE during a couple weeks, and then I call this function that tracks all my org file and archives all DONE / CANCELLED items. This is great because I don’t have to do it one by one. (defun my/org-archive-done-tasks-file () (interactive) (org-map-entries (lambda () (org-archive-subtree) (setq org-map-continue-from (outline-previous-heading))) "TODO=\"DONE\"|TODO=\"CANCELED\\"" 'file)) Do you think there is a way to combine these two functions so that when I call the fucntion, I get to archive all DONE/CANCELLED & repeated DONE/CANCELLED tasks (the latter without deleting the logged task or its respective heading)? Best, G. El jue., 12 nov. 2020 a las 12:28, Ihor Radchenko () escribió: > > Hope it is clear now, thanks so much for any help! > > Sorry for not making my previous email more clear. I actually understood > what you want to achieve. My suggestion was rather an alternative > approach to "revisit the past" - you can always build agenda view for a > specific date (or range of dates) in the past. That way, you would not > need to look into archive file manually at all. > > On your actual question, I think I found some old reddit comment [1] that > may be relevant. The code provides a new command to archive an org > headline without actually deleting it. That way, you will get a copy of > your headline on the date of archival. Below is the original code with > me adding docstrings for more clarity. > > (defun my/org-archive-delete-logbook () > "Delete LOGBOOK of the entry at point. It is obsolete once the copy of > the item is moved to the archive file." > (save-excursion >(org-end-of-meta-data) >(let ((elm (org-element-at-point))) > (when (and > (equal (org-element-type elm) 'drawer) > (equal (org-element-property :drawer-name elm) "LOGBOOK")) >(delete-region (org-element-property :begin elm) > (org-element-property :end elm)) > > (defun my/org-archive-without-delete () > "Archive item at point, but do not actually delete it." > (cl-letf (((symbol-function 'org-cut-subtree) (lambda () nil))) > (org-archive-subtree))) > > (defun my/org-archive-logbook () > "Create an archive copy of subtree at point and delete LOGBOOK in the > first headline of the subtree." > (interactive) > (my/org-archive-without-delete) > (my/org-archive-delete-logbook)) > > I think you can modify the last function and call it in > org-trigger-hook, so that repeating items would be archived without > deleting every time you mark the item DONE. > > [1] > https://old.reddit.com/r/orgmode/comments/dg43hs/can_i_archive_a_property_drawer/f3frk2n/ > > Best, > Ihor > > Gerardo Moro writes: > > > Thanks, Ihor. > > Indeed, that is an excellent feature of agenda. I use it sometimes to > > visualize what I have DONE during the week on the sopt. > > What I aim to accomplish however is a more systematic log of all the DONE > > tasks, this is, to have an archive file where to archive all tasks. > > This file is in the format: > > > > 2020 > >2020-01-01 DONE task1 > >2020-01-12 DONE task2 > >2020-02-01 CANCELLED task3 > > > > So it is indeed a datetree file where I can revisit the past :) if you > will. > > The problem with habits and repeated tasks is that they don't get > archived > > when DONE... > > They get archived once the task is cancelled or completed as a whole, all > > under the day the task stopped continuing, under which I have all the > > logged individual completion. > > It would be desirable to have each "completion" archived under its > > corresponding datetree, it is more meaningful :) > > > > Hope it is clear now, thanks so much for any help! > > GM > > So even if I have beeng doing the task every wednesday for a year, it > won't > > be archived > > > > El mar., 3 nov. 2020 a las 7:53, Ihor Radchenko () > > escribió: > > > >> > It would be great if each of these individual "task > >> > happenings" were archived under the date and time they were completed > >> > individually, and not just all as one block. This way I could get > weekly > >> > reviews that take those into account. > >> > >> What about trying to do your weekly review using org-agenda? You can > >> show the task every day you complete it by enabling org-agenda-log-mode > >> in your weekly
Re: export and import github issues
On Mon, Nov 16 2020, Uwe Brauer wrote: > Hi > > Lately I have deal a lot in github issues, so I thought it would be > nice to use org for this however the only package I could find seems > org-sync which is from 2012 but does not allow me to connect. > > Anybody knows about a working package? It's not for GitHub, but for GitLab, I've written org-gitlab [1] to fill me own needs. It's build to fit my workflow, but it might help you to build something for GitHub that works for you. At the moment it only does one-way syncing (from GitLab to org). [1]: https://gitlab.com/to1ne/org-gitlab -- Toon
Re: Changed list indentation behavior: how to revert?
> PS: I started to donate to org-mode a few weeks ago when I realized just > how central it is to my workflows. If it’s the same for you, please > join up: https://liberapay.com/bzg > Creating reliable funding for development of essential Free Software > tools is one of the critical tasks for spreading Free Software. Done. You are right! smime.p7s Description: S/MIME cryptographic signature
export and import github issues
Hi Lately I have deal a lot in github issues, so I thought it would be nice to use org for this however the only package I could find seems org-sync which is from 2012 but does not allow me to connect. Anybody knows about a working package? Regards Uwe Brauer
Re: [PATCH] doc/org-manual.org: Extend table formulas Lisp form documentation
Daniele Nicolodi writes: > On 16/11/2020 11:25, Eric S Fraga wrote: >> Daniele, >> >> this looks good. One minor pedantic point: I think you mean >> "interpreted" when you say "interpolated" (several times in the >> text). Otherwise, this is a very useful addition to the manual. > > Thank you for reading and for the comment. > > "interpolated" looks strange to me in this context too, but it is the > word that is currently used in the manual. I decided to stick to this > term for consistency, however, I haven't check if it is used with the > same meaning elsewhere. > > I don't think it is wrong to use "interpolated", but if you thing it > should be changed I can change it and check the manual for consistency. > However, I don't think "interpreted" is the right word either. Probably > "replaced" or "substituted" are better choices in this context. > I agree. Interpolated is consistent with manuals for other programming languages which have similar functionality. However, org is also used by a more diverse community than typical programming languages, so perhaps 'replaced' or 'substituted' would be a better choice? -- Tim Cross
Re: Bug: Exporting "as PDF file and open" causes unnecessary revert prompt if PDF was already open [9.4 (release_9.4-103-gf0b8de @ /home/erik/.emacs.d/straight/build/org/)]
> This may have consequences for > users who are working with large PDF documents and high DPI settings who > may not want to re-generate the PDF every time, so it may be necessary > to make the auto reloading an option? IMO, selecting the "...and open" option implies that you want to (re-)load the PDF.
Re: Changed list indentation behavior: how to revert?
On Mon, Nov 16, 2020 at 8:43 AM Tim Cross wrote: > So essentially, this change has been made to make org-mode consistent > with the rest of emacs which enabled electric-indent by default in Emacs > 24. this is a good thing. Org should be consistent with other modes. Any > differences are likely to be the source of confusion and bug reports. > Hi Tim, Consistency is good but when people have been using org-mode for 10+ years get a fundamental behavior change (like when you hit enter) through an update it can be confusing. Perhaps old behavior should be preserved by default for current org users but the new behavior adopted for new installs. Maybe a heuristic something like this would work: 1) when org-mode starts, it could check to see if there are any existing customizations at all -- if there are, the user has used org before 2) if org-adapt-indentation is not currently customized, customize it to nil Or something like that. This should preserve the old behavior for old org users but use the new behavior for new users (except for old users with fresh emacs installs but maybe this is good enough). -- Bill
org-mode export toggle checkboxes
Hello Emacs and Org-Mode Users,
I have a question regarding the export options of org-mode.
Is there a way to toggle, whether checkboxes are exported to markdown
and plain text (ASCII buffer / file)? I did not find any on
https://orgmode.org/manual/Export-Settings.html and so far I tried the
following:
#+OPTIONS: ^:{} H:10 toc:2
#+STARTUP: content indent align inlineimages hideblocks entitiesplain nologdone
nologreschedule nologredeadline nologrefile
#+OPTIONS: ^:{}
#+OPTIONS: tags:nil
#+OPTIONS: tasks:nil
#+OPTIONS: toc:nil
#+OPTIONS: H:6
#+OPTIONS: p:nil
#+OPTIONS: pri:nil
#+OPTIONS: prop:nil
#+OPTIONS: todo:nil
#+OPTIONS: stat:nil
#+OPTIONS: |:t
#+OPTIONS: inline:nil
Regards,
Zelphir
--
repositories: https://notabug.org/ZelphirKaltstahl
Re: Changed list indentation behavior: how to revert?
Hi Tim, Hi All, On Mon, 16 Nov 2020 at 18:15, Tim Cross wrote: > Tim Cross writes: > >> >> Thanks for clarifying this Kyle. >> >> So essentially, this change has been made to make org-mode consistent >> with the rest of emacs which enabled electric-indent by default in Emacs >> 24. this is a good thing. Org should be consistent with other modes. Any >> differences are likely to be the source of confusion and bug reports. >> >> I am a little confused about the purpose of org-adapt-indentation >> though. According to the org news file, to get back the old behaviour, >> it says to explicity disable electric-indent mode using org-mode-hook. >> There is no mention of org-adapt-indentation. >> >> Is this just an artefact from before and in effect, we have two methods >> to disable the indentation behaviour? Is there anything functionally >> different between disabling electric-indent by calling >> electric-indent-local-mode -1 or setting org-adapt-indent to nil or is >> the result functionally equivalent? >> > > Following up to my own question. The two are NOT functionally equivalent > in that org-adapt-indentation supports other values than t or nil. You > can use this variable to tweak how the adaptive indentation works. While > setting it to nil may be equivalent to turning of electric-indent mode, > it can be used to adjust how adaptive indentation works as well. > > Tim > > -- > Tim Cross I think I might chime in again, as perhaps I have a point to add, and Tim's formulation here is a good hook for that. Setting `org-adapt-indentation' to nil is not equivalent to disabling `electric-indent-mode' not because there are more values than t or nil for the first, but because they are conceptually different. `org-adapt-indentation' controls how the indentation should be done by Org, `electric-indent-mode' just applies this setting when you hit RET. If you have `electric-indent-mode' off, but `org-adapt-indentation' set to t, type a heading hit RET, than TAB, you will get the same indentation up to the heading stars level. But the point of interest here, is not this difference by itself, but in some of its implications, and why so many people were unaware of `org-adapt-indentation'. I think this is the case because, with `electric-indent-mode' off, it is easy to slip through the right indentation, and get to believe things are working as expected, when they are actually just doing so by coincidence. Suppose you are in the status quo before 9.4, that is `org-adapt-indentation' set to its default value of true, and `electric-indent-mode' off, and you start to type a little document. If you type it always hitting TAB after RET, you will get: #+begin_src org ,** Foo First line Second line #+end_src (Indentation appears off, but that's just the escape comma). If, instead, you just type RET, you get what many people surprised by the change in this thread expect: #+begin_src org ,** Foo First line Second line #+end_src Now, the point is that, if you just miss the TAB on the first line, even if you hit TAB to indent on the subsequent ones, they will still not indent and be kept on the left margin. So things *appear* to be working as expected, but they are not. What is happening here is that *because indentation is broken in the first line* it goes amiss in the following ones. One might argue that, if it appears to work on all accounts, it is actually working. But if you have this situation, you will then be subject to all sorts of strange things. Suppose we are in the situation of the last block, and demote the heading: #+begin_src org ,*** Foo First line Second line #+end_src Surprise! the content of the heading was moved to the right by one space which is neither indented as it should, nor at the left margin as "expected". Now you try to "fix" this "incorrect" dragging of the content, by selecting the subtree and calling `org-indent-region'. #+begin_src org ,*** Foo First line Second line #+end_src Surprise! it's even "worse". So you then undo twice, and type the star directly to "correct" it (how else?). Try to expand an org-tempo template and get surprised that you can't get a non-indented expansion right after the heading, but you can do it after some content (from a real case at https://emacs.stackexchange.com/q/55413/18951). I haven't tried further, but I wouldn't be surprised if similar "strange" behaviors would also affect killing-yanking subtrees, refiling, etc. So, keeping `org-adapt-indentation' to t, but "solving" the inconvenience by disabling `electric-indent-mode' is not a solution, because this will just hide (keep hiding?) from you the fact that you are editing a document which is different from what Org is actually expecting according to the indentation settings, and this will result in inconsistencies of behavior at a number of points. We should probably thank `electric-indent-mode' for making people more aware of this user option, and correct this setting
Re: [PATCH] doc/org-manual.org: Extend table formulas Lisp form documentation
On 16/11/2020 11:25, Eric S Fraga wrote: > Daniele, > > this looks good. One minor pedantic point: I think you mean > "interpreted" when you say "interpolated" (several times in the > text). Otherwise, this is a very useful addition to the manual. Thank you for reading and for the comment. "interpolated" looks strange to me in this context too, but it is the word that is currently used in the manual. I decided to stick to this term for consistency, however, I haven't check if it is used with the same meaning elsewhere. I don't think it is wrong to use "interpolated", but if you thing it should be changed I can change it and check the manual for consistency. However, I don't think "interpreted" is the right word either. Probably "replaced" or "substituted" are better choices in this context. Cheers, Dan
TEC: update the new website ML page?
https://orgmode.org/community.html This really needs to state that the Org-mode mailing list is subscriber only. Membership is open, but that users should subscribe prior to posting. The Worg page for the ML says that. As a second request, can we get a link to Worg on the top level bar? -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Link to open PDF at a specific page
* Georges Ko [2020-11-14 11:48]: > If I export the file as HTML, it is output as: > > ... > > so I modified org-html-link from: > > (concat raw-path > "#" > (org-publish-resolve-external-link option path t)) > > to > > (concat raw-path > "#" > (let ((r (org-publish-resolve-external-link option path t))) > (or (and (string= r "MissingReference") >(string-match "\\.pdf\\'" path) >(string-match "[0-9]+" option) >(format "page=%s" option)) > r))) > > which generates the wanted HTML link: > > ... > > Is there any way less quick & dirty to achieve this? General function in plan Org program files shall not be modified in the main development branch to serve a specific PDF reader on specific OS system as that is hard coding and there are many PDF readers which all behave in different manner. Instead it is better if you make your custom link for Org that does what you want. It looks as being possible to be customized by using org-link-abbrev-alist Is it?
Bug: org-clone-subtree-with-time-shift throws error [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]
Summary: using org-clone-subtree-with-time-shift on an entry with the ID
property and a timestamp causes an error or does not create different IDs,
which worked before 27.1.
Long Description:
I have a calendar file with a lot of entries, but I slimmed it down to a MWE:
=== begin MWE ===
* my appointment with id
:PROPERTIES:
:ID: 048c5a49-1aed-45d4-b7a9-34caf4f13266
:END:
<2020-11-15 Sun 15:30>
example text
=== end MWE ===
I create such an entry routinely via a capture template with a timestamp and I
add the text, and the ID is created with (add-hook
'org-capture-prepare-finalize-hook 'org-id-get-create). For repeating tasks, 10
weeks ago and before (i.e. before I updated to 27.1), I used to use `M-x
org-clone-subtree-with-time-shift 10 +1w ` and I got 10
repetitions, each with a separate unique ID.
I tried this now and I get an error "wrong-type-argument stringp nil", with the
backtrace described below. If I change the order of the timestamp and the
properties drawer in the MWE, I get the date-shifted clones but each with the
same ID. In my calendar file with lots of entries, I still get the same error
if I change the order, so I suspect that the function is context sensitive.
Anyway to reproduce the error,
1. save the above MWE in an org file
2. open the file with emacs -Q
3. activate debugger with `M-x toggle-debug-on-error `
4. run `M-x org-clone-subtree-with-time-shift 10 +1w `
The following backtrace is then produced:
=== begin backtrace ===
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
string-match("^/tmp_mnt/" nil)
abbreviate-file-name(nil)
org-id-add-location("9f1a8e57-e9be-42aa-a113-f8f478cc2a1b" nil)
org-id-get(1 create)
org-id-get-create(t)
org-clone-subtree-with-time-shift(10)
funcall-interactively(org-clone-subtree-with-time-shift 10)
call-interactively(org-clone-subtree-with-time-shift record nil)
command-execute(org-clone-subtree-with-time-shift record)
execute-extended-command(nil "org-clone-subtree-with-time-shift" "org-clone")
funcall-interactively(execute-extended-command nil
"org-clone-subtree-with-time-shift" "org-clone")
call-interactively(execute-extended-command nil nil)
command-execute(execute-extended-command)
=== end backtrace ===
Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.22,
cairo version 1.17.3)
of 2020-08-28
Package: Org mode version 9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)
publickey - skaphle@pm.me - 0x0422F3DC.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
Bug: org-clone-subtree-with-time-shift throws error [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]
Summary: using org-clone-subtree-with-time-shift on an entry with the ID
property and a timestamp causes an error or does not create different IDs,
which worked before 27.1.
Long Description:
I have a calendar file with a lot of entries, but I slimmed it down to a MWE:
=== begin MWE ===
* my appointment with id
:PROPERTIES:
:ID: 048c5a49-1aed-45d4-b7a9-34caf4f13266
:END:
<2020-11-15 Sun 15:30>
example text
=== end MWE ===
I create such an entry routinely via a capture template with a timestamp and I
add the text, and the ID is created with (add-hook
'org-capture-prepare-finalize-hook 'org-id-get-create). For repeating tasks, 10
weeks ago and before (i.e. before I updated to 27.1), I used to use `M-x
org-clone-subtree-with-time-shift 10 +1w ` and I got 10
repetitions, each with a separate unique ID.
I tried this now and I get an error "wrong-type-argument stringp nil", with the
backtrace described below. If I change the order of the timestamp and the
properties drawer in the MWE, I get the date-shifted clones but each with the
same ID. In my calendar file with lots of entries, I still get the same error
if I change the order, so I suspect that the function is context sensitive.
Anyway to reproduce the error,
1. save the above MWE in an org file
2. open the file with emacs -Q
3. activate debugger with `M-x toggle-debug-on-error `
4. run `M-x org-clone-subtree-with-time-shift 10 +1w `
The following backtrace is then produced:
=== begin backtrace ===
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
string-match("^/tmp_mnt/" nil)
abbreviate-file-name(nil)
org-id-add-location("9f1a8e57-e9be-42aa-a113-f8f478cc2a1b" nil)
org-id-get(1 create)
org-id-get-create(t)
org-clone-subtree-with-time-shift(10)
funcall-interactively(org-clone-subtree-with-time-shift 10)
call-interactively(org-clone-subtree-with-time-shift record nil)
command-execute(org-clone-subtree-with-time-shift record)
execute-extended-command(nil "org-clone-subtree-with-time-shift" "org-clone")
funcall-interactively(execute-extended-command nil
"org-clone-subtree-with-time-shift" "org-clone")
call-interactively(execute-extended-command nil nil)
command-execute(execute-extended-command)
=== end backtrace ===
Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.22,
cairo version 1.17.3)
of 2020-08-28
Package: Org mode version 9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] doc/org-manual.org: Extend table formulas Lisp form documentation
Daniele, this looks good. One minor pedantic point: I think you mean "interpreted" when you say "interpolated" (several times in the text). Otherwise, this is a very useful addition to the manual. Thank you, eric -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4-107-ga0aaca.dirty
Re: More on design of org-contacts.el - Re: [UPDATED PATCH] Re: add new link type "contact:" for org-contacts.el
First, thank your very much for suggestion. What really I have not found your email in my Gmail (in web browser), I found it in mu4e (Emacs). Which I can't reply because I'm in China, sendmail to Gmail SMTP server is blocked. So I'm replying you in mu4e. Don't know whether you can receive my message. Jean Louis writes: > * stardiviner [2020-11-11 15:05]: > :PROPERTIES: > :CREATED: [2020-11-11 Wed 16:57] > :ID: 17d463d2-ff0c-4614-93da-06e3de8e6035 > :END: >> Thank you too. >> I indeed want to extend org-contacts.el. So I would like to be it's >> maintainer. >> >> Currently how many org-mode maintainer(mailing list manager)? >> If patch need to wait a month. Because I spend less time on org-mode too >> comparing before time. I agree with that, I might will add multiple PATCHes >> together. > > Side notes: > > I have looked into contacts. It relies on a query to find a contact. I > hope that I am right. > > Text based Org mode anyway may rely on built-in text searches like > incremental Emacs's search. > > org-contact wishes to pin point to specific contact. It wants to > create a hyperlink to one specific contact. It does not want to find 2 > contacts with the same query or more of them. > > As I have 195000 contacts in PostgreSQL database I know from browsing > them that many of them have same unique names. To reference to a > specific contact by using name query would be useless as I could miss > it and take other contact. Thus search involves narrowing contacts by > maybe state, location and other filters. Each contact has its own > uniquely assigned ID number. An integer assigned by the database > automatically. > > By using the ID number I can easily capture the reference link to th > contact from the database and insert such link into the Org file. As > long as I do not change the ID number even if contact name is changed > I would be able to pin point the specific number. > > Thus for org-contacts I recommend creation of unique IDs in the > properties for headings for each contact so that contact may be > referenced by the unique ID. Using unique ID is the only solution to identity contact. I already thought about this. But integrating org-id is hard for me. Have not spent that time on it yet. But I will, if I want to improve this org-contacts. > > Additional proposals: > > Each hyperdocument (within or without Emacs) that allows back linking > to its specifical parts should have a function or key binding to > quickly obtain the link reference. > > For example if user browses heading for *** John Doe anywhere within > such heading user should be able to press a key to capture the link to > the contact automatically. > > In the file my-contacts.org: > > *** John Doe > :PROPERTIES: > :ID: cc400d57-2adf-47af-90d9-c4d9fdd70d2b > :CREATED: [2020-11-11 Wed 16:57] > :END: > > DATA > > DATA > :PROPERTIES: > :CREATED: [2020-11-11 Wed 16:57] > :ID: 19781b53-211b-4291-af48-5f3655dd7cec > :END: > > DATA > :PROPERTIES: > :CREATED: [2020-11-11 Wed 16:57] > :ID: e8eb6647-8d8e-4ec6-b759-43dcfd60d17b > :END: > > Anywhere within the subtree for John Doe user should be able to obtain > the reference to the contact. For example by clicking `C-x w'. > > Upon key press following link could then be stored into memory, or > register, whatever is better design: > > [[org-contact:~/file/my-contacts.org#cc400d57-2adf-47af-90d9-c4d9fdd70d2b][John > Doe]] > > Then user would go to other Org file and use `C-y' to yank the contact > into the new file. > > One shall consider that obtaining the object reference should be > on the fly customizable. As maybe I wish to have in the link: > > - Contact's first name only like when addressing friends > > - Contact's full name, with or without middle names > > - Contact's name plus city and country > > Having several ways to obtain quickly reference to the contact (to > generate link in memory) is useful feature that shortens the time and > makes it less error prone for the user. If only query is used with > simple typo contact link will not work. What will follow is tedious > browsing and opening of files to find the right contact. > > User can have many Org contact files and file reference should be > included into the file. This assumes that files should be fixed in > file system. > > This proposal follows the Doug Engelbart's Technology Template Project > for Open Hyperdocument Systems (OHS) in relation to addressing: > https://www.dougengelbart.org/content/view/110/460/#2b1 > > Global, Human-Understandable, Object Addresses > > Every object that someone might validly want/need to cite or otherwise > access should have an unambiguous address, capable of being portrayed > in a human readable and interpretable manner. Most common existing > spreadsheet programs have provisions similar to this for cell > addressibility > > And: > > Link Addresses That Are Readable and
Re: [PATCH] lisp/org.el: Allow hiding #+SUBTITLE: keyword via `org-hidden-keywords'
On 2020-11-16 Mo 06:33, Kyle Meyer wrote: > Titus von der Malsburg writes: > >> Subject: [PATCH] lisp/org.el: Allow hiding #+SUBTITLE: keyword via >> `org-hidden-keywords' >> >> * lisp/org.el: Allow users to include 'subtitle in >> `org-hidden-keywords' to hide #+SUBTITLE: keyword. >> >> This way #+SUBTITLE is treated like similar keywords for title, date, >> e-mail, and author. > > Thanks, sounds good. > >> --- >> lisp/org.el | 1 + >> 1 file changed, 1 insertion(+) > > Could you add an entry to ORG-NEWS? Done. >> diff --git a/lisp/org.el b/lisp/org.el >> index 73b270712..0d2fbddda 100644 >> --- a/lisp/org.el >> +++ b/lisp/org.el >> @@ -3573,6 +3573,7 @@ appear in the buffer without the initial \"#+TITLE:\" >> part." >>:type '(set (const :tag "#+AUTHOR" author) >>(const :tag "#+DATE" date) >>(const :tag "#+EMAIL" email) >> + (const :tag "#+SUBTITLE" subtitle) >>(const :tag "#+TITLE" title))) > > Please add > > :package-version '(Org . "9.5") > > dropping the current ':version "24.1"'. Done. Updated patch attached. Thanks for your guidance. Titus >From fc3957aad8c94d1b1f3f1882c9f5d6da4552b640 Mon Sep 17 00:00:00 2001 From: Titus von der Malsburg Date: Mon, 16 Nov 2020 11:05:15 +0100 Subject: [PATCH] lisp/org.el: Allow hiding #+SUBTITLE: keyword via `org-hidden-keywords' * lisp/org.el: Allow users to include 'subtitle in `org-hidden-keywords' to hide #+SUBTITLE: keyword. This way #+SUBTITLE is treated like similar keywords for title, date, e-mail, and author. --- etc/ORG-NEWS | 6 ++ lisp/org.el | 3 ++- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS index 66347fe90..889eb4aab 100644 --- a/etc/ORG-NEWS +++ b/etc/ORG-NEWS @@ -12,6 +12,12 @@ Please send Org bug reports to mailto:emacs-orgmode@gnu.org. * Version 9.5 (not yet released) ** New options and settings +*** Option ~org-hidden-keywords~ now also applies to #+SUBTITLE: + +The option ~org-hidden-keywords~ previously applied +to #+TITLE:, #+AUTHOR:, #+DATE:, and #+EMAIL:. Now it can also be +used to hide the #+SUBTITLE: keyword. + *** New formatting directive ~%L~ for org-capture The new ~%L~ formatting directive contains the bare link target, and diff --git a/lisp/org.el b/lisp/org.el index 73b270712..2b50f94ee 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -3569,10 +3569,11 @@ lines to the buffer: For example, a value \\='(title) for this list makes the document's title appear in the buffer without the initial \"#+TITLE:\" part." :group 'org-appearance - :version "24.1" + :package-version '(Org . "9.5") :type '(set (const :tag "#+AUTHOR" author) (const :tag "#+DATE" date) (const :tag "#+EMAIL" email) + (const :tag "#+SUBTITLE" subtitle) (const :tag "#+TITLE" title))) (defcustom org-custom-properties nil -- 2.25.1 -- Dr. Titus von der Malsburg Dept. Linguistics, University of Potsdam Dept. Brain & Cognitive Sciences, MIT https://tmalsburg.github.io PGP fingerprint: C34C 7364 EAAD 4752 FABA 35E6 AE34 59F3 C613 689D
Re: S-RET
>> What I miss in Org Babel is an equivalent of 'S-RET' that in Jupyter >> creates a new code block relative to the current code block. > > 'C-c C-v C-d' (org-babel-demarcate-block) splits current code block into > two with the same settings. It might be what you want. Just bind it to > something easier to access maybe :P Thanks, I tried 'C-c C-v C-d', but it's not exactly what is needed, just an approximation. When #+RESULTS: already exists after the #+END_SRC line, 'C-c C-v C-d' doesn't add a new #+BEGIN_SRC after #+RESULTS:, it adds before it (however, this could be mitigated by evaluating both blocks after splitting.)
Re: S-RET
Juri Linkov writes: > > What I miss in Org Babel is an equivalent of 'S-RET' that in Jupyter > creates a new code block relative to the current code block. 'C-c C-v C-d' (org-babel-demarcate-block) splits current code block into two with the same settings. It might be what you want. Just bind it to something easier to access maybe :P /Leo
Re: Changed list indentation behavior: how to revert?
Tim Cross writes: > I am a little confused about the purpose of org-adapt-indentation > though. According to the org news file, to get back the old behaviour, > it says to explicity disable electric-indent mode using org-mode-hook. > There is no mention of org-adapt-indentation. Yep; as I mentioned in <87k0umjn74@gmail.com>, I didn't know about org-adapt-indentation when I wrote this NEWS entry. If I had, I would have - mentioned this variable in the NEWS entry, and/or - campaigned for a change to the default value.
