Re: Possible to exclude/include tags for agenda custom commands?
Hi Adam, Adam Porter writes: > Yes, I'd be glad for it to be listed on Worg. Feel free to add it if > you like, or I might add it myself after I add a bit more content. I'll let you add a link to your page on Worg when you have the time. > I was thinking about working on Worg rather than making yet another > resource, but: > > 1. I saw you mention that you're planning to reorganize Worg's content > soon, and I wouldn't want to interfere with that. Just to tell you a bit more about my plan: I will take the time to work on Worg next week, creating a dedicated branch and publishing it on orgmode.org/worg-next/ or something. > 2. I sometimes feel hesitant to put a lot of effort into curating and > organizing content on Worg because, like all wikis, that work can easily > be invalidated if others come along later and add content in random > places. Yes, I understand. Worg was a place to gather contributions when the Org users formed a small dedicated group. Org's "community" is larger now, and I think Org should be a place with less textual contents and more links to useful stuff. Like a giant structured FAQ, more than a giant... mess. > One of my goals for this "org-almanac" is to catalog content in a > somewhat canonical way, to avoid the "wiki effect." For this project, > I'd rather have less content that's organized more clearly, than have > lots of content scattered about. Of course, I don't presume to say that > the way I've done it is the best way, and I'm experimenting as I go. > > Anyway, do you have any more thoughts about these issues? I think that your goals for org-almanac resemble the ones I have for Worg: less content, clear structure, make it more maintainable, even collectively. Without sacrificing the current richness, of course. This will be more tangible when I start pushing worg-next/. Thanks, -- Bastien
Re: [PATCH] support colorful blocks display on org-agenda
Hi Stardiviner, stardiviner writes: > I reconsidered this patch, what about make it an minor-mode for Org > Mode and put it in contrib/ directory? WDYT? I suggest using worg/org-hacks.org instead: this describes precisely what it is, a nice hack, isn't it? Days for the "contrib/" directory are counted: before Org 9.5, I will extract it from Org's repository, make it an independant repository on code.orgmode.org and make it available through Org ELPA. So you'd better not add things there. Thanks, -- Bastien
Re: Regarding collapsing blank lines between headlines
Hi Adam, Adam Porter writes: > This is not exactly what you asked for, but here's some code that > ensures blank lines exist between headings and entry content. You could > modify it to remove excess lines without too much trouble. > > https://github.com/alphapapa/unpackaged.el#ensure-blank-lines-between-headings-and-before-contents FWIW, I have added this to worg/org-hacks.org: https://orgmode.org/worg/org-hacks.html Best, -- Bastien
Re: Survey: changing a few default settings for Org 9.4
Hi Adam, Adam Porter writes: > I generally approve of all of these changes. Thanks for sharing your opinion. > However, hiding emphasis and macro markers can make editing text at > the boundaries of emphasized text non-intuitive, which I can imagine > might frustrate some new users, so that should probably be carefully > considered. Interestingly, hiding emphasis and macro markers are the two changes that get the *less* votes, so we probably won't change these. Best, -- Bastien
Re: [PATCH] support colorful blocks display on org-agenda
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Bastien writes: > Hi Stardiviner, > > stardiviner writes: > >> I have got author's permission to add this patch to Org Mode. > > We need it explicitely here on this list. > > Please submit the patch as an inline or attach .patch file. > You just need to go in the modified file, C-x v v and save the patch. > > Even better, as a Git patch. > See https://orgmode.org/worg/org-contribute.html for details. > > Otherwise, it is difficult to understand what the patch does. > > Thanks! Hi, Bastien I reconsidered this patch, what about make it an minor-mode for Org Mode and put it in contrib/ directory? WDYT? - -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 -BEGIN PGP SIGNATURE- iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl5OLsgUHG51bWJjaGls ZEBnbWFpbC5jb20ACgkQG13xyVromsPAfQf/flxeneKlWnxpOm3248vjwz536+Sv V56OBsT/aGoCDqKfF7mmCPH6PIgQUoG5kyV5Mk/tkXb0pLdQ4kUpEE4Rz7Ylq7ev bUq/jWkrlrMUnK7O6y+lttFpCIgITS1nrcrOeWtGyuxaWJJA2/9kSbvLXlZpTfoD vJO2IWdWavuIMGCBBTvgvmgOumiISHGu5UOgXUgLJEqstKnLir+DnHLhK1A9JvPa 2shuD2u1lqXr3AoM9brEm2qV6eLCXY84n6WulxtYhF8Ho83ySDBa16bmh9O7h64+ f7breDStJp415nssyXixIqR+hqKRVH9CnNhQcyjdXwcXk+tlhP6yacqdMw== =PFDC -END PGP SIGNATURE-
Re: [PATCH] Fix ob-python.el initiate session error with py-shell
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jack Kamm writes: > Hi stardiviner, > > "numbch...@gmail.com" writes: > >> Yes, Jack, as Bastien said, you can format my commit, because my home >> network is broken, I'm using Mobile Phone's 4G network to get online. Can't >> get update immediately. > > OK, I've edited the commit message of your patch, and I also fixed the > compilation warning by updating the signature of "(declare-function > py-shell)". > > Commit has now been pushed to master :) > >> And thanks for tips about `python-mode' is deprecated. I didn't know that. >> I will migrate to `python.el'. > > Since python.el is built-in to Emacs, I think that things should > continue to work for python-mode.el users, even if we entirely switch > over to only using python.el. > > The only thing I'm not sure about, is whether the equivalent of > "python-shell-send-region" in python-mode.el will work with shells > started by python.el. If not, this could probably be addressed with a > patch to python-mode.el. > > You could test this by explicitly setting `org-babel-python-mode' to > `python' (it is probably set to `python-mode' on your system, which is > the default when python-mode.el is detected). > > I'll add a TODO for myself to explicitly mark python-mode-related > variables as deprecated. I'm also planning a major update to the Worg > documentation of ob-python when 9.4 comes out, and will mention the > deprecation there as well. Thanks for your work! Jack - -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 -BEGIN PGP SIGNATURE- iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl5OHPIUHG51bWJjaGls ZEBnbWFpbC5jb20ACgkQG13xyVromsMoIAgAupUPheHI9UoqcB7MIAH6qOZoZKfi A7WurI++ioXEUN6rBlGkv/cNA2WsOm7TIjfLq1uXIEHvfgLY4nM+0YQJmPX1XzGr ej+xNO+9sjwrXA83XELM5DcGhat2C3PBE0ANqZIeZxnE1roUOcYVCdIdrPsvrpWC /nSHIEB3fg19lq+QGwr17qXqLsNy/BjytixWclHQz9bmA5Cs9p9jGPDIamrEK+4w 7/1QMXg1B3GUPWrRLUfeMV3hye+btpPZOqVpk1OwVg0AJpp4brI/OvkzOrfDMhA4 fxjB/JE2Ll4hvN+MSJ0wGohMUIvClm9Li6jWsKmC1ZHtAdzn5lkKQ2nspA== =VCww -END PGP SIGNATURE-
Re: Regarding collapsing blank lines between headlines
interesting. i have often wanted blank lines between header and entry content, but only if there is meta stuff there like drawers. On 2/19/20, Adam Porter wrote: > Hi Russell, > > This is not exactly what you asked for, but here's some code that > ensures blank lines exist between headings and entry content. You could > modify it to remove excess lines without too much trouble. > > https://github.com/alphapapa/unpackaged.el#ensure-blank-lines-between-headings-and-before-contents > > > -- The Kafka Pandemic What is misopathy? https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: Regarding collapsing blank lines between headlines
Hi Russell, This is not exactly what you asked for, but here's some code that ensures blank lines exist between headings and entry content. You could modify it to remove excess lines without too much trouble. https://github.com/alphapapa/unpackaged.el#ensure-blank-lines-between-headings-and-before-contents
Re: Survey: changing a few default settings for Org 9.4
Marco Wahl writes: - org-loop-over-headlines-in-active-region => t >>> >>> I vote for => 'start-level. Loop over headlines with same level as the >>> first. >> >> Yes, good suggestion. > > Let's see what others say. I can see how that could be useful, but I feel like it would be less intuitive than looping over all headings in the region. I would be confused by that behavior if I weren't aware of this discussion and the option's settings. So I would vote for t over 'start-level. My two cents. :)
Re: Survey: changing a few default settings for Org 9.4
I generally approve of all of these changes. However, hiding emphasis and macro markers can make editing text at the boundaries of emphasized text non-intuitive, which I can imagine might frustrate some new users, so that should probably be carefully considered. The other changes seem like obvious improvements to me. :) Thanks for your work on this, Bastien!
Re: Possible to exclude/include tags for agenda custom commands?
Hi Bastien, Bastien writes: > Hi Adam, > > Adam Porter writes: > >> https://alphapapa.github.io/org-almanac/ > > this is a very nice list of resources! > > Do you think we can advertize it somewhere on Worg? > > If yes but are unsure *where*, just go ahead with whatever location > seems fine, we can always rearrange Worg's contents later on. Yes, I'd be glad for it to be listed on Worg. Feel free to add it if you like, or I might add it myself after I add a bit more content. I was thinking about working on Worg rather than making yet another resource, but: 1. I saw you mention that you're planning to reorganize Worg's content soon, and I wouldn't want to interfere with that. 2. I sometimes feel hesitant to put a lot of effort into curating and organizing content on Worg because, like all wikis, that work can easily be invalidated if others come along later and add content in random places. One of my goals for this "org-almanac" is to catalog content in a somewhat canonical way, to avoid the "wiki effect." For this project, I'd rather have less content that's organized more clearly, than have lots of content scattered about. Of course, I don't presume to say that the way I've done it is the best way, and I'm experimenting as I go. Anyway, do you have any more thoughts about these issues? Thanks, Adam
Re: Survey: changing a few default settings for Org 9.4
recent org stackoverexchangeflowwhatgever post queries why <* is broken. :) On 2/19/20, Bastien wrote: > Hi Vladimir, > > Vladimir Lomov writes: > >>> I'm tempted to count the number of fingers involved ;) >> >> C-c C-, s --> Ctrl c , s >> < s TAB --> Shift , s TAB >> >> ??? > > I added the smiley to make it clear it was a joke. > >>> Which may not be *that* stupid when considering "fast" typing. >>> But eh, I don't want vimers to come and laugh at us. >> >> How this relate with the topic? > > Well, it relates to the joke. > >> Please, don't take decision so light (because >> some people just ask on (not very well-known) channel about something >> that >> even NOT documented), take in mind that quick solutions most of time are >> troublesome in long living products (programs). > > I would not spend that much time and energy in discussing these > changes if I wasn't taking them seriously. > >> P.S. I wouldn't mention any "number of fingers" or '"fast" typing' >> especially >> when I know that users may use different than QWERTY/QWERTZ/AZERTY >> keyboards >> and even DVORAK layout. > > Typing text is one thing, hitting keybindings is another. > > Some keybindings blend more easily into typing text, others don't. > Even if "convenience" is a subjective notion, it is useful to discuss > how we can improve our collective (although distributed) experience > on these topics. > > I didn't get that part of your email: > > (because some people just ask on (not very well-known) channel about > something that even NOT documented) > > If you can explain it, thanks. > > -- > Bastien > > -- The Kafka Pandemic What is misopathy? https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: [PATCH] Re: org-hide-eading-stars-before-indent-mode
Hi, D writes: > Not quite, both are valid ways to revert hide-leading-stars to it's > original value, with the second (which I picked for the patch) having > the advantage to properly get rid off the buffer-local property again. > The mode itself calls for setting the variable locally to `t' instead of > the original value. Yes, you're right. > I attached the patch, which I hope is the correct format. I'm still a > bit new to this, my apologies if I cause any unnecessary work. It's perfect, applied to master, thanks! -- Bastien
Re: Survey: changing a few default settings for Org 9.4
Hi Vladimir, Vladimir Lomov writes: >> I'm tempted to count the number of fingers involved ;) > > C-c C-, s --> Ctrl c , s > < s TAB --> Shift , s TAB > > ??? I added the smiley to make it clear it was a joke. >> Which may not be *that* stupid when considering "fast" typing. >> But eh, I don't want vimers to come and laugh at us. > > How this relate with the topic? Well, it relates to the joke. > Please, don't take decision so light (because > some people just ask on (not very well-known) channel about something that > even NOT documented), take in mind that quick solutions most of time are > troublesome in long living products (programs). I would not spend that much time and energy in discussing these changes if I wasn't taking them seriously. > P.S. I wouldn't mention any "number of fingers" or '"fast" typing' especially > when I know that users may use different than QWERTY/QWERTZ/AZERTY keyboards > and even DVORAK layout. Typing text is one thing, hitting keybindings is another. Some keybindings blend more easily into typing text, others don't. Even if "convenience" is a subjective notion, it is useful to discuss how we can improve our collective (although distributed) experience on these topics. I didn't get that part of your email: (because some people just ask on (not very well-known) channel about something that even NOT documented) If you can explain it, thanks. -- Bastien
Re: Survey: changing a few default settings for Org 9.4
Hello ** Bastien [2020-02-19 18:24:43 +0100]: > Hi Nicolas, > Nicolas Goaziou writes: >> I don't understand. C-c C-, combination is as fast as Org Tempo: >> >> C-c C-, s : 3 keys >> < s TAB : 3 keys > I'm tempted to count the number of fingers involved ;) C-c C-, s --> Ctrl c , s < s TAB --> Shift , s TAB ??? > Which may not be *that* stupid when considering "fast" typing. > But eh, I don't want vimers to come and laugh at us. How this relate with the topic? Please, don't take decision so light (because some people just ask on (not very well-known) channel about something that even NOT documented), take in mind that quick solutions most of time are troublesome in long living products (programs). [...] P.S. I wouldn't mention any "number of fingers" or '"fast" typing' especially when I know that users may use different than QWERTY/QWERTZ/AZERTY keyboards and even DVORAK layout. --- WBR, Vladimir Lomov -- When a person goes on a diet, the first thing he loses is his temper. signature.asc Description: PGP signature
[PATCH] Re: org-hide-eading-stars-before-indent-mode
Hi! On 19.02.20 22:42, Bastien wrote: > IIUC, it would be "and", not "or": first use > > (setq-local org-hide-leading-stars (default-value 'org-hide-leading-stars)) > > to set org-hide-leading-stars to a temporary value *and* > > (kill-local-variable 'org-hide-leading-stars) > > to restore the global value. Not quite, both are valid ways to revert hide-leading-stars to it's original value, with the second (which I picked for the patch) having the advantage to properly get rid off the buffer-local property again. The mode itself calls for setting the variable locally to `t' instead of the original value. I attached the patch, which I hope is the correct format. I'm still a bit new to this, my apologies if I cause any unnecessary work. Regards, D. >From d3390eb442bccef476fa2514d4078b9f8e9d978a Mon Sep 17 00:00:00 2001 From: "D. Williams" Date: Wed, 19 Feb 2020 23:50:48 +0100 Subject: [PATCH] org-indent.el: Deprecate `org-hide-leading-stars-before-indent-mode' * lisp/org-indent.el (org-indent-mode): Make `org-hide-leading-stars' buffer local and revert it back to it's global value when exiting the mode without storing it's global value manually. (org-hide-leading-stars-before-indent-mode): Remove declaration. This commit implements my suggestion from the mailing list (https://lists.gnu.org/archive/html/emacs-orgmode/2020-02/msg00759.html) to rely on Emacs' native mechanisms for restoring a buffer-local variable to it's global default value instead of storing the global value in a temporary variable (in this case: `org-hide-leading-stars-before-indent-mode'). TINYCHANGE --- lisp/org-indent.el | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/lisp/org-indent.el b/lisp/org-indent.el index c136a75bd..73b077965 100644 --- a/lisp/org-indent.el +++ b/lisp/org-indent.el @@ -71,8 +71,6 @@ Delay used when the buffer to initialize isn't current.") (defvar org-indent--initial-marker nil "Position of initialization before interrupt. This is used locally in each buffer being initialized.") -(defvar org-hide-leading-stars-before-indent-mode nil - "Used locally.") (defvar org-indent-modified-headline-flag nil "Non-nil means the last deletion operated on a headline. It is modified by `org-indent-notify-modified-headline'.") @@ -183,8 +181,6 @@ during idle time." (or (eq org-adapt-indentation 'headline-data) (setq-local org-adapt-indentation nil))) (when org-indent-mode-turns-on-hiding-stars - (setq-local org-hide-leading-stars-before-indent-mode - org-hide-leading-stars) (setq-local org-hide-leading-stars t)) (org-indent--compute-prefixes) (if (boundp 'filter-buffer-substring-functions) @@ -216,9 +212,8 @@ during idle time." (delq (current-buffer) org-indent-agentized-buffers)) (when (markerp org-indent--initial-marker) (set-marker org-indent--initial-marker nil)) -(when (boundp 'org-hide-leading-stars-before-indent-mode) - (setq-local org-hide-leading-stars - org-hide-leading-stars-before-indent-mode)) +(when (local-variable-p 'org-hide-leading-stars) + (kill-local-variable 'org-hide-leading-stars)) (if (boundp 'filter-buffer-substring-functions) (remove-hook 'filter-buffer-substring-functions (lambda (fun start end delete) -- 2.24.1
Re: Survey: changing a few default settings for Org 9.4
in my old version at least, pretty entities talks about utf-8 and \name.
and the option under discussion does not mention pretty entitities.
dunno abou the implementation or any changes since my version,
but i am arguing from empiricism. the errors are all over the web. :)
On 2/19/20, Bastien wrote:
> Hi Samuel and Marcin,
>
> Marcin Borkowski writes:
>
>> There is already an option for that (~org-use-sub-superscripts~).
>> Changing the default to `{} seems a great idea.
>
> I didn't identify this possible change -- other ideas for new defaults
> are welcome, of course.
>
> I'm not sure about this one: since org-pretty-entities is nil by
> default, the default for org-use-sub-superscripts only affects the
> user when he toggle super- and subscript fontification with M-x
> org-toggle-pretty-entities RET -- or the default really a problem?
>
> I've slightly enhanced the documentation in this area, though.
>
> --
> Bastien
>
--
The Kafka Pandemic
What is misopathy?
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: [PATCH] Skip entries with no ID when updating ID locations
Bastien writes: > Hi Eric, > > Eric Abrahamsen writes: > >> Would the attached patch be acceptable? It's no big deal, just skips >> entries with no ID property when updating all ID locations. I couldn't >> figure out why I had several thousand "Duplicate ID "nil"" warnings in >> the *Messages* buffer after updating ID locations. > > A welcome enhancement - applied, thanks! Cool, thanks.
Re: org-hide-leading-stars-before-indent-mode
Hi, D writes: > 1) Wouldn't it be clearer to use defvar-local for > org-hide-leading-stars-before-indent-mode and replace the docstring with > something like "Holds the original value of `org-hide-leading-stars' > before Org indent." Yes, patch welcome. > 2) Considering that org-hide-leading-stars is global by default, > wouldn't it be even better to dispose of the temp variable entirely? > One could either use (kill-local-variable 'org-hide-leading-stars) or > (setq-local org-hide-leading-stars (default-value > 'org-hide-leading-stars)) for the same effect. IIUC, it would be "and", not "or": first use (setq-local org-hide-leading-stars (default-value 'org-hide-leading-stars)) to set org-hide-leading-stars to a temporary value *and* (kill-local-variable 'org-hide-leading-stars) to restore the global value. If you can make something that works, please send a patch. Thanks! -- Bastien
Re: [PATCH] Skip entries with no ID when updating ID locations
Hi Eric, Eric Abrahamsen writes: > Would the attached patch be acceptable? It's no big deal, just skips > entries with no ID property when updating all ID locations. I couldn't > figure out why I had several thousand "Duplicate ID "nil"" warnings in > the *Messages* buffer after updating ID locations. A welcome enhancement - applied, thanks! -- Bastien
Re: Survey: changing a few default settings for Org 9.4
Hi Samuel and Marcin,
Marcin Borkowski writes:
> There is already an option for that (~org-use-sub-superscripts~).
> Changing the default to `{} seems a great idea.
I didn't identify this possible change -- other ideas for new defaults
are welcome, of course.
I'm not sure about this one: since org-pretty-entities is nil by
default, the default for org-use-sub-superscripts only affects the
user when he toggle super- and subscript fontification with M-x
org-toggle-pretty-entities RET -- or the default really a problem?
I've slightly enhanced the documentation in this area, though.
--
Bastien
Re: Bug or not a bug? dot expansion in ob-shell
Hi Diego, Diego Zamboni writes: > I'm late to the discussion so I apologize in advance, but this fix > seems counterintuitive to me. In my mind, for any shell code: > > - Return value: exit code of the last command > - Output: whatever the commands print Yes, that's what is *now* possible if you set ob-shell-return-value-is-exit-status to t. Unless I miss something, it was not possible before today. #+begin_src shell echo Hello! #+end_src would simply return "Hello!" as a return. No exit code was *never* output. > So to me, it's intuitive that =:exports value= would return the exit > code of the last command, and =:exports output= would produce the > output of the commands. I don't understand why a new option is > needed. ... because it was not the case before. Or maybe *I* miss something. Can you show me something that was working before and that is not anymore? Thanks, -- Bastien
[PATCH] Skip entries with no ID when updating ID locations
Hi all, Would the attached patch be acceptable? It's no big deal, just skips entries with no ID property when updating all ID locations. I couldn't figure out why I had several thousand "Duplicate ID "nil"" warnings in the *Messages* buffer after updating ID locations. Thanks, Eric >From d3262aafe1afef3875de83ff46096d54c5c086fe Mon Sep 17 00:00:00 2001 From: Eric Abrahamsen Date: Wed, 19 Feb 2020 13:23:40 -0800 Subject: [PATCH] Skip entries with no ID when updating ID locations * lisp/org-id.el (org-id-update-id-locations): Saves a little chatter about duplicate "nil" IDs. --- lisp/org-id.el | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/lisp/org-id.el b/lisp/org-id.el index 91142917a..369b494ab 100644 --- a/lisp/org-id.el +++ b/lisp/org-id.el @@ -503,10 +503,11 @@ When FILES is given, scan also these files." i nfiles file)) (when (file-exists-p file) (insert-file-contents file nil nil nil 'replace) - (setq ids (org-map-entries - (lambda () - (org-entry-get (point) "ID")) - "ID<>\"\"")) + (setq ids (delq nil + (org-map-entries + (lambda () + (org-entry-get (point) "ID")) + "ID<>\"\""))) (dolist (id ids) (if (member id seen-ids) (progn -- 2.25.1
org-hide-leading-stars-before-indent-mode
Hi all, I have come across this rather strange variable in org-indent, and was wondering if someone could add a bit of documentation to clarify what it actually does. Currently, the variable org-hide-leading-stars-before-indent-mode is only documented as "used locally". However, upon closer inspection, the first thing I noticed was that it is actually declared using "defvar" instead of "defvar-local", which in turn would render the docstring redundant as it would automatically append the message "this variable becomes buffer local when set". Is this intentional? Looking at the code it seems to be a throwaway variable remembering the initial value of org-hide-leading-stars, restoring it buffer-locally when indent-mode is turned off. This leaves two questions for me: 1) Wouldn't it be clearer to use defvar-local for org-hide-leading-stars-before-indent-mode and replace the docstring with something like "Holds the original value of `org-hide-leading-stars' before Org indent." 2) Considering that org-hide-leading-stars is global by default, wouldn't it be even better to dispose of the temp variable entirely? One could either use (kill-local-variable 'org-hide-leading-stars) or (setq-local org-hide-leading-stars (default-value 'org-hide-leading-stars)) for the same effect. Cheers, D.
Re: Survey: changing a few default settings for Org 9.4
Hi Marco, Marco Wahl writes: > Fair enough. I tried to implement the sentence "When after the headline > text, kill the tags" from the documentation for org-special-ctrl-k, > which I interpreted as kill _all_ tags. Just to make clear my decision > for the patch. Yes, I understand - but the implicit here is "When after the headline text (and before the tags), kill the tags", which I think is intuitive enough. >> As for the other patch, I think it's important to explain that the >> whole subtree will be killed, even if not visible -- that's the whole >> point of this variable after all. > > AFAICS the kill of a folded (invisible) subtree is also performed > without having set org-special-ctrl-k. So I'd rather say that there is > no need for pointing out that behavior in the documentation. Mhh... you're right, I've updated the docstring slightly differently. Thanks for clarifying, -- Bastien
Re: Bug or not a bug? dot expansion in ob-shell
to stir the pot:
speaking for myself, i only wanted the output, and never the error
mechanism, and my attempts to get output reliably ended up in my
habitually putting in every shell block this boilerplate:
===
{
the code i actually want
} 2>&1
:
===
--
The Kafka Pandemic
What is misopathy?
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: Survey: changing a few default settings for Org 9.4
On 2020-02-19, at 21:02, Samuel Wales wrote:
> just an idea but changing the subscript and superscript export feature
> to ‘{}’ would reduce accidental invocation. i have seen solecistic
> subscripts on websites created with org (probably by experts who
> babelize their .emacs!), and on this ml :).
>
> i have seen it used accidentally more than i have seen it used for its
> intended purpose. {} seems more unambiguous.
>
> that would, of course, be an issue for those who already have a lot of
> the short form in their technical and scientific papers.
>
> so there would have to be a nice regexp fixer. or a warning.
+1!!!
There is already an option for that (~org-use-sub-superscripts~).
Changing the default to `{} seems a great idea.
Best,
--
Marcin Borkowski
http://mbork.pl
Re: Survey: changing a few default settings for Org 9.4
just an idea but changing the subscript and superscript export feature
to ‘{}’ would reduce accidental invocation. i have seen solecistic
subscripts on websites created with org (probably by experts who
babelize their .emacs!), and on this ml :).
i have seen it used accidentally more than i have seen it used for its
intended purpose. {} seems more unambiguous.
that would, of course, be an issue for those who already have a lot of
the short form in their technical and scientific papers.
so there would have to be a nice regexp fixer. or a warning.
--
The Kafka Pandemic
What is misopathy?
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: Bug or not a bug? dot expansion in ob-shell
I'm late to the discussion so I apologize in advance, but this fix seems counterintuitive to me. In my mind, for any shell code: - Return value: exit code of the last command - Output: whatever the commands print So to me, it's intuitive that =:exports value= would return the exit code of the last command, and =:exports output= would produce the output of the commands. I don't understand why a new option is needed. Am I missing something? --Diego On Wed, Feb 19, 2020 at 5:00 PM Bastien wrote: > I've implemented the suggestion I made in master: > > New option ~ob-shell-return-value-is-exit-status~ > > When set to =t=, consider the return value of a shell source code > block is the exit status of its last command. > > The default for this option is =nil=, i.e. the return value of a shell > block is the output of the commands. > > You can turn this on individual blocks by setting the header argument > =:value-is-exit-status= to =t=. > > Please test and let me know if it works. > > Thanks for bringing this up! > > -- > Bastien > >
Re: Survey: changing a few default settings for Org 9.4
Hi Bastien and all, >> Subject: [PATCH 1/2] org: Fix corner case for org-kill-line >> >> * lisp/org.el (org-kill-line): Kill _all_ tags when the cursor is on the >> tags part. > > There is a problem with this patch: when on a empty heading with tags, > killing the tags will let the cursor back right after the last "*". > Not a big deal in most headlines, but when on the first headline, this > leads to an error. Okay. Thanks for this finding. > I think org-kill-line should not try to do too much, and kill only > parts of the tags when the cursor is in the middle of tags is the > right thing to do. Fair enough. I tried to implement the sentence "When after the headline text, kill the tags" from the documentation for org-special-ctrl-k, which I interpreted as kill _all_ tags. Just to make clear my decision for the patch. > As for the other patch, I think it's important to explain that the > whole subtree will be killed, even if not visible -- that's the whole > point of this variable after all. AFAICS the kill of a folded (invisible) subtree is also performed without having set org-special-ctrl-k. So I'd rather say that there is no need for pointing out that behavior in the documentation. > So I'm sorry but these patches can't make it. > > Thanks anyway! You are welcome. That's fine with me. Ciao!
Re: org link to OCaml comment
Hello, Alan Schmitt writes: > I understand, and I can be careful (and easily fix the link if needed). > If `org-store-link' could do it for me, that would be perfect. I pushed some changes to `org-store-link' in order to fix this. Please report if there is anything wrong. Regards, -- Nicolas Goaziou
Re: Survey: changing a few default settings for Org 9.4
Hi Nicolas, Nicolas Goaziou writes: > I don't understand. C-c C-, combination is as fast as Org Tempo: > > C-c C-, s : 3 keys > < s TAB : 3 keys I'm tempted to count the number of fingers involved ;) Which may not be *that* stupid when considering "fast" typing. But eh, I don't want vimers to come and laugh at us. > We could even add an "expert" interface that would not display the > help menu for an even faster C-c C-, experience. That's a good idea, yes. I can even imagine that M-TAB can expand <* using org-insert-structure-template only, and they we don't have the problem of requiring this problematic tempo library. >> M-x customize-option RET org-modules seems okay to me. > > Then you may belong to the happy few that happen to find Customize > interface "okay". :> Well, no, I'm not one of these happy few... > I was speaking about "init.el" hacking. One must be cautious when > setting Org modules: it requires to be set before Org is loaded. Ok, fair point. > Also, my question is still open: is there any strong reason to provide, > out of the box, two template mechanisms in Org? This is genuine > question. No, there is no good reason for two template mechanism, and if we can rely on org-insert-structure-template only, while still being able to complete <* at the beginning of the line, that'd be perfect to me. > In any case, I don't think it is just a matter of personal preference, > like defcustoms. There should be some clear design decision behind the > answer. I get your point. What would you think of this idea: (1) only one function for inserting templates, but callable in two different ways, one interactive (C-c C-, possibly with expert mode) and one by just typing and hitting M-TAB. In a word: I just want to add a simpler completion mechanism to the current template insertion mechanism. If we can get rid of org-tempo from Org's core, that's even better. > Let's un-bundle this issue from the rest of the poll, and think > about it separately. Agreed. > H. This is another topic. Yes, let's raise this issue later on. Thanks, -- Bastien
Re: Item descriptions get surrounded by wrong curly braces in LaTeX export
On Wednesday, 19 Feb 2020 at 18:15, Bastien wrote: >> The problem, I think, seems to have been caused by commit 5acf4d4692 > > Indeed, it should be fixed now, thanks! Confirmed! Many thanks. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-354-g9d5880
Re: Item descriptions get surrounded by wrong curly braces in LaTeX export
Hi Eric and Joon, "Fraga, Eric" writes: > The problem, I think, seems to have been caused by commit 5acf4d4692 Indeed, it should be fixed now, thanks! -- Bastien
Re: Survey: changing a few default settings for Org 9.4
Hi Detlef, if you can, please add your vote to the poll: https://framadate.org/Ufc42EVxS2jO1Ajz This is not to say that qualitative comments such as Matt's one won't be taken into account, I read them carefull, especially when they come from (very-)long-time users, but I hope the poll can be representative enough. Thanks, -- Bastien
Re: Survey: changing a few default settings for Org 9.4
Hi Joost, thanks for your feedback. If you can, please add your vote to the poll, so that we collect all votes in a single place. Thanks, -- Bastien
Re: Survey: changing a few default settings for Org 9.4
Am Wed, 19 Feb 2020 09:41:21 -0600 schrieb Matthew Lundin : > Bastien writes: > > > - org-fontify-done-headline => t > > > > This is useful to visualize done headlines and can be easily > > turned off, while not being easily discovered for Org newcomers. > > I find this a bit visually distracting, but that's likely because I've > used Org mode in the "old school" way for so long. So no strong > opinions on this one. Same here. No strong opinion. > > > - org-hide-emphasis-markers => t > > - org-hide-macro-markers => t > > > > The two changes proposed above will probably trigger some > > reactions as they touch something very sensitive: whether Org > > should try to be "too clever" at making things invisible. I am all > > for letting Org newcomers enjoying these visual enhancements, while > > letting experts turning them off if needed. > > I have a few concerns about this. I believe that markup syntax, as a > rule, should be visible. Most markdown editors do not hide markup by > default. I realize that there are some exceptions in Org (e.g., > links). But editing around the invisible boundaries of links can be > in Org can be fussy (sometimes I have to do M-x visible-mode when > editing near the edges of links). So I'd recommend not changing the > default here, especially for emphasis markers. > I really dislike invisible markup as default. Org is a markup "language", not a word-processor. Even links feel more consistent when visible. So fully agree with Matt again. > > - org-allow-promoting-top-level-subtree => t > > > > With the current default of nil, an error is thrown when the user > > tries to promote a top level subtree. The new default setting > > would let users convert the top level heading to a commented > > heading. > > From my point of view, this is too destructive a default. I think it > makes it too easy accidentally to turn important TODO headlines into > commented lines (which will be buried in another entry). If I wanted > to change a first level headline to a comment, it would only take two > keystrokes (C-d #). Forcing users to type this explicitly seems > preferable to creating a risk that users will accidentally bury/lose > first-level headlines as comments in another entry. And again a simple +1. Detlef > > Matt >
Re: Exporting comments to comments?
On Wednesday, 19 Feb 2020 at 11:04, Allen S. Rout wrote:
> I thought about making a block of a 'comment' type, but of course all
I use drawers for this functionality. By default, I do not export
drawers (#+options: d:nil) but I can turn this on and then process
specific drawers using filters, as in:
#+begin_src elisp
(setq org-latex-format-drawer-function
(lambda (name contents)
(cond ((string= name "solution")
(format
"\\begin{mdframed}\\paragraph{Solution.} %s\\end{mdframed}"
contents))
(t (format "\\textbf{%s}: %s" name contents)
#+end_src
which I use for :solution: drawers when preparing courseworks/exams. If
you want to ignore all other drawers except specific ones, have no
action in the =t= clause of the =cond=.
Using this right now preparing a coursework for my students... ;-)
--
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-350-g39f1c1
Re: Survey: changing a few default settings for Org 9.4
On Wed, Feb 19 2020, Matthew Lundin wrote: - org-hide-emphasis-markers => t - org-hide-macro-markers => t [...] I have a few concerns about this. I believe that markup syntax, as a rule, should be visible. Most markdown editors do not hide markup by default. I realize that there are some exceptions in Org (e.g., links). But editing around the invisible boundaries of links can be in Org can be fussy (sometimes I have to do M-x visible-mode when editing near the edges of links). So I'd recommend not changing the default here, especially for emphasis markers. I was going to say the same thing. I set `org-hide-emphasis-markers` to t when I started out using Org, but at some point changed it to `nil` because editing at the beginning/end of words in emphasis markers was just too unpredictable. Same with links, BTW. What I'm wondering, though, is why Org doesn't make hidden markup visible when the cursor moves into it. `prettify-symbols-mode` can do this, and AUCTeX does it by default (IINM) in folded macros and preview snippets, so it's definitely doable. So my suggestion would be to keep it off unless/until such make-visible-at-point functionality is implemented. -- Joost Kremers Life has its moments
Re: Item descriptions get surrounded by wrong curly braces in LaTeX export
The problem, I think, seems to have been caused by commit 5acf4d4692 which addressed problems with check boxes. I'm not sure how to fix it. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-350-g39f1c1
Exporting comments to comments?
I'd like to write an org-mode document, export it to markdown, and have
comments exist in the markdown.
I feel like I'm thinking about the process incorrectly, and it's hard to
search around because the discussions around 'org-mode comments' focus
on org data for which authors would like to _prevent_ export.
I saw some old conversations about making links to the hacked-in
comment: URI scheme, but that seemed quite hackish indeed.
I thought about making a block of a 'comment' type, but of course all
the workflow for that is, again, focused on either preventing its export
in the first place, or making sure that it's exported in a visible
manner in the output. ("I want to print the comments in my LaTeX..").
So... am I missing something obvious? Anyone else trying something similar?
- Allen S. Rout
Re: [PATCH] Fix ob-python.el initiate session error with py-shell
Hi Jack, Jack Kamm writes: > I'll add a TODO for myself to explicitly mark python-mode-related > variables as deprecated. I'm also planning a major update to the Worg > documentation of ob-python when 9.4 comes out, and will mention the > deprecation there as well. Worg needs more love - thanks for taking care of this! -- Bastien
Re: ICS agenda export exceeds max-specpdl-size probably because of org-depend (org-edna same?)
Hi Karl, Karl Voit writes: > A couple days ago, the issue re-appeared (with org-depend being > active again). To me, this is a clear indicator, that the issue is > content-related and not config/binary-related: Can you bisect and deduce what part of your contents is producing this? When you have a clue, could you also bisect and see what change in Org introduced this problem for the problematic contents? Such issues are difficult to reproduce and track outside your files. Thanks! -- Bastien
Re: Bug or not a bug? dot expansion in ob-shell
I've implemented the suggestion I made in master: New option ~ob-shell-return-value-is-exit-status~ When set to =t=, consider the return value of a shell source code block is the exit status of its last command. The default for this option is =nil=, i.e. the return value of a shell block is the output of the commands. You can turn this on individual blocks by setting the header argument =:value-is-exit-status= to =t=. Please test and let me know if it works. Thanks for bringing this up! -- Bastien
Re: Item descriptions get surrounded by wrong curly braces in LaTeX export
On Tuesday, 18 Feb 2020 at 00:50, Joon Ro wrote:
> Hi,
>
> I noticed that in LaTeX export, descriptions in description lists are
> surrounded by {} instead of [] in LaTeX export, making them not
> correctly rendered.
I can confirm this with the latest version of org from git. The outcome
is not what is desired nor what was previously the case.
--
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-350-g39f1c1
Re: ICS agenda export exceeds max-specpdl-size probably because of org-depend (org-edna same?)
Hi Bastien, * Bastien wrote: > Hi Karl, > > did you manage to fix this one? > > I read "Property drawers allowed before first headline" in > etc/ORG-NEWS from the master branch: > > Property drawers are now allowed before the first headline. > > Org mode is moving more towards making things before the first > headline behave just as if it was at outline level 0. Inheritance > for properties will work also for this level. In other words: > defining things in a property drawer before the first headline will > make them "inheritable" for all headlines. > > I guess your problem might be related to this new behavior. A couple days ago, the issue re-appeared (with org-depend being active again). To me, this is a clear indicator, that the issue is content-related and not config/binary-related: Emacs 26.3: : emacs --batch --load /home/vk/.emacs.d/init.el --eval '(progn (my-export-agenda))' : [...] : Garbage collecting... : Garbage collecting...done : Garbage collecting... : Garbage collecting...done : Garbage collecting... : Garbage collecting...done : Position saved to mark ring, go back with ‘C-c &’. : Position saved to mark ring, go back with ‘C-c &’. : Position saved to mark ring, go back with ‘C-c &’. : Position saved to mark ring, go back with ‘C-c &’. : Position saved to mark ring, go back with ‘C-c &’. : Position saved to mark ring, go back with ‘C-c &’. : Garbage collecting... : Garbage collecting...done : Variable binding depth exceeds max-specpdl-size : emacs --batch --load /home/vk/.emacs.d/init.el --eval 8029,80s user 4,30s system 99% cpu 2:14:02,16 total Yes, that's over two hours. With Emacs 27.0.50, the same job is currently running for over five hours. I guess this will end with an error as well some day. -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: [PATCH] Fix ob-python.el initiate session error with py-shell
Hi stardiviner, "numbch...@gmail.com" writes: > Yes, Jack, as Bastien said, you can format my commit, because my home > network is broken, I'm using Mobile Phone's 4G network to get online. Can't > get update immediately. OK, I've edited the commit message of your patch, and I also fixed the compilation warning by updating the signature of "(declare-function py-shell)". Commit has now been pushed to master :) > And thanks for tips about `python-mode' is deprecated. I didn't know that. > I will migrate to `python.el'. Since python.el is built-in to Emacs, I think that things should continue to work for python-mode.el users, even if we entirely switch over to only using python.el. The only thing I'm not sure about, is whether the equivalent of "python-shell-send-region" in python-mode.el will work with shells started by python.el. If not, this could probably be addressed with a patch to python-mode.el. You could test this by explicitly setting `org-babel-python-mode' to `python' (it is probably set to `python-mode' on your system, which is the default when python-mode.el is detected). I'll add a TODO for myself to explicitly mark python-mode-related variables as deprecated. I'm also planning a major update to the Worg documentation of ob-python when 9.4 comes out, and will mention the deprecation there as well.
Re: [PATCH] Re: ob-clojure.el: Add ClojureScript interface
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Bastien writes: > Hi stardiviner, > > stardiviner writes: > >> I tested your method, true. And I also pulled that latest ob-clojure.el >> changes. >> Works great, I like this new method more. Thanks for your >> improvement. > > Thanks for your feedback. > > Also, you may have noted that the code for Clojure sessions has been > removed - I could not make it work, even in previous versions. Yes, I always check related changes on Org Mode master branch source code. > > If you know sesman/cider better than I do and can propose to handle > sesman/cider sessions correctly, please go ahead. > > By "correctly" I mean requesting the launch of a (sibling?) nREPL > process buffer when :session is set to a string. Actually I'm not very familiar with CIDER, but I want to take a try. :) > >> The clojurescript support has a ~:target~ header argument to tell CIDER this >> is a >> clojurescript code, I don't know CIDER internal much, but CIDER eval should >> eval >> in a ClojureScript corresponding REPL. > > Yes, what I meant was that for now ":target cljs" won't let you start > a nREPL unless you are in a ClojureScript project. > > cider-jack-in-cljs will ask for the cljs method (figwheel-main, etc.) > but if your org file is in, e.g., an empty directory, there is no such > cljs configuration file. I agree. - -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 -BEGIN PGP SIGNATURE- iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl5NWYoUHG51bWJjaGls ZEBnbWFpbC5jb20ACgkQG13xyVromsNpkggAtMIWaYdp6nJrNw820X8BZaL4luW4 hZeBf7YJaomopWZK5ToGquGMVTCsPuvxKtSBwlM00WEaklDfmDN6C50aqDvyVesk E+emQ4rF8a2A0LfvUw4CwoRLaqoa9gJUzGzwWFuz//HY8DHkl2n2jbTaLDLuzlOT laAFODwzGHbJlm/MFayKds+jLMLP95F5D+6G6ZPKitfnfyurAwp9OGnI9G63w9Ye LVD0Yqcr3jLUgHJfSSaUAny8DV9DOlvaVez1AZQosc//PER5DqxXHeMhaLMSNEGB RI7W6ufOfSRT0L4gQ3H9W4X34Kt28+Aoj2wGvx2q4niI9pxEkW1kLzpF2w== =LNjE -END PGP SIGNATURE-
Re: Survey: changing a few default settings for Org 9.4
Bastien writes: > - org-fontify-done-headline => t > > This is useful to visualize done headlines and can be easily turned > off, while not being easily discovered for Org newcomers. I find this a bit visually distracting, but that's likely because I've used Org mode in the "old school" way for so long. So no strong opinions on this one. > - org-hide-emphasis-markers => t > - org-hide-macro-markers => t > > The two changes proposed above will probably trigger some reactions > as they touch something very sensitive: whether Org should try to be > "too clever" at making things invisible. I am all for letting Org > newcomers enjoying these visual enhancements, while letting experts > turning them off if needed. I have a few concerns about this. I believe that markup syntax, as a rule, should be visible. Most markdown editors do not hide markup by default. I realize that there are some exceptions in Org (e.g., links). But editing around the invisible boundaries of links can be in Org can be fussy (sometimes I have to do M-x visible-mode when editing near the edges of links). So I'd recommend not changing the default here, especially for emphasis markers. > - org-allow-promoting-top-level-subtree => t > > With the current default of nil, an error is thrown when the user > tries to promote a top level subtree. The new default setting would > let users convert the top level heading to a commented heading. >From my point of view, this is too destructive a default. I think it makes it too easy accidentally to turn important TODO headlines into commented lines (which will be buried in another entry). If I wanted to change a first level headline to a comment, it would only take two keystrokes (C-d #). Forcing users to type this explicitly seems preferable to creating a risk that users will accidentally bury/lose first-level headlines as comments in another entry. Matt
Re: Survey: changing a few default settings for Org 9.4
Hi Bastien - comments in-line below Bastien writes: > Hi Tim, > > Tim Cross writes: > >> I agree 100%. We have already gone through this pain and as has been >> pointed out numerous times, the 'new' approach has significant benefits >> over the old > old habits, but once done the new version works fine. > > Point taken. But as I said, I think both approaches fit different use > cases. > > So my question is rather: why would it be so bad to enable org-tempo > expansion by default? Well I'm not convinced there are two different use cases. The number of keystrokes required to insert a template is the same for both approaches and with the non-tempo version, you can even bind it to a different key with fewer keystrokes if you want. I have also had issues in the past with the tab based expansion and the other completion setup I had (though that was probably my mis-configuration!). I also think having 2 different template expansion solutions will result in confusion, especially for new users. Out of the box, I think it makes sense to have a clear one way to do it. This can always be changed by those who really want to (this is emacs after all). I also don't think tempo was a good choice. I used it for many years and while it is quite powerful, writing and debugging new templates is a pain. It is pat of the reason other templating solutions, like yasnippet, came into existence. I would not be surprised if we don't see increased messages and bug reports as people try to fix/debug modified or homebrew tempo templates. A better solution would probably have been to provide examples of yasnippet templates as this is a common templating system, bundled with many popular 'canned' configs like spacemacs, purcell, prelude etc. > > When simply use, it just allows <* expansion. > >> I also think Nicolas' point that adding (require 'org-tempo) is a lot >> more trivial than removing it from the list of loaded modules. > > Yes, I somehow agree, but yet: the poll so far seems to show that most > users want it back (10 on 15, as the moment, two votes against.) > > Org is not poll-driven software, but this says something that we might > want to listen to. > The problem with having a poll is I suspect many respondents will be long-term users who were use to the original approach. I'm not sure how many new users actually have any issue with the C-c C-, style and the old users who prefer the old approach have already added (require 'org-tempo) to their setup, so are not really affected by the default change. IMO changing defaults is about new uses more than existing users. However, you cannot poll future users. For me, I voted based on what I thought would have been best for me when I first started using org rather than what I want now. (even though I will have to update my config because of some of these changes if they occur). To some extent, defaults should be about creating the safest envrionment with the fewest 'surprises' for new users - one reason I voted against the 'looping' defaults - these seem like a feature which more experienced users may want, but possibly dangerous or confusing for new users. >> The other poinit is that while tempo has been around for years, it is >> not the easiest templating solution to use, especially for those >> unfamiliar with it who may want to add their own tempo templates. Other >> templating solutions, like yasnippets, are likely much easier for new >> users to adopt than tempo. > > In its basic usage, <* expansion seems very simple to me. > > I'm all for not enable org-tempo by default iff we can allow expansion > of <* strings at the beginning of the line. I don't actually get why the old <* is 'simpler'. They both seem as simple to me and I find I really like the ease of wrapping a region in a block. I'd be happy to have expansion on <* if I could also have region wrapping! -- Tim Cross
Re: Survey: changing a few default settings for Org 9.4
Hello, Bastien writes: > Well, let's agree to disagree on this one. > > org-tempo and C-c C- fill two different use cases: the first one for > fast block insertion while typing, the second one for e.g. when the > region is selected. I don't understand. C-c C-, combination is as fast as Org Tempo: C-c C-, s : 3 keys < s TAB : 3 keys I can agree to disagree, but I don't buy the "fast block insertion while typing" argument: they are as fast. We could even add an "expert" interface that would not display the help menu for an even faster C-c C-, experience. And, about the "while typing" part, C-c C-, can be used anywhere amidst a line. One true argument in favor of Org Tempo, however, is its extensibility. IIRC, it can also insert non-block templates, e.g., "#+include:", whereas C-c C-, cannot. Org has built-in completion for these, tho. > M-x customize-option RET org-modules seems okay to me. Then you may belong to the happy few that happen to find Customize interface "okay". :> I was speaking about "init.el" hacking. One must be cautious when setting Org modules: it requires to be set before Org is loaded. >> By the way, this does not belong to the same category as other >> defcustoms discussed. This is only tangential to "how does Org should >> look and feel by default". It relates to: should Org provide multiple >> snippet extensions, knowing this is not a central feature, and Org is >> often seen as bloated by Emacs devs? I don't think so, no matter how >> useful this feature can be for some users. > > I'll be more receptive to this argument when animate-birthday-present > is not in Emacs's core anymore :) That's true. But I think they do have a point, though. Also, my question is still open: is there any strong reason to provide, out of the box, two template mechanisms in Org? This is genuine question. In any case, I don't think it is just a matter of personal preference, like defcustoms. There should be some clear design decision behind the answer. Let's un-bundle this issue from the rest of the poll, and think about it separately. > That said, I'm receptive to the idea that Org could be more focused to > its core functionalities. E.g., I think we could be more minimalistic > about the ol-* and ox-* libraries in Org. H. This is another topic. "ox-" are fine, IMO, even though I'm not sure about the health of "ox-odt" these days. "ol-*" libraries make sense as long as the suffix is bundled with Emacs. E.g.,"ol-eww" is fine, but "ol-w3m" could be an external module. A real issue, however, lies within "ob-*". Many of them require libraries external to Emacs. There's a running bug report about it, IIRC. We may not ship them with Emacs. But, again, this is another topic. Regards, -- Nicolas Goaziou
Re: Bug or not a bug? dot expansion in ob-shell
On Wednesday, 19 Feb 2020 at 14:43, Bastien wrote:
> Note that currently (9.3) we have this:
[...]
> ... so the default today is not even to consider "the last command",
> but the output of all commands.
Maybe, if you wish to get version 9.4 out, the best approach would be to
fix that one outlier case ("." giving "0") for now and later handle
value/output distinction properly (should it be desired, of course)?
--
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-350-g39f1c1
Re: Bug or not a bug? dot expansion in ob-shell
Hi Eric, "Fraga, Eric" writes: > On Wednesday, 19 Feb 2020 at 14:00, Bastien wrote: >> Anyway, I don't have yet a clue on how to add this new option. I'll >> leave it to Eric first (if he has time) then look at it later this >> week. > > Time is an issue (middle of teaching term). More importantly, my > elisp-fu is not necessarily up to the level required. It would be best > if somebody up to speed with org babel attempt this. I will have a look. > In any case, it would be interesting to know if people do depend on > value being somehow the output of the last command in a shell > script. I'd never even considered that possibility, at least not > consciously! Note that currently (9.3) we have this: #+begin_src shell echo "Hello!" echo "What?" #+end_src #+RESULTS: | Hello! | | What? | ... so the default today is not even to consider "the last command", but the output of all commands. Have a nice week, -- Bastien
Re: Survey: changing a few default settings for Org 9.4
Hi Marco, Marco Wahl writes: >> Can you propose a patch against the maint branch for the fixes above? > > Sure. See the attachments. Thanks... > From 49b00d2cf7ca4b8484e0a9679b39b62873ee30b6 Mon Sep 17 00:00:00 2001 > From: Marco Wahl > Date: Wed, 19 Feb 2020 13:48:01 +0100 > Subject: [PATCH 1/2] org: Fix corner case for org-kill-line > > * lisp/org.el (org-kill-line): Kill _all_ tags when the cursor is on the tags > part. There is a problem with this patch: when on a empty heading with tags, killing the tags will let the cursor back right after the last "*". Not a big deal in most headlines, but when on the first headline, this leads to an error. I think org-kill-line should not try to do too much, and kill only parts of the tags when the cursor is in the middle of tags is the right thing to do. As for the other patch, I think it's important to explain that the whole subtree will be killed, even if not visible -- that's the whole point of this variable after all. So I'm sorry but these patches can't make it. Thanks anyway! -- Bastien
Re: problem with org-capture for calendar invite
On Wednesday, 19 Feb 2020 at 13:38, Bastien wrote: > Yes, this was a mistake I made when trying to warn the user for > missing initial contents or annotation. > > Fixed now, thanks for reporting this, Confirmed. Thank you! -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-350-g39f1c1
Re: Bug or not a bug? dot expansion in ob-shell
On Wednesday, 19 Feb 2020 at 14:00, Bastien wrote: > Anyway, I don't have yet a clue on how to add this new option. I'll > leave it to Eric first (if he has time) then look at it later this > week. Time is an issue (middle of teaching term). More importantly, my elisp-fu is not necessarily up to the level required. It would be best if somebody up to speed with org babel attempt this. In any case, it would be interesting to know if people do depend on value being somehow the output of the last command in a shell script. I'd never even considered that possibility, at least not consciously! -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-345-g415083
Re: Bug or not a bug? dot expansion in ob-shell
Hi Tim, Tim Cross writes: > I'm not sure - need to think about it some more and go back through the > manual. My initial feeling is that the example block you show should > only return "Hello!" when you request output as the reuslts and > otherwise return the return value of echo (which is the exit code in > this case). Yes - my point in this thread is that for now it returns "Hello!" and I guess this is a natural thing to expect. > The main problem with the additional variable you propose is that you > would only want it enabled on some source blocks and not others, so it > might need to be settable as a header option to turn it on/off for a > specific block. Yes, hence the proposal to have :value-is-exit-code as a header arg. Let's find the right approach to this. Thanks, -- Bastien
Re: Survey: changing a few default settings for Org 9.4
Hi! >>> - org-loop-over-headlines-in-active-region => t >> >> I vote for => 'start-level. Loop over headlines with same level as the >> first. > > Yes, good suggestion. Let's see what others say. >>> - org-special-ctrl-k => t >>> >>> The default value for the sister option org-special-ctrl-a is set to >>> reversed and while this changes a fundamental Emacs command behavior >>> it feels useful. I'd argue this is the same for org-special-ctrl-k: >>> setting it to t will feel natural. >> >> AFAICS there is a contradiction between the documentation of >> org-special-ctrl-k and the code! Doc: kill the tags. Code: >> (org-align-tags). >> >> Further I propose to delete the part " and possible the folded subtree >> below the line" from the documentation. > > Can you propose a patch against the maint branch for the fixes above? Sure. See the attachments. >>> - org-src-tab-acts-natively => t >>> - org-allow-promoting-top-level-subtree => t >> >> Just an idea for the "reverse": provide a function to convert a comment >> line to a heading (one level below the current level) and demote the >> subtrees below. > > I don't think converting a comment to a headline is a common use case. Ok. That was just an idea. >>> * We have regular meetings with https://www.emacs-doctor.com/ >> >> What are these meetings? > > We gather with fellow Emacsers in Paris once in a while. Ahhh! Paris! Thanks for the information. Paris is out of my reach, though. >From 49b00d2cf7ca4b8484e0a9679b39b62873ee30b6 Mon Sep 17 00:00:00 2001 From: Marco Wahl Date: Wed, 19 Feb 2020 13:48:01 +0100 Subject: [PATCH 1/2] org: Fix corner case for org-kill-line * lisp/org.el (org-kill-line): Kill _all_ tags when the cursor is on the tags part. --- lisp/org.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org.el b/lisp/org.el index f7547eba1..f4fe76f82 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -20392,7 +20392,7 @@ depending on context." (skip-chars-backward " \t") (point (if (<= end (point)) ;on tags part - (kill-region (point) (line-end-position)) + (kill-region end (line-end-position)) (kill-region (point) end))) (org-align-tags)) (t (kill-region (point) (line-end-position) -- 2.25.1 >From a81744de15f42d1817482f2209f555a959e9e66c Mon Sep 17 00:00:00 2001 From: Marco Wahl Date: Wed, 19 Feb 2020 13:51:01 +0100 Subject: [PATCH 2/2] org: Remove irritating documentation line * lisp/org.el (org-special-ctrl-k): Omit irritating documentation line. --- lisp/org.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org.el b/lisp/org.el index f4fe76f82..7327bfe21 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -1575,7 +1575,7 @@ When nil, `C-k' will call the default `kill-line' command. When t, the following will happen while the cursor is in the headline: - When the cursor is at the beginning of a headline, kill the entire - line and possible the folded subtree below the line. + line. - When in the middle of the headline text, kill the headline up to the tags. - When after the headline text, kill the tags." :group 'org-edit-structure -- 2.25.1
Re: Survey: changing a few default settings for Org 9.4
Hi Tim, Tim Cross writes: > I agree 100%. We have already gone through this pain and as has been > pointed out numerous times, the 'new' approach has significant benefits > over the old old habits, but once done the new version works fine. Point taken. But as I said, I think both approaches fit different use cases. So my question is rather: why would it be so bad to enable org-tempo expansion by default? When simply use, it just allows <* expansion. > I also think Nicolas' point that adding (require 'org-tempo) is a lot > more trivial than removing it from the list of loaded modules. Yes, I somehow agree, but yet: the poll so far seems to show that most users want it back (10 on 15, as the moment, two votes against.) Org is not poll-driven software, but this says something that we might want to listen to. > The other poinit is that while tempo has been around for years, it is > not the easiest templating solution to use, especially for those > unfamiliar with it who may want to add their own tempo templates. Other > templating solutions, like yasnippets, are likely much easier for new > users to adopt than tempo. In its basic usage, <* expansion seems very simple to me. I'm all for not enable org-tempo by default iff we can allow expansion of <* strings at the beginning of the line. -- Bastien
Re: Bug or not a bug? dot expansion in ob-shell
Hi Bastien, I'm not sure - need to think about it some more and go back through the manual. My initial feeling is that the example block you show should only return "Hello!" when you request output as the reuslts and otherwise return the return value of echo (which is the exit code in this case). The main problem with the additional variable you propose is that you would only want it enabled on some source blocks and not others, so it might need to be settable as a header option to turn it on/off for a specific block. Bastien writes: > Hi Tim, > > thanks for your proposal. I think we agree here. > > My suggestion is to have a new option ob-shell-value-is-exit-status. > > When set to nil (the default), the "return value" of a shell source > block would be the output of the last command. This is the current > behavior where we have e.g. > > #+begin_src shell > echo "Hello!" > #+end_src > > #+RESULTS: > : Hello! > > When set to t, the return value of a shell source block would be the > exit code of the last command. This would be useful for side effect > and other use cases. > > We can also consider a specific parameter :value-is-exit-code to set > for individual blocks--useful for noweb. > > My only point is I don't think ob-shell-value-is-exit-status should be > t by default, as it would cause all shell blocks to return the status > code by default, which may not be what most users want. > > Anyway, I don't have yet a clue on how to add this new option. I'll > leave it to Eric first (if he has time) then look at it later this > week. > > Thanks! -- Tim Cross
Re: Survey: changing a few default settings for Org 9.4
Am Mittwoch, 19. Februar 2020, 12:30:59 CET schrieb Nicolas Goaziou: > Hello, > > Bastien writes: > > - Add org-tempo to org-modules > > > > Last but not least: we had long discussions about this one in the > > past. Expansion of the " > the beginning of the line has been turned off. I have IRL met with > > Org users* who just thought the feature was broken/deleted, without > > having/taking the time/knowledge/guts to look for the things they > > can turn on. I am all for turning this on again, letting experts > > disabling the feature if they don't want it. > > > > * We have regular meetings with https://www.emacs-doctor.com/ > > This is not a good default, at least for beginners, because Org provides > a better solution out of the box. There are also better solutions > outside Org (e.g., Yasnippet). > > It is only valuable for existing users, who relied on this feature, and > don't want to switch. It's perfectly understandable, but it is also fair > to assume they can add (require 'org-module) to their own configuration. > _Removing_ the module, OTOH, is subtle. > > By the way, this does not belong to the same category as other > defcustoms discussed. This is only tangential to "how does Org should > look and feel by default". It relates to: should Org provide multiple > snippet extensions, knowing this is not a central feature, and Org is > often seen as bloated by Emacs devs? I don't think so, no matter how > useful this feature can be for some users. > > Regards, Hello, what Bastien suggests, doesn't that lead to two ways of getting getting e.g. a quote? Either with C-c C-, or again with "
Re: Bug or not a bug? dot expansion in ob-shell
Hi Tim, thanks for your proposal. I think we agree here. My suggestion is to have a new option ob-shell-value-is-exit-status. When set to nil (the default), the "return value" of a shell source block would be the output of the last command. This is the current behavior where we have e.g. #+begin_src shell echo "Hello!" #+end_src #+RESULTS: : Hello! When set to t, the return value of a shell source block would be the exit code of the last command. This would be useful for side effect and other use cases. We can also consider a specific parameter :value-is-exit-code to set for individual blocks--useful for noweb. My only point is I don't think ob-shell-value-is-exit-status should be t by default, as it would cause all shell blocks to return the status code by default, which may not be what most users want. Anyway, I don't have yet a clue on how to add this new option. I'll leave it to Eric first (if he has time) then look at it later this week. Thanks! -- Bastien
Re: Survey: changing a few default settings for Org 9.4
I agree 100%. We have already gone through this pain and as has been pointed out numerous times, the 'new' approach has significant benefits over the old writes: > Hello, > > Bastien writes: > >> - Add org-tempo to org-modules >> >> Last but not least: we had long discussions about this one in the >> past. Expansion of the "> the beginning of the line has been turned off. I have IRL met with >> Org users* who just thought the feature was broken/deleted, without >> having/taking the time/knowledge/guts to look for the things they >> can turn on. I am all for turning this on again, letting experts >> disabling the feature if they don't want it. >> >> * We have regular meetings with https://www.emacs-doctor.com/ > > This is not a good default, at least for beginners, because Org provides > a better solution out of the box. There are also better solutions > outside Org (e.g., Yasnippet). > > It is only valuable for existing users, who relied on this feature, and > don't want to switch. It's perfectly understandable, but it is also fair > to assume they can add (require 'org-module) to their own configuration. > _Removing_ the module, OTOH, is subtle. > > By the way, this does not belong to the same category as other > defcustoms discussed. This is only tangential to "how does Org should > look and feel by default". It relates to: should Org provide multiple > snippet extensions, knowing this is not a central feature, and Org is > often seen as bloated by Emacs devs? I don't think so, no matter how > useful this feature can be for some users. > > Regards, -- Tim Cross
Re: Bug or not a bug? dot expansion in ob-shell
I think I agree with Eric here. However, perhaps I don't fully understand all the details. Many shell commans, especially those which mainly perform 'side effects' like echo, return the exit code. This value is often used in shell scripts as a type of short hand/short circuit i.e. combined with logic operators. Question: would it not be import to separate return value from output value when it comes to shell scripts and noweb type expansion e.g. if I had a block where the last command does not do any output, but does return an exit value as the return value, might it not be important to have that exit value for the next babel block which uses the previous block? Something else which may be relevant is to note that bash is not the only shell and some commands, like echo, will behave differently depending on the shell. For exmaple, in some shells, echo with no arguments will just ouput a newline while on other shells, you need to explicitly request this behaviour with -n switch. As a general principal, I think the return value and the output value should be considered to be distinct items and it would be a mistake to return the output value when it appears the last command does not return a value. Do what the shell would do - if it returns the exit code then return that. If the last command really doesn't return anything i.e. hot even an exit code, return nil (though I think under posix, at the very least, the exit code is returned). Fraga, Eric writes: > On Wednesday, 19 Feb 2020 at 12:38, Bastien wrote: >> "0" is the _exit code_ of the successful echo command, not the value >> returned by the echo command. > > But echo does not "return" the string as a value. It outputs the > string. > > To quote the man page for bash, "the return value of a simple command is > its status". Further, a function does not actually return any value > beyond the status of the last command or a value given on a =return= > statement. > >> So In Vladimir's example, both ":results value" and ":results output" >> should return the same result, i.e. ".". > > I disagree. I think the current behaviour (i.e. before your attempt to > "correct"" this) is correct given the documentation you quoted! > >> Was it common to expect the exit code when executing shell code? > > Common? I have no idea. *I* did expect this. But that's maybe because > I do use the shell a lot. > > I think there's a clear distinction between value and output for src > blocks and blurring this distinction for shell src blocks would be > misleading. The option to request the output as the outcome of the src > block is already there. -- Tim Cross
Re: problem with org-capture for calendar invite
Hi Eric, "Fraga, Eric" writes: > For some reason, this no longer works and I get the following error: Yes, this was a mistake I made when trying to warn the user for missing initial contents or annotation. Fixed now, thanks for reporting this, -- Bastien
Re: Bug or not a bug? dot expansion in ob-shell
Bastien writes: > Then we need to fix ob-shell.el to return the exit code of the last > command when :results is not set or explicitely set to "value". Is > this something you want to look at? > > Maybe by adding a "echo $?" instruction at the end of shell blocks > or by wrapping the code into something that returns the result? > > I think it will come as a surprise for many users, since the natural > expectation seems to get the "output", disregarding bash notion of a > "return value". Maybe ob-shell.sh could have an option ob-shell-value-is-exit-status set to nil by default to stick with the current behavior, but letting users get the exit status as the value if they want to. WDYT? -- Bastien
Re: Bug or not a bug? dot expansion in ob-shell
Hi Eric, note that the previous behavior only _seemed_ right by chance: there is no notion of getting the exit code of the shell command in ob-shell.el, and returning "0" is just a hazard here, just because (org-babel--string-to-number ".") returns "0", while it should return nil. "Fraga, Eric" writes: > On Wednesday, 19 Feb 2020 at 12:38, Bastien wrote: >> "0" is the _exit code_ of the successful echo command, not the value >> returned by the echo command. > > But echo does not "return" the string as a value. It outputs the > string. > > To quote the man page for bash, "the return value of a simple command is > its status". Further, a function does not actually return any value > beyond the status of the last command or a value given on a =return= > statement. Then we need to fix ob-shell.el to return the exit code of the last command when :results is not set or explicitely set to "value". Is this something you want to look at? Maybe by adding a "echo $?" instruction at the end of shell blocks or by wrapping the code into something that returns the result? I think it will come as a surprise for many users, since the natural expectation seems to get the "output", disregarding bash notion of a "return value". I don't know. > I disagree. I think the current behaviour (i.e. before your attempt to > "correct"" this) is correct given the documentation you quoted! Yes, I see how it seems correct, but this was random... >> Was it common to expect the exit code when executing shell code? > > Common? I have no idea. *I* did expect this. But that's maybe because > I do use the shell a lot. I won't release 9.4 until we properly fix this, it's important. > I think there's a clear distinction between value and output for src > blocks and blurring this distinction for shell src blocks would be > misleading. Agreed. > The option to request the output as the outcome of the src block is > already there. Yes, agreed again. If you or someone else can look at ob-shell.el and see what can be done to get the proper value (in bash's terms) of the last command in the block, that'd be great. Thanks! -- Bastien
Re: Bug or not a bug? dot expansion in ob-shell
That's an excellent response, Eric! Now what about this block: #+begin_src shell printf "%s" ' (computer . ?type) exit' #+end_src ср, 19 февр. 2020 г. в 19:56, Fraga, Eric : > On Wednesday, 19 Feb 2020 at 12:38, Bastien wrote: > > "0" is the _exit code_ of the successful echo command, not the value > > returned by the echo command. > > But echo does not "return" the string as a value. It outputs the > string. > > To quote the man page for bash, "the return value of a simple command is > its status". Further, a function does not actually return any value > beyond the status of the last command or a value given on a =return= > statement. > > > So In Vladimir's example, both ":results value" and ":results output" > > should return the same result, i.e. ".". > > I disagree. I think the current behaviour (i.e. before your attempt to > "correct"" this) is correct given the documentation you quoted! > > > Was it common to expect the exit code when executing shell code? > > Common? I have no idea. *I* did expect this. But that's maybe because > I do use the shell a lot. > > I think there's a clear distinction between value and output for src > blocks and blurring this distinction for shell src blocks would be > misleading. The option to request the output as the outcome of the src > block is already there. > -- > : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-345-g415083 > -- Yours sincerely, Vladimir Nikishkin
Re: Survey: changing a few default settings for Org 9.4
Hi Nicolas, Nicolas Goaziou writes: > This is not a good default, at least for beginners, because Org provides > a better solution out of the box. There are also better solutions > outside Org (e.g., Yasnippet). Well, let's agree to disagree on this one. org-tempo and C-c C- fill two different use cases: the first one for fast block insertion while typing, the second one for e.g. when the region is selected. I don't think allowing org-tempo "shadows" C-c C-, in any fashion. > It is only valuable for existing users, who relied on this feature, and > don't want to switch. It's perfectly understandable, but it is also fair > to assume they can add (require 'org-module) to their own configuration. > _Removing_ the module, OTOH, is subtle. M-x customize-option RET org-modules seems okay to me. > By the way, this does not belong to the same category as other > defcustoms discussed. This is only tangential to "how does Org should > look and feel by default". It relates to: should Org provide multiple > snippet extensions, knowing this is not a central feature, and Org is > often seen as bloated by Emacs devs? I don't think so, no matter how > useful this feature can be for some users. I'll be more receptive to this argument when animate-birthday-present is not in Emacs's core anymore :) That said, I'm receptive to the idea that Org could be more focused to its core functionalities. E.g., I think we could be more minimalistic about the ol-* and ox-* libraries in Org. Also, we should get rid of org-modules altogether now that Emacs has a packaging system. I'd suggest a discussion on this for after 9.4. -- Bastien
Re: Bug or not a bug? dot expansion in ob-shell
On Wednesday, 19 Feb 2020 at 12:38, Bastien wrote: > "0" is the _exit code_ of the successful echo command, not the value > returned by the echo command. But echo does not "return" the string as a value. It outputs the string. To quote the man page for bash, "the return value of a simple command is its status". Further, a function does not actually return any value beyond the status of the last command or a value given on a =return= statement. > So In Vladimir's example, both ":results value" and ":results output" > should return the same result, i.e. ".". I disagree. I think the current behaviour (i.e. before your attempt to "correct"" this) is correct given the documentation you quoted! > Was it common to expect the exit code when executing shell code? Common? I have no idea. *I* did expect this. But that's maybe because I do use the shell a lot. I think there's a clear distinction between value and output for src blocks and blurring this distinction for shell src blocks would be misleading. The option to request the output as the outcome of the src block is already there. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-345-g415083
problem with org-capture for calendar invite
For a long time, I have been using this template for org-capture:
#+begin_src emacs-lisp
(add-to-list 'org-capture-templates
'("#"
"used by gnus-icalendar-org"
entry (file+olp+datetree "~/s/notes/diary.org")
"%i"
:immediate-finish t))
#+end_src
For some reason, this no longer works and I get the following error:
,
| Debugger entered--Lisp error: (error "Capture abort: Missing initial
annotation in this ...")
| signal(error ("Capture abort: Missing initial annotation in this ..."))
| gnus-article-read-summary-keys(nil)
| funcall-interactively(gnus-article-read-summary-keys nil)
| call-interactively(gnus-article-read-summary-keys nil nil)
| command-execute(gnus-article-read-summary-keys)
`
The problem is the %i in the template above. This will include any
"description" found in the calendar invite, if there, but should be
nothing if not. I am sure (but maybe I am wrong) that this capture
template used to work before.
In any case, if the initial contents are not defined, should this really
be an error?
org up to date from git as of a minute or two ago; emacs from git from a
couple of days ago.
Thank you.
PS - maybe it's gnus that is at fault here?
--
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-345-g415083
Re: Survey: changing a few default settings for Org 9.4
Hi Marco, Marco Wahl writes: >> - org-loop-over-headlines-in-active-region => t > > I vote for => 'start-level. Loop over headlines with same level as the > first. Yes, good suggestion. >> - org-special-ctrl-k => t >> >> The default value for the sister option org-special-ctrl-a is set to >> reversed and while this changes a fundamental Emacs command behavior >> it feels useful. I'd argue this is the same for org-special-ctrl-k: >> setting it to t will feel natural. > > AFAICS there is a contradiction between the documentation of > org-special-ctrl-k and the code! Doc: kill the tags. Code: > (org-align-tags). > > Further I propose to delete the part " and possible the folded subtree > below the line" from the documentation. Can you propose a patch against the maint branch for the fixes above? >> - org-src-tab-acts-natively => t >> - org-allow-promoting-top-level-subtree => t > > Just an idea for the "reverse": provide a function to convert a comment > line to a heading (one level below the current level) and demote the > subtrees below. I don't think converting a comment to a headline is a common use case. >> * We have regular meetings with https://www.emacs-doctor.com/ > > What are these meetings? We gather with fellow Emacsers in Paris once in a while. -- Bastien
Re: Bug or not a bug? dot expansion in ob-shell
Hi Eric, "Fraga, Eric" writes: > On Wednesday, 19 Feb 2020 at 10:41, Bastien wrote: >> It returned "0" for me, while I guess "." is expected. > > I expected 0 as that is the "value" (i.e. the status in a shell) of > the last command. Quoting the manual: ‘value’ Default. Functional mode. Org gets the value by wrapping the code in a function definition in the language of the source block. That is why when using ‘:results value’, code should execute like a function and return a value. For languages like Python, an explicit ‘return’ statement is mandatory when using ‘:results value’. Result is the value returned by the last statement in the code block. "0" is the _exit code_ of the successful echo command, not the value returned by the echo command. So In Vladimir's example, both ":results value" and ":results output" should return the same result, i.e. ".". Was it common to expect the exit code when executing shell code? -- Bastien
Re: Survey: changing a few default settings for Org 9.4
Hello, Bastien writes: > - Add org-tempo to org-modules > > Last but not least: we had long discussions about this one in the > past. Expansion of the " the beginning of the line has been turned off. I have IRL met with > Org users* who just thought the feature was broken/deleted, without > having/taking the time/knowledge/guts to look for the things they > can turn on. I am all for turning this on again, letting experts > disabling the feature if they don't want it. > > * We have regular meetings with https://www.emacs-doctor.com/ This is not a good default, at least for beginners, because Org provides a better solution out of the box. There are also better solutions outside Org (e.g., Yasnippet). It is only valuable for existing users, who relied on this feature, and don't want to switch. It's perfectly understandable, but it is also fair to assume they can add (require 'org-module) to their own configuration. _Removing_ the module, OTOH, is subtle. By the way, this does not belong to the same category as other defcustoms discussed. This is only tangential to "how does Org should look and feel by default". It relates to: should Org provide multiple snippet extensions, knowing this is not a central feature, and Org is often seen as bloated by Emacs devs? I don't think so, no matter how useful this feature can be for some users. Regards, -- Nicolas Goaziou
Re: Bug or not a bug? dot expansion in ob-shell
On Wednesday, 19 Feb 2020 at 10:41, Bastien wrote: > It returned "0" for me, while I guess "." is expected. I expected 0 as that is the "value" (i.e. the status in a shell) of the last command. If you want ".", I would expect one to use :results output in the src block header? -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-316-g5dd772
Re: Survey: changing a few default settings for Org 9.4
Bastien writes: > while Org 9.4 is on its way, I am considering changing a few default > settings (10 options in total). I have created a survey here: > > https://framadate.org/Ufc42EVxS2jO1Ajz > > Can you take a few minutes and express your opinion there? Ok. I'll go there in a minute. > Here is the list of options and a line of justification - feel free to > discuss this on the mailing list too, of course. These changes look good to me. Thanks for bringing this up. Find a few comments and a question below. > - org-loop-over-headlines-in-active-region => t I vote for => 'start-level. Loop over headlines with same level as the first. > - org-agenda-loop-over-headlines-in-active-region => t > - org-fontify-done-headline => t > - org-hide-emphasis-markers => t > - org-hide-macro-markers => t > - org-refile-use-cache => t > - org-special-ctrl-k => t > > The default value for the sister option org-special-ctrl-a is set to > reversed and while this changes a fundamental Emacs command behavior > it feels useful. I'd argue this is the same for org-special-ctrl-k: > setting it to t will feel natural. AFAICS there is a contradiction between the documentation of org-special-ctrl-k and the code! Doc: kill the tags. Code: (org-align-tags). Further I propose to delete the part " and possible the folded subtree below the line" from the documentation. > - org-src-tab-acts-natively => t > - org-allow-promoting-top-level-subtree => t Just an idea for the "reverse": provide a function to convert a comment line to a heading (one level below the current level) and demote the subtrees below. > - Add org-tempo to org-modules > * We have regular meetings with https://www.emacs-doctor.com/ What are these meetings? Thanks.
Re: Bug or not a bug? dot expansion in ob-shell
Bastien writes: > PS: Ouch, I broke a few tests. I'm looking at this right now. Those have been fix, together with org-babel--string-to-number, which should not allow "1 2" to be interpreted as a number. Eric, if my reading of the expected output does not match yours please let me know. -- Bastien
Re: Bug or not a bug? dot expansion in ob-shell
Bastien writes: > Let me know if it does the right thing for you. PS: Ouch, I broke a few tests. I'm looking at this right now. -- Bastien
Re: Bug or not a bug? dot expansion in ob-shell
Hi Eric and Vladimir, "Fraga, Eric" writes: > On Wednesday, 19 Feb 2020 at 17:02, Vladimir Nikishkin wrote: >> Could you check if the following block behaves as expected? > > It does for me. What did you expect and what did you get? It returned "0" for me, while I guess "." is expected. The function org-babel--string-to-number was not interpreting Emacs numbers correctly: for example, -1e3 would not return a number, while it should. I've now fixed it in maint. Let me know if it does the right thing for you. Thanks, -- Bastien
Regarding collapsing blank lines between headlines
I prefer to keep at least one empty line between my Org headers. I find myself frequently clearing or collapsing multiple empty lines after the content of a block before the next headline. Did I miss a variable to customize collapsing blank space? Perhaps I can just add a hook to when I mark a TODO to DONE to remove extra whitespace at the end of the block. I already use org-blank-before-new-entry to try and keep proper spacing. For example: * Item 1 Block of text for item 1 * Item 2 Block of text for item 2 ;; excess empty lines that should be removed * Item 3 Block of text for item 3 -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Bug or not a bug? dot expansion in ob-shell
On Wednesday, 19 Feb 2020 at 17:02, Vladimir Nikishkin wrote: > Could you check if the following block behaves as expected? It does for me. What did you expect and what did you get? -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-316-g5dd772
Bug or not a bug? dot expansion in ob-shell
Hello, everyone Could you check if the following block behaves as expected? #+begin_src shell echo . #+end_src -- Yours sincerely, Vladimir Nikishkin
Re: Survey: changing a few default settings for Org 9.4
Hi Samuel, thanks for your feedback. Samuel Wales writes: > On 2/19/20, Bastien wrote: >> - org-refile-use-cache => t >> >> This is a speed boost when refiling entries: if org-refile-targets >> is big, caching refile targets help refiling faster. > > i predict this will generate bug reports. Yes, that's to be expected - for this change and maybe others. This is also the purpose of this proposal: help to track and fix bugs that may not yet surface because the feature is unknown to most users. -- Bastien
Re: Survey: changing a few default settings for Org 9.4
On 2/19/20, Bastien wrote: > - org-refile-use-cache => t > > This is a speed boost when refiling entries: if org-refile-targets > is big, caching refile targets help refiling faster. i predict this will generate bug reports. in particular pay close attention to restricted refile and whether caching works for both it and unrestricted refile. it is better to change the thing being cached to be faster if possible. i agree speed is needed. org's biggest issue imo is speed. this will be increasingly apparent as users use org for more data, moore's law falters, and emacs continues to rely on a single core. i am not saying don't change the default or change the default. just saying if you do, then be careful. -- The Kafka Pandemic What is misopathy? https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
