Re: [PROPOSAL] New function `org-headings-to-point' and displayer.
Very nice! It works also in Narrow mode, which makes it even more useful for me. Thanks! --Diego On Tue, Dec 3, 2019 at 3:58 AM Karl Fogel wrote: > Hi. I've been using this for a while and find it very handy. > > If people like this and want it in Org Mode, I'll do the rest of the work > to package it up as a patch, with ChangeLog entry, NEWS, etc, and post it > here for review before committing. > > To try it out, just evaluate both functions and then run > > `M-x org-display-headings-to-point' > > from somewhere deep in an org subtree. Comments/feedback welcome. > > Best regards, > -Karl > > (defun org-headings-to-point () > "Return all the Org Mode headings leading to point." > (when (not (eq major-mode 'org-mode)) > (error "ERROR: this only works in Org Mode")) > (let ((headings (list (org-heading-components > (save-excursion > (save-match-data > (save-restriction > (widen) > (while (org-up-heading-safe) > (setq headings (cons (org-heading-components) headings) > headings))) > > (defun org-display-headings-to-point () > "Display Org Mode heading titles from level 1 to current subtree. > Display each title on its own line, indented proportionally to its level." > (interactive) > (let* ((heading-titles (mapcar (lambda (heading) >(nth 4 heading)) > (org-headings-to-point))) > (level 0) > (hierarchy (mapcar (lambda (title) > (prog1 > (if (zerop level) > (concat "• " title) > (concat "\n" > (make-string (* level 2) ? ) > "→ " title)) > (setq level (1+ level > heading-titles))) > (display-message-or-buffer (string-join hierarchy > >
[PROPOSAL] New function `org-headings-to-point' and displayer.
Hi. I've been using this for a while and find it very handy. If people like this and want it in Org Mode, I'll do the rest of the work to package it up as a patch, with ChangeLog entry, NEWS, etc, and post it here for review before committing. To try it out, just evaluate both functions and then run `M-x org-display-headings-to-point' from somewhere deep in an org subtree. Comments/feedback welcome. Best regards, -Karl (defun org-headings-to-point () "Return all the Org Mode headings leading to point." (when (not (eq major-mode 'org-mode)) (error "ERROR: this only works in Org Mode")) (let ((headings (list (org-heading-components (save-excursion (save-match-data (save-restriction (widen) (while (org-up-heading-safe) (setq headings (cons (org-heading-components) headings) headings))) (defun org-display-headings-to-point () "Display Org Mode heading titles from level 1 to current subtree. Display each title on its own line, indented proportionally to its level." (interactive) (let* ((heading-titles (mapcar (lambda (heading) (nth 4 heading)) (org-headings-to-point))) (level 0) (hierarchy (mapcar (lambda (title) (prog1 (if (zerop level) (concat "• " title) (concat "\n" (make-string (* level 2) ? ) "→ " title)) (setq level (1+ level heading-titles))) (display-message-or-buffer (string-join hierarchy
Re: Displaying remote images
* As always I much agree with Nick, looks like a great patch ** Meanwhile, this will read your R output and stick it at the end of the line & and show it all-at-once elisp:(progn (shell-command "rsync -a BlahRemoteHost:/blah-R-output.png /tmp")(sleep-for 3)(iimage-mode))]] /tmp/blah-R-output.png <-[The .png file showed up right here--no brackets necessary--but name of the file is] *** RSync may be replaced by SCP for sure On Mon, Dec 2, 2019 at 3:29 PM Nick Dokos wrote: > Jack Kamm writes: > > > I've attached a patch which implements displaying remote images. > > > >> This is a longstanding problem, and there was an attempt to patch it in > >> 2014, but the patch was never accepted: > >> https://lists.gnu.org/archive/html/emacs-orgmode/2014-11/msg00583.html > > > > Compared to the previous attempt from 2014, I think my patch is simpler > > -- it doesn't require creating any temp files. > > > >> The fault might be with image.el rather than with org-mode itself -- > >> for example, when I execute the following elisp, I get the same blank > >> box: > > > > After doing some reading, I learned that image.el doesn't really create > > the image. Instead, create-image simply creates a blank string with a > > text property pointing to the image file location, and the rendering of > > the image gets handled later by the C code (for example, png_load_body() > > in image.c), which doesn't know how to read remote image files. > > > > Since I wasn't comfortable trying to get the C code to read the remote > > file, I instead took the approach used by image-mode.el, which reads the > > remote image file and passes its contents directly to create-image, > > instead of just passing the filename. > > > > From 47120666dad6eb0b6ca716325d7de86924e1d28e Mon Sep 17 00:00:00 2001 > > From: Jack Kamm > > Date: Thu, 28 Nov 2019 17:45:56 -0800 > > Subject: [PATCH] org: display remote images > > > > --- > > lisp/org.el | 13 ++--- > > 1 file changed, 10 insertions(+), 3 deletions(-) > > > > diff --git a/lisp/org.el b/lisp/org.el > > index 90f222c8b..dc7bcc7aa 100644 > > --- a/lisp/org.el > > +++ b/lisp/org.el > > @@ -16754,13 +16754,20 @@ buffer boundaries with possible narrowing." > > (t nil))) > > (old (get-char-property-and-overlay > > (org-element-property :begin link) > > - 'org-image-overlay))) > > + 'org-image-overlay)) > > + (remote-p (file-remote-p file))) > > (if (and (car-safe old) refresh) > > (image-refresh (overlay-get (cdr old) 'display)) > > - (let ((image (create-image file > > + (let ((image (create-image (if (not remote-p) > > +file > > + (with-temp-buffer > > + > (insert-file-contents file) > > +(string-make-unibyte > > + > (buffer-substring-no-properties > > + (point-min) > (point-max) > > (and > (image-type-available-p 'imagemagick) > > width 'imagemagick) > > -nil > > +remote-p > > :width width))) > > (when image > > (let ((ov (make-overlay > > FWIW, looks good to me, but I've only (carefully) read the patch: I have > not actually ran it. > > -- > Nick > > "There are only two hard problems in computer science: cache > invalidation, naming things, and off-by-one errors." -Martin Fowler > > >
Re: Editting from the agenda view
Shérab writes: >> To reschedule an entry remotely from the agenda view, you can press S-right >> (org-agenda-do-date-later) or S-left (org-agenda-do-date-earlier). > > I indeed remember having seen these commands! > The thing is that I am using emacs in the Linux console where these > bindings do not work, so I couldn't try them. Is there a way to bind > them to different key bindings? Check out 'TTY Keys' in the orgmode manual. , [ (org) TTY keys ] | 15.9 Using Org on a tty | === | | Org provides alternative key bindings for TTY and modern mobile | devices | that cannot handle cursor keys and complex modifier key chords. Some | of | these workarounds may be more cumbersome than necessary. Users should | look into customizing these further based on their usage needs. For | example, the normal ‘S-’ for editing timestamp might be better | with ‘C-c .’ chord. [...] ` Checking org-agenda-do-date-later, I see , | org-agenda-do-date-later is an interactive compiled Lisp function in | ‘../org-mode/lisp/org-agenda.el’. | | It is bound to , C-c C-x , | . ` So C-c C-x should be a tty friendly alternative to . hth mem -- /---\ | SDF and SDF-EU Public Access UNIX System | | http://sdf.org || http://sdf-eu.org | =
Re: Support for something like org-image-max-width
Terje Larsen writes: > There is already org-image-actual-width but the problem with that one is > that images that have quite small width, but are tall will be scaled and > become very tall. > I think it would make sense to introduce something like > org-image-max-width, which would scale images that are larger than this > width, but leave images within this width alone. I think this is doable since there is already a max-width parameter for images IIRC. But this means some work AFAICS. A way could be to allow a pair like (max-width . 555) as org-image-actual-width with the meaning to downsize any image wider than 555 and let the smaller images alone. Could you invest some energy and possibly suggest a patch? You have all the time. > Another interesting thing would be to be able to adjust the max-width to > the width of the buffer, but not sure how well that will play in all > cases and how complex that would be. This looks also doable AFAICT. FWIW I use a little extension of the image-map which allows to adjust the image width with the window-width with key "W" on the image. (Quite a bunch of w's in that sentence.) This is the respective code from my init file: #v+ (defun mw-image-change-width-to-window-width () "Resize image width to match window-width." (interactive) (let* ((image (image--get-image)) (new-image (image--image-without-parameters image))) (setcdr image (cdr new-image)) (plist-put (cdr image) :width (nth 2 (window-inside-pixel-edges) (define-key image-map "W" #'mw-image-change-width-to-window-width) #v-
Re: Displaying remote images
Jack Kamm writes: > I've attached a patch which implements displaying remote images. > >> This is a longstanding problem, and there was an attempt to patch it in >> 2014, but the patch was never accepted: >> https://lists.gnu.org/archive/html/emacs-orgmode/2014-11/msg00583.html > > Compared to the previous attempt from 2014, I think my patch is simpler > -- it doesn't require creating any temp files. > >> The fault might be with image.el rather than with org-mode itself -- >> for example, when I execute the following elisp, I get the same blank >> box: > > After doing some reading, I learned that image.el doesn't really create > the image. Instead, create-image simply creates a blank string with a > text property pointing to the image file location, and the rendering of > the image gets handled later by the C code (for example, png_load_body() > in image.c), which doesn't know how to read remote image files. > > Since I wasn't comfortable trying to get the C code to read the remote > file, I instead took the approach used by image-mode.el, which reads the > remote image file and passes its contents directly to create-image, > instead of just passing the filename. > > From 47120666dad6eb0b6ca716325d7de86924e1d28e Mon Sep 17 00:00:00 2001 > From: Jack Kamm > Date: Thu, 28 Nov 2019 17:45:56 -0800 > Subject: [PATCH] org: display remote images > > --- > lisp/org.el | 13 ++--- > 1 file changed, 10 insertions(+), 3 deletions(-) > > diff --git a/lisp/org.el b/lisp/org.el > index 90f222c8b..dc7bcc7aa 100644 > --- a/lisp/org.el > +++ b/lisp/org.el > @@ -16754,13 +16754,20 @@ buffer boundaries with possible narrowing." > (t nil))) > (old (get-char-property-and-overlay > (org-element-property :begin link) > - 'org-image-overlay))) > + 'org-image-overlay)) > + (remote-p (file-remote-p file))) > (if (and (car-safe old) refresh) > (image-refresh (overlay-get (cdr old) 'display)) > - (let ((image (create-image file > + (let ((image (create-image (if (not remote-p) > +file > + (with-temp-buffer > +(insert-file-contents > file) > +(string-make-unibyte > + > (buffer-substring-no-properties > + (point-min) > (point-max) > (and (image-type-available-p > 'imagemagick) > width 'imagemagick) > -nil > +remote-p > :width width))) > (when image > (let ((ov (make-overlay FWIW, looks good to me, but I've only (carefully) read the patch: I have not actually ran it. -- Nick "There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors." -Martin Fowler
Re: is this a known issue in clocktable output?
Marco Wahl writes: > Soubzriquet writes: >>> [...] > >>> > odd issue with using "day" steps where the date is getting offset >>> > sometimes. >>> > >>> > I saw the issue with 26.1, was not fixed by updating to current >>> > environment with an empty init.el on OS X: >>> > ... >>> > Daily report: [2019-11-03 Sun] >>> > | Headline | Time | >>> > |--+| >>> > | *Total time* | *3:00* | >>> > |--+| >>> > | Day 3| 3:00 | >>> > >>> > Daily report: [2019-11-03 Sun] >>> > | Headline | Time | >>> > |--+| >>> > | *Total time* | *4:00* | >>> > |--+| >>> > | Day 4| 4:00 | >>> > >>> I can not reproduce this behavior. > >> Hi, sorry I was not more clear - the issue occurs also with emacs -Q or >> with empty init.el on my system. > > Okay, thanks. I think I'm at the end of my abilities to investigate the > issue further. > > I suggest you dig a little deeper for better understanding. E.g.: > > - Try make the example of failure as small as you can. > > - Check with a newer version of Org. > > - Debug the issue. > > > Possibly someone else can confirm the issue. > > I can reproduce the issue with 9.1.9, but it goes away with 9.2 or later. Marco's suggestion to use a newer version is the right thing to do. -- Nick "There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors." -Martin Fowler
Re: [PATCH] Derive non-default start value for ordered list
On 2019-12-02, at 08:23, Nicolas Goaziou wrote: > Jens Lechtenboerger writes: > >> [...] >> What do you think about the attached patch that allows to omit the >> @-syntax? Controlled by the new variable >> org-list-use-first-bullet-as-non-standard-counter, the code assigns >> a counter value to the first list item from its bullet string if the >> item >> 1. does not specify a counter itself, >> 2. has an alphanumeric bullet, and >> 3. does not have a default start value (1, a, A). > > I think the current situation is better. It works, as advertised, and it > allows you to re-number any item in the list, not necessarily the first > one. One can still do this. > Of course, it may be less "elegant", but the overhead is negligible, > and, as a data point, I'd rather have continuation lists more visible > than not, as it could create confusion in the document. I understand. > I do not know about org-re-reveal, but included exporters do not display > the [@xxx] part. However, they use its value to start lists at an > appropriate number, if technically possible. I suggest org-re-reveal to > do the same if that's not the case. My backend does this, but maybe the user did not know about the @-syntax. Also, he did not want to change all his preexisting lists. Thanks for your feedback Jens
Re: [PATCH] Use prefix arg to control scope of org-narrow-to-subtree.
On 02 Dec 2019, Marco Wahl wrote: >Karl Fogel writes: >> Since `widen' itself is already available via C-x n w, it might be >> better to save a special flag value like that for some special >> behavior that we (or someone else) might think of in the future. I'm >> pretty sure that anyone using `org-narrow-to-subtree' must also know >> about the `widen' command, too. > >Okay, this sounds sound. > >Let me be a bit more explicit about my wish: I vote for the prefix arg 0 >to widen because this fits to the logic to view the whole file as level >0 subtree. With this perspective on the feature the effect of a numeric >prefix argument is clear as day: > >... >C-u 2 M-x org-narrow... => Narrow to the level-2 subtree containing point. >C-u 1 M-x org-narrow... => Narrow to the level-1 subtree containing point. >C-u 0 M-x org-narrow... => Narrow to the level-0 subtree containing point. > >The last line stands in opposition to the current behavior. > >C-u 0 M-x org-narrow... => Narrow to the level-1 subtree containing point. >^ ^ Oh, yes, I get the logic, from a consistency standpoint. My only concern is that a) it's unnecessary, because `widen' is available, and b) some day we might think of a better special meaning for C-u 0 (and in the meantime it could error instead of narrowing to the current level-1 subtree). But I don't feel strongly about it either way. Perhaps consistency is desirable here, although I tend to think that consistency is overrated in UI/UX in general -- the famous example of "`transpose-chars' at the end of a line" comes to mind. Hmm, but on the other hand, your proposed consistency *would* be good if anyone's ever calling `org-narrow-to-subtree' from Lisp with an algorithmically calculated STEPS argument. I can't imagine what kind of circumstance that would be, but if it's a general principle of Org Mode to consider "level 0" to be the entire buffer, then we should probably go with your proposed behavior. So I guess I'm tentatively +1... Does anyone else have any thoughts on this? Best regards, -Karl
Re: [PATCH] Derive non-default start value for ordered list
On 2019-12-01, at 14:13, Samuel Wales wrote: > i think it might be partlly a question of whether these numbers are > fixed things that refer to fixed items [like referring to sections in > a law that is not in the document] vs. being used to continue lists. > > they are both legitimate uses. in the first case, the @ syntax makes > sense to me, because it specifies a fixed alphanumber. yes i made > that word up. > > some exporters assume the numbers in the org source list don't matter > and start from 1 or the @ in the exported text. If I took the effort to type something, then that should not be ignored by an exporter. > so your solution would be anomalous. But meet some users’ expectations. Quite likely, those of new Org users. > and i'm used to exporters doing that so it feels strange to me to rely > on the org text. If text is ignored, I should not need to type it in the first place. > i view that as potentially changing. what should > occur if you do something that renumbers it? If I renumber, then, of course, I want to see the new numbers after export. > in the second case, the @ syntax and your solution both seem brittle > to me. you might add to the first list. I agree. > i think there can be a third solution that would be less brittle. > > just as a brainstorm, consider the common case of continued lists like > > vvv > 1. asdf > 2. <> asdf > > a paragraph. > > 3. [@asdf-list-end] asdf > ^^^ This would indeed be a cool solution. Thanks Jens
Re: [PATCH] Use prefix arg to control scope of org-narrow-to-subtree.
Karl Fogel writes: > On 02 Dec 2019, Marco Wahl wrote: >>What about numeric prefix arg 0 to reveal the whole buffer (aka >>'widen')? I think this would be a logical completion to the feature. > > Since `widen' itself is already available via C-x n w, it might be > better to save a special flag value like that for some special > behavior that we (or someone else) might think of in the future. I'm > pretty sure that anyone using `org-narrow-to-subtree' must also know > about the `widen' command, too. Okay, this sounds sound. Let me be a bit more explicit about my wish: I vote for the prefix arg 0 to widen because this fits to the logic to view the whole file as level 0 subtree. With this perspective on the feature the effect of a numeric prefix argument is clear as day: ... C-u 2 M-x org-narrow... => Narrow to the level-2 subtree containing point. C-u 1 M-x org-narrow... => Narrow to the level-1 subtree containing point. C-u 0 M-x org-narrow... => Narrow to the level-0 subtree containing point. The last line stands in opposition to the current behavior. C-u 0 M-x org-narrow... => Narrow to the level-1 subtree containing point. ^ ^
Re: [PATCH] Use prefix arg to control scope of org-narrow-to-subtree.
On 02 Dec 2019, Marco Wahl wrote: >What about numeric prefix arg 0 to reveal the whole buffer (aka >'widen')? I think this would be a logical completion to the feature. Since `widen' itself is already available via C-x n w, it might be better to save a special flag value like that for some special behavior that we (or someone else) might think of in the future. I'm pretty sure that anyone using `org-narrow-to-subtree' must also know about the `widen' command, too. Thoughts? Best regards, -Karl
Re: [PATCH] Use prefix arg to control scope of org-narrow-to-subtree.
Karl Fogel writes: > It allows you to choose what level subtree to narrow to. There are > two ways to specify the subtree: use repeated C-u's to select "upward" > from the current subtree, or use a direct numeric prefix arg to > specify the subtree "downward" from level 1. (This is a somewhat > unusual prefix argument usage, but it's useful to be able to choose > from either direction, and the convenience of using C-u to select > upward is quite enormous -- I expect it to be the common case, and > it's pretty much the only way I use the feature.) > > The prefix arg is optional, of course: if you don't pass it, then > `org-narrow-to-subtree' behaves the same way it has always behaved. What about numeric prefix arg 0 to reveal the whole buffer (aka 'widen')? I think this would be a logical completion to the feature.
Re: Editting from the agenda view
Hi Victor, many thanks for your response! Victor A. Stoichita (2019/11/26 20:19 +0100): > Indeed they are not global bindings. I don’t know how to rebind them for the > agenda view. > Meanwhile, the same functions in the agenda view are also bound to C-c C-x > and C-c C-x . These should work in the terminal, but I’m not > sure how handy they are as "shortcuts". Well at least I could try the commands, thanks a lot for that! So in my understanding thiese reschedule the event for the previous/next day and I assume that the prefix argument can be used to reschedule by a different number of days. Best wishes, Shérab.
Re: Editting from the agenda view
Dear Sebastian, Many thanks for your helpful message. Sebastian Miele (2019/11/27 02:55 +): > After opening the agenda, inspection of the buffer-local variable > major-mode (e.g. by C-h v) reveals that the major mode in the agenda > buffer is org-agenda-mode. A search for a variable containing > "org-agenda", and "map" reveals that most probably org-agenda-mode-map > is the keymap used there. It follows the usual naming scheme for major > mode maps. > > After (require 'org-agenda) it will be possible to (define-key > org-agenda-mode-map KEY BINDING) in an init file. Thank you so much for also having taken the time to explain how you found it, that's very helpful! Best wishes, Shérab.
Re: [PATCH] Use prefix arg to control scope of org-narrow-to-subtree.
Karl Fogel writes: > This is the enhancement to `org-narrow-to-subtree' that I suggested back in > May [1]. > > It allows you to choose what level subtree to narrow to. There are two > ways to specify the subtree: use repeated C-u's to select "upward" > from the current subtree, or use a direct numeric prefix arg to > specify the subtree "downward" from level 1. (This is a somewhat > unusual prefix argument usage, but it's useful to be able to choose > from either direction, and the convenience of using C-u to select > upward is quite enormous -- I expect it to be the common case, and > it's pretty much the only way I use the feature.) Just 2c: you're right that's a slightly odd use of the prefix argument. I think a slightly more conventional approach might be to use positive and negative numerical arguments, positive going one direction, negative the other. Just a suggestion, though -- I like this addition a lot.
