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
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
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.
>
>
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
-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
-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
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
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.
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
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
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,
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
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'
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
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
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
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 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*
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
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
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:
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
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
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
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
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?
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
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
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
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
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,
--
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
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
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
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
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
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
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
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
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
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
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 -
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
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
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
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
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
-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
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
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
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
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
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
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:
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
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
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
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
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
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).
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
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.
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
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
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
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
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"
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,
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
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
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"
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
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.
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,
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
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.
>
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 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
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
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
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
Hello, everyone
Could you check if the following block behaves as expected?
#+begin_src shell
echo .
#+end_src
--
Yours sincerely, Vladimir Nikishkin
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
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
84 matches
Mail list logo
