Nicolas Goaziou, 2018-01-31 20:12:
Nikolai Weibull writes:
At first I figured that the rules had changed and that the
:PROPERTY: drawer must come first
That's correct.
but then I tried it out and Org would gladly create a new
:LOGBOOK: drawer for an entry that already had a :PRO
Hi!
I’m doing some restructuring of my Org files and I’m getting a lot
of claims that I have malformed drawers. Some of these files are
quite old, so at first this seemed like a reasonable problem, but
when I looked closer everything looked fine. The problem was that
I had :LOGBOOK: drawers
---
etc/ORG-NEWS | 3 +++
1 file changed, 3 insertions(+)
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index f1d85c1..dc0d8b1 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -12,6 +12,9 @@ Please send Org bug reports to emacs-orgmode@gnu.org.
** New features
*** Org linter
~org-lint~ can check syn
* org-agenda.el (org-agenda-insert-diary-strategy): Add new value
'date-tree-last.
(org-agenda-insert-diary-make-new-entry): Handle
`org-agenda-insert-diary-strategy' set to 'date-tree-last.
To allow for diary entries to be entered in time order in the date tree,
add a new value to `org-agen
On Sun, Aug 23, 2015 at 9:40 AM, Nicolas Goaziou wrote:
>> + (let ((last (eq org-agenda-insert-diary-strategy 'date-tree-last))
>> + (has-children (save-excursion (org-goto-first-child
>> +(if (not (and last has-children))
>> + (outline-next-heading)
>> + (org-goto-first-chi
* org-agenda.el (org-agenda-insert-diary-strategy): Add new value
'date-tree-last.
(org-agenda-insert-diary-make-new-entry): Handle
`org-agenda-insert-diary-strategy' set to 'date-tree-last.
To allow for diary entries to be entered in time order in the date tree,
add a new value to `org-agen
* org-agenda.el (org-agenda-maybe-redo): Test for
org-agenda-this-buffer-name as well.
The Agenda buffer will have a different name if it’s in sticky mode,
but some commands that alter the agenda should still redo it, for
example, org-agenda-remove-restriction-lock, just like
org-agenda-filter-by-
* org-agenda.el (org-agenda-maybe-redo): Test for
org-agenda-this-buffer-name as well.
The Agenda buffer will have a different name if it’s in sticky mode,
but some commands that alter the agenda should still redo it, for
example, org-agenda-remove-restriction-lock, just like
org-agenda-filter-by-
* org-agenda.el (org-agenda-maybe-redo): Test for
org-agenda-this-buffer-name as well.
The Agenda buffer will have a different name if it’s in sticky mode,
but some commands that alter the agenda should still redo it, for
example, org-agenda-remove-restriction-lock, just like
org-agenda-filter-by-
Attached, finally. My FSF papers are signed.
On Mon, Feb 16, 2015 at 10:05 AM, Nicolas Goaziou
wrote:
> Hello,
>
> Nikolai Weibull writes:
>
>> Sorry for the late reply. Here’s a patch that should work:
>
> Thank you.
>
> Could you provide an appropriate commit
Here’s the patch again, as I don’t think the one I sent yesterday got
through. My FSF papers are signed, by the way.
I am so disappointed with everything that has to do with e-mail right
now. For some reason the e-mail isn’t being delivered. I assume it’s
not being accepted by the mailing list, but I can’t see why. I’m not
getting any error message.
Anyway, here’s the relevant part (and let’s see if this e-ma
Here’s a patch that I hope I managed to compile correctly via git-send-email.
On Sun, Mar 8, 2015 at 6:59 PM, Achim Gratz wrote:
> Nikolai Weibull writes:
>> Is trying to manage it via git+make oneself less likely to cause
>> incidents?
> There's a bunch of people who seem to manage it just fine.
Did I say otherwise?
Does this preclude making a
On Sun, Mar 8, 2015 at 3:17 PM, Aaron Ecay wrote:
> IMO this is a bad idea. The bleeding edge version is expected to be
> somewhat unstable, and exposing it via ELPA will lead to foot-shooting
> incidents.
Is trying to manage it via git+make oneself less likely to cause incidents?
>From the FA
On Mon, Jul 28, 2014 at 4:20 PM, Bastien wrote:
> Nikolai Weibull writes:
>
>> Here’s a suggested solution. We keep track of whether the parent
>> entry already has any children, then we call org-insert-heading with
>> two universal arguments to add an entry a
On Sat, Mar 7, 2015 at 3:47 PM, Xavier Maillard wrote:
> Nikolai Weibull writes:
>> Would it be of interest to anyone else if the bleeding edge version
>> was available via elpa?
> Isn't it already available via M-x package interface ?
No, only the version based
Hi!
Would it be of interest to anyone else if the bleeding edge version
was available via elpa?
On Mon, Jan 19, 2015 at 6:38 PM, Nicolas Goaziou wrote:
> Nikolai Weibull writes:
>
>> On Sun, Jan 18, 2015 at 11:39 PM, Nicolas Goaziou
>
>>> It could make sense, but the current behaviour is simple and
>>> consistent : always refresh manually, no exception.
On Sun, Jan 18, 2015 at 11:39 PM, Nicolas Goaziou
wrote:
> Nikolai Weibull writes:
>
>> I realize that you have to update it manually, but wouldn’t it make
>> sense to have it be updated automatically when you call
>> org-agenda-(set|remove)-restriction-lock? At least wh
On Sun, Jan 18, 2015 at 11:26 AM, Nicolas Goaziou
wrote:
> Nikolai Weibull writes:
>
>> I’m bumping this again, as this feels like a bug and I’m surprised
>> that no one has at least responded to it.
>>
>> On Wed, Jan 7, 2015 at 6:51 PM, Nikolai Weibull wrot
I’m bumping this again, as this feels like a bug and I’m surprised
that no one has at least responded to it.
On Wed, Jan 7, 2015 at 6:51 PM, Nikolai Weibull wrote:
> Hi!
>
> Anyone else experiencing this? Or is my configuration wrong in some way?
>
> On Mon, Dec 22, 2014 at 7
Hi!
Anyone else experiencing this? Or is my configuration wrong in some way?
On Mon, Dec 22, 2014 at 7:10 PM, Nikolai Weibull wrote:
> Hi!
>
> It seems that agendas created when org-agenda-sticky-mode is t aren’t
> automatically redone when calling
> org-agenda-(set|remove)-r
Hi!
It seems that agendas created when org-agenda-sticky-mode is t aren’t
automatically redone when calling
org-agenda-(set|remove)-restriction-lock. The reason is that
(org-agenda-maybe-redo) checks whether there’s a window displaying a
buffer named org-agenda-buffer-name. Org-agenda-buffer-nam
On Fri, May 30, 2014 at 5:24 PM, Bastien wrote:
> Hi Nikolai,
>
> Nikolai Weibull writes:
>
>> When set to 'top-level, the documentation mentions that it adds it to
>> the end of the file and testing confirms this. It thus seems more
>> consistent to always
On Fri, May 30, 2014 at 4:04 PM, Bastien wrote:
> Nikolai Weibull writes:
>
>> Wouldn’t it be better to fix the function? I’m thinking that you
>> probably want entries added later during the day to appear later in
>> the file, right?
>
> Personally, I prefer t
On Fri, May 30, 2014 at 2:10 PM, Bastien wrote:
> Nikolai Weibull writes:
>
>> The documentation for org-agenda-insert-diary-make-new-entry says that
>> it adds the entry as the last child, but it seems that it’s adding it
>> as the first child instead. (My org-agenda-
Hi!
The documentation for org-agenda-insert-diary-make-new-entry says that
it adds the entry as the last child, but it seems that it’s adding it
as the first child instead. (My org-agenda-insert-diary-strategy is
'date-tree.)
On Wed, May 21, 2014 at 3:48 PM, Nikolai Weibull wrote:
> On Wed, May 21, 2014 at 1:31 PM, Bastien wrote:
>
>> Nikolai Weibull writes:
>>
>>> Yes, the hiding of the stars is cancelled, but it seems that the
>>> org-hide face is still being applied and leaking
On Wed, May 21, 2014 at 1:31 PM, Bastien wrote:
> Nikolai Weibull writes:
>
>> Yes, the hiding of the stars is cancelled, but it seems that the
>> org-hide face is still being applied and leaking unto the whole
>> headline. I got around this by adjusting the org-column
On Wed, May 21, 2014 at 4:35 AM, Bastien wrote:
> Hi Nikolai,
>
> Nikolai Weibull writes:
>
>>> It seems that if you use
>>>
>>> #+STARTUP: indent
>>>
>>> the org-hide face used for the hidden stars will remain when using the
>
On Sat, May 10, 2014 at 1:35 PM, Nikolai Weibull wrote:
> Hi!
>
> It seems that if you use
>
> #+STARTUP: indent
>
> the org-hide face used for the hidden stars will remain when using the
> org-columns view, resulting on, in my case, white on gray.
To clarify, this leaks
Hi!
It seems that if you use
#+STARTUP: indent
the org-hide face used for the hidden stars will remain when using the
org-columns view, resulting on, in my case, white on gray.
Is there a workaround to this that I’m not thinking of?
On Tue, Mar 18, 2014 at 4:27 PM, Bastien wrote:
> Nikolai Weibull writes:
>
>> (org-mode): When loading Org buffers through desktop
>
> I'm not sure what the above means, can you explain it?
> Also, what is exactly the bug this fixes (beyond setting
> somethi
* org.el (org-mode): Add guard around set-face-foreground.
(org-mode): When loading Org buffers through desktop, there will not be
a foreground set for org-hide. Therefore, simply do not set the
foreground of org-hide unless there is one to set.
---
lisp/org.el | 4 +++-
1 file changed, 3 inserti
Hi!
I would like to use Org mode with MobileOrg over Dropbox and have all
my org-agenda-files synced between all my computers, that is, my home
computer, my work computer, and my mobile. Currently, as I understand
MobileOrg and org-mobile-push/-pull, MobileOrg is only really designed
to sync betw
36 matches
Mail list logo
