Re: Do not show a TODO item in the global TODO list until certain date?
Hello, Ihor Radchenko writes: > Check out org-agenda-skip-function (see A.7 Special Agenda Views section > of the manual). > > Also, I am doing something similar in my personal config using > SHOWFROMDATE property. See > https://github.com/yantar92/emacs-config/blob/master/config.org#properties > for inspiration. thanks for the pointers. I will check both alternatives and see which one suits me best. -- Ángel de Vicente Research Software Engineer (Supercomputing and BigData) Instituto de Astrofísica de Canarias (https://www.iac.es/en)
[PATCH 4] New: auto display inline images under subtree when `org-cycle'.
Ihor Radchenko writes: > "Christopher M. Miles" writes: > >> Ihor, My new patch still have some issue in the 'fold state which I >> added "FIXME" marker. Hope can get some solution from you. > > I will comment only on the first patch for now. > >> "EXPORT_OPTIONS" "EXPORT_TEXT" "EXPORT_FILE_NAME" >> "EXPORT_TITLE" "EXPORT_AUTHOR" "EXPORT_DATE" "UNNUMBERED" >> "ORDERED" "NOBLOCKING" "COOKIE_DATA" "LOG_INTO_DRAWER" "REPEAT_TO_STATE" >> -"CLOCK_MODELINE_TOTAL" "STYLE" "HTML_CONTAINER_CLASS") >> +"CLOCK_MODELINE_TOTAL" "STYLE" "HTML_CONTAINER_CLASS" >> +"ORG-IMAGE-ACTUAL-WIDTH") > > This change should also be mentioned in the commit message. Done > >> @@ -16164,14 +16165,19 @@ buffer boundaries with possible narrowing." >> (org-element-property :begin par) >> (re-search-forward attr-re par-end t))) >>(match-string 1))) >> + ;; support subtree-level property "ORG-IMAGE-ACTUAL-WIDTH" >> specified width. >> + (subtree-property-width >> +(ignore-errors (org-property-or-variable-value >> 'ORG-IMAGE-ACTUAL-WIDTH))) > > You are checking the property too late. I suggest to let-bind > org-image-actual-width around the whole `cond' instead. > > That way, subtree-local value of ORG-IMAGE-ACTUAL-WIDTH will have an > effect of setting `org-image-actual-width' value. Done > > Also, is there any particular reason why you wrap > `org-property-or-variable-value' into `ignore-errors'? Remove, I originally use another property keyword instead of ORG-IMAGE-ACTUAL-WIDTH, so ~org-property-or-variable-value~ will raise error if property does not exist. SO I added ~ignore-errors~. Now removed. > > Finally, you can simply do > > (org-property-or-variable-value 'org-image-actual-width) > > It will return the property value _or_ org-image-actual-width value. > Done >> - (car org-image-actual-width)) >> + ;; Try to use subtree-level width before fallback. >> + (or subtree-property-width >> + ;; Fallback to `org-image-actual-width' if no interprable >> width is given. >> + (car org-image-actual-width))) > > With my last suggestion, this code will not be needed. Done > > Also, this change should be documented in etc/NEWS and also in > "12.7 Images" section of the manual. Done. (the manual, you mean org-manual.org right? I found too many documents under doc/ folder, confused for a while) P.S: I merged two commits into one for clear. From 4ba9bb3063bde50511457b1d30f1299a85e3ffaf Mon Sep 17 00:00:00 2001 From: stardiviner Date: Mon, 12 Sep 2022 09:45:09 +0800 Subject: [PATCH] org.el: Add hook function to auto display inline images of subtree * lisp/org.el (org-display-subtree-with-inline-images): Add an option and hook function to auto display of inline images under current expanded visible subtree. * lisp/org.el (org-display-inline-image--width): support subtree-level property "ORG-IMAGE-ACTUAL-WIDTH" specified width. * lisp/org.el (org-default-properties): Add a new property in to override global org-image-actual-width subtree level. --- doc/org-manual.org | 5 ++ etc/ORG-NEWS | 5 ++ lisp/org.el| 133 ++--- 3 files changed, 100 insertions(+), 43 deletions(-) diff --git a/doc/org-manual.org b/doc/org-manual.org index a37b8390c..77274e250 100644 --- a/doc/org-manual.org +++ b/doc/org-manual.org @@ -11314,6 +11314,11 @@ command: startup by configuring the variable ~org-startup-with-inline-images~[fn:119]. +If you want to override global variable ~org-image-actual-width~ of +inline image display width, you can specify property +"=ORG-IMAGE-ACTUAL-WIDTH=" in subtree level. It will only affect +inline images under the specified subtree. + ** Captions :PROPERTIES: :DESCRIPTION: Describe tables, images... diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS index a7f32671e..42e7e4292 100644 --- a/etc/ORG-NEWS +++ b/etc/ORG-NEWS @@ -296,6 +296,11 @@ headings in HTML export. Use the header argument =:var x=code-block[]= or : #+CALL: fn(x=code-block[]) to pass the contents of a named code block as a string argument. +*** New default property =ORG-IMAGE-ACTUAL-WIDTH= for overriding global ~org-image-actual-width~ + +The subtree-level property "ORG-IMAGE-ACTUAL-WIDTH" can override the +global variable ~org-image-actual-width~ settings for inline images +width under current property specified subtree. ** New options *** New custom settings =org-icalendar-scheduled-summary-prefix= and =org-icalendar-deadline-summary-prefix= diff --git a/lisp/org.el b/lisp/org.el index 6e6c437d5..98cac1c1c 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -1108,6 +1108,13 @@ the following lines anywhere in the buffer: :version "24.1" :type 'boolean) +(defcustom org-cycle-display-inline-images nil + "Non-nil means auto display inline images under subtree when
Re: 'make autoloads' works but 'make ; make autoloads' fails with a version mismatch?
> Thanks for reporting! > Fixed on main. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=2d3802658156153974f540877a82bf5a384a2ad4 Thanks that fix it for me too. Charles signature.asc Description: PGP signature
Re: 'make autoloads' works but 'make ; make autoloads' fails with a version mismatch?
Daniel Ortmann writes: > What's up with this behavior? It began a couple of weeks ago. I have > the load-path set immediately in my init.el followed by require org. > > Versions are: > > * GNU Emacs 29.0.50 (build 9, x86_64-pc-linux-gnu, GTK+ Version > 3.22.30, cairo version 1.15.12) of 2022-09-14 > * Org mode version 9.5.5 (release_9.5.5-785-g86c463 @ > /home/dortmann/src/git-org-mode/lisp/) > > 'make clean' followed by 'make autoloads' works fine: Thanks for reporting! Fixed on main. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=2d3802658156153974f540877a82bf5a384a2ad4 -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: [PATCH 3] New: auto display inline images under subtree when `org-cycle'.
"Christopher M. Miles" writes: > Ihor, My new patch still have some issue in the 'fold state which I > added "FIXME" marker. Hope can get some solution from you. I will comment only on the first patch for now. > "EXPORT_OPTIONS" "EXPORT_TEXT" "EXPORT_FILE_NAME" > "EXPORT_TITLE" "EXPORT_AUTHOR" "EXPORT_DATE" "UNNUMBERED" > "ORDERED" "NOBLOCKING" "COOKIE_DATA" "LOG_INTO_DRAWER" "REPEAT_TO_STATE" > -"CLOCK_MODELINE_TOTAL" "STYLE" "HTML_CONTAINER_CLASS") > +"CLOCK_MODELINE_TOTAL" "STYLE" "HTML_CONTAINER_CLASS" > +"ORG-IMAGE-ACTUAL-WIDTH") This change should also be mentioned in the commit message. > @@ -16164,14 +16165,19 @@ buffer boundaries with possible narrowing." > (org-element-property :begin par) > (re-search-forward attr-re par-end t))) >(match-string 1))) > + ;; support subtree-level property "ORG-IMAGE-ACTUAL-WIDTH" > specified width. > + (subtree-property-width > +(ignore-errors (org-property-or-variable-value > 'ORG-IMAGE-ACTUAL-WIDTH))) You are checking the property too late. I suggest to let-bind org-image-actual-width around the whole `cond' instead. That way, subtree-local value of ORG-IMAGE-ACTUAL-WIDTH will have an effect of setting `org-image-actual-width' value. Also, is there any particular reason why you wrap `org-property-or-variable-value' into `ignore-errors'? Finally, you can simply do (org-property-or-variable-value 'org-image-actual-width) It will return the property value _or_ org-image-actual-width value. > - (car org-image-actual-width)) > + ;; Try to use subtree-level width before fallback. > + (or subtree-property-width > + ;; Fallback to `org-image-actual-width' if no interprable > width is given. > + (car org-image-actual-width))) With my last suggestion, this code will not be needed. Also, this change should be documented in etc/NEWS and also in "12.7 Images" section of the manual. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
'make autoloads' works but 'make ; make autoloads' fails with a version mismatch?
What's up with this behavior? It began a couple of weeks ago. I have
the load-path set immediately in my init.el followed by require org.
Versions are:
* GNU Emacs 29.0.50 (build 9, x86_64-pc-linux-gnu, GTK+ Version
3.22.30, cairo version 1.15.12) of 2022-09-14
* Org mode version 9.5.5 (release_9.5.5-785-g86c463 @
/home/dortmann/src/git-org-mode/lisp/)
'make clean' followed by 'make autoloads' works fine:
dortmann@ddo-linux:git-org-mode$ make autoloads
make -C lisp autoloads
make[1]: Entering directory '/home/dortmann/src/git-org-mode/lisp'
rm -f org-version.el org-loaddefs.el org-version.elc org-loaddefs.elc
org-install.elc
org-version: 9.5.5 (release_9.5.5-785-g86c463)
Loading /home/dortmann/src/git-org-mode/lisp/org-compat.el (source)...
Loading /home/dortmann/src/git-org-mode/mk/org-fixup.el (source)...
Package autoload is deprecated
org-loaddefs: 9.5.5 (release_9.5.5-785-g86c463)
Loading /home/dortmann/src/git-org-mode/lisp/org-compat.el (source)...
Loading /home/dortmann/src/git-org-mode/mk/org-fixup.el (source)...
Package autoload is deprecated
make[1]: Leaving directory '/home/dortmann/src/git-org-mode/lisp'
dortmann@ddo-linux:git-org-mode$
*==>> *But 'make clean' and then 'make' followed by 'make autoloads'
fails. I could not get around it by manipulating load-path further:
dortmann@ddo-linux:git-org-mode$ make autoloads
make -C lisp autoloads
make[1]: Entering directory '/home/dortmann/src/git-org-mode/lisp'
rm -f org-version.el org-loaddefs.el org-version.elc org-loaddefs.elc
org-install.elc
org-version: 9.5.5 (release_9.5.5-785-g86c463)
Loading /home/dortmann/src/git-org-mode/lisp/org-compat.el (source)...
Warning (emacs): Org version mismatch. Make sure that correct
‘load-path’ is set early in init.el
This warning usually appears when a built-in Org version is loaded
prior to the more recent Org version.
Version mismatch is commonly encountered in the following situations:
1. Emacs is loaded using literate Org config and more recent Org
version is loaded inside the file loaded by ‘org-babel-load-file’.
‘org-babel-load-file’ triggers the built-in Org version clashing
the newer Org version attempted to be loaded later.
It is recommended to move the Org loading code before the
‘org-babel-load-file’ call.
2. New Org version is loaded manually by setting ‘load-path’, but some
other package depending on Org is loaded before the ‘load-path’ is
configured.
This "other package" is triggering built-in Org version, again
causing the version mismatch.
It is recommended to set ‘load-path’ as early in the config as
possible.
3. New Org version is loaded using straight.el package manager and
other package depending on Org is loaded before straight triggers
loading of the newer Org version.
It is recommended to put
(straight-use-package ’org)
early in the config. Ideally, right after the straight.el
bootstrap. Moving ‘use-package’ :straight declaration may not be
sufficient if the corresponding ‘use-package’ statement is
deferring the loading.
Error: error ("Org version mismatch. Make sure that correct ‘load-path’
is set early in init.el")
mapbacktrace(#f(compiled-function (evald func args flags) #0xa578661cbaef144>))
debug-early-backtrace()
debug-early(error (error "Org version mismatch. Make sure that
correct ‘load-path’ is set early in init.el"))
signal(error ("Org version mismatch. Make sure that correct
‘load-path’ is set early in init.el"))
error("Org version mismatch. Make sure that correct `load-path' is
set early in init.el")
byte-code("\300 \301\232\204\17\0\302\303!\210\304\305!\210\300\207"
[org-git-version "release_9.5.5-785-g86c463" warn "Org version
mismatch. Make sure that correct `load-path' is set early in
init.el\nThis warning usually appears when a built-in Org version is
loaded\nprior to the more recent Org version.\n\nVersion mismatch is
commonly encountered in the following situations:\n1. Emacs is loaded
using literate Org config and more recent Org\n version is loaded
inside the file loaded by `org-babel-load-file'.\n
`org-babel-load-file' triggers the built-in Org version clashing\n the
newer Org version attempted to be loaded later.\n\n It is recommended
to move the Org loading code before the\n `org-babel-load-file'
call.\n\n2. New Org version is loaded manually by setting `load-path',
but some\n other package depending on Org is loaded before the
`load-path' is\n configured.\n This \"other package\" is triggering
built-in Org version, again\n causing the version mismatch.\n\n It is
recommended to set `load-path' as early in the config as\n
possible.\n\n3. New Org version is loaded using straight.el package
manager and\n other package depending on Org is loaded before straight
triggers\n loading of the newer Org version.\n\n It is recommended
to put\n (straight-use-package 'org)\n early in the config.
Ideally, right
Re: Use lexical-scoping in tests
> The fix is in preparation, but obviously I had tested my patch > incorrectly (i.e. I probably compiled and tested another code than the > one I had patched). OK, here's a better version. As you can see, it's not nearly as simple. Stefan >From 9cd41bcbb6ca6771bd4c79f8b9d07241c67250ea Mon Sep 17 00:00:00 2001 From: Stefan Monnier Date: Wed, 14 Sep 2022 17:21:37 -0400 Subject: [PATCH] testing: Make all files use `lexical-binding` Mainly, add the corresponding cookie, but also add various `require`s so that the compiler knows which vars should be trated as dynbound. This does not fix all the warnings, but does try to eliminate all those about "unused" variables. For the variables truly unused, the patch usually adds an underscore to their name to silence the warning. Some of the fixes affect files which already used `lexical-binding`. Not sure why the test worked before: maybe because the tests were run without compiling them first (which could cause some of the missing `require`d packages to be autoloaded before we got to the problematic code, thus hiding the problem)? I found some suspicious code, for which I added FIXMEs. There are also a few changes to the main files. * lisp/org-protocol.el (org-protocol-check-filename-for-protocol): Don't call `server-edit` if it's not yet defined. [ Needed to get the tests to pass. ] * lisp/ob-core.el (org-babel-temporary-directory) (org-babel-temporary-stable-directory): Always define (and use nil if we don't want to create a directory for it). Simplify the code based on the fact that (defvar V E) only evaluates E if V is not yet `boundp`. (org-babel-temp-file, org-babel-temp-stable-file) (org-babel-remove-temporary-directory) (org-babel-remove-temporary-stable-directory): Adjust accordingly. * lisp/org.el (org-log-beginning): Add FIXME. * testing/org-test.el: Require `org` and `org-id`. (org-id-locations-file): Don't `defconst` it. (org-test-at-id, org-test-in-example-file, org-test-at-marker) (org-test-with-temp-text, org-test-with-temp-text-in-file): Move edebug specs into `declare` (and simplify them). (org-test-with-tramp-remote-dir--worker): Declare dynbound tramp vars. (org--compile-when): Fix quoting of `exp`. (org-test-load): Tweak regexps. * testing/org-batch-test-init.el: Tweak regexp, remove dead code and add a FIXME about it. * testing/lisp/test-ox.el: Require `ox` instead of erroring out if it's not already loaded. Also require `org-inlinetask`. (org-test-with-parsed-data): Silence warnings when `info` is not used. (test-org-export/bind-keyword): Add FIXME. * testing/lisp/test-ox-publish.el: Require `org-test` and `ox-publish`. (test-org-publish/resolve-external-link): Expose lambdas to the compiler. Remove unused var `ids`. (test-org-publish/get-project-from-filename): Remove unused var `file`. * testing/lisp/test-org.el: Require `org-macs`, `org`, `org-inlinetask`, `org-refile`, and `org-agenda`. (test-org/org-read-date): Declare `org-time-was-given` as dynbound. (test-org/set-regexps-and-options): Add FIXME. * testing/lisp/test-org-timer.el: Require `org-timer`. * testing/lisp/test-org-table.el: Require `ox`. * testing/lisp/test-org-protocol.el: Require `org-protocol` instead of erroring out if it's not already loaded. Also require `capture`, and add missing `provide` statement. * testing/lisp/test-org-pcomplete.el: Require `org`. * testing/lisp/test-org-list.el: Require `org-list` and `org`. * testing/lisp/test-org-lint.el: Require `org-footnote` and `org-lint`. * testing/lisp/test-org-footnote.el: Require `org-footnote`. * testing/lisp/test-org-element.el: Require `org-element` instead of erroring out if it's not already loaded. Also require `org` and `org-inlinetask`. * testing/lisp/test-org-duration.el: Require `org-duration`. * testing/lisp/test-org-datetree.el: Require `org-datetree`. * testing/lisp/test-org-colview.el: Require `org-colview`, `org-duration`, and `org-inlinetask`. * testing/lisp/test-org-clock.el: Require `org-duration` and `org-clock`. * testing/lisp/test-org-archive.el: Require `org-archive`. * testing/lisp/test-org-agenda.el (test-org-agenda/bulk-custom-arg-func): Add FIXME. * testing/lisp/test-ol.el: Require `ol` and `org-id`. (test-org-link/store-link): Declare `org-store-link-props` and add FIXME. * testing/lisp/test-oc.el (test-org-cite/export-capability): Add FIXME. * testing/lisp/test-ob.el: Require `ob-core`, `org-src`, `ob-ref`, and `org-table`. (test-ob/eval-header-argument): Rename `foo` to `test-ob--foo` and declare it as dynbound. (test-ob/blocks-with-spaces, test-ob/specific-colnames): Add FIXME. (test-ob/noweb-expansions-in-cache): Declare `noweb-expansions-in-cache-var` as dynbound. * testing/lisp/test-ob-tangle.el: Require `org` and `ob-tangle`. * testing/lisp/test-ob-shell.el: * testing/lisp/test-ob-python.el: Require `ob-core`. * testing/lisp/test-ob-lob.el: Require `ob-lob`. (temporary-value-for-test): Declare as dynbound. *
Re: org-assert-version considered harmful
Stefan Monnier writes: >>> In my book step 3 above is a mistake (even if moved to step 2). >> I am confused. >> AFAIK, changing the load-path is a common way for users to install >> packages manually. > > No, you're not confused, I just think that installing packages manually > (including messing with `load-path` and writing `(autoload ...)` in your > init file) is very last century :-) > but Emacs *is* last century! :-) It is the fact we *can* manipulate load-path, autoloads and manually control what is installed which makes it so powerful. See how far you get when a core VS Code extension you rely on changes in a manner you don't like and you want to revert to the previous version. I know your comment was tongue in cheek, but I also do see some danger in a future where we only interact with the well defined 'surface' layer of software like Emacs and only a few hard core devs actually get into crafting their init.el file. It could be the reason we seem to be seeing an increase in the type of issues which kicked this off is because fewer people are familiar with manipulating load-path and autoloads, Less familiarity means less familiarity with the common pitfalls and issues you may run into.
Re: Use lexical-scoping in tests
Ihor Radchenko [2022-09-14 20:32:53] wrote: > Stefan Monnier writes: >> The patch below simply enables `lexical-binding` in all the test files. >> As far as I can tell, it's all that's needed (beside a missing >> `require`). > Thanks, but the patch causes 23 tests to fail (running make test). Oh, lord! The fix is in preparation, but obviously I had tested my patch incorrectly (i.e. I probably compiled and tested another code than the one I had patched). [ At least it explains why I was seeing this weird "it's all that's needed", which I always hope for but is so rarely true. ] > Also, is there any reason why it was a plain diff? Lack of inspiration, mostly. Stefan
Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency
Karl Voit [2022-09-13 Tue 10:07] wrote: > Is it only me who is thinking that a non-blocking cancelled checkbox > state would be a good idea? At first it makes sense, but we do have headlines and TODO keywords to express different states, colors and even sets of states. This is just a checklist construct. I think if I wanted to mark something as canceled or not relevant I would do something like this: - [ ] this is important. - [X] +canceled+ this is not important. or even strike through everything. I think it's consistent in terms of statistics; you want the total number to represent what you wrote down and what's left does not include the "canceled" tasks. -- Daniel Fleischer
Re: Reinstalling compat fixed everything breaking
On 14 September 2022, Charles Philip Chan wrote: I am seeing the same problem. However, it did not resolve for me after upgrading the compat library to the current git version. I am still getting: , | Warning (emacs): Org version mismatch. Make sure that correct ‘load-path’ is | set early in init.el This warning usually appears when a built-in Org version is | loaded prior to the more recent Org version. ` during "make install". I never had this problem before. I've never done a "make install" because I run it from the source tree,¹ so maybe that's why my configuration works now but yours still doesn't. I hope someone who knows more about all this can pitch in. Bill ¹ Configured so: (use-package org :pin manual :load-path "/usr/local/src/org-mode/lisp" :init ;; Lots of stuff here ) -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada
Re: Reinstalling compat fixed everything breaking
William Denton writes: Hello, > Yesterday I pulled the current source trees for Org and Emacs and compiled as > I usually do ... and everything broke, with Org complaining about mixed > versions, and all kinds of warnings and backtraces and "Invalid function: > compat-declare-version" errors. > > After looking at various things I noticed a couple of mild warnings related to > the package compat, which I'd seen for a while (several weeks, at least) but > never bothered about, because everything worked. I thought maybe it was all > connected, what with the new version-checking and such, and indeed "M-x > package-reinstall compat" did the trick and now everything works. I am seeing the same problem. However, it did not resolve for me after upgrading the compat library to the current git version. I am still getting: , | Warning (emacs): Org version mismatch. Make sure that correct ‘load-path’ is | set early in init.el This warning usually appears when a built-in Org version is | loaded prior to the more recent Org version. ` during "make install". I never had this problem before. Charles signature.asc Description: PGP signature signature.asc Description: PGP signature
Re: Reinstalling compat fixed everything breaking
William Denton writes: Hello, > Yesterday I pulled the current source trees for Org and Emacs and compiled as > I usually do ... and everything broke, with Org complaining about mixed > versions, and all kinds of warnings and backtraces and "Invalid function: > compat-declare-version" errors. > > After looking at various things I noticed a couple of mild warnings related to > the package compat, which I'd seen for a while (several weeks, at least) but > never bothered about, because everything worked. I thought maybe it was all > connected, what with the new version-checking and such, and indeed "M-x > package-reinstall compat" did the trick and now everything works. I am seeing the same problem. However, it did not resolve for me after upgrading the compat library to the current git version. I am still getting: , | Warning (emacs): Org version mismatch. Make sure that correct ‘load-path’ is | set early in init.el This warning usually appears when a built-in Org version is | loaded prior to the more recent Org version. ` during "make install". I never had this problem before. Charles signature.asc Description: PGP signature
[PATCH] ol.el: Always prompt for description in `org-insert-link'
Hi, The `org-insert-link' function has the `auto-desc' variable to suppress user prompt for link description. It worked accordingly its intention (as I understand it) a couple of months a decade ago, after that the logic was broken. Actually the behavior is rather strange: users may edit description only when it is not identical to link path (target). I am attaching a patch that removes this variable with hope that always prompting the user for description is more consistent behavior. Actually during last week completion stored link by its description has been restored, storing link has been changed to prefer nil as description to the path when nothing meaningful may be added. So behavior have become more close to original one. I have an idea how to fix the code to bypass the description prompt if path is completed by description discarding identical path and description, but I prefer to drop the confusing variable and not depend on the means how the link was selected from the list of stored items. Have I missed something and unconditional prompt to edit link description may be undesired in some cases?From b4e5195da4f084a9efd9697db556168d9907a17e Mon Sep 17 00:00:00 2001 From: Max Nikulin Date: Wed, 14 Sep 2022 22:43:51 +0700 Subject: [PATCH 1/2] ol.el: Always prompt for description in `org-insert-link' * lisp/ol.el (org-insert-link): Do not bypass code trying to generated description and prompt user when link path and description are identical. Make behavior of description prompt more consistent. Remove confusing `auto-desc' local variable. Originally the variable was added with implementation of completion of stored link target by the description in the commit 1e34c5d34 Bastien Guerry, "org.el: Fontify links to current buffer when inserting a link", 2012-08-03 14:08:20 +0200. The feature was broken soon by the commit 7f096ad37 Tony Day, "org-insert-link: Use ido when inserting links", 2012-10-12 14:39:53 +1100. Last decade users were not asked to edit description in the case of the same link target and description (a remained side effect of 1e34c5d34). Recent commit 0432f4fe6 Max Nikulin, "ol.el: Restore complete by description for insert link", 2022-09-10 17:23:13 +0700 restored completion by description. Due to the commit 4fc2c8dd8 Ihor Radchenko, "org-store-link: Default to empty description for target/custom-id links", 2022-08-10 13:25:26 +0800 description identical to link path became a more rare case. An alternative would be fixing condition to allow users to edit description when it is the same as the path, but use stored description without additional interaction when the link is chosen by description completion. Despite it was likely the original intention, always asking the user to confirm or edit description may be more consistent behavior. --- lisp/ol.el | 72 ++ 1 file changed, 35 insertions(+), 37 deletions(-) diff --git a/lisp/ol.el b/lisp/ol.el index f3f6e04ef..8f700397e 100644 --- a/lisp/ol.el +++ b/lisp/ol.el @@ -1822,7 +1822,7 @@ non-interactively, don't allow to edit the default description." (all-prefixes (append (mapcar #'car abbrevs) (mapcar #'car org-link-abbrev-alist) (org-link-types))) - entry auto-desc) + entry) (cond (link-location) ; specified by arg, just use it. ((org-in-regexp org-link-bracket-re 1) @@ -1885,8 +1885,7 @@ Use TAB to complete link prefixes, then RET for type-specific completion support (unless (org-string-nw-p link) (user-error "No link selected")) (dolist (l org-stored-links) (when (equal link (cadr l)) - (setq link (car l)) - (setq auto-desc t))) + (setq link (car l (when (or (member link all-prefixes) (and (equal ":" (substring link -1)) (member (substring link 0 -1) all-prefixes) @@ -1963,41 +1962,40 @@ Use TAB to complete link prefixes, then RET for type-specific completion support (when (equal desc origpath) (setq desc path) -(unless auto-desc - (let* ((type - (cond - ((and all-prefixes - (string-match (rx-to-string `(: string-start (submatch (or ,@all-prefixes)) ":")) link)) -(match-string 1 link)) - ((file-name-absolute-p link) "file") - ((string-match "\\`\\.\\.?/" link) "file"))) - (initial-input - (cond - (description) - (desc) - ((org-link-get-parameter type :insert-description) -(let ((def (org-link-get-parameter type :insert-description))) - (condition-case nil - (cond - ((stringp def) def) - ((functionp def) -(funcall def link desc))) -(error - (message "Can't get link description from org link parameter
Re: org-assert-version considered harmful
>> In my book step 3 above is a mistake (even if moved to step 2). > I am confused. > AFAIK, changing the load-path is a common way for users to install > packages manually. No, you're not confused, I just think that installing packages manually (including messing with `load-path` and writing `(autoload ...)` in your init file) is very last century :-) Stefan
Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency
Karl Voit writes: >> So, to me the main use case to have an explicit cancel, is when I have a >> long list, and to remember that I stated it as "cancelled". >> If we go that way, having no other nice idea at the moment, I quite like >> the [C] which is explicit although language specific. > > ... if it is possible with the current implementation, we could > introduce an official convention that any single (upper case?) > character between the brackets is interpreted as a non-open > checkbox. So any user is able to choose her character of choice even > language-dependent. I do not like the idea of pre-defining a meaning of an arbitrary single character. This will leave too less flexibility for future. As for cancelled state, it makes sense to add it. I have seen cancelled state in other outliners. However, adding a new checkbox state will involve changing Org syntax (https://orgmode.org/worg/dev/org-syntax.html#Items). Also, list implementation in Org is not particularly modular---someone will need to go across the code and make sure that new checkbox state is not going to break anything. The manual will also need to be updated. To conclude, if there is sufficient interest, I do not see why not. But it will be an involved change in Org code someone will need to perform. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: Do not show a TODO item in the global TODO list until certain date?
Angel de Vicente writes: > As per the example I was giving, I don't want that entry to be scheduled > for October 16 (and thus clutter my agenda view), I just want it to be > visible in my Global TODO list from that date, so then, depending on how > busy I'm around that date, then I can decide when to schedule it for. > > I hope it makes sense (and there is some way to accomplish it). Check out org-agenda-skip-function (see A.7 Special Agenda Views section of the manual). Also, I am doing something similar in my personal config using SHOWFROMDATE property. See https://github.com/yantar92/emacs-config/blob/master/config.org#properties for inspiration. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: Use lexical-scoping in tests
Stefan Monnier writes: > The patch below simply enables `lexical-binding` in all the test files. > As far as I can tell, it's all that's needed (beside a missing > `require`). Thanks, but the patch causes 23 tests to fail (running make test). Also, is there any reason why it was a plain diff? -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: Do not show a TODO item in the global TODO list until certain date?
Hello, "Rohit Patnaik" writes: >> (not a scheduled one, since I don't need to do it on a particular date) > > The `SCHEDULED' property is in fact the correct way to indicate that you wish > to > hide the task from the global to-do list until a particular date. `SCHEDULED' > indicates the day upon which you wish to start working on the task. If > there's a > particular date by which the task has to be completed, the `DEADLINE' property > is appropriate. Thanks for the pointer, but maybe I use SCHEDULED items a bit different, since I want only a few items in my agenda view, only those that I really intend to start working on the given date. As per the example I was giving, I don't want that entry to be scheduled for October 16 (and thus clutter my agenda view), I just want it to be visible in my Global TODO list from that date, so then, depending on how busy I'm around that date, then I can decide when to schedule it for. I hope it makes sense (and there is some way to accomplish it). Cheers, -- Ángel de Vicente Research Software Engineer (Supercomputing and BigData) Instituto de Astrofísica de Canarias (https://www.iac.es/en)
Re: org-super-agenda global list of TODO items
Hello,
Angel de Vicente writes:
> great. That looks very promising, and without the need to change the
> source code. I will try it later on and report back.
I ended up with this (and going back to unmodified source code for
org-super-agenda, and it now works beautifully.
,
| (setq own-agenda-groups '((:name "Efemerides" :tag "efemerides" :order 1)
| (:name "IMPORTANT" :priority "A" :transformer
| (--> it
| (propertize it 'face
| '(:foreground "red"
:background "green")))
| :order 1)
| (:name "Astrophysics" :tag "astrophysics" :order 3)
| (:name "Hacking" :tag "hacking" :order 3)
| (:name "Admin" :tag "admin" :order 4)))
|
| (setq org-agenda-custom-commands
| '(("h" "Agenda and tasks"
|((agenda "" ((org-super-agenda-groups
|(append
| '((:todo "DONE" :discard)
| (:name "Schedule" :time-grid t :transformer
| (--> it
| (propertize it 'face
| '(:foreground "yellow")
| own-agenda-groups
| (alltodo "" ((org-super-agenda-groups
| (append
| '((:todo "DONE" :discard))
| own-agenda-groups
`
Many thanks,
--
Ángel de Vicente
Research Software Engineer (Supercomputing and BigData)
Instituto de Astrofísica de Canarias (https://www.iac.es/en)
Re: Do not show a TODO item in the global TODO list until certain date?
> (not a scheduled one, since I don't need to do it on a particular date) The `SCHEDULED' property is in fact the correct way to indicate that you wish to hide the task from the global to-do list until a particular date. `SCHEDULED' indicates the day upon which you wish to start working on the task. If there's a particular date by which the task has to be completed, the `DEADLINE' property is appropriate. The relevant org-mode manual page is: https://orgmode.org/manual/Deadlines-and-Scheduling.html I believe. -- Rohit
Re: org-super-agenda global list of TODO items
Hello, Christophe Schockaert writes: > If I am right (I am playing with the config, it’s not in my daily setup yet > for > now), I could achieve this by defining "org-agenda-custom-commands" as shown > in > the "Projects" example : > https://github.com/alphapapa/org-super-agenda/blob/master/examples.org#projects. > > In that case, "org-super-agenda-groups" is defined differently according to > the > context, so the "time-grid" captures the timed entries in its scope. Then, > "org-super-agenda-groups" applies to the TODOs in the "todo" or "alltodo" > context (I used the latter one) where I don’t define the "time-grid" > selection. Or, maybe I applied it to the "alltodo" only, and discarded it for > the agenda grid to work only on the TODOs. I don’t remember exactly, however > this might be a workaround to try that does not need an update of the code, > especially if it is not expected to be stable and supported by the author. great. That looks very promising, and without the need to change the source code. I will try it later on and report back. Cheers, -- Ángel de Vicente Research Software Engineer (Supercomputing and BigData) Instituto de Astrofísica de Canarias (https://www.iac.es/en)
Do not show a TODO item in the global TODO list until certain date?
Hello, I'm wondering if it is possible to have a TODO item, but to not show it in the global TODO list until certain date? For example: I need to get a new insurance for my motor bike, but insurance companies will not give me a quote until October 16, so I would like to create a TODO entry (not a scheduled one, since I don't need to do it on a particular date), but to hide it from view until October 16, since there is no point on trying to do it before that, and it clutters my TODO list. I checked the Org manual and didn't see anything obvious, but maybe there is some way? Thanks, -- Ángel de Vicente Research Software Engineer (Supercomputing and BigData) Instituto de Astrofísica de Canarias (https://www.iac.es/en)
