Thank you Re: [PATCH v2] org-agenda: Use `window-max-chars-per-line' to calculate max text width
At 15:04 +0800 on Sunday 2022-04-24, Ihor Radchenko wrote: > > "N. Jackson" writes: > >> I have tested with your v2 patch applied to Org 9.5.3: >> >> 1. It fixes the two bugs I reported in this thread >> >> 2. It also makes the Agenda display properly after the font size >> has been altered with C-x +/- > > Thanks. > Applied. > I have installed the patch onto main as 81a2fe4f0. Great. Thank you. >> 3. As is to be expected, it doesn't help with an Agenda displayed >> with a proportional font -- but it doesn't seem to make things >> any worse. > > I am not sure if there is much interest in this. I have proposed > pixel-precise alignment in agenda in the past. There was not much > interest. Indeed. I think there are things to be fixed, improved, and implemented that are much more important. Regards, N.
Re: [PATCH v2] org-agenda: Use `window-max-chars-per-line' to calculate max text width
At 17:27 +0800 on Friday 2022-04-22, Ihor Radchenko wrote: > > "N. Jackson" writes: >> >> If Org needs to support versions of Emacs before 25.1 then I assume >> you need the same guard on every instance of >> window-max-chars-per-line -- because window-max-chars-per-line was >> added to Emacs at the same time as window-font-width: > > We do not need to worry about this. Org supports the latest released > Emacs version + 2 previous [1]. Now, it means Emacs >=26. > > [1] https://orgmode.org/worg/org-maintenance.html#emacs-compatibility Ah, I didn't know that. Thanks. I have tested with your v2 patch applied to Org 9.5.3: 1. It fixes the two bugs I reported in this thread (with one or both fringes off, Agenda wraps `auto' (right) aligned tags unnecessarily and wraps the block separator). 2. It also makes the Agenda display properly after the font size has been altered with C-x +/-. This didn't work before, even with default fringes. [One has to hit `g' to refresh the Agenda after changing the font size.] 3. As is to be expected, it doesn't help with an Agenda displayed with a proportional font -- but it doesn't seem to make things any worse. FWIW a summary of my testing of tags alignment, separator width, and new time stamps for various fringe modes is shown below. 1. With my normal default font (-PfEd-DejaVu Sans Mono-normal-normal-normal-*-11-*-*-*-m-0-iso10646-1): |+---+---+---+---+---+---| || Tags alignment | Separator width |New time | | Fringe mode +---+---+---+---+---+---| || 9.5.3 | +v2 Patch | 9.5.3 | +v2 Patch | 9.5.3 | +v2 Patch | |+---+---+---+---+---+---| | Default (Both) | OK| OK| OK| OK| OK| OK| | Minimal| OK| OK| OK| OK| OK| OK| | Left only | FAIL | OK| FAIL | OK| OK| OK| | Right only | FAIL | OK| FAIL | OK| OK| OK| | No fringes | FAIL | OK| FAIL | OK| OK| OK| |+---+---+---+---+---+---| 2. After `C-x + + +' and also `C-x - - -' (giving -PfEd-DejaVu Sans Mono-normal-normal-normal-*-21-*-*-*-m-0-iso10646-1 and -PfEd-DejaVu Sans Mono-normal-normal-normal-*-7-*-*-*-m-0-iso10646-1): |+---+---+---+---+---+---| || Tags alignment | Separator width |New time | | Fringe mode +---+---+---+---+---+---| || 9.5.3 | +v2 Patch | 9.5.3 | +v2 Patch | 9.5.3 | +v2 Patch | |+---+---+---+---+---+---| | Default (Both) | FAIL | OK| FAIL | OK| OK| OK| | Minimal| FAIL | OK| FAIL | OK| OK| OK| | Left only | FAIL | OK| FAIL | OK| OK| OK| | Right only | FAIL | OK| FAIL | OK| OK| OK| | No fringes | FAIL | OK| FAIL | OK| OK| OK| |+---+---+---+---+---+---| 3. With a proportional font (-1ASC-Liberation Sans-normal-normal-normal-*-13-*-*-*-*-0-iso10646-1): |+---+---+---+---+---+---| || Tags alignment | Separator width |New time | | Fringe mode +---+---+---+---+---+---| || 9.5.3 | +v2 Patch | 9.5.3 | +v2 Patch | 9.5.3 | +v2 Patch | |+---+---+---+---+---+---| | Default (both) | FAIL | FAIL | FAIL | FAIL | OK| OK| | Minimal| FAIL | FAIL | FAIL | FAIL | OK| OK| | Left only | FAIL | FAIL | FAIL | FAIL | OK| OK| | Right only | FAIL | FAIL | FAIL | FAIL | OK| OK| | No fringes | FAIL | FAIL | FAIL | FAIL | OK| OK| |+---+---+---+---+---+---| Note: My testing of the position of the new time stamps was only cursory. I never pay attention to them in normal use. I just checked that they were approximately right aligned. [I think, in fact, that both before and after your patch the behaviour isn't quite correct -- the stamps appear to be one character too far to the left. Of course that is barely noticeable and there are clearly far far more important things in Org to be worked on.] Regards, N.
Re: [PATCH v2] org-agenda: Use `window-max-chars-per-line' to calculate max text width
At 13:58 +0800 on Friday 2022-04-22, Ihor Radchenko wrote: > > Attaching the updated patch. > @@ -10301,10 +10301,7 @@ (defun org-agenda-show-new-time (marker stamp > &optional prefix) > (line-end-position) > '(display nil)) > (org-move-to-column > - (- (if (fboundp 'window-font-width) ^^^ > - (/ (window-width nil t) (window-font-width)) > -;; Fall back to pre-9.3.3 behavior on Emacs <25. > -(window-width)) > + (- (window-max-chars-per-line) The fboundp version guard on window-font-width was added to Org recently: commit 94837fc6b5ca204962f3ed992e30cd998d66a9fe Author: Kyle Meyer Date: Sat May 1 15:48:11 2021 -0400 agenda: Fix org-agenda-show-new-time on Emacs 24 * lisp/org-agenda.el (org-agenda-show-new-time): Add fallback for when window-font-width isn't available. efbf96389 (org-agenda.el: Fix display of agenda new time, 2020-02-02) reworked the column calculation to use window-font-width, but that function isn't available until Emacs 25, and it's definition can't be easily ported to org-compat. Instead just use the old logic, which had been in place since v8.2.6, when window-font-width isn't available. Reported-by: Ihor Radchenko Link: https://orgmode.org/list/87y2d2mqik.fsf@localhost If Org needs to support versions of Emacs before 25.1 then I assume you need the same guard on every instance of window-max-chars-per-line -- because window-max-chars-per-line was added to Emacs at the same time as window-font-width: commit 4a50af936e24b5f71df4079beb6dde82ed1955c2 Author: Titus von der Malsburg Date: Sat Mar 21 12:31:29 2015 +0200 Add new functions for computing default font dimensions lisp/window.el (window-font-width, window-font-height) (window-max-chars-per-line): New functions. lisp/simple.el (default-font-height): Doc fix. (default-font-width): New function. etc/NEWS: Mention `default-font-width', `window-font-height', `window-font-width', and `window-max-chars-per-line'. [These functions were new in Emacs 25.1: $ cat etc/NEWS.25 | grep -C 5 window-max-chars-per-line *** New functions 'window-font-height' and 'window-font-width' return the height and average width of characters in a specified face and window. If FACE is remapped (see 'face-remapping-alist'), the function returns the information for the remapped face. *** A new function 'window-max-chars-per-line' returns the maximal number of characters that can be displayed on one line. If a face and/or window are provided, these values are used for the calculation. This function is different from 'window-body-width' in that it accounts for (i) continuation glyphs, (ii) the size of the font, and (iii) the specified window. ] Perhaps this calls for a new wrapper function in Org, an org--window-max-chars-per-line that wraps window-max-chars-per-line in an fboundp and falls back to window-width -- rather than clutter up the code with the fboundp guard. Regards, N.
Re: [PATCH] org-agenda: Use `window-max-chars-per-line' instead of `window-width'
Hello Ihor, At 03:16 -0400 on Thursday 2022-04-21, N. Jackson wrote: > > However, the problem with the tags wrapping in Agenda (instead of > being right aligned) remains. I believe the problem with the wrapping of the Agenda tags is here: (defun org-agenda-align-tags (&optional line) "Align all tags in agenda items to `org-agenda-tags-column'. When optional argument LINE is non-nil, align tags only on the current line." (let ((inhibit-read-only t) (org-agenda-tags-column (if (eq 'auto org-agenda-tags-column) (- (window-text-width)) ^ org-agenda-tags-column)) (end (and line (line-end-position))) l c) ... Changing window-text-width to window-max-chars-per-line fixes the problem here and seems like the right thing to do. Regards, N.
Re: [PATCH] org-agenda: Use `window-max-chars-per-line' instead of `window-width'
At 13:25 +0800 on Thursday 2022-04-21, Ihor Radchenko wrote: > > Attaching the patch. Great. I tested the patch (with Org mode version 9.5.3) and that fixes the problem for the block separator wrapping. However, the problem with the tags wrapping in Agenda (instead of being right aligned) remains. Thank you and best regards, N. > From 5de3de87872ddae994f5b68eba74d915d5f73201 Mon Sep 17 00:00:00 2001 > Message-Id: > <5de3de87872ddae994f5b68eba74d915d5f73201.1650518543.git.yanta...@gmail.com> > From: Ihor Radchenko > Date: Thu, 21 Apr 2022 13:18:39 +0800 > Subject: [PATCH] org-agenda: Use `window-max-chars-per-line' instead of > `window-width' > > * lisp/org-agenda.el (org-agenda-prepare): > (org-todo-list): > (org-agenda-show-new-time): Calculate the maximum number of chars > fitting into window via `window-max-chars-per-line' instead of > `window-with'. The latter can return larger number when fringes are > disabled [1]. > > [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19395 > > Reported in https://orgmode.org/list/87czhdqi9p.fsf_-_@moondust.localdomain > --- > lisp/org-agenda.el | 9 +++-- > 1 file changed, 3 insertions(+), 6 deletions(-) > > diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el > index a09b53563..9ddee81ee 100644 > --- a/lisp/org-agenda.el > +++ b/lisp/org-agenda.el > @@ -3925,7 +3925,7 @@ (defun org-agenda-prepare (&optional name) > (insert "\n" > (if (stringp org-agenda-block-separator) > org-agenda-block-separator > - (make-string (window-width) org-agenda-block-separator)) > + (make-string (window-max-chars-per-line) > org-agenda-block-separator)) > "\n")) > (narrow-to-region (point) (point-max))) > (setq org-done-keywords-for-agenda nil) > @@ -4944,7 +4944,7 @@ (defun org-todo-list (&optional arg) > (let ((n 0)) >(dolist (k kwds) > (let ((s (format "(%d)%s" (cl-incf n) k))) > - (when (> (+ (current-column) (string-width s) 1) > (window-width)) > + (when (> (+ (current-column) (string-width s) 1) > (window-max-chars-per-line)) > (insert "\n ")) >(insert " " s > (insert "\n")) > @@ -10301,10 +10301,7 @@ (defun org-agenda-show-new-time (marker stamp > &optional prefix) > (line-end-position) > '(display nil)) > (org-move-to-column > - (- (if (fboundp 'window-font-width) > - (/ (window-width nil t) (window-font-width)) > -;; Fall back to pre-9.3.3 behavior on Emacs <25. > -(window-width)) > + (- (window-max-chars-per-line) >(length stamp)) > t) >(add-text-properties
Re: [BUG] Off-by-one error in width of Agenda window?
At 12:01 +0800 on Wednesday 2022-04-20, Ihor Radchenko wrote: > > "N. Jackson" writes: > >> It seems that Org maybe should be using window-max-chars-per-line >> rather than window-width. >> >> [Unfortunately w-m-c-p-l is not a drop in replacement for >> window-width; it doesn't just fix the continuation glyph column >> "bug", but it also adds additional functionality and has a different >> signature.] > > Could you elaborate why window-max-chars-per-line cannot be used > instead of window-width by Org? It appears to be strictly more > accurate. No, I'm not saying Org shouldn't use window-max-chars-per-line -- rather the opposite in fact. I'm just saying it maybe needs to be thought about carefully first. If it works as advertised it would seem to be the right choice as long as Emacs bug #19395 exists (which looks like it will be forever). My reservations about the function are only that its spec is more ambitious than that of window-width (because it handles faces) and the added complexity might potentially introduce more corner cases where it doesn't work. But perhaps that's just the paranoia of someone who thinks that text editors should restrict themselves to monospaced fonts! Regards, N.
Re: [BUG] Off-by-one error in width of Agenda window?
At 11:16 +0800 on Tuesday 2022-04-19, Ihor Radchenko wrote: > > Thanks! I was able to reproduce the problem. > > I believe that it is not Org's fault. Org is trusting (window-width) > return value to calculate the width of the separator line. However, with > you settings, (window-width) apparently returns a wrong value. You can > see it yourself by running (insert (make-string (window-width) ?=)) in > scratch buffer with and without your fringe settings. > > Probably, you should report this as Emacs bug. It turns out there is already an Emacs bug for this (Bug 19395: Setting left fringe to 0 messes up window-width (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19395)). My understanding of the discussion is that the bug is caused by window-width including in its return value the width of the column reserved for the continuation glyph (which column exists when one or both of the fringes is/are turned off), so window-width over-reports the available width of the window in this case. The bug hasn't been closed, but IIUC it has been "fixed" by changing the documentation of window-width to indicate the limitation. The latter part of the bug thread is a discussion and development of the function window-max-chars-per-line. It seems that Org maybe should be using window-max-chars-per-line rather than window-width. [Unfortunately w-m-c-p-l is not a drop in replacement for window-width; it doesn't just fix the continuation glyph column "bug", but it also adds additional functionality and has a different signature.] Regards, N. P.S. I learnt in my reading that turning off one of my fringes gains me nothing because Emacs then turns around an puts an empty column on the right side of my window to potentially display a continuation glyph. So, to work around this Agenda bug temporarily I have turned on both fringes.
Re: [BUG] Off-by-one error in width of Agenda window? [9.5.2 (release_9.5.2-25-gaf6f12 @ /data/installs/snapshots/emacs-28.1/lisp/org/)]
At 21:39 +0800 on Monday 2022-04-18, Ihor Radchenko wrote: > "N. Jackson" writes: > >> Recently it seems as if Org Agenda thinks its window is one >> character wider than it actually is. The incorrect behaviour I >> observe is: > > I do not see any issues on both stable bugfix and main branches. > > Are you able to reproduce starting from emacs -Q? No, it doesn't happen just with emacs -Q. I have bisected my init file and narrowed it down to this setting in my custom-set-variables: '(fringe-mode '(nil . 0) nil (fringe)) Here is a recipe to reproduce the problem from emacs -Q: 0. M-x global-visual-line-mode RET 1. M-x org-agenda RET n [To generate the default block Agenda.] 2. Notice that the line of equal signs separating the two blocks of the Agenda is not wrapped. <== CORRECT 3. M-x customize-option RET fringe-mode RET 4. Click the Value Menu button and choose "Left only". 5. Click the Apply button. 6. If the Agenda buffer is no longer visible switch to it (or just run org-agenda again). 7. Notice that the line of equal signs is now wrapped. <== INCORRECT Note that setting visual line mode is not really needed for the recipe, it just makes the problem easier to see. When visual line mode is not on a $ sign is displayed at the end of the overlong lines to show they are truncated, and that is not as glaring an error as when they are wrapped. Regards, N.
[BUG] Off-by-one error in width of Agenda window? [9.5.2 (release_9.5.2-25-gaf6f12 @ /data/installs/snapshots/emacs-28.1/lisp/org/)]
Recently it seems as if Org Agenda thinks its window is one
character wider than it actually is. The incorrect behaviour I
observe is:
1. Tags in Agenda are all wrapped to the next line even though there
is plenty of space to display them on the same
line. (org-agenda-tags-column is set to its default value of `auto'
so I expect tags to be right aligned to the right edge of the
window.)
2. In a block agenda, the last '=' character of the block separator
is wrapped to the next line. (org-agenda-block-separator is set to
its default value of character 61 ('=') so I expect a line of equals
signs as wide as the Agenda window -- I don't expect it to be so
wide that it wraps to the next line.)
Emacs : GNU Emacs 28.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30,
cairo version 1.17.4)
of 2022-04-18
Package: Org mode version 9.5.2 (release_9.5.2-25-gaf6f12 @
/data/installs/snapshots/emacs-28.1/lisp/org/)
[O] org-agenda-log-mode omits some items from LOGBOOK drawers
In Org Agenda, `C-u l', which IIUC is supposed to "show all possible log items, not only the ones configured in `org-agenda-log-mode-items'" shows clocking of work, closing of entries, and other state changes of entries (tagged in the agenda with "Clocked", "Closed", and "State" respectively). That is very useful. However, note entries in the LOGBOOK drawer (created with org-add-note) are unfortunately omitted. Also, all my LOGBOOK drawers contain a CREATED inactive time stamp (placed there by my capture templates), but these CREATED entries are also omitted. Am I doing something wrong? Are these other entries from the LOGBOOK drawer expected to be included in the Agenda with `C-u l' -- I realise that "all possible log items" is not the same as "all log items", but it isn't clear why it wouldn't be possible!
[O] Feature request: Numeric prefix argument for org-move-item-up/down
It would be nice if org-move-item-up (and org-move-item-down) took a numeric prefix argument to specify how many times to move the item up (or down). I was surprised that this is missing and I'm guessing there might be a good reason for that? Otherwise, I think this would be a useful addition. Thanks, N.
Re: [O] Capture broken with org-plus-contrib-20170917
Hi Josiah, At 09:48 -0700 on Thursday 2017-09-21, Josiah Schwab wrote: > Have you looked at the incompatible changes described in the > release notes? No, I hadn't. This is the downside of having the convenience of a package manager in Emacs rather than installing things manually -- one neglects to read the release notes! > I believe this change (and the migration) are described in > "org-capture-templates no longer accepts S-expressions as file > names". Indeed. You are quite right, that explains the problem exactly. > Hope that helps, Yes it did, thank you. Thanks for the quick answer. I have now bitten the bullet and "fixed" all my capture templates. One advantage of this is that they are now slightly easier to read! N.
[O] Capture broken with org-plus-contrib-20170917
After an Emacs package update a few days ago, my Org captures no
longer work. This is with org-plus-contib-20170917 from
http://orgmode.org/elpa/.
After I select a capture template to run, I get the error message
Invalid file location: nil
and setting debug-on-error I see this:
Debugger entered--Lisp error: (error "Invalid file location: nil")
signal(error ("Invalid file location: nil"))
error("Invalid file location: %S" nil)
org-capture-expand-file((concat org-directory "/notes.org"))
org-capture-target-buffer((concat org-directory "/notes.org"))
org-capture-set-target-location()
org-capture(nil)
funcall-interactively(org-capture nil)
call-interactively(org-capture nil nil)
command-execute(org-capture)
. Checking the value returned by the concat,
M-: (concat org-directory "/notes.org")
the correct value
"/data/org/notes.org"
is returned. This is the correct file and it exists etc..
There have been no changes to my org configuration since June of
2016 and I have had no problem with my captures until the latest
Emacs package update.
An example of the capture templates that are suddenly failing is
this one:
(setq org-capture-templates
'(
("n"
"Note"
;; This one is a bit ugly. I see the guts of the template while the
prompt is displayed. Also the PROPERTIES drawer is after the LOGBOOK instead of
before.
entry (file (concat org-directory "/notes.org"))
"* %^{Enter Note Title}%^g\n :PROPERTIES:\n :Created: %U\n
:END:\n\n%?\n%i\n"
:kill-buffer t :empty-lines 1 :clock-in t :clock-resume t)
)
)
I found a work-around, in that if I change the `entry' line of the
capture template to read
entry (file "notes.org")
the capture works again (taking advantage of what I assume must be
a new(ish) feature that org-directory is automatically used when
the file name in the capture template is unqualified).
Is this problem a new bug in Org, or is it simply that my capture
templates are wrong and that they've only worked all these years
by some accident?
If my capture templates are valid, then I would much rather see
Org put back the way it was so that they work, rather than have to
go through the error-prone process of having to edit them all (I
have dozens of them).
Thank you and best regards,
N.
[O] bug#23917: Re: bug#23917: 25.0.95; commit 3a9d6296b35e5317c497674d5725eb52699bd3b8 causing org-capture to error out
At 21:08 -0400 on Thursday 2016-07-21, npost...@users.sourceforge.net wrote: > I made the same adjustments to the saved sub_start and sub_end > variables, but I had a mistake in that adjustment which caused the false > positives. Fixed in the attached v2 patch. We could just drop the > check, though I've already found it useful to catch bugs > (https://github.com/joaotavora/yasnippet/issues/720). > > If I drop the checks (see attached v3 patch), then after following the > bug#23869 recipe, I get: > > ## -*- Octave -*- > -module(bug). > -export([identity/1, is_even/1, size/1, reverse/1]). Thanks Noam, Both the v2 and the v3 patch work for me with all my Org captures under my full config, and with the simple recipe under `emacs -Q". I'm not familiar with the details of the bug or the patches, but turning off checks doesn't sound right, so I've stayed with the v2 patch. I am now running the v2 patch as my every day Emacs. FWIW, my versions of Emacs and Org are: GNU Emacs 25.0.95.15 (x86_64-unknown-linux-gnu, GTK+ Version 3.18.9) of 2016-07-22 built on moondust Repository revision: 4157159a37b43712440da91a45a6d5f71eb96e8a and Org-mode version 8.3.5 (8.3.5-elpa @ /home/nlj/.emacs.d/elpa/org-20160719/) .
[O] bug#23917: 25.0.95; commit 3a9d6296b35e5317c497674d5725eb52699bd3b8 causing org-capture to error out
At 10:19 +0200 on Thursday 2016-07-21, Robert Pluim wrote: > > nljlistb...@gmail.com (N. Jackson) writes: > >> At 20:56 -0400 on Wednesday 2016-07-20, npost...@users.sourceforge.net wrote: >>> >>> From: Noam Postavsky >>> Subject: [PATCH v1] Adjust match data before calling after-change-funs >> >> It puzzles me that your patch doesn't work for the emacs -Q recipe but >> does work for my normal configuration, so much so that I suspected that >> I had made a mistake, but I have reset and reapplied the patch three >> times and I continue to see the same results. > > You're not alone: this patch doesn't fix the issue for me either with > emacs -Q or with my normal capture templates. FWIW, taking into account that I needed to rebuild Org Mode using the patched Emacs, I redid my tests of Noam's patch and got the same puzzling results as before. That is the patch *does* fix the problem for me with my normal caputure templates, but it does not fix the problem with the simple recipe in emacs -Q. N.
[O] bug#23917: 25.0.95; commit 3a9d6296b35e5317c497674d5725eb52699bd3b8 causing org-capture to error out
At 10:08 +0200 on Thursday 2016-07-21, Robert Pluim wrote: >> > nljlistb...@gmail.com (N. Jackson) writes: > >> At 21:09 +0300 on Monday 2016-07-18, Eli Zaretskii wrote: >> >>> diff --git a/lisp/subr.el b/lisp/subr.el >>> index e9e19d3..1bb1cb3 100644 >>> --- a/lisp/subr.el >>> +++ b/lisp/subr.el >>> @@ -3466,7 +3466,7 @@ save-match-data >>>;; if you need to recompile all the Lisp files using interpreted code. >>>(declare (indent 0) (debug t)) >>>(list 'let >>> - '((save-match-data-internal (match-data))) >>> + '((save-match-data-internal (match-data 'integers))) >>> (list 'unwind-protect >>> (cons 'progn body) >>> ;; It is safe to free (evaporate) markers immediately here, >> >> FWIW on my system applying this patch does not resolve the org-capture >> issue. I'm testing with org-20160718 from GNU Elpa and latest Emacs 25 >> branch from the git (Repository revision: >> 4157159a37b43712440da91a45a6d5f71eb96e8a). > > save-match-data is a macro. Did you recompile org with the modified > emacs? Thanks Robert. I failed to take that into account. After re-applying Eli's patch above and then rebuilding Org Mode from GNU Elpa (now org-20160719), the org-capture match-data-clobbered error/abort no longer occurs, neither with the simple recipe in emacs -Q nor with my own capture templates with my full config loaded. Sorry for the noise. [For completeness, I should say that I then removed the patch and rebuilt org-20160719 again, and confirmed that it does trigger the bug in both emacs -Q and with my configuration.] N.
[O] bug#23917: 25.0.95; commit 3a9d6296b35e5317c497674d5725eb52699bd3b8 causing org-capture to error out
At 20:56 -0400 on Wednesday 2016-07-20, npost...@users.sourceforge.net wrote:
>
> From a8098080dff5f83f7cbcbec2bc263f9db3b45ad9 Mon Sep 17 00:00:00 2001
> From: Noam Postavsky
> Date: Wed, 20 Jul 2016 20:15:14 -0400
> Subject: [PATCH v1] Adjust match data before calling after-change-funs
>
> * src/insdel.c (replace_range): Add new parameter ADJUST_MATCH_DATA, if
> true. Update all callers except Freplace_match to pass 0 for the new
> parameter.
> * src/search.c (update_search_regs): New function, extracted from
> Freplace_match.
> (Freplace_match): Remove match data adjustment code, pass 1 for
> ADJUST_MATCH_DATA to replace_range instead.
> ---
> src/cmds.c| 2 +-
> src/editfns.c | 6 +++---
> src/insdel.c | 10 --
> src/lisp.h| 4 +++-
> src/search.c | 50 +-
> 5 files changed, 44 insertions(+), 28 deletions(-)
>
> diff --git a/src/cmds.c b/src/cmds.c
> index 1e44ddd..4003d8b 100644
> --- a/src/cmds.c
> +++ b/src/cmds.c
> @@ -447,7 +447,7 @@ internal_self_insert (int c, EMACS_INT n)
> string = concat2 (string, tem);
> }
>
> - replace_range (PT, PT + chars_to_delete, string, 1, 1, 1);
> + replace_range (PT, PT + chars_to_delete, string, 1, 1, 1, 0);
>Fforward_char (make_number (n));
> }
>else if (n > 1)
> diff --git a/src/editfns.c b/src/editfns.c
> index 412745d..32c8bec 100644
> --- a/src/editfns.c
> +++ b/src/editfns.c
> @@ -3192,7 +3192,7 @@ DEFUN ("subst-char-in-region", Fsubst_char_in_region,
> /* replace_range is less efficient, because it moves the gap,
>but it handles combining correctly. */
> replace_range (pos, pos + 1, string,
> - 0, 0, 1);
> + 0, 0, 1, 0);
> pos_byte_next = CHAR_TO_BYTE (pos);
> if (pos_byte_next > pos_byte)
> /* Before combining happened. We should not increment
> @@ -3405,7 +3405,7 @@ DEFUN ("translate-region-internal",
> Ftranslate_region_internal,
> /* This is less efficient, because it moves the gap,
>but it should handle multibyte characters correctly. */
> string = make_multibyte_string ((char *) str, 1, str_len);
> - replace_range (pos, pos + 1, string, 1, 0, 1);
> + replace_range (pos, pos + 1, string, 1, 0, 1, 0);
> len = str_len;
> }
> else
> @@ -3446,7 +3446,7 @@ DEFUN ("translate-region-internal",
> Ftranslate_region_internal,
> {
> string = Fmake_string (make_number (1), val);
> }
> - replace_range (pos, pos + len, string, 1, 0, 1);
> + replace_range (pos, pos + len, string, 1, 0, 1, 0);
> pos_byte += SBYTES (string);
> pos += SCHARS (string);
> cnt += SCHARS (string);
> diff --git a/src/insdel.c b/src/insdel.c
> index 4ad1074..fc3f19f 100644
> --- a/src/insdel.c
> +++ b/src/insdel.c
> @@ -1268,7 +1268,9 @@ adjust_after_insert (ptrdiff_t from, ptrdiff_t
> from_byte,
> /* Replace the text from character positions FROM to TO with NEW,
> If PREPARE, call prepare_to_modify_buffer.
> If INHERIT, the newly inserted text should inherit text properties
> - from the surrounding non-deleted text. */
> + from the surrounding non-deleted text.
> + If ADJUST_MATCH_DATA, then adjust the match data before calling
> + signal_after_change. */
>
> /* Note that this does not yet handle markers quite right.
> Also it needs to record a single undo-entry that does a replacement
> @@ -1279,7 +1281,8 @@ adjust_after_insert (ptrdiff_t from, ptrdiff_t
> from_byte,
>
> void
> replace_range (ptrdiff_t from, ptrdiff_t to, Lisp_Object new,
> -bool prepare, bool inherit, bool markers)
> + bool prepare, bool inherit, bool markers,
> + bool adjust_match_data)
> {
>ptrdiff_t inschars = SCHARS (new);
>ptrdiff_t insbytes = SBYTES (new);
> @@ -1426,6 +1429,9 @@ replace_range (ptrdiff_t from, ptrdiff_t to,
> Lisp_Object new,
>MODIFF++;
>CHARS_MODIFF = MODIFF;
>
> + if (adjust_match_data)
> +update_search_regs (from, to, from + SCHARS (new));
> +
>signal_after_change (from, nchars_del, GPT - from);
>update_compositions (from, GPT, CHECK_BORDER);
> }
> diff --git a/src/lisp.h b/src/lisp.h
> index 6a98adb..25f811e 100644
> --- a/src/lisp.h
> +++ b/src/lisp.h
> @@ -3516,7 +3516,7 @@ extern void adjust_after_insert (ptrdiff_t, ptrdiff_t,
> ptrdiff_t,
>ptrdiff_t, ptrdiff_t);
> extern void adjust_markers_for_delete (ptrdiff_t, ptrdiff_t,
> ptrdiff_t, ptrdiff_t);
> -extern void replace_range (ptrdiff_t, ptrdiff_t, Lisp_Object, bool, bool,
> bool);
> +extern void replace_range (ptrdiff_t, ptrdiff_t, Lisp_Object, bool, bool,
> bool, bool);
> extern void replace_range_2 (pt
[O] bug#23917: 25.0.95; commit 3a9d6296b35e5317c497674d5725eb52699bd3b8 causing org-capture to error out
At 21:09 +0300 on Monday 2016-07-18, Eli Zaretskii wrote: > My suggestion to fix this is below. I ask for opinions on (1) whether > this looks like TRT, (2) whether it is safe enough for emacs-25, and > (3) whether someone has better ideas. If someone thinks I've > misunderstood the issue, don't hesitate to explain why, because > frankly it feels very strange to find bugs that seem to have existed > since 1990. > > diff --git a/lisp/subr.el b/lisp/subr.el > index e9e19d3..1bb1cb3 100644 > --- a/lisp/subr.el > +++ b/lisp/subr.el > @@ -3466,7 +3466,7 @@ save-match-data >;; if you need to recompile all the Lisp files using interpreted code. >(declare (indent 0) (debug t)) >(list 'let > - '((save-match-data-internal (match-data))) > + '((save-match-data-internal (match-data 'integers))) > (list 'unwind-protect > (cons 'progn body) > ;; It is safe to free (evaporate) markers immediately here, FWIW on my system applying this patch does not resolve the org-capture issue. I'm testing with org-20160718 from GNU Elpa and latest Emacs 25 branch from the git (Repository revision: 4157159a37b43712440da91a45a6d5f71eb96e8a). With these versions of Org and Emacs and your patch applied, with a recipe similar to that posted by Robert Pluim on 2016-07-18, specifically src/emacs -Q M-: (custom-set-variables '(package-selected-packages (quote (org-20160718 RET M-x package-initialize RET C-x C-f ; find file. C-S-backspace ; kill-whole-line. ~/.notes RET ; Open the file expected by default capture template. M-x org-mode RET ; put the buffer into Org Mode. M-x org-capture RET t ; Run the default "Task" capture template bound to the t key. I get the error: org-capture: Capture template ‘t’: Match data clobbered by buffer modification hooks . I also get a similar error with your patch and my full configuration loaded and using my own capture templates: org-capture: Capture abort: (error Match data clobbered by buffer modification hooks) . The results above are same as I get if I do not apply your patch. [On the other hand, with the same version of Org as above and Emacs from the 25.0.95 tarball, I do not see these error.]
[O] Bug: org-add-note closes log book drawer
When org-log-into-drawer is t and the log book drawer is open, using org-add-note closes the log book drawer. I think it would be better if org-add-note left the state (open or closed) of the log book drawer alone. In comparison org-clock-in and org-clock-out do leave the state of the log book drawer alone, which is much more satisfactory. This is with org-20160718 from GNU Elpa (which is Org Mode version 8.3.4) on GNU Emacs 25.0.95 (from the pre-release tarball).
Re: [O] Will there be an updated Org Mode in Emacs 25?
At 19:49 +0200 on Monday 2016-07-18, Nicolas Goaziou wrote: > > My secret plan is to have Org 9.0 merged in Emacs master branch just > after Emacs 25.1 is released. The effectiveness of this strategy might depend upon whether Emacs 25.2 is cut from what is now the Emacs master branch or from the emacs-25 branch. My understanding is that this has not yet been decided.
[O] Will there be an updated Org Mode in Emacs 25?
Hello Org Mode developers, I'm wondering if there will be an updated version of Org Mode bundled with Emacs 25? In the tarball for the most recent pre-release version (25.0.95) the bundled Org Mode is 8.2.10. This is the same version that was bundled with Emacs 24.5 15 months ago or so, and presumably it is even older than that! As the release or the next Emacs looks like it will be fairly soon (on the order of a few weeks?), this would seem to be something needing addressing fairly soon. :) (I asked this question on the Emacs developers' list and they suggested [1] that I ask the Org Mode developers.) Thanks. Regards, N. [1] http://lists.gnu.org/archive/html/emacs-devel/2016-07/msg00792.html
Re: [O] Struggling with setting up ox-koma-letter.el
At 16:09 -0300 on Sunday 2016-06-26, N. Jackson wrote: > I am trying to get ox-koma-letter.el working in my Emacs (25.0.95). > > I have been following the instructions at > http://orgmode.org/worg/exporters/koma-letter-export.html and I am > testing with the "A simple letter example" > (http://orgmode.org/cgit.cgi/worg.git/plain/exporters/koma-letter-new-example.org). > > My org and my ox-koma-letter.el are from the Org Elpa org-plus-contrib > package (version 20160620) and are located in > ~/.emacs.d/elpa/org-plus-contrib-20160620/. After the version 20160627 update came down, I no longer get any error messages on export, which is great. However, the PDF generated by the exporter isn't quite right. Some of the problems with it are likely due to my LaTeX setup (page size etc.) and I'm investigating those, and some might be flaws in koma-letter-new-example.org, but I think I still don't have ox-koma-letter.el properly configured yet. For example, it seems to not be recognising the "location" headline and hence it is treating it as the first undefined headline in the file and is using it as the salutation. My .PDF output file is attached for comparison with the correct one at http://orgmode.org/cgit.cgi/worg.git/plain/exporters/koma-letter-new-example.pdf. Any suggestions? Thanks, N. koma-letter-test.pdf Description: Example letter PDF output file
[O] Struggling with setting up ox-koma-letter.el
I am trying to get ox-koma-letter.el working in my Emacs (25.0.95).
I have been following the instructions at
http://orgmode.org/worg/exporters/koma-letter-export.html and I am
testing with the "A simple letter example"
(http://orgmode.org/cgit.cgi/worg.git/plain/exporters/koma-letter-new-example.org).
My org and my ox-koma-letter.el are from the Org Elpa org-plus-contrib
package (version 20160620) and are located in
~/.emacs.d/elpa/org-plus-contrib-20160620/.
I get an error message when I try to export the example letter using
`C-c C-e k p'. The message is
org-export-as: Wrong number of arguments: #[(templates)
"ebÆ^XÇÈÆÉ#
\\^@Ê ^YË !Ì=X^@Í \"^[ÎÏ \"^\ ÎÐ
\"E^]<^@ÑÒÎÓ \"\"W^@ W^@^MB^P ÎÔ
\"bÕÆx`| c)+)^F^@*" [record object
templates value begin signature nil re-search-forward "{{{[-A-Za-z0-9_]"
t ...] 6 ("/data/projects/vc/emacs/emacs-25.0.95/lisp/org/org-macro.elc"
. 3784)], 3
I can't read this error message due to all the escaped characters, but I
do see a mention of an incorrect file. The org-macro.elc file mentioned
in the error message is the one built in to Emacs and it should be
hidden.
I have normal-looking load path shadows, with the the elpa version
hiding the version built in to Emacs (e.g. list-load-path-shadows shows
for example that ~/.emacs.d/elpa/org-plus-contrib-20160620/org-macro
hides /data/projects/vc/emacs/emacs-25.0.95/lisp/org/org-macro).
I would welcome any help with getting this working.
Thanks,
N.
Re: [O] Bug: File mode specification error opening Org file without headline on first line [8.3.4 (8.3.4-39-ge0acd8-elpa @ /home/nlj/.emacs.d/elpa/org-20160418/)]
Thanks Kyle. At 21:41 -0400 on Wednesday 2016-04-20, Kyle Meyer wrote: > > Based on your configuration dump, it seems like you're using outshine, You are right. I had installed navi-mode (and its dependencies outshine and outorg) a few months ago to try it out. I have removed them and the problem is fixed. [FWIW, I had version 2.0 of all three files.] Thank you, and sorry for the noise. [I never found the time to actually try navi-mode; perhaps I'll have some spare time in the future when I can re-install it and give it a test drive.] N.
[O] Bug: File mode specification error opening Org file without headline on first line [8.3.4 (8.3.4-39-ge0acd8-elpa @ /home/nlj/.emacs.d/elpa/org-20160418/)]
For several months now I have been getting the error "File mode
specification error: (error Before first heading)" when I open some of
my Org files. [After the error message, the file opens just fine and Org
works normally.]
What distinguishes the Org files that do not suffer from this problem
from those that do is that they have a headline in the first line of
the file.
A fairly minimal recipe:
1. $ cat > ~/temp-org-test.org
An introduction.
* A Headline
Some text.
** Sub-Topic 1
** Sub-Topic 2
*** Additional entry
^D
2. $ emacs &
3. Visit ~/temp-org-test.org
At this point the error message "File mode specification error: (error
Before first heading)" is displayed.
Note: This test file is from
http://orgmode.org/worg/dev/org-syntax.html.
Setting debug-on-error, I get the following backtrace:
Debugger entered--Lisp error: (error "Before first heading")
signal(error ("Before first heading"))
error("Before first heading")
outline-back-to-heading()
outline-flag-subtree(t)
hide-subtree()
(save-excursion (goto-char (point-min)) (hide-subtree) (show-children
keep-levels) (condition-case err (while (outline-get-next-sibling)
(hide-subtree) (show-children keep-levels)) (error nil)))
outline-hide-sublevels(1)
org-overview()
org-content()
org-set-startup-visibility()
org-mode()
set-auto-mode-0(org-mode nil)
set-auto-mode()
normal-mode(t)
after-find-file(nil t)
find-file-noselect-1(# "~/temp-org-test.org"
nil nil "~/temp-org-test.org" (801256 64773))
find-file-noselect("/home/nlj/temp-org-test.org" nil nil nil)
find-file("/home/nlj/temp-org-test.org")
On the other hand, if I edit the test file and add a headline on the
first line of the file, for example
* COMMENT This is dummy headline
then the error does not occur. Of course, this seems a rather ugly
work-around.
Emacs : GNU Emacs 25.0.92.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.18.9)
of 2016-04-18
Package: Org-mode version 8.3.4 (8.3.4-39-ge0acd8-elpa @
/home/nlj/.emacs.d/elpa/org-20160418/)
current state:
==
(setq
org-export-backends '(ascii beamer html icalendar latex odt)
org-tab-first-hook '(org-hide-block-toggle-maybe
org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
outline-minor-mode-hook '(outshine-hook-function)
org-speed-command-hook '(org-speed-command-default-hook
org-babel-speed-command-hook)
org-reverse-note-order t
org-occur-hook '(org-first-headline-recenter)
org-checkbox-hierarchical-statistics nil
org-metaup-hook '(org-babel-load-in-session-maybe)
org-agenda-start-on-weekday nil
org-log-done t
org-format-latex-options '(:foreground default :background default :scale 1.5
:html-foreground "Black" :html-background
"Transparent"
:html-scale 1.0 :matchers ("begin" "$1" "$" "$$"
"\\(" "\\["))
org-confirm-shell-link-function 'yes-or-no-p
org-finalize-agenda-hook '(nlj-agenda-to-appt)
org-startup-folded 'content
org-file-apps '((auto-mode . emacs) ("\\.mm\\'" . default) ("\\.x?html?\\'" .
default)
("\\.pdf\\'" . "evince %s"))
org-agenda-skip-scheduled-if-done t
org-support-shift-select 'always
org-default-notes-file "/data/org//notes.org"
org-capture-templates '(("t" "Todo" entry
(file+headline (concat org-directory
"/organiser.org") "Todos")
"* TODO %?\n:LOGBOOK:\n CREATED: %U\n:END:\n%i\n"
:prepend t
:kill-buffer t :empty-lines 1)
("e" "Event" entry
(file+headline (concat org-directory
"/organiser.org") "Events")
"* %?\n:LOGBOOK:\n CREATED: %U\n:END:\n%i\n"
:kill-buffer t
:empty-lines 1)
("a" "Appointment" entry
(file+headline (concat org-directory "/organiser.org")
"Appointments")
"* APPT %?\n:LOGBOOK:\n CREATED: %U\n:END:\n%i\n"
:kill-buffer t
:empty-lines 1)
("l" "Log" plain (file (concat org-directory
"/log.org"))
"* %U\n\n%?\n%i\n" :kill-buffer t :empty-lines 1
:clock-in t
:clock-resume t)
("n" "Note" entry
(file+headline (concat org-directory "/notes.org")
"Notes")
"* %^{Enter Note Title}%^g\n :PROPERTIES:\n
:Created: %U\n :END:\n\n%?\n%i\n" :kill-buffer t :empty-lines 1 :clock-in t
:clock-resume t)
("o" "Old-style Dated Note" entry
(file+headline (concat org-directory "/notes.org")
"Dated Notes")
"* %U\n%?\n%i\n" :kill-buffer t :empty-lines 1
:clock-in t
[O] bug#5753: something, something, org-mode, shift-select, something
Bastien writes: > nljlistb...@gmail.com (N. Jackson) writes: > >> Ah, that sounds like the start of a new adventure... >> >> ... which went _far_ more smoothly than I expected! I am now testing >> with GNU Emacs 24.3.50.1 Repository revision: 116400 and Org-mode >> version 8.2.5c. > > Yes, sorry, I meant "emacs -Q" in my recipes. > > I can't reproduce the bug with GNU Emacs 24.3.50.6, so it has probably > been fixed between 24.3.50.1 and 24.3.50.6. Bastien, you misunderstood what I wrote (sorry). I _did_ build 24.3.50(.1) from the current (yesterday's) trunk from Bazaar. And, assuming the failure of shift selection in cua-mode _is_ the bug the OP was reporting (I was never clear about that), then the bug _is_ fixed using that build, as I wrote here: >> In any case, with both recipes, Org behaves correctly in 24.3.50.1. and here: >> emacs -Q >> M-: (org-support-shift-select t) RET >> M-x cua-mode RET; Turn _on_ cua mode >> C-x C-f new-test.org RET >> a >> S-; Expected: "a" is selected / highlighted >> C-x ; Expected: "a" is removed to the clipboard >> In Emacs 24.3.1 (as, I believe, in Emacs 23), the S- just moves >> the cursor, no selection is highlighted, and the C-x fails to remove >> the "a" to the clipboard. This defect is fixed in Emacs 24.3.50.1. :) > I'll close it when you have a chance to build Emacs from current > trunk. Lennart, I believe you were the original poster? Is the one above the bug you intended to report? (I was confused by the discussion of org-replace-disputed-keys, which doesn't seem to be a factor here.) And if so, do you want to test on 24.3.50, or are you satisfied that the bug is fixed? > Thanks again for the detailed reports! You're welcome, but clearly I need to improve my clarity! Thank you for being there to do something about them. Regards, N.
[O] bug#5753: something, something, org-mode, shift-select, something
Bastien writes: > can you tell me what exactly the bug is wrt cua-mode and org-mode? Hi Bastien, Well, I can tell you the symptoms; I'm sorry to report that I know nothing of the internals. I have this snippet of code in my configuration files and with it everything works fine and has been working fine for a few years: ;; This snippet from jisang-yoo on reddit to enable shift select in ;; org mode when cua-mode is on. (eval-after-load "org" '(progn (eval-after-load "cua-base" '(progn (defadvice org-call-for-shift-select (before org-call-for-shift-select-cua activate) (if (and cua-mode org-support-shift-select (not (use-region-p))) (cua-set-mark))) ;; End jisang-yoo snippet If I comment out that snippet and restart Emacs, then shift selection no longer works in org-mode unless I turn off cua-mode. When I say shift selection doesn't work, I mean that when I hold down the shift key and move the cursor with the arrow keys I don't get any highlighting of the text I'm trying to select. And it's not just a failure to highlight the selection, there seems to be no selection happening because a cut or copy of the imaginary selection doesn't do anything. If I toggle off cua-mode (from the menu for example), then shift selection immediately starts working in org-mode. If I leave cua-mode tuned on and M-x fundamental-mode, then shift selection immediately starts working in the buffer with org file. That is to say, the symptoms are simple and 100% reproducible. > If the bug is here for Emacs 24.3, can you try downloading and > installing the latest Org stable version (http://orgmode.org) and see > if the bug is still there? I am currently using Org-mode version 8.2.5h-6-g8e1386-elpa of 2014-02-03 on GNU Emacs 24.3.1. If you need me to try a newer version of Org, I can do so, although I do prefer to use the version from Elpa as it seems it would be easier to uninstall it if it breaks my Emacs. > Thanks in advance for your help, You're welcome. Please let me know if you need me to install the latest Org stable version or do any specific testing. N.
[O] bug#5753: something, something, org-mode, shift-select, something
Bastien writes: > Can you try the two recipes I gave here: > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5753#26 Wherein Bastien gnu.org> writes: >> With Emacs from trunk: Ah, that sounds like the start of a new adventure... ... which went _far_ more smoothly than I expected! I am now testing with GNU Emacs 24.3.50.1 Repository revision: 116400 and Org-mode version 8.2.5c. >> ~$ emacs RET >> C-x C-f test.org RET >> M-x cua-mode RET >> M-: (setq org-support-shift-select t) RET >> M-: (insert "blahblah") RET C-a >> S- >> >> will select correctly here. >> >> ~$ emacs RET >> M-: (setq org-support-shift-select t) RET >> M-: (setq org-replace-disputed-keys t) RET >> M-: (insert "* A headline") RET >> C-a >> S- >> >> will also select correctly instead of switching the TODO keyword. > and tell me where it does not produce the expected output? The first recipe is ambiguous because M-x cua-mode RET toggles the on/off or off/on state of cua-mode, so it depends on how it is set in one's configuration files. In any case, with both recipes, Org behaves correctly in 24.3.50.1. The first recipe fails in 24.3.1 when cua-mode is not enabled in one's configuration files (i.e. when you turn it on at the beginning of the recipe). Here's a simpler recipe: emacs -Q M-: (org-support-shift-select t) RET M-x cua-mode RET; Turn _on_ cua mode C-x C-f new-test.org RET a S-; Expected: "a" is selected / highlighted C-x ; Expected: "a" is removed to the clipboard In Emacs 24.3.1 (as, I believe, in Emacs 23), the S- just moves the cursor, no selection is highlighted, and the C-x fails to remove the "a" to the clipboard. This defect is fixed in Emacs 24.3.50.1. :) As far as shift selection over headlines, todos, and datestamps is concerned, in general, shift selection behaviour in Emacs 24.3.50.1 (unlike in Emacs 24.3.1) now seems to behave as it is described in the doc string: C-h v org-support-shift-select RET as follows: org-support-shift-select is a variable defined in `org.el'. Its value is always Original value was nil Documentation: Non-nil means make shift-cursor commands select text when possible. In Emacs 23, when `shift-select-mode' is on, shifted cursor keys start selecting a region, or enlarge regions started in this way. In Org-mode, in special contexts, these same keys are used for other purposes, important enough to compete with shift selection. Org tries to balance these needs by supporting `shift-select-mode' outside these special contexts, under control of this variable. The default of this variable is nil, to avoid confusing behavior. Shifted cursor keys will then execute Org commands in the following contexts: - on a headline, changing TODO state (left/right) and priority - (up/down) on a time stamp, changing the time in a plain list item, - changing the bullet type in a property definition line, switching - between allowed values in the BEGIN line of a clock table - (changing the time block). Outside these contexts, the commands will throw an error. When this variable is t and the cursor is not in a special context, Org-mode will support shift-selection for making and enlarging regions. To make this more effective, the bullet cycling will no longer happen anywhere in an item line, but only if the cursor is exactly on the bullet. If you set this variable to the symbol `always', then the keys will not be special in headlines, property lines, and item lines, to make shift selection work there as well. If this is what you want, you can use the following alternative commands: `C-c C-t' and `C-c ,' to change TODO state and priority, `C-u C-u C-c C-t' can be used to switch TODO sets, `C-c -' to cycle item bullet types, and properties can be edited by hand or in column view. However, when the cursor is on a timestamp, shift-cursor commands will still edit the time stamp - this is just too good to give up. XEmacs user should have this variable set to nil, because `shift-select-mode' is in Emacs 23 or later only. You can customize this variable. This is very very helpful stuff, clearly presented, and I feel it ought to be in the info manual as well. [The only part that I don't see working properly is the changing of bullet types. As far as I can tell, this doesn't happen -- but it's not something I've ever tried to do and maybe I'm not using it right.] I just did a cursory look at the effect of org-replace-disputed-keys, because I don't use this. Was an issue with this reported in the original bug? If so, I can test it more thoroughly. I hope the above report is of some use. Regards, N.
[O] bug#5753: something, something, org-mode, shift-select, something
This post is for the sake of completeness, and to summarise / add to my previous posts on this bug, namely: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5753#17 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5753#35 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5753#41 In GNU Emacs 23.3.1 [1] and 24.3 [2], either of the settings (setq org-support-shift-select t) or (setq org-support-shift-select (quote always)) will enable shift selection in org-mode, as described in C-h v org-support-shift-select RET _only if_ cua-mode is turned off. But if cua-made is turned on, shift selection fails everywhere in org mode -- no selection gets made. Adding the following workaround fixes the problem: ;; This snippet from jisang-yoo on reddit to enable shift select in org ;; mode when cua-mode is on. (eval-after-load "org" '(progn (eval-after-load "cua-base" '(progn (defadvice org-call-for-shift-select (before org-call-for-shift-select-cua activate) (if (and cua-mode org-support-shift-select (not (use-region-p))) (cua-set-mark))) ;; End jisang-yoo snippet In GNU Emacs GNU Emacs 24.3.50.1 [3] org-support-shift-select works essentially as documented, and the workaround is not required. :) --- [1] GNU Emacs 23.3.1 (i386-mingw-nt5.1.2600) of 2011-03-10 on Windows XP (5.1.2600) with Org-mode version 7.9.2 (7.9.2-48-gb7c5cf-elpa) of 2012-10-15. [2] GNU Emacs 24.3.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.8.2) of 2013-08-14 on Fedora 19 with Org-mode version 8.2.5h (8.2.5h-6-g8e1386-elpa) of 2014-02-03. [3] GNU Emacs 24.3.50.1 (Repository revision: 116400) of 2014-02-10 on Fedora 19 and Org-mode version 8.2.5c (release_8.2.5c) of unknown date.
[O] bug#5753: something, something, org-mode, shift-select, something
The following message is a courtesy copy of an article that has been posted to gnu.emacs.bug as well. Lars Ingebrigtsen writes: > Lennart Borgman writes: > >> Shift-select in cua-mode does not work in org-mode although >> org-replace-disputed-keys is t, org-disputed-keys are set for shift >> arrow keys and org-support-shift-select is always > > Is this problem still present in Emacs 24.3? Naturally I can't answer for the OP (and I don't know about disputed keys) but I can report that in general this problem persists in Emacs 24.3. On GNU Emacs 24.3.1 [1], shift select does not work in org mode. I'm not certain this is a bug, as my understanding is that the org authors did not design it to work with shift select? In any case, I use a very simple workaround which makes shift select work just fine in org mode; I've never had any problems with it. It looks like this (Note: It is of unknown provenance, aside from the attribution in the comment.): ;; This snippit from jisang-yoo on reddit to enable shift select in org ;; mode when cua-mode is on. (eval-after-load "org" '(progn (eval-after-load "cua-base" '(progn (defadvice org-call-for-shift-select (before org-call-for-shift-select-cua activate) (if (and cua-mode org-support-shift-select (not (use-region-p))) (cua-set-mark))) ;; End jisang-yoo snippit With this in my org settings, I have no problems with shift select except that you cannot start a selection on a timestamp (because shift with cursor keys adjusts timestamps), but I've learnt to automatically start my selection from the end of the line above the timestamp so I don't have any problems. I hope this information is of some use. [1] GNU Emacs 24.3.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.8.2) of 2013-08-14 on buildvm-15.phx2.fedoraproject.org
Re: [O] Bug: org-capture Does not take user to any new buffer
Update: This is now resolved (for me). The capture failures I was seeing (when the type was "entry" rather than "plain") was either a problem with my installation of Version 7.8.11 org-20120611 or a bug in that version. Reverting to the built-in version of Org Mode (Version 6.33x) (by turning off the Emacs package manager) fixed the problem, and so did updating to Version 7.8.11 org-20120618 (from ELPA using the package manager).
Re: [O] Bug: org-indent-mode cursor movement [7.8.03]
Update: This is now resolved (for me). The jumping cursor behaviour I was seeing was either a problem with my installation of Version 7.8.11 org-20120611 or a bug in that version. Reverting to the built-in version (Version 6.33x) (by turning off the Emacs package manager) fixed the problem, and so did updating to Version 7.8.11 org-20120618 (from ELPA using the package manager).
Re: [O] Bug: org-capture Does not take user to any new buffer
> On Tue, Jun 5, 2012 at 9:07 AM, Mike Fitzgerald gmail.com>
wrote:
>
> I'm presented with an "*Org Select*" buffer that offers me the available
choices"
> However, this part does not work as expected:"when I select one of those I
select one of those, I get a "CAPTURE-foo.org" buffer"I would expect: A) new
buffer would be created and B) EMACS would switch to it andC) Some message with
value to the userB and C do not happen. A happens but I need to manually
switch
to itI get a message that has little value: "Capture template `j': org-
called-interactively-p"I have never used the working version of capture (this
is
it), but I have usedremember a little and seem to recall it gives a message
something
>
I am seeing similar behaviour from Org Capture. That is:
- It doesn't open the buffer for the user to add text to the capture.
- A message "byte-code: Capture template `t': org-called-interactively-p" is
displayed.
- The capture _does_ get written to the target file.
- However the capture written to the target file contains "%?" literally
inserted into the entry.
>
> (setq org-log-done t)(setq org-capture-templates
> '(("t" "Todo" entry (file+headline "~/org/gtd.org" "Tasks")
>
> "* TODO %?\n %i\n %a")
> ("j" "Journal" entry (file+datetree "~/org/journal.org")
> "* %?\nEntered on %U\n %i\n %a")))
I'm using templates similar to these.
The main thing I can add, is that if I change "entry" to "plain", Capture works
just fine. (Of course, in many cases one wants entries, so this is not a
solution.)
I'm using GNU Emacs 23.3.1 ((i386-mingw-nt5.1.2600) of 2011-03-10) and Org
Version 20120611 (7.8.11) which I downloaded/installed with the Emacs package
manager system.
I apologise if there is already a solution to this issue (I didn't see it), and
I hope this additional information is helpful.
Regards,
N.
>
> ;org-capture binding
> ;(global-set-key "\C-c-c" 'org-capture)(global-set-key [(control c) (c)] 'org-
capture)Does this look OK?
> ThanksMike
> On Mon, Jun 4, 2012 at 10:56 PM, Nick Dokos hp.com>
wrote:Mike Fitzgerald gmail.com> wrote:
> > To duplicate:
> >
> I haven't tried specifically to duplicate your setup but org-capture
> seems to work fine here.
>
> > 1) Run org-capture with C-c c
> > 2) User is Promoted with the two templates expected
> > (copied the templates from the org-mode site)
> >
> > 3) Enter j for journal
> > 4) Expect switch to new buffer
> > 5) No switch occurs
> So what happens instead? If I start capture, I get another window where
> I'm presented with an "*Org Select*" buffer that offers me the available
> choices and when I select one of those, I get a "CAPTURE-foo.org" buffer
> for some value of "foo". This is actually an indirect buffer and the
> text should be inserted into the target location already, so you can
> look at ~/org/journal.org (or whatever) and see that it contains the
> partial entry just started. See the description of org-capture: C-h f
> org-capture RET.
> If I were you, I'd probably use edebug to step through the org-capture
> function (and I'd forget about byte compiling anything until whatever
> problem you have is identified and solved).
> HTH,
> Nick
>
> > Note that journal.org is open, but I need to switch to it
> >
> > I expected EMACS to switch to a new buffer after choosing
> > the template.
> >
> > Running GNU EMACS 23.3 on Win7
> >
> > Org mode update byte compiled by hand (without make) using
> >
> > (defun my/compile-org(&optional directory)
> > "Compile all *.el files that come with org-mode."
> > (interactive)
> > ;Found on a org-mode related page.
> >
> > Thanks
> >
> > Mike
> >
> > Remember to cover the basics, that is, what you expected to happen and
> > what in fact did happen. You don't know how to make a good report? See
> >
> > http://orgmode.org/manual/Feedback.html#Feedback
> >
> > Your bug report will be posted to the Org-mode mailing list.
> >
> >
> > Emacs : GNU Emacs 23.3.1 (i386-mingw-nt6.1.7600)
> > of 2011-03-10 on 3249CTO
> > Package: Org-mode version 7.8.11
> >
> > current state:
> > ==
> > (setq
> > org-log-done 'time
> > org-export-latex-after-initial-vars-hook '(org-beamer-after-initial-vars)
> > org-speed-command-hook '(org-speed-command-default-hook org-babel-speed-
command-hook)
> > org-metaup-hook '(org-babel-load-in-session-maybe)
> > org-capture-templates '(("t" "Todo" entry (file+headline "~/org/gtd.org"
"Tasks")
> > "* TODO %?\n %i\n %a")
> > ("j" "Journal" entry (file+datetree "~/org/journal.org")
> > "* %?\nEntered on %U\n %i\n %a")
> > )
> > org-after-todo-state-change-hook '(org-clock-out-if-current)
> > org-export-latex-format-toc-function 'org-export-latex-format-toc-default
> > org-tab-first-hook '(org-hide-block-toggle-maybe org-src-native-tab-
command-
Re: [O] Bug: org-indent-mode cursor movement [7.8.03]
Andrew Stine gmail.com> writes: > > When org-indent-mode is active, the cursor repeatedly jumps to the > bottom of the buffer. This makes using the buffer impossible while > org-indent-mode is active. > I am experiencing the same behaviour (cursor jumping to the end of the buffer whenever I try to move it). This happens when I have #+STARTUP: indent in an org-mode file. Editing the file in Fundamental Mode and removing the "#+STARTUP: indent" line from the file (and switching back to Org Mode), fixes the problem. I am using Org-mode version 7.8.11 with GNU Emacs 23.3.1 (i386-mingw-nt5.1.2600).
