Re: Unable to get current or via use-package
"Cook, Malcolm" writes: >>(use-package org >>:ensure org-contrib) > > I believe `:ensure org-contrib` is no longer needed. Well, I would need it if I actually wanted anything from org-contrib, but I really have to check whether this is still the case. > I tend to use the org-mode from the package manager, but do not do it > interactively from within emacs. Instead, which when I want to refresh org, > I do from the command line: > > emacs -Q -batch -eval "(progn (require 'package) (package-initialize) > (package-refresh-contents) (package-install 'org))" Is that necessary? Can't I just use the package manager to update Org along with any other packages? Or does the issue about not visiting and .org file before installing via the package manager apply to updates too? > Also, early in my init.el, as extra level of precaution against getting the > built-in org-mode, I ensure it never gets loaded: > (require 'cl-seq) (delete (car (cl-member "lisp/org" load-path :test > #'string-match)) load-path) Interesting, although I would generally want at least some version of Org even if a more recent version is installed but somehow broken. >> >>I moved the old-plus-contrig ELPA folder out the way. However, I now >>just get the built-in version of Org: >> >>Org mode version 9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/) >> >>Is this a problem use-package has with built-in packages, as described here >> >>https://github.com/jwiegley/use-package/issues/319 >> >>? Or am I doing something wrong? Or do I just need to install via M-x >>list-packages (bearing in mind the caveat about not visiting an org file >>beforehand)? >> >>Cheers, >> >>Loris >> >>-- >>This signature is currently under construction. >>
Re: [PATCH] org-agenda: Skip formatting if format string is ""
Thanks Ihor for the detailed explanation,
I updated the patch as you suggested.
On Sun, Feb 6, 2022 at 12:53 PM Ihor Radchenko wrote:
> Samim Pezeshki writes:
>
> > This commit prevents having extra spaces when the TODO format string is
> an
> > empty string (""). It was not working properly, with this patch now it
> > works correctly.
>
> Thanks for the patch!
>
> > (concat
> > (substring x 0 (match-end 1))
> > ...
> > + (unless (string= org-agenda-todo-keyword-format "")
> > + (format org-agenda-todo-keyword-format
> > + (match-string 2 x))
> > + ;; Remove `display' property as the icon could leak
> > + ;; on the white space.
> > + (org-add-props " " (org-plist-delete (text-properties-at 0 x)
> > + 'display)))
> > (substring x (match-end 3)))
> >x)))
>
> Your patch will unconditionally hide todo keywords in agenda even when
> org-agenda-todo-keyword-format is not empty. This will happen because
> (unless ...) form will only return the last " ", but never the keyword.
>
> You should better wrap the (org-add-props ...) with another unless
> condition.
>
> Best,
> Ihor
>
From 2e90cac33c22cf8ea09f7f02e644df983b7ca0d1 Mon Sep 17 00:00:00 2001
From: Samim Pezeshki
Date: Sat, 5 Feb 2022 20:11:19 +0330
Subject: [PATCH] lisp/org-agenda.el: Fix bug in `org-agenda-highlight-todo'
* lisp/org-agenda.el (org-agenda-highlight-todo): Skip formatting
the to-do keyword when `org-agenda-todo-keyword-format' is the
empty string.
TINYCHANGE
---
lisp/org-agenda.el | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 9bc44a56e..3b6397b25 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -7634,14 +7634,15 @@ The optional argument TYPE tells the agenda type."
(setq x
(concat
(substring x 0 (match-end 1))
- (unless (string= org-agenda-todo-keyword-format "")
- (format org-agenda-todo-keyword-format
- (match-string 2 x)))
- ;; Remove `display' property as the icon could leak
- ;; on the white space.
- (org-add-props " " (org-plist-delete (text-properties-at 0 x)
-'display))
- (substring x (match-end 3)))
+ (unless (string= org-agenda-todo-keyword-format "")
+ (format org-agenda-todo-keyword-format
+ (match-string 2 x)))
+ (unless (string= org-agenda-todo-keyword-format "")
+ ;; Remove `display' property as the icon could leak
+ ;; on the white space.
+ (org-add-props " " (org-plist-delete (text-properties-at 0 x)
+ 'display)))
+ (substring x (match-end 3)))
x)))
(defsubst org-cmp-values (a b property)
--
2.35.1
Re: Lazy load of org-protocol
On 2/9/2022 8:46 AM, Max Nikulin wrote: It is not a problem to implement --apply in addition to --arg. [snip] For the purposes of this issue, I think either solution would probably work. It probably depends on what people think on emacs-devel. On a related note, there is still an issue with `--eval' in some cases. It fails to work with emacsclient when invoking an alternate editor: emacsclient --alternate-editor emacs --eval '(message "hi")' If Emacs isn't already running, that will open a new buffer named '(message "hi")'. I think that's just a bug in how emacsclient handles `--eval', though fixing it would make org-protocol links work more reliably (if they used `--eval' as proposed, that is). emacsclient --alternate-editor '' --eval '(message "hi")' But it makes it harder to use it during debugging when -Q -L ~/src/org-mode/lisp options are required. Right, invoking the main Emacs instance as a daemon (i.e. when --alternate-editor is the empty string) works pretty differently from invoking the main Emacs instance directly (i.e. when --alternate-editor is "emacs" or somesuch). In the former case, emacsclient starts "emacs --daemon" and then tries to reconnect to the daemon; in the latter, it just takes the arguments passed to emacsclient and forwards them (well, some of them) to emacs. The end result is that it runs "emacs '(message "hi")'", which isn't correct. It'd be nice to fix the behavior of "--alternate-editor emacs" so it passes the --eval flag along too. This might be tricky though, since the semantics of --eval aren't quite the same for emacs and emacsclient. For emacs, --eval means that just the next argument is Lisp code; for emacsclient, --eval means that *all* subsequent (positional) arguments are Lisp code. In practice though, I don't think fixing this is actually *required* to fix the issue of how org-protocol is handled. It only causes issues for the subset of people who use "--alternate-editor emacs" or something similar. - Jim
Re: Unable to get current or via use-package
Loris, et al.,
> Thanks, that did the trick. I was hoping that when I use the same
> init.el on a different machine I wouldn't have to remember anything and
> use-package would automatically install the latest version. Seemingly
> not :-/
this is maybe an appropriate time to insert a plug for straight.el:
https://github.com/raxod502/straight.el
though, in reality, it has its own rough edges. yremv ("your rough
edges may vary" :).
cheers, Greg
RE: Unable to get current or via use-package
>(use-package org >:ensure org-contrib) I believe `:ensure org-contrib` is no longer needed. I tend to use the org-mode from the package manager, but do not do it interactively from within emacs. Instead, which when I want to refresh org, I do from the command line: emacs -Q -batch -eval "(progn (require 'package) (package-initialize) (package-refresh-contents) (package-install 'org))" Also, early in my init.el, as extra level of precaution against getting the built-in org-mode, I ensure it never gets loaded: (require 'cl-seq) (delete (car (cl-member "lisp/org" load-path :test #'string-match)) load-path) > >I moved the old-plus-contrig ELPA folder out the way. However, I now >just get the built-in version of Org: > >Org mode version 9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/) > >Is this a problem use-package has with built-in packages, as described here > >https://github.com/jwiegley/use-package/issues/319 > >? Or am I doing something wrong? Or do I just need to install via M-x >list-packages (bearing in mind the caveat about not visiting an org file >beforehand)? > >Cheers, > >Loris > >-- >This signature is currently under construction. >
Re: Lazy load of org-protocol
On 08/02/2022 17:44, Tianshu Wang wrote: Max Nikulin writes: Thank you, such approach, unlike mine example, does not have code duplication. On the other hand it loads org-protocol on any remote command, not only for "files" representing org-protocol URIs. Maybe defadvice in org-protocol.el should be changed by newer advice-add with a function containing body of the old advice. Yes, I replaced the original code with advice-add (not fully tested). Sorry, I was not clear enough. I meant a patch similar to the attached one. It is not tested for greedy subprotocols. It allows to check arguments to decide if it is necessary to load org-protocol: (defun org-protocol-lazy-load (args) (if (or (featurep 'org-protocol) (not (delq nil (mapcar (lambda (loc) ;; loc: (file-name . (line . column)) (string-match-p "\\(?:^\\|[/]\\)org-protocol:" (car loc))) (car args) args (require 'org-protocol) (org-protocol-detect-protocol-server args))) (server-start) (advice-add 'server-visit-files :filter-args #'org-protocol-lazy-load) On 08/02/2022 02:06, Jim Porter wrote: On 2/7/2022 6:57 AM, Max Nikulin wrote: Maybe another option would be to add an --apply argument that really *does* consume the other command-line args and turns them into a properly-quoted function call. Roughly speaking, it would turn this: emacs --apply func foo bar baz into this: (apply #'func '(foo bar baz)) You have almost managed to sell this idea to me. However even --apply is just sugar for emacsclient --eval "(apply #'func command-line-args-left)" --arg 1 2 So it is --apply option that may require to write a dedicated function if --arg is not implemented. Another limitation of --apply is that the function must accept string arguments only, no lists or even integers or boolean. Yeah, `--arg' does have greater flexibility in that regard, but it comes at the cost of verbosity and some slight behavioral differences with the equivalent in the main emacs executable. For emacs itself, any elements of `command-line-args-left' that aren't consumed by a function will get opened as files, but I don't think that would be the case with emacsclient. Does this difference matter? Probably not. However, avoiding `command-line-args-left' just feels intuitively "cleaner" to me. Still, I think `--arg' should work and be backwards-compatible, so I don't mind it, even if I prefer the simplicity of `--apply'. It is not a problem to implement --apply in addition to --arg. It may just mean --eval '(apply-from-command-line-args-left)' emacs --batch -l apply-from-command-line-args-left.el \ --eval '(apply-from-command-line-args-left)' \ message 'test %S, %S' Hello 'World!' (defun apply-from-command-line-args-left () (let* ((name (car command-line-args-left)) (func (symbol-function (intern name (if func (apply func (cdr command-line-args-left)) (error (format "Symbol's function definition is void: %s" name) OK, I forgot to set the variable to nil. On a related note, there is still an issue with `--eval' in some cases. It fails to work with emacsclient when invoking an alternate editor: emacsclient --alternate-editor emacs --eval '(message "hi")' If Emacs isn't already running, that will open a new buffer named '(message "hi")'. I think that's just a bug in how emacsclient handles `--eval', though fixing it would make org-protocol links work more reliably (if they used `--eval' as proposed, that is). emacsclient --alternate-editor '' --eval '(message "hi")' But it makes it harder to use it during debugging when -Q -L ~/src/org-mode/lisp options are required.From 8a4f8db239d004513be35249ed71e222381b0162 Mon Sep 17 00:00:00 2001 From: Max Nikulin Date: Wed, 9 Feb 2022 23:25:28 +0700 Subject: [PATCH] org-protocol.el: New-style advice lisp/org-protocol.el (org-protocol-detect-protocol-server): Use `advice-add' instead of deprecated `defadvice'. Advice as a function allows to call it from another similar advice loading `org-protocol' on demand. --- lisp/org-protocol.el | 20 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/lisp/org-protocol.el b/lisp/org-protocol.el index 7c4de03bc..fb41e3c0f 100644 --- a/lisp/org-protocol.el +++ b/lisp/org-protocol.el @@ -687,25 +687,29 @@ to deal with new-style links.") (throw 'fname t fname))) -(defadvice server-visit-files (before org-protocol-detect-protocol-server activate) +(defun org-protocol-detect-protocol-server (args) "Advice server-visit-flist to call `org-protocol-modify-filename-for-protocol'." - (let ((flist (if org-protocol-reverse-list-of-files - (reverse (ad-get-arg 0)) - (ad-get-arg 0))) -(client (ad-get-arg 1))) + (let* ((files
Re: Unable to get current or via use-package
Hi Eric, Eric S Fraga writes: > On Wednesday, 9 Feb 2022 at 14:25, Loris Bennett wrote: >> Is this a problem use-package has with built-in packages, as described here >> >> https://github.com/jwiegley/use-package/issues/319 > > Yes, I think so. > > What happens if you "M-x package-list-packages" and then install org > from there? (use "i" to request installation and then "x" to execute) Thanks, that did the trick. I was hoping that when I use the same init.el on a different machine I wouldn't have to remember anything and use-package would automatically install the latest version. Seemingly not :-/ Cheers, Loris -- This signature is currently under construction.
[PATCH] Fix org-set-tags-command active region bug
When `org-loop-over-headlines-in-active-region' is 'start-level, the command should loop only over the headings having the same level as the first one, but it loops over all headings in the region. This patch fixes the issue. From 289d6bdcb8328554c6dd4136d38f1220d239940e Mon Sep 17 00:00:00 2001 From: alexgiorev Date: Wed, 9 Feb 2022 16:22:09 +0200 Subject: [PATCH] lisp/org.el: Fix org-set-tags-command active region bug * lisp/org.el (org-set-tags-command): When called with an active region and `org-loop-over-headlines-in-active-region` having a value `start-level', it is supposed to loop only over the headings at the same level as the first one, but without this fix it loops over all headings in the region. --- lisp/org.el | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index ef8d460e1..b2091a4fe 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -12183,11 +12183,12 @@ in Lisp code use `org-set-tags' instead." (cond ((equal '(4) arg) (org-align-tags t)) ((and (org-region-active-p) org-loop-over-headlines-in-active-region) - (let (org-loop-over-headlines-in-active-region) ; hint: infinite recursion. + (let ((original org-loop-over-headlines-in-active-region) +(org-loop-over-headlines-in-active-region nil)) ; hint: infinite recursion. (org-map-entries #'org-set-tags-command nil - (if (eq org-loop-over-headlines-in-active-region 'start-level) + (if (eq original 'start-level) 'region-start-level 'region) (lambda () (when (org-invisible-p) (org-end-of-subtree nil t)) -- 2.25.1
Re: Unable to get current or via use-package
On Wednesday, 9 Feb 2022 at 14:25, Loris Bennett wrote: > Is this a problem use-package has with built-in packages, as described here > > https://github.com/jwiegley/use-package/issues/319 Yes, I think so. What happens if you "M-x package-list-packages" and then install org from there? (use "i" to request installation and then "x" to execute) -- : Eric S Fraga, with org release_9.5.2-364-ge7ea95 in Emacs 29.0.50
Unable to get current or via use-package
Hi,
After Emacs started nagging me with the following
IMPORTANT: please install Org from GNU ELPA as Org ELPA will close
before Org 9.6
I set in init.el
(setq package-archives
'(("gnu" . "http://elpa.gnu.org/packages/;)
("nongnu" . "http://elpa.nongnu.org/nongnu/;)
("melpa" . "http://melpa.org/packages/;)))
and have
(use-package org
:ensure org-contrib)
I moved the old-plus-contrig ELPA folder out the way. However, I now
just get the built-in version of Org:
Org mode version 9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)
Is this a problem use-package has with built-in packages, as described here
https://github.com/jwiegley/use-package/issues/319
? Or am I doing something wrong? Or do I just need to install via M-x
list-packages (bearing in mind the caveat about not visiting an org file
beforehand)?
Cheers,
Loris
--
This signature is currently under construction.
Re: [PATCH] lisp/org-capture.el: Add hook & hook options to org-capture (Valentin Herrmann)
Ihor Radchenko writes: No Wayman writes: I've implemented what you're proposing here (and much more) in a package you may find useful a couple years ago. I pitched adopting some of the ideas into org-mode proper and was willing to do the work. My proposal was met with enthusiastic silence: https://www.github.com/progfolio/doct I think Nicolas gave some reasonable comments, didn't he? He suggested to incorporate some of the ideas into the existing Org mode code. https://orgmode.org/list/87wo66t8i7@gmail.com Best, Ihor I believe you're referring to: https://list.orgmode.org/87y2qlgq33@nicolasgoaziou.fr/ He had some reasonable questions about the design, but said he only uses very basic capture templates, and could not comment beyond that on the design. The hope was that people who use more of org-capture's features would chime in. That didn't happen. Of course doct's features could be added to org-capture in a piecemeal fashion, but I'm not too keen on contributing anything non-trivial to Org these days. Too much back and forth coupled with discussion that can stall due to lack of interest. e.g. https://list.orgmode.org/87h7e6dluc@gmail.com/ https://list.orgmode.org/87tuit73ij@gmail.com/
