Re: yank in middle of text a headline
> if i copy x and yank it where | is, it yanks immediately above y. i > prefer that it yanks at |. is this possible? I cannot reproduce it on my side. What is the org-mode version you are using? Best, Ihor Samuel Wales writes: > === > * x > hi > | > there > * y > === > > if i copy x and yank it where | is, it yanks immediately above y. i > prefer that it yanks at |. is this possible? > > is this new behavior?
Re: [Patch] Bug: org-indent-region doesn't restore cursor position when org-src-tab-acts-natively is t [9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/26.3/lisp/org/)]
Hi, The attached patch fixes this issue for emacs >= 26.1. It also fixes a similar issue where comment-line moves the cursor to the beginning of the block aswell. Can this patch be applied ? Regards, Sébastien Miquel >From 36f01b8e9d8dc335564f8dc932caf21c43c374eb Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= Date: Sun, 4 Oct 2020 21:33:30 +0200 Subject: [PATCH] org-edit-src: Use replace-buffer-contents * lisp/org-src.el (org-src--contents-for-write-back): Use a write back buffer * lisp/org-src.el (org-edit-src-exit): Use replace-buffer-contents * lisp/org-src.el (org-edit-src-save): Use replace-buffer-contents --- lisp/org-src.el | 40 +++- 1 file changed, 27 insertions(+), 13 deletions(-) diff --git a/lisp/org-src.el b/lisp/org-src.el index 28733d011..4f0044394 100644 --- a/lisp/org-src.el +++ b/lisp/org-src.el @@ -432,8 +432,8 @@ spaces after it as being outside." (line-end-position) (point)) -(defun org-src--contents-for-write-back () - "Return buffer contents in a format appropriate for write back. +(defun org-src--contents-for-write-back (write-back-buf) + "Populate write-back-buf with contents in a format appropriate for write back. Assume point is in the corresponding edit buffer." (let ((indentation-offset (if org-src--preserve-indentation 0 @@ -445,7 +445,7 @@ Assume point is in the corresponding edit buffer." (source-tab-width org-src--tab-width) (contents (org-with-wide-buffer (buffer-string))) (write-back org-src--allow-write-back)) -(with-temp-buffer +(with-current-buffer write-back-buf ;; Reproduce indentation parameters from source buffer. (setq indent-tabs-mode use-tabs?) (when (> source-tab-width 0) (setq tab-width source-tab-width)) @@ -462,8 +462,7 @@ Assume point is in the corresponding edit buffer." (let ((i (current-column))) (delete-region (line-beginning-position) (point)) (indent-to (+ i indentation-offset - (forward-line))) - (buffer-string + (forward-line)) (defun org-src--edit-element (datum name initialize write-back contents remote) @@ -1189,20 +1188,27 @@ Throw an error if there is no such buffer." (interactive) (unless (org-src-edit-buffer-p) (user-error "Not in a sub-editing buffer")) (set-buffer-modified-p nil) - (let ((edited-code (org-src--contents-for-write-back)) + (let ((write-back-buf (generate-new-buffer "*org-src-write-back*")) (beg org-src--beg-marker) (end org-src--end-marker) (overlay org-src--overlay)) +(org-src--contents-for-write-back write-back-buf) (with-current-buffer (org-src-source-buffer) (undo-boundary) (goto-char beg) ;; Temporarily disable read-only features of OVERLAY in order to ;; insert new contents. (delete-overlay overlay) - (delete-region beg end) (let ((expecting-bol (bolp))) - (insert edited-code) + (if (version< emacs-version "26.1") + (progn (delete-region beg end) + (insert (with-current-buffer write-back-buf (buffer-string + (save-restriction + (narrow-to-region beg end) + (replace-buffer-contents write-back-buf) + (goto-char (point-max (when (and expecting-bol (not (bolp))) (insert "\n"))) + (kill-buffer write-back-buf) (save-buffer) (move-overlay overlay beg (point ;; `write-contents-functions' requires the function to return @@ -1219,7 +1225,8 @@ Throw an error if there is no such buffer." (remote org-src--remote) (coordinates (and (not remote) (org-src--coordinates (point) 1 (point-max - (code (and write-back (org-src--contents-for-write-back + (write-back-buf (and write-back (generate-new-buffer "*org-src-write-back*" +(when write-back (org-src--contents-for-write-back write-back-buf)) (set-buffer-modified-p nil) ;; Switch to source buffer. Kill sub-editing buffer. (let ((edit-buffer (current-buffer)) @@ -1229,13 +1236,20 @@ Throw an error if there is no such buffer." (kill-buffer edit-buffer)) ;; Insert modified code. Ensure it ends with a newline character. (org-with-wide-buffer - (when (and write-back (not (equal (buffer-substring beg end) code))) + (when (and write-back (not (equal (buffer-substring beg end) + (with-current-buffer write-back-buf (buffer-string) (undo-boundary) (goto-char beg) - (delete-region beg end) (let ((expecting-bol (bolp))) - (insert code) - (when (and expecting-bol (not (bolp))) (insert "\n") + (if (version< emacs-version "26.1") + (progn (delete-region beg end) + (insert (with-current-buffer write-back-buf (buffer-string + (save-restriction + (narrow-to-region beg end) + (replace-buffer-contents write-back-buf) + (goto-char (point-max + (when (and expecting-bol (not (bolp))) (insert "\n"))) + (kill-buffer
Re: Proposal: do not align tags in Agenda
Hello Kyle, Thanks very much for your feedback. As these are changes I made months ago, I forgot the … finer details—I basically got my narrative completely wrong, my apologies. My problem wasn't at all, as you point out, that the tag would erase the entry. It has to do with habits: The habit graph overwrites anything else. I like having org-agenda-tags-column to a low value (wide screen), but tags are crucial to my workflow, so them being overwritten is problematic. My previous patch is completely overkill for that purpose (it's even misguided since it does stem from a misunderstanding of tags alignment). Here's a simpler patch. It may be a matter of taste, though. Cheers, M. On Tue, Sep 29, 2020 at 10:36 PM Kyle Meyer wrote: > > Michaël Cadilhac writes: > > > Hello all, > > > > I have a wide screen, which makes right edge alignment of tags in the > > agenda inconvenient (they're hard to match with the main entry). > > Setting org-agenda-tags-column to a specific column overwrites part of > > the entry, which is not optimal. I'd simply want the tag to be put > > _after_ the entry. > > Hmm, I don't think it's supposed to overwrite part of the entry. I > haven't been able to trigger that on my end. Here's the setup I tried > with an otherwise vanilla configuration: > > (setq org-agenda-files (list "/tmp/scratch.org")) > (setq org-agenda-tags-column 25) > > where /tmp/scratch.org looks like this > > * TODO foo bar baz > :one: > * TODO b > :two: > > When I run org-todo-list, the longer top entry isn't overwritten: > > Global list of TODO items of type: ALL > Press ‘N r’ (e.g. ‘0 r’) to search again: (0)[ALL] (1)TODO (2)DONE > scratch:TODO foo bar baz :one: > scratch:TODO b :two: > > What am I missing? diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index e4a334dbd..a80123853 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -9080,6 +9080,10 @@ current line." (goto-char (match-beginning 1)) (delete-region (save-excursion (skip-chars-backward " \t") (point)) (point)) + (when (get-text-property (point) 'org-habit-p) + (setq c (max c (+ 1 org-habit-graph-column + org-habit-preceding-days + org-habit-following-days (insert (org-add-props (make-string (max 1 (- c (current-column))) ?\s) (plist-put (copy-sequence (text-properties-at (point)))
Re: Bug: org-priority face has extra space at the end starting from version 9.4 [9.4 (9.4-elpaplus @ /home/rrudakov/.emacs.d/elpa/org-plus-contrib-20200914/)]
On 2020-09-29, 08:00 +, Roman Rudakov wrote: > "Protesilaos Stavrou" writes: > >> Roman Rudakov [2020-09-15, 18:50 +]: >> >>> I use theme which draw boxes around priority cookie. Before updating to >>> version 9.4 box was rendered just around square brackets, but since >>> version 9.4 it has additional space at the end. >>> >>> I think it's related to the fact that org-priority face definition used >>> to use separate regex which didn't include space, and now it uses >>> variable org-priority-regexp which does include additional space >>> character. >>> >>> [...] >> >> This issue is noticeable with any face properties for 'org-priority' >> such as box, background, underline, overline. >> >> Just to add a reproducible recipe for this case. >> >> On 'emacs -Q' running Org 9.4: >> >> + C-x C-f /tmp/test.org >> + Insert a heading, like: >> >> * TODO [#A] This is a test >> >> …see attached screenshot with "default" state. >> >> * Now evaluate the following expression: >> >> (set-face-attribute 'org-priority nil :underline t) >> >> …see attached screenshot with "edited" state. >> >> -- >> Protesilaos Stavrou >> protesilaos.com > > Hello, > > I think proper value for `org-priority-regex` should be > ".*?\\(\\[#\\([A-Z0-9]+\\)\\]\\) ?", extra space should be moved out of > the brackets, It won't break anything and face definition will be > correct. > > Best regards. This is to confirm that I and Ilja (in Cc) get the desired behaviour by evaluating the suggested regexp. Steps to quickly reproduce this on 'emacs -Q': + C-x C-f /tmp/test.org + Insert a heading with a priority cookie: - * TODO [#A] This is a test + Evaluate: (set-face-attribute 'org-priority nil :background "#ddd") - The background is just to visualise the extra blank to the right of the cookie's closing bracket. Same principle for underlines, overlines, boxes. + Eval: (setq org-priority-regexp ".*?\\(\\[#\\([A-Z0-9]+\\)\\]\\) ?") + M-x org-mode-restart + The extra space which was coloured before should no longer be affected by the face properties. The background we added must only cover the priority cookie's text. Best regards, Protesilaos -- Protesilaos Stavrou protesilaos.com
