Hi Marco,
On Mon, 17 Aug 2020 at 06:40, Marco Wahl
wrote:
I don't know if there is a strong reason to hard-code the set of keys
in `org-speed-commands-default'. But, if there isn't, could you
consider (somehow) exposing the whole set of `org-speed-commands' to
user customization?
This
Hi All,
Org's speed keys are a very interesting feature to which I've long been
attracted to. And indeed, I've flirted with it a number of times in the
past. But every time I do so, I end up stepping back, because I get
weary of fat fingering my documents. The whole set of speed keys is
Hi All,
There is some adverse interaction between Emacs sentence related
commands and Org emphasis markers, when whole sentences are emphasized.
This report describe some cases of this interaction, for your
consideration. But, as a general rule, if a whole sentence is
emphasized, sentence
On Wed, 29 Jul 2020 at 12:41, Kevin Liu wrote:
The graph works for hourly repeaters in exactly the same way as it
works
in all other cases. It illustrates whether the task was done on a
given
day.
But what will happen is that the task will be both "done" and "due" on
the same day.
Hi Kevin,
On Wed, 29 Jul 2020 at 11:46, Kevin Liu wrote:
On 29 July 2020 04:06, Gustavo Barros wrote:
Kevin, how do you see an hourly repeater would work with org-habit's
consistency graph? Or, more generally, what would be the purpose of
an
hourly repeated habit task?
An example
Hi Kyle, Hi Kevin,
On Tue, 28 Jul 2020 at 22:29, Kyle Meyer wrote:
> Kevin Liu writes:
>
>>> Is there any way to do this or are the docs out of date?
>>
>> I made a few quick changes to org-habit and it works prima facie. Will
>> continue testing for a bit.
>
> The hourly repeater came in
Hi Marco,
thank you for your answer.
On Tue, 28 Jul 2020 at 17:34, Marco Wahl wrote:
>> I'm not sure this is a "bug", strictly speaking, or if it is correct
>> unfortunate behavior. Anyway, is there something that could be done
>> from Org's side?
>
> Also not sure if this is a bug. But you
Hi All,
The Org line commands -- `org-beginning-of-line', `org-end-of-line', and
`org-kill-line' -- all take due care for the presence of
`visual-line-mode' to do the right thing if it is turned on. However,
when `visual-line-mode' is indeed on, the bindings on
`visual-line-mode-map' shadow
Hi Nicolas,
Hi All,
On Sun, 05 Jul 2020 at 17:49, Gustavo Barros
wrote:
A fourth issue is point placement after the emphasis is
added. `org-emphasis'
takes a stance here and places point within the emphasis. I do agree
with this
option, but it is still true that sometimes, one might want
Hi Nicolas,
Hi All,
On Sun, 05 Jul 2020 at 07:50, Nicolas Goaziou
wrote:
The problem is not your implementation, really. It's just that I don't
think it should be the _built-in_ way to solve emphasis
management. IOW,
we shouldn't need to activate a minor mode to make that management
Hi Nicolas,
On Sun, 28 Jun 2020 at 14:26, Nicolas Goaziou
wrote:
This is done in master.
Thank you very much.
Regards,
Gustavo.
Hi Kyle,
On Fri, 26 Jun 2020 at 22:03, Kyle Meyer wrote:
I've managed to trigger it now. Your picture gave me the hint that
maybe my "making my frame height very small" wasn't the thing to do.
Plus I should have realized that the default-frame-alist in your
minimal
configuration probably
Hi Nicolas,
On Wed, 24 Jun 2020 at 12:46, Nicolas Goaziou
wrote:
Hello,
Gustavo Barros writes:
You have a good point here. When I made the suggestion I was naively
thinking the featured could be plugged/hooked somewhere in Org, when
fontification is done. But that's not really true
Hi Shankar,
Detailed comments are up for Kyle, or someone more qualified than
myself, but I leave one further comment regarding the suggestion I had
made.
On Wed, 24 Jun 2020 at 09:53, Shankar Rao wrote:
I agree that adding this functionality as additional options to
Hi Kyle, Hi Shankar,
On Mon, 22 Jun 2020 at 05:40, Kyle Meyer wrote:
> Shankar Rao writes:
>
>> This patch adds a minor mode that makes emphasis markers be automatically
>> unhidden when the point is inside the region of emphasis and then the
>> markers are rehidden when the point is moved
Hi All,
Org 'attachment:' links are essentially file links to local files and,
while 'org-lint' checks 'file:' links for the existence of the
corresponding files with `org-lint-link-to-local-file', as far as I can
tell, the same check is not done for 'attachment:' links.
So, I'd like to
Hi Nicolas,
On Fri, 12 Jun 2020 at 18:59, Nicolas Goaziou
wrote:
I removed the warning for dir property. Thank you.
Thank you very much.
Regards,
Gustavo.
Hi All,
When setting the 'DIR' property for attachments for a whole file with
=#+PROPERTY: DIR ...=, 'org-lint' will issue a deprecation warning and
recommend the use "header-args" instead. Of course, 'org-lint' means
here babel blocks, but as far as I understand, setting the 'DIR'
property
makes sense, same as for 29:00
|
| 30h | no match | as per the regexp
|
WDYT?
Best,
Gustavo.
>From 02829c7771a1f7a0c00d607a924fb8f56d2f3dd6 Mon Sep 17 00:00:00 2001
From: Gustavo Barros
Date: Wed, 3 Jun 2020 08:57:53 -0300
Subject: [PATCH] date/time prompt: Provide sup
Hi stardiviner,
On Tue, Jun 02 2020, stardiviner wrote:
Which date/time prompt do you mean? Like set schedule or deadline? If
just raw
timestamp, it makes me confused whether it is time continuance.
The date/time prompt is Org's interface for querying for date and time
which is
a release. Thank you very much for
considering it.
Gustavo Barros writes:
With this, we'd have some example inputs, and their respective
results:
8h -> 08:00
10h30-> 10:30
18h -> 18:00
9h-10h -> 09:00-10:00
9h30-10h -> 09:30-10:00
All the above looks goo
, if anyone is already onto it, please disregard the ping.
Best,
Gustavo.
On Sat, Feb 29 2020, Gustavo Barros wrote:
Hi All,
The export dispatcher scrolling seems to interact unfavorably general
Emacs
scroll option "scroll-margin", in particular, setting it a positive
displaces
the dispatch
Hi Robert,
On Thu, May 21 2020, Robert Horn wrote:
Eric S Fraga writes:
On Thursday, 21 May 2020 at 09:29, Gustavo Barros wrote:
So I'd like to suggest a simplification there, which is: a string in
the format "hour h minute" (that's small caps letter "H"), but in
On Thu, May 21 2020, Gustavo Barros wrote:
format "hour h minute" (that's small caps letter "H"), but
^^
Sorry, I obviously would like to have said "lowercase" here.
Best,
Gustavo.
Hi All,
the Org date/time prompt does deliver the promise in the manual that we
"start getting annoyed by pretty
much any other way of entering a date/time out there". It has indeed
become so for me, as the date/time prompt is very neat. But there is
one place where input could be even
Hi Kyle,
On Sun, Apr 12 2020, Kyle Meyer wrote:
I'll plan to revert the commit tomorrow. Please chime in if you
disagree with me doing so.
Reverted in 1de7eabf2.
Thank you very much for this. I've already received the weekly build,
and it looks good again.
Hopefully a solution for the
, please disregard the bump.
Best,
Gustavo.
On Fri, Feb 28 2020, Kyle Meyer wrote:
Hi Gustavo,
Gustavo Barros writes:
Hi All,
As of recently, repeating tasks are no longer showing up in the
agenda
for future dates. Below a minimal example of the issue:
Thanks for the report and the minimal
Hi All,
The export dispatcher scrolling seems to interact unfavorably general
Emacs scroll option "scroll-margin", in particular, setting it a
positive displaces the dispatcher upwards, eventually hiding completely
the options section at the top, even when there is space in the
frame/window
Hi All,
As of recently, repeating tasks are no longer showing up in the agenda
for future dates. Below a minimal example of the issue:
Start "emacs -Q" and do some setup:
#+begin_src emacs-lisp
(package-initialize)
(setq org-agenda-files '("~/test/agenda.org"))
#+end_src
Where
Hi Bastien,
On Sun, Feb 16 2020, Bastien wrote:
Hi Gustavo,
Gustavo Barros writes:
But the fact that
'completing-read-default' returns the refile location with a double
trailing slash makes me think there is still something to be fixed in
'org-refile-get-location'.
if you're not tired
Hi Bastien,
On Fri, Feb 14 2020, Bastien wrote:
I hope you can fix
this somehow, maybe upstream.
Unfortunately, I'm afraid I don't understand this enough, and what
'ivy-completing-read' was supposed to do, to be able to provide a
pertinent report there.
I personally don't have a problem
Hi Bastien,
On Fri, Feb 14 2020, Bastien wrote:
I've revisited org-refile-get-location given your new information on
ivy-completing-read but I'm not able to see something wrong in the
current implementation of org-refile-get-location. At the same time,
I don't see why ivy-completing-read
Hi Bastien,
On Fri, Feb 14 2020, Bastien wrote:
I've revisited org-refile-get-location given your new information on
ivy-completing-read but I'm not able to see something wrong in the
current implementation of org-refile-get-location. At the same time,
I don't see why ivy-completing-read
Hi Bastien,
On Thu, Feb 13 2020, Bastien wrote:
I tested it and indeed the duplicate candidate is gone. However, the
last refile target no longer seems to be offered as the default for a
subsequent refile operation. Was that intentional?
Nope, an oversight -- fixed in master.
Thank you
Hi Bastien,
On Thu, Feb 13 2020, Bastien wrote:
Am I missing something, or wouldn't it be more appropriate
`https://code.orgmode.org/bzg/org-mode.git' in the manual?
Indeed, applied, thanks!
Thanks!
Hi Bastien,
On Wed, Feb 12 2020, Bastien wrote:
this should be fixed in Org master branch, thanks for the detailed
report. If you can confirm the fix, even better.
By the way, I almost forgot, a small "side-report" on this.
In going to test this from master, I followed the instructions in
Hi Bastien,
thank you very much for looking into this.
On Wed, Feb 12 2020, Bastien wrote:
this should be fixed in Org master branch, thanks for the detailed
report. If you can confirm the fix, even better.
I tested it and indeed the duplicate candidate is gone. However, the
last refile
Hi Bastien,
On Tue, Feb 04 2020, Bastien wrote:
I managed to reproduce this bug, it is fixed in maint now.
I can report this issue is gone with the update to Org 9.3.3.
Thank you very much!
Best,
Gustavo.
Hi Bastien,
thanks for looking into this.
On Tue, Feb 04 2020, Bastien wrote:
I cannot reproduce this issue with latest stable Org and emacs -q.
Can you check and report if this still needs a fix?
Yes, I can still reproduce this as described in the original report with
current version
Hi Nate,
On Fri, Nov 01 2019, Nathan Neff wrote:
Indeed, I do use org-refile-use-outline-path 'file. However, I have a
simple
directory specified for my org-agenda-files. ("~/org-mode")
Therefore
I'll need to
do something a bit different.
It appears that your solution creates "targets"
Hi Nate,
On Sun, Oct 27 2019, Nathan Neff wrote:
> 1) My org-agenda-files show up in the list. For example, foo.org and bar.org
> show up in the refile targets, despite the
> function should return nil if a heading does not contain "Tasks"
Curiously, I’ve been scratching this itch just today.
uot;, refile it to "Top heading 1"
- Go to heading "Entry 2", and call `org-refile'
- Observe the available candidates, and notice "test.org/Top heading 1"
is there twice, once as the default candidate, without a trailing
slash, and also on the paths list, with the slas
On Mon, Sep 09 2019, Michaël Cadilhac wrote:
> Is this the expected behavior?
>
> 1. Create an empty org file
> 2. Insert
> * Test
> * Test 2
> 3. With the cursor at Test, hit C-x n s to narrow the view to the Test subtree
> 4. Hit C-c C-s to schedule the line at any date.
>
> As a result, the
On Mon, Sep 09 2019, Michaël Cadilhac wrote:
> Is this the expected behavior?
>
> 1. Create an empty org file
> 2. Insert
> * Test
> * Test 2
> 3. With the cursor at Test, hit C-x n s to narrow the view to the Test subtree
> 4. Hit C-c C-s to schedule the line at any date.
>
> As a result, the
at the same time?
Best regards,
Gustavo Barros.
Hi Nicolas,
On Thu, Aug 15 2019, Nicolas Goaziou wrote:
Hello,
Gustavo Barros writes:
`org-latex-babel-language-alist' and
`org-latex-polyglossia-language-alist' have the language code for
Brazilian as =("bt-br" . "brazilian")=. I am a native Brazilian and
our la
Hi Carsten,
On Sat, Aug 10 2019, Carsten Dominik wrote:
Hi Gustavo,
I am also on Emacs 26.2, and I don't know where to look if I cannot
reproduce the problem.
It would be useful if someone else tries your minimal example and
reports
back.
Carsten
I’ve tried to put my hands on possible
look if I cannot
reproduce the problem.
It would be useful if someone else tries your minimal example and
reports
back.
Carsten
On Sat, Aug 10, 2019 at 12:54 PM Gustavo Barros
wrote:
Hi Carsten,
thank you for looking into this.
On Sat, Aug 10 2019, Carsten Dominik wrote:
> I tried to r
Hi Carsten,
thank you for looking into this.
On Sat, Aug 10 2019, Carsten Dominik wrote:
I tried to reproduce your example, and things worked properly
I followed the described steps to the letter (except for the clear typo,
where I should have written 'and cancel it with "C-c C-k"').
Hi all,
`org-latex-babel-language-alist' and
`org-latex-polyglossia-language-alist' have the language code for
Brazilian as =("bt-br" . "brazilian")=. I am a native Brazilian and our
language is Portuguese, and Brazilian Portuguese is a variant. That to
say that I’ve never seen the
On Mon, Jul 29 2019, Gustavo Barros wrote:
But the ability to have line breaks is a clear edge
of soul, and the reason of the original request which started this
thread.
I must correct myself, the difference between ulem and soul is not that
one allows line breaks while the other does
/bzg/org-mode/commit/95eeefa9bca1b6c57fe62c248a0a35302cd7374d).
Neither soul nor ulem is very active nowadays, but are used quite
extensively, as far as I know (from following TeX.SX). And both have
their limitations. But the ability to have line breaks is a clear edge
of soul, and the reason of the original request which started this
thread.
So, if the only reason to prefer ulem back in 2013 was utf8 support,
perhaps soulutf8 might be worthy of your reconsideration.
Best regards,
Gustavo Barros.
ved from the template, and I
don’t know if its inclusion is to be considered bad practice,
particularly as the capture templates already have a structure to handle
empty lines. But, if my memory does not betray me in this respect, one
will find plenty of those laying around in folks configs
s indeed a behavior
that does
not correspond to documentation and, to my understanding, should be
considered
a bug.
Best regards,
Gustavo Barros.
Emacs : GNU Emacs 26.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.22.30)
of 2019-04-19
Package: Org mode version 9.2.4 (9.2.4-11-g1c3eae-elp
ss, you will see that this is
indeed the case). I also cannot add a newline manually in the template (with,
"** TODO %?\n"), for it is ignored, unless there is some content after it.
Again, I’m not sure if this is technically unexpected behavior, but I thought
it worth reporting. And, in case it is as
#+RESULTS:
: 2
#+end_verbatim
When 'org-list-demote-modify-bullet' has its default value of nil, all the
lines of the item are kept aligned with the first one, as would be expected.
Best regards,
Gustavo Barros.
Emacs : GNU Emacs 26.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version
nd all TODOs"
((agenda "" nil)
(alltodo "" nil))
nil)
#+end_src
With this, =M-x org-version= returns: "Org mode version 9.2.1
(9.2.1-33-g029cf6-elpaplus @
/home/gustavo/.emacs.d/elpa/org-plus-contrib-20190225/)".
In this setting, if I try to access my "Work Agenda
Hi all,
Hi Johannes,
for the record, there has been a question regarding this in Emacs.SX as
of recent:
https://emacs.stackexchange.com/q/47239/18951
Best,
Gustavo.
On 27/01/2019 15:51, Johannes Altmanninger wrote:
Hi,
My installation of Emacs bundles Org mode 9.1.9
and it defines
Louis,
a hunch, which might work.
It seems that, if you try to set the length in your preamble,
`\beamer@frametextheight` is not yet defined.
So, you might try the hook `\AtBeginDocument` to see if the definition
comes at a better timing.
#+LATEX_HEADER:
101 - 159 of 159 matches
Mail list logo
