Re: [O] Is is possible to summarize contents of a task in the agenda headings?
writes: > Thanks, I'm already using (setq org-agenda-todo-list-sublevels nil) and > org-super-agenda. Both reduce clutter which is good. OTOH I now lack > information about subtasks that has been removed from the agenda > view. It is this concern i would like to address. A bit of work, but, if you set a property name of (say) PARENT on each parent project and gave it the value of that parent project name, each child of the parent would pick up the property and then should show up in an :auto-property group under org-super-agenda-mode (I think). That might get a bit cluttered, though, if you're doing a deep hierarchy of projects. -- David
Re: [O] Porting Apple Calendars to org-mode
Thanks, I actually got .org-mac-iCal working, and even changed it to be able to load non-Apple calendars if present in the local calendar app. I will try and push the modified version to github or send a patch. On Thu, Apr 25, 2019 at 11:34 PM David Masterson wrote: > Mohamed Wael Khobalatte writes: > > > Hi guys, I posted a question to the Emacs StackExchange > > ( > https://emacs.stackexchange.com/questions/50137/show-apple-calendar-events-in-org-mode > ), > > but I believe it's better asked here. Does anyone know how I can get > > my Apple calendar to show up in org-mode as readonly (preferably)? > > > > I had no luck with org-mac-iCal. Only one calendar (the Birthdays > > calendar) shows up, eventhough all other calendars are *checked*, as > > the documentation from that package requires. It is also rather old, > > so not sure if it works anymore? > > A suggestion is to look at https://github.com/pimutils/vdirsyncer. I > don't know anything more, but it looks promising. > > -- > David > -- Wael Khobalatte
Re: [O] Porting Apple Calendars to org-mode
Mohamed Wael Khobalatte writes: > Hi guys, I posted a question to the Emacs StackExchange > (https://emacs.stackexchange.com/questions/50137/show-apple-calendar-events-in-org-mode), > but I believe it's better asked here. Does anyone know how I can get > my Apple calendar to show up in org-mode as readonly (preferably)? > > I had no luck with org-mac-iCal. Only one calendar (the Birthdays > calendar) shows up, eventhough all other calendars are *checked*, as > the documentation from that package requires. It is also rather old, > so not sure if it works anymore? A suggestion is to look at https://github.com/pimutils/vdirsyncer. I don't know anything more, but it looks promising. -- David
[O] Bug: Preserving agenda settings per buffer? [9.2.3 (9.2.3-7-g222408-elpaplus @ .emacs.d/elpa/org-plus-contrib-20190415/)]
Example variables: org-agenda-todo-list-sublevels org-agenda-dim-blocked-tasks If org-agenda-dim-blocked-tasks is default true, and you have custom agenda views foo and bar, where bar sets this to false, opening bar will result in an agenda view where blocked tasks are not dimmed, but if you go back to a previously opened buffer for foo and revert, the foo agenda view will now also not be dimming blocked tasks. This is because the local settings for an agenda view are stored in the org-lprops property of org-agenda-redo-command, so there can only be one set of local agenda settings, for whichever agenda command was run last. This behavior is confusing when combined with org-agenda-sticky, because you can switch to the buffers of previously run agenda commands, but if you redo/revert them, the results may be completely different. Actually fixing this is difficult. Probably it should be documented somewhere that switching directly to agenda buffers produces undefined behavior and you have to use the agenda command. On a slightly different tack, the variables I listed above could be made "local" to an agenda command, like how some vars (org-agenda-sorting-strategy I think?) have special handling so they stick to a particular agenda buffer. That doesn't solve the general problem that local settings provided to a custom agenda commnd are effectively set globally. Emacs : GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.24), modified by Debian Package: Org mode version 9.2.3 (9.2.3-7-g222408-elpaplus @ .emacs.d/elpa/org-plus-contrib-20190415/)
[O] bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter)
чт, 25 апр. 2019 г. в 23:52, Philipp Stephani : > Am Do., 25. Apr. 2019 um 10:41 Uhr schrieb Dmitrii Korobeinikov > : > > I have imagined that at the low level there is an actual data structure > that keeps the raw textual data and it could be directly shared by multiple > buffers. > > That's what indirect buffers do. Maybe the indirect buffer > functionality could be beefed up to support what you want? > https://www.gnu.org/software/emacs/manual/html_node/emacs/Indirect-Buffers.html > The text of the indirect buffer is always identical to the text of its base buffer; changes made by editing either one are visible immediately in the other. But in all other respects, the indirect buffer and its base buffer are completely separate. They can have different names, different values of point, different narrowing, different markers, different major modes, and different local variables. Awesome! Looks like we have some solid rails to drive on. BTW what's the purpose of lentic-mode then? To be "providing multiple persistent views"? https://github.com/phillord/lentic
[O] bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter)
Dear Ihor, > Another use case for me is to speed up agenda creation. > I usually do not like to split my org files into too many. However, it > results in very large and slow org buffers later. If I can store some > parts of the org files externally and only show them if some condition > is met (say, for certain todo state of the parent entry), it would speed > up my agenda and the buffer navigation quite significantly. That's a good one! > Let me put some historical context to this proposal. > There was a discussion of similar feature in emacs-dev last year. > The idea was to implement nested buffers: > https://lists.gnu.org/archive/html/emacs-devel/2018-07/msg00863.html An interesting read, provides another use-case (collect external data in one place to easily view/edit): https://lists.gnu.org/archive/html/emacs-devel/2018-07/msg00890.html > There are also several projects, which implement part of the > functionality you described: > - mmm-mode: https://github.com/purcell/mmm-mode > - polymode: https://github.com/polymode/polymode Pretty cool stuff. For thoroughness, let's discuss how these work. I found a comment which mentions polymode's working principle. https://www.reddit.com/r/emacs/comments/50p34n/polymode_is_awesome/?depth=1 >> Polymode doesn't keep its modes in a single emacs buffer but in several indirect buffers, as many as different modes are there in a file. Consequently, polymode is as fast as switching emacs buffers because it never re-installs major modes like other multi-modes do. Dave Love's multi-mode.el gets full credit for this idea. > It looks like it slows emacs to a crawl in my main org config file. It seems to work fairly well in some of my notes files (though with some weird indenting behavior). Basically, simplicity is in place but at the cost of duplication. Lenses could avoid duplication, while yielding increased functionality and speed. (e.g. in polymode, a syntax checker couldn't yield correct results unless narrowing was constantly used, which is inefficient) Now, to MMM-mode. According to the info file: > Within the file, MMM-mode creates /submode regions/ within which other major modes are in effect. > While the point is in a submode region, the following changes occur: > <...> keymap <...> local variables <...> syntax table and indentation <...> font-lock > The submode regions are represented internally by Emacs Lisp objects known as /overlays/. > A lot of the functionality of MMM Mode---that which makes the major mode > appear to change---is implemented by saving and restoring the values of > local variables, or pseudo-variables. What I don't understand is where the modes of the submode region run and when they are turned on. Are necessary modes just allowed to run at the right time for the whole buffer? But then, how are they limited in their effect to just the necessary region? Narrowing? Could, for example, syntax checking be done efficiently that way? Could someone, please, explain? Best regards, Dmitrii.
[O] bug#35419: Fwd: Re: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter)
--- Begin Message --- Dear Dmitrii, I strongly support the proposal. Another use case for me is to speed up agenda creation. I usually do not like to split my org files into too many. However, it results in very large and slow org buffers later. If I can store some parts of the org files externally and only show them if some condition is met (say, for certain todo state of the parent entry), it would speed up my agenda and the buffer navigation quite significantly. Example: #+begin_src org * Projects ** 2019 *** TODO Project 1 :ORG: # the project contents is stored in an external file :PROPERTIES: :ORG-FILE: project1.org :END: # beginning of a lense, which is linked to project1.org Heading 1 Heading 2 And many headings below # ... # end of the lense *** HOLD Project 2 :ORG: :PROPERTIES: :ORG-FILE: project2.org :END: # beginning of another lense # nothing is included here because the project state is =HOLD= # end of the lense #+end_src Let me put some historical context to this proposal. There was a discussion of similar feature in emacs-dev last year. The idea was to implement nested buffers: https://lists.gnu.org/archive/html/emacs-devel/2018-07/msg00863.html There are also several projects, which implement part of the functionality you described: - mmm-mode: https://github.com/purcell/mmm-mode - polymode: https://github.com/polymode/polymode Best, Ihor Dmitrii Korobeinikov writes: > I have written a proposal for buffer lenses which could prove useful in > Org-mode, especially for interacting with code. > If you are interested, please, see this link: > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35419 -- Ihor Radchenko, signature.asc Description: PGP signature --- End Message --- -- Ihor Radchenko, signature.asc Description: PGP signature
[O] bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter)
> Have you looked at Phil Lord's lentic package? I think it implements a > lot of what you're talking about. > https://github.com/phillord/lentic This is nice to see! Indeed, except for embedding, there is a large overlap with what I described as buffer lenses. BTW, judging by this description: "changes percolation now happens incrementally, so only those parts of the buffer are updated. As a result, lentic now cope with long files with little noticable delay", the buffers don't share any data and need to sync with the master [linked] buffer. Is this the best solution? I have imagined that at the low level there is an actual data structure that keeps the raw textual data and it could be directly shared by multiple buffers. I mean, when a buffer is saved to a file, the text doesn't need to be stripped of properties beforehand, right? чт, 25 апр. 2019 г. в 07:37, Noam Postavsky : > Dmitrii Korobeinikov writes: > > > * Implementation > > > > I am not familiar with Emacs internals to say what's feasible of the > > proposed structure. > > Have you looked at Phil Lord's lentic package? I think it implements a > lot of what you're talking about. > > https://github.com/phillord/lentic >
Re: [O] [PROPOSAL] Use prefix arg to control scope of org-narrow-to-subtree.
Hello, Karl Fogel writes: > My proposal is for each raw prefix arg (each `C-u' prefix) to expand > the narrowing level outward/upward by one. So in the above situation: I suggest to use a numeric argument for that. M-1 for one level, M-2 for two levels, maybe M-0 equivalent to current behaviour. C-u can be a shortcut for M-1. > If you offer too many `C-u's, such that the narrowing would be wider than the > current surrounding first-level subtree, then there are two possible ways we > could handle it: > > 1) Extra `C-u's are ignored -- just narrow to surrounding 1st-level subtree. > > 2) Throw an error. > > I prefer (1), because it would be the more useful behavior, even > though (2) would be easier to implement (since `org-back-to-heading' > already throws the error). However, I'd welcome others' feedback on > that question, or on any other aspect of this proposal. 1 sounds good. I think it is a good idea. Thank you. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] Fix behaviour of ":dir" when ":mkdirp" is not defined
Hello, Joaquín Aguirrezabalaga writes: > Hello, > > I think the behaviour of ":dir" is broken since commit 8b5941330 > (ob-core: Make :mkdirp work for :dir too). It only works now if > ":mkdirp" is defined. > > If I execute the following: > > #+begin_src elisp :dir /tmp/some-test-dir > default-directory > #+end_src > > > Instead of the expected "/tmp/some-test-dir" returned value, I get my > current directory. > > Only add ":mkdirp t": > > #+begin_src elisp :dir /tmp/some-test-dir :mkdirp t > default-directory > #+end_src > > do I get the expected result. > > Please find attached my proposal for fixing the issue. Applied, with a slight refactoring to use `cond' instead of `or' + `if'. I added TINYCHANGE at the end of the commit message since I don't know if you signed FSF papers already. Thank you. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] org-manual: Fix typo
Hello, Sebastian Miele writes: > * doc/org-manual.org (Footnotes): Fix typo. Applied. Thank you. Regards, -- Nicolas Goaziou
Re: [O] table --> org-drill
> On 2019-Apr-24, at 23:57, Damon Permezel wrote: > > Just noticed a bug as I was reading my post. Just if argument-prefix is > applied, it will keep trying a line with no tabs (or less than 2) and not > advance the line. I’m sure there are more…. > This version is somewhat better. It skips comment lines and org headers lines, plus fixes a few bugs, while introducing an equal measure of new ones + 1. (defun txt-to-TSV () "turn a tab-separated text line into TSV" (interactive) (save-mark-and-excursion (save-restriction (let ((beg (progn (beginning-of-line) (point))) (end (progn (end-of-line) (point))) (tsv (vector)) (prev nil)) (narrow-to-region beg end) (goto-char beg) (when (and (not (= (following-char) ?#)) (not (= (following-char) ?*))) (setq prev beg) (while (< (point) end) (when (looking-at "\t") (setq tsv (vconcat tsv (vector (buffer-substring prev (point) (setq prev (+ 1 (point (forward-word)) (setq tsv (vconcat tsv (vector (buffer-substring prev (point)) tsv (defun txt-to-drill (arg) "convert TSV to drill" (interactive "p") (let ((query (concat "*** Query :drill:\n" ":PROPERTIES:\n" ":END:\n")) (answer (concat " Answer\n"))) (while (> arg 0) (setq arg (- arg 1)) (let ((tsv (txt-to-TSV))) (if (> (length tsv) 1) (progn (beginning-of-line) (insert "\n" query (aref tsv 0)) (insert "\n" answer (aref tsv 1)) (let ((i 2)) (while (< i (length tsv)) (insert "\n" (aref tsv i)) (setq i (+ 1 i (insert "\n") (insert "# ") (beginning-of-line (forward-line signature.asc Description: Message signed with OpenPGP
