Re: Write Markdown in Org mode

2021-06-12 Thread leo
Gi Juan

On 12 Jun 2021, at 22:35, Juan Manuel Macías wrote:

> Hi Leo,
>
> leo writes:
>
>> Hi there
>>
>> I write a lot of Markdown notes. At the moment I use Melpa’s markdown-mode, 
>> but I am considering switching to Org mode.
>>
>> But I’m not sure whether Org mode supports this. In the manual I found an 
>> option to *export* to Markdown, but I planning to *write* the notes directly 
>> as Markdown.
>>
>> Is this possible with Org mode?
>>
>> Many thanks!
>>
>
> I do not know the characteristics or the contexts of your workflow, but
> seen the case from the outside, from what you comment I would say that
> it would not have a lot of sense for you to write your Org docs in
> Markdown, since Org is also a lightweight markup language, but much more
> powerful than Markdown. Org mode is intended to write in Org syntax.
>
> I started writing my notes in Markdown, and when I migrated to Org, I
> converted all my old Markdown notes to Org via pandoc.
>
> Anyway, inside an Org document you can write Markdown using a source
> block:
>
> #+begin_src markdown
> your text in markdown...
> #+end_src
>
> If you do C-c ' inside the block, you can edit it in another buffer with
> the markdown mode activated[1].
>
> You can also generate a * .md file from that block (see
> https://orgmode.org/manual/Extracting-Source-Code.html):
>
> #+begin_src markdown :tangle my-file.md
> your text in markdown...
> #+end_src
>
> Best regards,
>
> Juan Manuel

Good to know. I’m not too keen to learn yet another text markup language, but I 
might give org mode a try…

Leo



Write Markdown in Org mode

2021-06-12 Thread leo
Hi there

I write a lot of Markdown notes. At the moment I use Melpa’s markdown-mode, but 
I am considering switching to Org mode.

But I’m not sure whether Org mode supports this. In the manual I found an 
option to *export* to Markdown, but I planning to *write* the notes directly as 
Markdown.

Is this possible with Org mode?

Many thanks!



Re: [PATCH 0/1] Add option to delay fontification of source blocks

2021-04-02 Thread Leo Okawa Ericson
Kyle Meyer  writes:

> Have you explored whether jit-lock (e.g., jit-lock-defer-time) helps for
> your use case?

No I didn't know about it. I have tried it now and it seems to solve
the same problem as my patch. 

> If we do go this route, I think the case needs to be made why this
> spot is special, and why we don't expect or would reject follow-up
> patches for this and that other area.
>

I can't think of a reason either (now that I know that jit-lock exists)
so I will retract my patch. 



[PATCH 0/1] Add option to delay fontification of source blocks

2021-03-27 Thread Leo Okawa Ericson
From: Leo Okawa Ericson 

I tried sending this patch once before, but I think it got caught as spam so I'm
trying this again.

Fontification of long code blocks can be very slow. The patch (in the reply to
this email) mitigates this by adding an option to delay the fontification after
the user has become idle by using idle timers. This seems to be faster from my
limited testing, but I'm not sure if something will go horribly wrong because of
the timers.

There is a trade-off in that there will be no syntax highlightinting when the
user is typing. I don't know how to keep existing fontification so it would be
great if somebody could share a solution to that.

I have signed the copyright papers so that shouldn't be a problem. This is my
first patch submission so any suggestions for improvement are welcome.

Leo Okawa Ericson (1):
  org-src.el: Add option to delay fontification of source blocks

 lisp/org-src.el | 29 +
 1 file changed, 29 insertions(+)

-- 
2.25.1




[PATCH 1/1] org-src.el: Add option to delay fontification of source blocks

2021-03-27 Thread Leo Okawa Ericson
* lisp/org-src.el (org-src-font-lock-fontify-block): Add option to delay
fontification of source blocks.  If
`org-src-font-lock-fontify-idle-delay' is non-nil fontification of
code blocks is delayed until the user has become
idle.

Fontification of source blocks can be very slow. This will add an option
for users to delay the fontification until they have become idle so that
the typing delay is kept low. The trade-off is that there will be no
syntax highlighting when the user is typing.
---
 lisp/org-src.el | 29 +
 1 file changed, 29 insertions(+)

diff --git a/lisp/org-src.el b/lisp/org-src.el
index 20acee4e6..b1446e105 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -584,11 +584,40 @@ (defun org-src--edit-element
 
 
 ;;; Fontification of source blocks
+(defvar org-src-font-lock-fontify-idle-timer nil
+  "Idle timer to use for when fontifying with a timer.")
+
+
+(defvar org-src-font-lock-fontify-idle-delay nil
+  "Duration of the delay until fontification of source blocks.
+If non-nil, source blocks are fontified when the user has been
+idle for `org-src-font-lock-fontify-idle-delay' seconds. This
+means that instead of applying syntax highlighting when you type
+it is delayed until you become idle. Not that when typing there
+will be no fontification.
+")
 
 (defun org-src-font-lock-fontify-block (lang start end)
   "Fontify code block.
 This function is called by emacs automatic fontification, as long
 as `org-src-fontify-natively' is non-nil."
+  (if org-src-font-lock-fontify-idle-delay
+  (progn
+(when org-src-font-lock-fontify-idle-timer
+  (cancel-timer org-src-font-lock-fontify-idle-timer))
+(setq org-src-font-lock-fontify-idle-timer
+  (let ((buf (current-buffer)))
+(run-with-idle-timer
+ org-src-font-lock-fontify-idle-delay
+ nil
+ (lambda ()
+   (with-current-buffer buf
+ (org-src-font-lock-fontify-block-1 lang start end)
+ (when org-src-font-lock-fontify-idle-timer
+   (cancel-timer org-src-font-lock-fontify-idle-timer)) 
))
+(org-src-font-lock-fontify-block-1 lang start end)))
+
+(defun org-src-font-lock-fontify-block-1 (lang start end)
   (let ((lang-mode (org-src-get-lang-mode lang)))
 (when (fboundp lang-mode)
   (let ((string (buffer-substring-no-properties start end))
-- 
2.25.1




[PATCH 0/1] Add option to delay fontification of source blocks

2021-03-27 Thread Leo Okawa Ericson
Fontification of long code blocks can be very slow. The patch, which should be
in another other email, mitigates this by
adding an option to delay the fontification after the user has become idle by
using idle timers. This seems to be faster from my limited testing, but I'm not
sure if something will go horribly wrong because of the timers.

There is a trade-off in that there will be no syntax highlightinting when the
user is typing. I don't know how to keep existing fontification so it would be
great if somebody could share a solution to that.

I have signed the copyright papers so that shouldn't be a problem. This is my
first patch submission so any suggestions for improvement are welcome.

Leo Okawa Ericson (1):
  org-src.el: Add option to delay fontification of source blocks

 lisp/org-src.el | 29 +
 1 file changed, 29 insertions(+)

-- 
2.25.1




[PATCH 1/1] org-src.el: Add option to delay fontification of source blocks

2021-03-27 Thread Leo Okawa Ericson
* lisp/org-src.el (org-src-font-lock-fontify-block): Add option to delay
fontification of source blocks.  If
`org-src-font-lock-fontify-idle-delay' is non-nil fontification of
code blocks is delayed until the user has become
idle.

Fontification of source blocks can be very slow. This will add an option
for users to delay the fontification until they have become idle so that
the typing delay is kept low. The trade-off is that there will be no
syntax highlighting when the user is typing.
---
 lisp/org-src.el | 29 +
 1 file changed, 29 insertions(+)

diff --git a/lisp/org-src.el b/lisp/org-src.el
index 20acee4e6..b1446e105 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -584,11 +584,40 @@ (defun org-src--edit-element
 
 
 ;;; Fontification of source blocks
+(defvar org-src-font-lock-fontify-idle-timer nil
+  "Idle timer to use for when fontifying with a timer.")
+
+
+(defvar org-src-font-lock-fontify-idle-delay nil
+  "Duration of the delay until fontification of source blocks.
+If non-nil, source blocks are fontified when the user has been
+idle for `org-src-font-lock-fontify-idle-delay' seconds. This
+means that instead of applying syntax highlighting when you type
+it is delayed until you become idle. Not that when typing there
+will be no fontification.
+")
 
 (defun org-src-font-lock-fontify-block (lang start end)
   "Fontify code block.
 This function is called by emacs automatic fontification, as long
 as `org-src-fontify-natively' is non-nil."
+  (if org-src-font-lock-fontify-idle-delay
+  (progn
+(when org-src-font-lock-fontify-idle-timer
+  (cancel-timer org-src-font-lock-fontify-idle-timer))
+(setq org-src-font-lock-fontify-idle-timer
+  (let ((buf (current-buffer)))
+(run-with-idle-timer
+ org-src-font-lock-fontify-idle-delay
+ nil
+ (lambda ()
+   (with-current-buffer buf
+ (org-src-font-lock-fontify-block-1 lang start end)
+ (when org-src-font-lock-fontify-idle-timer
+   (cancel-timer org-src-font-lock-fontify-idle-timer)) 
))
+(org-src-font-lock-fontify-block-1 lang start end)))
+
+(defun org-src-font-lock-fontify-block-1 (lang start end)
   (let ((lang-mode (org-src-get-lang-mode lang)))
 (when (fboundp lang-mode)
   (let ((string (buffer-substring-no-properties start end))
-- 
2.25.1




[PATCH 1/1] org-src.el: Add option to delay fontification of source blocks

2021-03-25 Thread leo
From: Leo Okawa Ericson 

* lisp/org-src.el (org-src-font-lock-fontify-block): Add option to delay
fontification of source blocks.  If
`org-src-font-lock-fontify-idle-delay' is non-nil fontification of
code blocks is delayed until the user has become
idle.

Fontification of source blocks can be very slow. This will add an option
for users to delay the fontification until they have become idle so that
the typing delay is kept low. The trade-off is that there will be no
syntax highlighting when the user is typing.
---
 lisp/org-src.el | 29 +
 1 file changed, 29 insertions(+)

diff --git a/lisp/org-src.el b/lisp/org-src.el
index 20acee4e6..b1446e105 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -584,11 +584,40 @@ (defun org-src--edit-element
 
 
 ;;; Fontification of source blocks
+(defvar org-src-font-lock-fontify-idle-timer nil
+  "Idle timer to use for when fontifying with a timer.")
+
+
+(defvar org-src-font-lock-fontify-idle-delay nil
+  "Duration of the delay until fontification of source blocks.
+If non-nil, source blocks are fontified when the user has been
+idle for `org-src-font-lock-fontify-idle-delay' seconds. This
+means that instead of applying syntax highlighting when you type
+it is delayed until you become idle. Not that when typing there
+will be no fontification.
+")
 
 (defun org-src-font-lock-fontify-block (lang start end)
   "Fontify code block.
 This function is called by emacs automatic fontification, as long
 as `org-src-fontify-natively' is non-nil."
+  (if org-src-font-lock-fontify-idle-delay
+  (progn
+(when org-src-font-lock-fontify-idle-timer
+  (cancel-timer org-src-font-lock-fontify-idle-timer))
+(setq org-src-font-lock-fontify-idle-timer
+  (let ((buf (current-buffer)))
+(run-with-idle-timer
+ org-src-font-lock-fontify-idle-delay
+ nil
+ (lambda ()
+   (with-current-buffer buf
+ (org-src-font-lock-fontify-block-1 lang start end)
+ (when org-src-font-lock-fontify-idle-timer
+   (cancel-timer org-src-font-lock-fontify-idle-timer)) 
))
+(org-src-font-lock-fontify-block-1 lang start end)))
+
+(defun org-src-font-lock-fontify-block-1 (lang start end)
   (let ((lang-mode (org-src-get-lang-mode lang)))
 (when (fboundp lang-mode)
   (let ((string (buffer-substring-no-properties start end))
-- 
2.25.1




[PATCH 0/1] Add option to delay fontification of source blocks

2021-03-25 Thread leo
From: Leo Okawa Ericson 

I tried sending this patch once before, but I think it got caught as spam so I'm
trying this again.

Fontification of long code blocks can be very slow. The patch (in the reply to
this email) mitigates this by adding an option to delay the fontification after
the user has become idle by using idle timers. This seems to be faster from my
limited testing, but I'm not sure if something will go horribly wrong because of
the timers.

There is a trade-off in that there will be no syntax highlightinting when the
user is typing. I don't know how to keep existing fontification so it would be
great if somebody could share a solution to that.

I have signed the copyright papers so that shouldn't be a problem. This is my
first patch submission so any suggestions for improvement are welcome.

Leo Okawa Ericson (1):
  org-src.el: Add option to delay fontification of source blocks

 lisp/org-src.el | 29 +
 1 file changed, 29 insertions(+)

-- 
2.25.1




Re: Refile Targets Custom Function Support

2021-01-30 Thread Leo
Kevin Foley  writes:

> I'd like to use an `org-ql' query in order to get eligible targets when
> calling `org-refile'.
>
I actually also wanted to do that a couple of weeks ago. I ended up
using org-ql and completing-read to select a target. The last optional
argument to org-refile lets you specify a location to refile to.

I have shared this code in my dotfiles:
https://github.com/Zetagon/literate-dotfiles/blob/master/config.org#refiling
. Keep in mind that it depends on dash.el too. I also discussed this in
an issue in org-ql: https://github.com/alphapapa/org-ql/issues/177




Re: ob-haskell

2021-01-04 Thread Leo
Lawrence Bottorff  writes:

> Enclosing code in :{ ... :} is fairly good -- again you can type this in at
> the REPL prompt and see how it works -- however, there are gotchas.
>

I don't think I understand what the problem is with :{ ... :}. Doing
this manually has worked pretty well for me.

>
> What would be nice is if a C-c C-c inside a block could somehow act as
> though the ghci were being sent a regular  *.hs buffer in haskell-mode --
> and that, of course, cumulatively. C-' creates a decent haskell-mode
> environment, BTW, so some form of a babel block to haskell-mode connection
> does exist
>

This makes a lot of sense in many cases. One case that I think it might
be suboptimal in is when I have a heavy computation that generates
some data. Then I would want to try to do a bunch of things to that data
which means that reloading everything would be suboptimal.

I don't know how other babel plugins work, but the way I enjoy working
with ghci the most is to load in a file to ghci and then test a bunch of
expressions in the repl. Maybe ob-haskell could work like this as well,
with one type of block that loads the code as a file and another block
that just sends the code to the repl. There are some problems here that
needs to be sorted out though. For example should each block of the
former type be loaded in its own module or should all of the code blocks
be loaded in the same module? 


/A sporadic user of ob-haskell



Re: Clock tables and two ways to categorize tasks

2020-11-20 Thread Leo Okawa Ericson


Some time ago I hacked together a bunch of elisp to create a clock table
based on tags. [1] It uses org's dynamic block feature[2] to create a
piechart with gnuplot and a simple table that shows percentages of time
spent on different tags. I should say that it has basically no
documentation at all, but if there is interest I could write something
to explain the basic usage at least.

[1] https://github.com/Zetagon/dotfiles/blob/master/doom/pichart-property.el

[2] https://orgmode.org/manual/Dynamic-Blocks.html




Re: S-RET

2020-11-16 Thread Leo
Juri Linkov  writes:
>
> What I miss in Org Babel is an equivalent of 'S-RET' that in Jupyter
> creates a new code block relative to the current code block.

'C-c C-v C-d' (org-babel-demarcate-block) splits current code block into
two with the same settings. It might be what you want. Just bind it to
something easier to access maybe :P

/Leo



Re: New website - back to the old unicorn!

2020-10-26 Thread Leo Vivier
Hi there,

TEC  writes:

> These issues have now been fixed! Go wild :P

I really like the new design.  You’ve done some fantastic work, Timoty,
as well as all the people who’ve contributed. :)

I especially like the new page for Tools:
https://orgmode.org/tools.html

The only nitpick I’d have on that page is that we’re grabbing the
picture from remote domains, which means that users of uMatrix have to
greenlight them before they can be displayed.  A solution could be to
host them ourselves, which should have a minimal footprint.

Best,

-- 
Leo Vivier
Freelance Software Engineer
Website: www.leovivier.com | Blog: www.zaeph.net



Re: Shower thought: submit an IETF RFC to register Org as a MIME type

2020-10-24 Thread Leo Vivier
Bastien  writes:

> Sorry, perhaps I was not clear: (1) and (2) do not need to be separate
> documents.

No, you were quite clear.  I just surmised that two documents would be
required, but upon thinking about it some more, (1) and (2) would make
for a cohesive whole.

> Great, thanks for volunteering.  I think this is something you should
> perhaps do with a long time Org user, ping-pong'ing with commits, not
> alone.

Sure, I’d be up for that.

> Would it be okay for you if we rename worg/dev/org-syntax.org to
> something like worg/dev/org-elements-syntax.org or would that be
> confusing?

Since we already have worg/dev/org-element-api.org [1], I think the
rename to worg/dev/org-element-syntax.org would be welcome.

Notes :
[1] https://orgmode.org/worg/dev/org-element-api.html

-- 
Leo Vivier
Freelance Software Engineer
Website: www.leovivier.com | Blog: www.zaeph.net



Re: Shower thought: submit an IETF RFC to register Org as a MIME type

2020-10-24 Thread Leo Vivier
Hi there,

Bastien  writes:

> As the first paragraph says: 
>
>   "This document describes and comments Org syntax as it is currently
>   read by its parser (Org Elements)"
>
> while we need a description of Org's syntax from the point of view of 
> (1) a human writer and (2) any possible Org parser.

I agree that (1) and (2) should be two different documents.  (2) would
be especially interesting since there are quite a few projects afoot to
parse Org documents outside of Emacs:
- go-org (Go)
  https://github.com/niklasfasching/go-org
- orgize (Rust)
  https://docs.rs/orgize/0.8.4/orgize/

They are in various stages of advancement, but a design document would
go a long way in federating those efforts.

> I don't know how difficult it is, but I suspect it is quite a lot of
> work.

I assume that it would be, yes.  However, as someone with a vested
interest in developing an efficient external parser for Org documents,
I’d love to contribute.  I’ve been playing around lately with ox.el to
write an exporter to Jupyter (more on that soon), and since it makes
extensive use of org-element.el, I’d have a modicum of knowledge upon
which I could initiate the effort.

Best,

-- 
Leo Vivier
Freelance Software Engineer
Website: www.leovivier.com | Blog: www.zaeph.net



Re: a catastrophic orgmode issue - a definite show stopper, put on your tin hats

2020-09-06 Thread Leo Vivier
Hi there,

hj-orgmod...@hj.proberto.com writes:

>   Aliens! Beware! ... We will be looking for Bastien. Give us back our 
> Bastien, or you will have a war on your hands!

Before waging war, please make sure to get a copyright assignment from
them.  We wouldn’t want to have an intergalactic hold-up on the next
release.

Best,

-- 
Leo Vivier
Freelance Software Engineer
Website: www.leovivier.com | Blog: www.zaeph.net



Re: [PATCH] org-capture: Update plist before finalizing

2020-09-05 Thread Leo Vivier
Hi there,

Kyle Meyer  writes:

> Thanks for the detailed write-up and the patch (and sorry for the slow
> reply).

No worries, and thanks for the review.

> It'd be good to at least point to the motivation/usecase for this change
> here.  (Your description section above already does a nice job of
> that.)

Done.  I’ve also added a link to this thread.

> Convention nit: please end your comment with a period.

Done.

> Perhaps add a brief mention of `org-capture-after-finalize' (or some
> other hint of why) here.

I’ve added some details to bridge the gap with the docstring for
`org-capture-current-plist'.

You’ll find the amended commit below.

Best,

-- 
Leo Vivier
Freelance Software Engineer
Website: www.leovivier.com | Blog: www.zaeph.net
>From ab47e50dae4029622d3e8378f816f77153c180d9 Mon Sep 17 00:00:00 2001
From: Leo Vivier 
Date: Sat, 25 Jul 2020 21:53:07 +0200
Subject: [PATCH] org-capture: Update plist before finalizing
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* lisp/org-capture.el (org-capture-finalize): Update
`org-capture-plist' with local-value before finalizing.

We use the global-variable `org-capture-plist' to populate the
local-variable `org-capture-current-plist' on the init of the
`org-capture' buffer.  However, we do not do the opposite (i.e. update
the global-variable with the local-variable) on
`org-capture-finalize'.

This is fine for the majority of `org-capture-finalize', since we’re
using the LOCAL arg of `org-capture-get' to read
`org-capture-current-plist' instead of `org-capture-list', but this
trick does not work for `org-capture-after-finalize', since the hook
is run after the `org-capture-buffer' has been closed.

This causes problem with `:kill-buffer t', and it limits what can be
done with cleanup functions in `org-capture-after-finalize'.

See <https://orgmode.org/list/87h7tv9pkm.fsf@hidden/> for details.
---
 lisp/org-capture.el | 5 +
 1 file changed, 5 insertions(+)

diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index 0ca75c772..b74978c82 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -735,6 +735,11 @@ captured item after finalizing."
 
   (run-hooks 'org-capture-prepare-finalize-hook)
 
+  ;; Update `org-capture-plist' with the buffer-local value.  Since
+  ;; captures can be run concurrently, this is to ensure that
+  ;; `org-capture-after-finalize-hook' accesses the proper plist.
+  (setq org-capture-plist org-capture-current-plist)
+
   ;; Did we start the clock in this capture buffer?
   (when (and org-capture-clock-was-started
 	 org-clock-marker
-- 
2.28.0



[PATCH] org-capture: Update plist before finalizing

2020-07-25 Thread Leo Vivier
Hi there,

I’m working on the parallelisation of `org-capture' for Org-roam, and
I’ve run into a problem with the updating of `org-capture-plist'.

;;-
;; DESCRIPTION
;;-
We use the global-variable `org-capture-plist' to populate the
local-variable `org-capture-current-plist' on the init of the
`org-capture' buffer.  However, we do not do the opposite (i.e. update
the global-variable with the local-variable) on `org-capture-finalize'.

This is fine for the majority of `org-capture-finalize', since we’re
using the LOCAL arg of `org-capture-get' to read
`org-capture-current-plist' instead of `org-capture-list', but this
trick does not work for `org-capture-after-finalize', since the hook is
run after the `org-capture-buffer' has been closed.

This causes problem with `:kill-buffer t', and it limits what can be
done with cleanup functions in `org-capture-after-finalize'.

;;-
;; DEMONSTRATION
;;-
Tested in emacs -Q.

Summary:
- Start a capture process (A)
- Start another capture process (B)
- Cancel B
- Cancel A

Form:
[START]
;; Eval the following form:
(progn
  (setq org-capture-templates
'(("a" "foo" plain (file "/tmp/foo.org") "* %?"
   :kill-buffer t)
  ("b" "bar" plain (file "/tmp/bar.org") "* %?"
   :kill-buffer t)))
  (let* ((a (save-window-excursion
  (org-capture nil "a")
  (current-buffer)))
 (b (save-window-excursion
  (org-capture nil "b")
  (current-buffer
(with-current-buffer b
  (org-capture-kill))
(with-current-buffer a
  (org-capture-kill

;; Result: (error "Selecting deleted buffer")
;; `foo.org' is still alive
-[END]-

;;-
;; ANALYSIS
;;-
The problem happens during `org-capture-after-finalize'. A’s
`org-capture-finalize' does not update `org-capture-plist' with the value
of `org-current-capture-plist' during its execution, which means that
`org-capture-plist' still holds B’s value, including :buffer.  Since B’s
base-buffer was killed, :buffer points to a killed buffer, which is what
is raising the error.

;;-
;; PATCH
;;-
I propose to update `org-capture-plist' early in `org-capture-finalize'.
I don’t think this would have unforeseen effects, since
`org-capture-list' is already meant to be transient, and we’d only be
expanding its use from init-only to init-and-exit.

HTH,

-- 
Leo Vivier
>From d14f15ab76d60c3f65837a6d14712dadabf324bf Mon Sep 17 00:00:00 2001
From: Leo Vivier 
Date: Sat, 25 Jul 2020 21:53:07 +0200
Subject: [PATCH] org-capture: Update plist before finalizing

* lisp/org-capture.el (org-capture-finalize): Update
`org-capture-plist' with local-value before finalizing.
---
 lisp/org-capture.el | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index 2cc1ce394..223ed4124 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -728,6 +728,9 @@ captured item after finalizing."
 
   (run-hooks 'org-capture-prepare-finalize-hook)
 
+  ;; Update `org-capture-plist' with the local-value
+  (setq org-capture-plist org-capture-current-plist)
+
   ;; Did we start the clock in this capture buffer?
   (when (and org-capture-clock-was-started
 	 org-clock-marker
-- 
2.27.0



Re: [PATCH] org: Update example in docstring to accommodate new name and new format

2020-07-22 Thread Leo Vivier
Hi there,

Kyle Meyer  writes:

> Thanks.  Applied (c9abb4c29), adding a period after the changelog
> description.

Splendid, thank you for the merge, and sorry for the period.

> I also added a TINYCHANGE cookie based on your status listed at
> <https://orgmode.org/worg/org-contribute.html>.  You're bumping up
> against the tiny change threshold, so please consider submitting the
> copyright assignment paperwork.

I have already filled the paperwork, and I will send you the scan in
a separate email.  Could you move me to the list of current
contributors?

Thanks.

Best,

-- 
Leo Vivier



Re: [PATCH] org: Update example in docstring to accommodate new name and new format

2020-07-22 Thread Leo Vivier
Hi there,

Kyle Meyer  writes:

> Anyway, in my view the example doesn't really add much value.  What do
> you think about just removing it?

Yeah, I agree.  I thought it was an interesting way to discover
`condition-case' for those who didn’t know about it, so I think we could
keep the mention.  The example itself can go.

Thanks for the review.

HTH,

-- 
Leo Vivier
>From 48b50f0ebb5d21ca6b337d78a16a203888161d43 Mon Sep 17 00:00:00 2001
From: Leo Vivier 
Date: Mon, 20 Jul 2020 22:11:15 +0200
Subject: [PATCH] org: Remove useless example in docstring

* lisp/org.el (org-find-olp): Remove useless example in docstring
---
 lisp/org.el | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 12a853bd6..9ac513d0c 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -13490,29 +13490,23 @@ completion."
'((effort . identity)
 	 (effort-minutes . org-duration-to-minutes))
nval)
   (when (string= org-clock-current-task heading)
 	(setq org-clock-effort nval)
 	(org-clock-update-mode-line)))
 (run-hook-with-args 'org-property-changed-functions key nval)))
 
 (defun org-find-olp (path  this-buffer)
   "Return a marker pointing to the entry at outline path OLP.
-If anything goes wrong, throw an error.
-You can wrap this call to catch the error like this:
-
-  (condition-case msg
-  (org-mobile-locate-entry (match-string 4))
-(error (nth 1 msg)))
-
-The return value will then be either a string with the error message,
-or a marker if everything is OK.
+If anything goes wrong, throw an error, and if you need to do
+something based on this error, you can catch it with
+`condition-case'.
 
 If THIS-BUFFER is set, the outline path does not contain a file,
 only headings."
   (let* ((file (if this-buffer buffer-file-name (pop path)))
 	 (buffer (if this-buffer (current-buffer) (find-file-noselect file)))
 	 (level 1)
 	 (lmin 1)
 	 (lmax 1)
 	 end found flevel)
 (unless buffer (error "File not found :%s" file))
-- 
2.26.2



Re: [PATCH] org: Update example in docstring to accommodate new name and new format

2020-07-20 Thread Leo Vivier
Hi again,

I forgot a closing paren in the previous commit.  You’ll find an amended
version below, as well as a little more context-lines.  Sorry!

HTH,

-- 
Leo Vivier
>From 01acc00866f14a6e70e3abcb024534c392dc8a27 Mon Sep 17 00:00:00 2001
From: Leo Vivier 
Date: Mon, 20 Jul 2020 22:11:15 +0200
Subject: [PATCH] org: Update docstring

* lisp/org.el (org-find-olp): Update example in docstring to
accommodate new name and new format
---
 lisp/org.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index 12a853bd6..a5d552fc0 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -13494,21 +13494,21 @@ completion."
 	(setq org-clock-effort nval)
 	(org-clock-update-mode-line)))
 (run-hook-with-args 'org-property-changed-functions key nval)))
 
 (defun org-find-olp (path  this-buffer)
   "Return a marker pointing to the entry at outline path OLP.
 If anything goes wrong, throw an error.
 You can wrap this call to catch the error like this:
 
   (condition-case msg
-  (org-mobile-locate-entry (match-string 4))
+  (org-find-olp (list (match-string 4)) t)
 (error (nth 1 msg)))
 
 The return value will then be either a string with the error message,
 or a marker if everything is OK.
 
 If THIS-BUFFER is set, the outline path does not contain a file,
 only headings."
   (let* ((file (if this-buffer buffer-file-name (pop path)))
 	 (buffer (if this-buffer (current-buffer) (find-file-noselect file)))
 	 (level 1)
-- 
2.26.2



[PATCH] org: Update example in docstring to accommodate new name and new format

2020-07-20 Thread Leo Vivier
Hi there,

I’ve spotted an example in a docstring that wasn’t updated when the
command was renamed and moved to another file in
d34786f2279d0fd02e7d0484e36bc22adc760de2.

I took the liberty to update it.

HTH,

-- 
Leo Vivier
>From 83dde9d0735cc6223233aa18c938a4ae14b4c88c Mon Sep 17 00:00:00 2001
From: Leo Vivier 
Date: Mon, 20 Jul 2020 22:11:15 +0200
Subject: [PATCH] org: Update docstring

* lisp/org.el (org-find-olp): Update example in docstring to
accommodate new name and new format
---
 lisp/org.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index 12a853bd6..5900e692a 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -13501,7 +13501,7 @@ If anything goes wrong, throw an error.
 You can wrap this call to catch the error like this:
 
   (condition-case msg
-  (org-mobile-locate-entry (match-string 4))
+  (org-find-olp (list (match-string 4) t)
 (error (nth 1 msg)))
 
 The return value will then be either a string with the error message,
-- 
2.26.2



texinfo manual links not working?

2020-06-20 Thread Leo Alekseyev
M-x org-store-link tells me "No method for storing a link from this
buffer", and info: type is not in the list when I try to insert a link
via C-c C-l. Has the support been deprecated or is there a problem
with my system?



Re: Get Grades Done: the joys of Org's simple power

2020-06-13 Thread Leo Okawa Ericson
Diego Zamboni  writes:

> Hi Leo,
>
> Thanks - I had seen that one too, and couldn't figure out which one
> was a fork of the other one. Both have recent activity - do you know
> what are the main differences between them?
>

Well the changelog in org-web hasn't been updated in quite a while:
https://github.com/DanielDe/org-web/blob/master/changelog.org
wheras organice seem to actively developed
https://github.com/200ok-ch/organice/blob/master/changelog.org .

The have a section in their readme that shows how they differ: 
https://github.com/200ok-ch/organice#org-web



Re: Get Grades Done: the joys of Org's simple power

2020-06-12 Thread Leo Okawa Ericson
Diego Zamboni  writes:

> Hi Devin,
>
> Your could try https://org-web.org/ - it allows online editing of Org files
> and a quick test shows that it supports the automatic update of checkbox
> counts.

Or you could try https://github.com/200ok-ch/organice - it is a friendly
fork of org-web.



Re: [PATCH] org-element.el: Fix properties being upcased by parser

2020-06-11 Thread Leo Vivier
Hello,

Nicolas Goaziou  writes:

> Leo Vivier  writes:
>
>> Yeah, I’ve reached the same conclusion, and I agree that we could
>> mention the normalisation in a docstring.  Do you want me to take care
>> of it?
>
> Sure! Thank you.

The patch is attached.

HTH,

-- 
Leo Vivier
>From e96e96931109026f406b3cabb0186319e902aca7 Mon Sep 17 00:00:00 2001
From: Leo Vivier 
Date: Fri, 12 Jun 2020 06:45:32 +0200
Subject: [PATCH] org-element.el: Update comment

* org-element.el (org-element-keyword-parser): Mention that `keyword'
is normalized by being upcased
---
 lisp/org-element.el | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index a5641e6ee..a693cb68d 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -2174,9 +2174,9 @@ the buffer position at the beginning of the first affiliated
 keyword and CDR is a plist of affiliated keywords along with
 their value.
 
-Return a list whose CAR is `keyword' and CDR is a plist
-containing `:key', `:value', `:begin', `:end', `:post-blank' and
-`:post-affiliated' keywords."
+Return a list whose CAR is a normalized `keyword' (uppercase) and
+CDR is a plist containing `:key', `:value', `:begin', `:end',
+`:post-blank' and `:post-affiliated' keywords."
   (save-excursion
 ;; An orphaned affiliated keyword is considered as a regular
 ;; keyword.  In this case AFFILIATED is nil, so we take care of
-- 
2.26.2



[PATCH] org-element.el: Update comment

2020-06-09 Thread Leo Vivier
Hi there,

I’ve noticed that a comment on the caching of org-element wasn’t up to
date, so I went ahead and updated it.  I’ve also fixed a missing quote
for one of the variables.

HTH,

-- 
Leo Vivier
>From bf1fcc1c0650c30e1e12244df084ab344a2cac59 Mon Sep 17 00:00:00 2001
From: Leo Vivier 
Date: Tue, 9 Jun 2020 09:57:03 +0200
Subject: [PATCH] org-element.el: Update comment
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* lisp/org-element.el (org-element-normalize-contents): Update comment

The comment mentions that caching for `org-elements' is enabled by
default, but this isn’t the case anymore since
bbdecd1e64a07b3821714d905a58eaca12828cb6, cf. `org-element-use-cache'.
---
 lisp/org-element.el | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index ac41b7650..a5641e6ee 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -4821,10 +4821,12 @@ indentation removed from its contents."
 ;;
 ;; A single public function is provided: `org-element-cache-reset'.
 ;;
-;; Cache is enabled by default, but can be disabled globally with
+;; Cache is disabled by default for now because it sometimes triggers
+;; freezes, but it can be enabled globally with
 ;; `org-element-use-cache'.  `org-element-cache-sync-idle-time',
-;; org-element-cache-sync-duration' and `org-element-cache-sync-break'
-;; can be tweaked to control caching behavior.
+;; `org-element-cache-sync-duration' and
+;; `org-element-cache-sync-break' can be tweaked to control caching
+;; behavior.
 ;;
 ;; Internally, parsed elements are stored in an AVL tree,
 ;; `org-element--cache'.  This tree is updated lazily: whenever
-- 
2.26.2



Re: [PATCH] org-element.el: Fix properties being upcased by parser

2020-06-08 Thread Leo Vivier
Hi there,

Nicolas Goaziou  writes:

> IMO, this is not worth changing. Besides, I'm quite sure it will break
> some code elsewhere. Why bother?

Yeah, I’ve reached the same conclusion, and I agree that we could
mention the normalisation in a docstring.  Do you want me to take care
of it?

Best,

-- 
Leo Vivier



Re: [PATCH] org-element.el: Fix properties being upcased by parser

2020-06-08 Thread Leo Vivier
Hello,

Nicolas Goaziou  writes:

> This is unrelated to capitalization usage in Org buffers. Upcasing is
> used to tell the difference between, e.g., :value and :VALUE.

I understand, but I think the function is also used to modify
file-parameters like `#+title`.  If you run `org-element-parse-buffer`
on a buffer with the following content:
[START]
#+title: Foo
-[END]-

Here’s what you get:
[START]
(org-data
 nil
 (section
  (:begin 1
   :end 14
   :contents-begin 1
   :contents-end 14
   :post-blank 0
   :post-affiliated 1
   :parent #0)
  (keyword
   (:key "TITLE"   ; <--
:value "Foo"
:begin 1
:end 14
:post-blank 0
:post-affiliated 1
:parent #1
-[END]-

This caused us some head-scratching when we updated Org-roam to use
lower case file-parameters.

Here’s how my Edebug session went:
org-element-parse-buffer
-> org-element--parse-elements
-> org-element--current-element
[START]
   ((looking-at "\\+\\S-+:")
(beginning-of-line)
(org-element-keyword-parser limit affiliated))
-[END]-

Ultimately, it’s not changing anything for the users, but I did find it
a little counterintuitive.

HTH,

-- 
Leo Vivier



[PATCH] org-element.el: Fix properties being upcased by parser

2020-06-08 Thread Leo Vivier
Hi there,

I’ve noticed that `org-element-parser` upcases the keywords, even though
the standard established in 13424336a6f30c50952d291e7a82906c1210daf0 is
to ‘Prefer lower case letters for blocks and keywords’.

I’ve changed it to `downcase` to maintain consistency.  This might cause
problems with some hard-coded upper case letters in the codebase, but
I haven’t run into any issue so far.

HTH,

-- 
Leo Vivier
>From 574549a1ab07fd1500111a25d3f1caec4aa40bfb Mon Sep 17 00:00:00 2001
From: Leo Vivier 
Date: Mon, 8 Jun 2020 12:14:55 +0200
Subject: [PATCH] org-element.el: Fix properties being upcased by parser
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* org-element.el (org-element-keyword-parser): Downcase properties
instead of upcasing them.

This is to follow the standard established by
13424336a6f30c50952d291e7a82906c1210daf0 to ‘Prefer lower case letters
for blocks and keywords’.

TINY CHANGE
---
 lisp/org-element.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index ac41b7650..e73b37b2b 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -2184,7 +2184,7 @@ containing `:key', `:value', `:begin', `:end', `:post-blank' and
 (let ((begin (or (car affiliated) (point)))
 	  (post-affiliated (point))
 	  (key (progn (looking-at "[ \t]*#\\+\\(\\S-*\\):")
-		  (upcase (match-string-no-properties 1
+		  (downcase (match-string-no-properties 1
 	  (value (org-trim (buffer-substring-no-properties
 			(match-end 0) (point-at-eol
 	  (pos-before-blank (progn (forward-line) (point)))
-- 
2.26.2



Re: Is there a way to export only a subtree of a document to LaTeX (or anywhere)?

2020-05-25 Thread Leo Okawa Ericson
Kyle Meyer  writes:

> Vladimir Nikishkin writes:
>
> When you enter the export dispatch, you should see an "Export scope"
> option bound to C-s.  That toggles between buffer and subtree export.

I think it also works to narrow the buffer to what you want to export.
Calling org-narrow-to-subtree and then exporting will export only that
subtree (at least for me).



[PATCH] Fix typo in doc

2020-04-19 Thread Leo Vivier
Hello,

I’ve spotted a small mistake in the doc.

Best,

-- 
Leo Vivier
>From b2b2582b4eb1deb1a41f200a17876dfbcbf26b5e Mon Sep 17 00:00:00 2001
From: Leo Vivier 
Date: Sun, 19 Apr 2020 12:01:30 +0200
Subject: [PATCH] * lisp/org.el (org-mode-map): fix typo

---
 lisp/org-keys.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org-keys.el b/lisp/org-keys.el
index 066720fdf..d358da763 100644
--- a/lisp/org-keys.el
+++ b/lisp/org-keys.el
@@ -219,7 +219,7 @@
 ;;; Variables
 
 (defvar org-mode-map (make-sparse-keymap)
-  "Keymap fo Org mode.")
+  "Keymap for Org mode.")
 
 (defvaralias 'org-CUA-compatible 'org-replace-disputed-keys)
 
-- 
2.26.0



Bug: Org with auto-fill does not insert linebreaks properly [9.3 (release_9.3 @ /snap/emacs/current/usr/share/emacs/27.0.90/lisp/org/)]

2020-04-12 Thread Leo Alekseyev
Consider the following text:
begin example
---
---
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do
---
---
end example-

With auto-fill mode on, continuing to type on the "Lorem ipsum"
line results in the following:
begin example
---
---
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do
---eiusmod asdf
---
end example-

Notice how "eiusmod" does not start on a new line, as would be expected.
Here is a GIF of this behavior in action:
https://www.dropbox.com/s/w9a803t0qotqe6j/org_autofill_bug.gif?dl=0

Tested with emacs -Q, org 9.3 (lisp that ships with emacs 27)


[PATCH] Fix small mistake in doc

2020-04-08 Thread Leo Vivier
Hello,

I’ve noticed a small mistake in the doc for `org-time-stamp-inactive`.
You’ll find the details in the patch.

HTH.

Best,

-- 
Leo Vivier

>From 021dd8d98b7d8e86fcfdff659cb225be6dc51939 Mon Sep 17 00:00:00 2001
From: Leo Vivier 
Date: Wed, 8 Apr 2020 10:22:20 +0200
Subject: [PATCH] org: Fix doc
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* lisp/org.el (org-time-stamp-inactive): Change ‘active’ to ‘inactive’
in the doc
---
 lisp/org.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index 57682fd16..a46b1c56b 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -13466,7 +13466,7 @@ If the user specifies a time like HH:MM or if this command is called with
 at least one prefix argument, the time stamp contains the date and the time.
 Otherwise, only the date is included.
 
-When called with two universal prefix arguments, insert an active time stamp
+When called with two universal prefix arguments, insert an inactive time stamp
 with the current time without prompting the user."
   (interactive "P")
   (org-time-stamp arg 'inactive))
-- 
2.25.1



DST and appointments in other timezones

2019-11-13 Thread Leo Gaspard
Hello world,

I have appointments that are scheduled on timezones other than my
computer's. Does org-mode support setting that? It looks like timestamps
don't support adding a timezone, so I'm wondering whether there's a
reasonable way to use s-expressions in timestamps for this?

Well, ideally org-mode could be adapted to support timestamps in
arbitrary timezones, but I guess there are reasons why that's not
supported?

Cheers, and huge thanks to all the devs and people who answer questions
like these!
  Leo



org-capture fails to insert link even on :immediate-finish templates

2019-11-02 Thread Leo Gaspard
Hello,

I have an org-capture template with :immediate-finish t. In
notmuch-mode, it looks like org-capture support is not implemented yet
for the search interfaces, and so when capturing on these interfaces
(without noticing), I get a capture without the link.

Is it possible to make org-capture fail loudly when capturing a
=:immediate-finish t= template for which all the substitutions didn't
succeed, instead of just having empty strings at the substitution
locations?

Thank you!
  Leo



[O] Org-agenda and error in tags position

2019-05-16 Thread leo

Hi! I write because I am experiencing a problem with org agenda and
more precisely with the positioning of the tags which as can be seen
from the screenshot are always displayed on a new line (while I expect
them to be displayed to the right of the task).
It only happens with org-agenda. In .org files the display is correct

The problem is with Org 9.2.3 and Emacs 26.1 on xubuntu 19.04.

Here a screenshot of how the org-agenda view appears:
https://share.riseup.net/#E1pz3vlYKm27KKTSTQE6qg

I also tried a new .emacs configuration but nothing changes.

Here the part of my configuration concerning org agenda:
https://pad.riseup.net/p/Nv-AnovgxUkUlXwz3HzC

I researched but did not find similar situations and a solution on the
web.

Can you
give me a hand?

Thanks a lot,

--
leo



Re: [O] [PATCH] Fix narrowed 1-line subtrees

2019-02-23 Thread Leo Vivier
Hello,

Samuel Wales  writes:

> most users and many writers of code are likely to mark a region by
> going to bol, not eol.  they don't likely think the region should end
> before the final newline, in most cases.

I don't know about most users, but that's what I do.  It's easier to
mark the beginning of a region and then `forward-line' your way to the
end of the region.

> but org calls some outline function or two that grabs or narrows to or
> marks a region that is shorter by 1 char than imo it should be.

I'm not sure.  It might be a case of Stockholm syndrome, but I've found
that not including the final newline in the narrowed subtree holds some
semantic value, especially when you like to keep your .org files tight
with only 1 newline between two headings, i.e. `*Tree 1^J*Tree 2'.

When `(org-end-of-subtree t)' lands you somewhere where the hl-line does
not extend to the right fringe, it means that you (or a misbehaving
commands) haven't introduced any spurious newline.

> i reported one bug, which joined two lines [including headers], that
> had remained unfixed for many years.
>
> this is probably because noticing certain types of data corruption /at
> the time of corruption/ can sometimes be tricky.  thus, linking it to
> user behavior or org code changes can be tricky and the bug report
> would be like "um, i have no mwe but...".

Thank you for your insight.  I think this is something we could address
with an arsenal of tests.  The idea would be to run in a narrowed
subtree all the commands which would add or remove content below it.
Then, we widen the buffer and check whether the following tree has been
corrupted.  I'll get on it as soon as I can.

> in this particular case, when you did find joined lines, it was likely
> to be long after the corruption.  [low s/n.]
>
> the problem was that when you sorted headers in a narrowed region, it
> joined lines.  the region was off by one because the outline function
> is [imo] off by one.
>
> it would not surprise me if long-term users checked their files now
> for joined lines, such as headers, they'd find old corruption.

Maybe we could add a function to `org-lint' which would throw a warning
when a regex like "\\(\\sw\\|\\s.\\)\\(\\* .*$\\)" matches something.

With the following structure:
[START]
* Test 1* Corrupted 1

* Test 2
With text in the body.* Corrupted 2

* Test 3 * Not corrupted
-[END]-
The regex correctly matches `Corrupted 1' and `Corrupted 2', but we'd
obviously need to find a way to make it safer.  But as it stands, it
could be used as a way to address past corruptions.

So, to recap:
1. We address *potential corruptions* by adding more tests in order to
   catch them before they get a chance to corrupt anything.
2. We address *past corruptions* by adding a function to `org-lint'
   which catches corrupted subtrees and throw a warning.

HTH.

Best,
-- 
Leo Vivier
English Studies & General Linguistics
Master Student, English Department
Université Rennes 2



Re: [O] [PATCH] Fix narrowed 1-line subtrees

2019-02-22 Thread Leo Vivier
Hello,

Samuel Wales  writes:

> i have not been able to follow this conversation, but is it possible
> that /all/ of this complexity is due to outline-mode's dubious choice
> of not considering the final newline in an entry to be part of an
> entry?

I don't know much about outline-mode, but I doubt it would be the case.
In my email sent on Thu, 21 Feb 2019 16:41:43 +0100, I've investigated
the problem, and one of my conclusions was the following:

[START]
Going back to our example, if narrowing to a 1-line subtree included
that last newline, we could delete it inside our narrowed buffer.  If
that newline was also the beginning of a new subtree, the subtree
would not be functional anymore, since we'd end up with something like
this: `*Subtree 1* Subtree 2'.
-[END]-

So, if we kept the newline, we'd put the user at risk of breaking the
following subtree.  An option could be to protect that newline by
modifying our deletion commands, but after having done that in a
previous implementation, it'd bring its fair share of complexity.

>From my point of view, I do not see it as 'complex', but rather as a
different way from doing what we'd been doing so far.  Most of the
functions are only *slightly* modified to preserve the ambiguous
newline.

HTH.

Best,
-- 
Leo Vivier
English Studies & General Linguistics
Master Student, English Department
Université Rennes 2



Re: [O] [PATCH] Fix narrowed 1-line subtrees

2019-02-22 Thread Leo Vivier
Hello again,

Leo Vivier  writes:

> You'll find those three patches at the bottom alongside another with all
> the patches until now squashed together (except the patch for
> `org-remove-timestamp-with-keyword' which wasn't related).

I ended up sending the wrong patch, i.e. the one for
`org-remove-timestamp-with-keyword'.  You'll find the squashed patch
below.

Sorry for that.

Best,
-- 
Leo Vivier
English Studies & General Linguistics
Master Student, English Department
Université Rennes 2
>From c00c911f06ba059b61d8246f25e679f06a8f8491 Mon Sep 17 00:00:00 2001
From: Leo Vivier 
Date: Thu, 21 Feb 2019 00:16:27 +0100
Subject: [PATCH] Fix narrowed 1-line subtrees (squashed)

* lisp/org.el (org-add-planning-info): Ensure insertion in current
  restriction.
  (org-remove-timestamp-with-keyword): Respect ambiguous newline when
  narrowed to 1-line-subtree.
  (org-remove-empty-drawer-at): Respect ambiguous newline when
  narrowed to 1-line subtree.
  (org-entry-delete): Respect ambiguous newline when narrowed to
  1-line subtree.
  (org-log-beginning): Ensure insertion in current restriction.
  (org-store-log-note): Ensure insertion in current restriction.

* lisp/org-clock.el (org-clock-find-position): Ensure clock-drawer
  insertion in current restriction.
  (org-clock-in): Ensure insertion in current
  restriction.

This patch addresses multiple issues occuring when running commands on
a 1-line subtree when the buffer is narrowed to it.  A 1-line subtree
is a subtree only containing a heading and a newline at the end.

Typical problem:
---
* Tree 1
:PROPERTIES:
:TEST: t
:END:
* Tree 2
---
With point on `Tree 1', run the following:
(progn
  (org-narrow-to-subtree)
  (org-delete-property "TEST")
  (org-back-to-heading)
  (end-of-line)
  (delete-char 1)
  (widen))

Result:
---
* Tree 1* Tree 2
---

Observation:
The newline between the two headings has been removed despite the fact
that it wasn't in the buffer restriction.

The problem is due to two things:
- The way that narrowing works in Emacs, notably how restrictions are
  restored after `save-restriction'.
- The ambiguous newline between the end of a 1-line subtree and a
  following subtree.

The solution is to stop the problematic commands from interacting with
the ambiguous newline in order to preserve the narrowed region's
`point-max'.  This is done by inserting or removing newlines from
the top of a heading rather than its bottom.

Visually, instead of deleting the following bracketed region...
---
* Tree 1
{:PROPERTIES:
:TEST: t
:END:
}* Tree 2
---

We delete the following one:
---
* Tree 1{
:PROPERTIES:
:TEST: t
:END:}
* Tree 2
---

org-log-beginning: Fix drawer creation

* lisp/org.el

This commit ensures that the log-drawer for state-changes and notes is
created within the current restriction.

org-store-log-note: Fix drawer-less logging

* lisp/org.el (org-log-beginning):
---
 lisp/org-clock.el | 14 --
 lisp/org.el   | 27 +++
 2 files changed, 23 insertions(+), 18 deletions(-)

diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index b20158df6..5c9b0a1cf 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -1292,6 +1292,7 @@ the default behavior."
 		(org-todo org-clock-in-switch-to-state)))
 	 (setq org-clock-heading (org-clock--mode-line-heading))
 	 (org-clock-find-position org-clock-in-resume)
+	 (forward-char -1)
 	 (cond
 	  ((and org-clock-in-resume
 		(looking-at
@@ -1315,8 +1316,8 @@ the default behavior."
 	   (sit-for 2)
 	   (throw 'abort nil))
 	  (t
-	   (insert-before-markers "\n")
-	   (backward-char 1)
+	   (insert "\n")
+	   (org-indent-line)
 	   (org-indent-line)
 	   (when (and (save-excursion
 			(end-of-line 0)
@@ -1508,12 +1509,13 @@ line and position cursor in that line."
 	  (when (and org-clock-into-drawer
 		 (or (not (wholenump org-clock-into-drawer))
 			 (< org-clock-into-drawer 2)))
-	(let ((beg (point)))
-	  (insert ":" drawer ":\n:END:\n")
+	(let ((beg (1- (point
+	  (forward-char -1)
+	  (insert "\n:" drawer ":\n:END:")
 	  (org-indent-region beg (point))
 	  (org-flag-region
-	   (line-end-position -1) (1- (point)) t 'org-hide-drawer)
-	  (forward-line -1
+	   (line-end-position 0) (point) t 'org-hide-drawer)
+	  (beginning-of-line
 	 ;; When a clock drawer needs to be

Re: [O] [PATCH] Fix narrowed 1-line subtrees

2019-02-22 Thread Leo Vivier
Hello,

I've found and fixed three new functions which didn’t behave properly
when the buffer was restricted to a subtree:
* lisp/org.el (org-log-beginning): Fix drawer creation.
* lisp/org.el (org-store-log-note): Fix drawer-less logging.
* lisp/org-capture.el (org-clock-in): Fix drawer-less clocking.

You'll find those three patches at the bottom alongside another with all
the patches until now squashed together (except the patch for
`org-remove-timestamp-with-keyword' which wasn't related).

HTH.

Best,
-- 
Leo Vivier
English Studies & General Linguistics
Master Student, English Department
Université Rennes 2
>From 745e106406a5f5b296bbd9dbda9f9dbd965a2e30 Mon Sep 17 00:00:00 2001
From: Leo Vivier 
Date: Fri, 22 Feb 2019 18:03:24 +0100
Subject: [PATCH 1/3] org-log-beginning: Fix drawer creation

* lisp/org.el (org-log-beginning): Ensure insertion in current
  restriction.

This commit ensures that the log-drawer for state-changes and notes is
created within the current restriction.
---
 lisp/org.el | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 4c3c3cd78..f22f8b807 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -13118,12 +13118,13 @@ narrowing."
 	   ;; No drawer found.  Create one, if permitted.
 	   (when create
 	 (unless (bolp) (insert "\n"))
-	 (let ((beg (point)))
-	   (insert ":" drawer ":\n:END:\n")
+	 (let ((beg (1- (point
+	   (forward-char -1)
+	   (insert "\n:" drawer ":\n:END:")
 	   (org-indent-region beg (point))
 	   (org-flag-region
-		(line-end-position -1) (1- (point)) t 'org-hide-drawer))
-	 (end-of-line -1)
+		(line-end-position 0) (point) t 'org-hide-drawer))
+	 (end-of-line 0)
   (t
(org-end-of-meta-data org-log-state-notes-insert-after-drawers)
(skip-chars-forward " \t\n")
-- 
2.20.1

>From c94c86fdac09a97267c29f7e3d4dcf5c3398 Mon Sep 17 00:00:00 2001
From: Leo Vivier 
Date: Fri, 22 Feb 2019 18:17:35 +0100
Subject: [PATCH 2/3] org-store-log-note: Fix drawer-less logging

* lisp/org.el (org-log-beginning): Ensure insertion in current
  restriction.

This commit ensures that drawer-less state-changes and notes are
created within the current restriction.
---
 lisp/org.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index f22f8b807..27cd2bbd7 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -13263,7 +13263,7 @@ EXTRA is additional text that will be inserted into the notes buffer."
 	 ;; Note associated to a clock is to be located right after
 	 ;; the clock.  Do not move point.
 	 (unless (eq org-log-note-purpose 'clock-out)
-	   (goto-char (org-log-beginning t)))
+	   (goto-char (1- (org-log-beginning t
 	 ;; Make sure point is at the beginning of an empty line.
 	 (cond ((not (bolp)) (let ((inhibit-read-only t)) (insert "\n")))
 	   ((looking-at "[ \t]*\\S-") (save-excursion (insert "\n"
-- 
2.20.1

>From 2fc86ae438725e5f0656c8966eaa4935e0203ee4 Mon Sep 17 00:00:00 2001
From: Leo Vivier 
Date: Fri, 22 Feb 2019 18:23:40 +0100
Subject: [PATCH 3/3] org-clock-in: Fix drawer-less clocking

* lisp/org-clock.el (org-clock-in): Ensure insertion in current
  restriction.

This commit ensures that drawer-less clock-lines are created within
the current restriction.
---
 lisp/org-clock.el | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index 5624af32a..5c9b0a1cf 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -1292,6 +1292,7 @@ the default behavior."
 		(org-todo org-clock-in-switch-to-state)))
 	 (setq org-clock-heading (org-clock--mode-line-heading))
 	 (org-clock-find-position org-clock-in-resume)
+	 (forward-char -1)
 	 (cond
 	  ((and org-clock-in-resume
 		(looking-at
@@ -1315,8 +1316,8 @@ the default behavior."
 	   (sit-for 2)
 	   (throw 'abort nil))
 	  (t
-	   (insert-before-markers "\n")
-	   (backward-char 1)
+	   (insert "\n")
+	   (org-indent-line)
 	   (org-indent-line)
 	   (when (and (save-excursion
 			(end-of-line 0)
-- 
2.20.1

>From bb5a7feee1684cf47f1e8a29805c442c8ae64c37 Mon Sep 17 00:00:00 2001
From: Leo Vivier 
Date: Thu, 21 Feb 2019 12:44:26 +0100
Subject: [PATCH] Fix spaces with `org-remove-timestamp-with-keyword'
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* lisp/org.el (org-remove-timestamp-with-keyword): Fix space deletion
  between timestamps

When an entry had a CLOSED, a DEADLINE and a SCHEDULED timestamps,
removing the middle one caused the space between the 1st and 3rd to be
removed as well.  Checking whether we’re at the end of the line before
deleting the space fixes it.
---
 lisp/org.el | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lisp/org.el b/lisp/org.el
index ef6e40ca9..b8e378e73 100644
---

[O] [PATCH] Fix spaces with `org-remove-timestamp-with-keyword'

2019-02-21 Thread Leo Vivier
* lisp/org.el (org-remove-timestamp-with-keyword): Fix space deletion
  between timestamps

When an entry had a CLOSED, a DEADLINE and a SCHEDULED timestamps,
removing the middle one caused the space between the 1st and 3rd to be
removed as well.  Checking whether we’re at the end of the line before
deleting the space fixes it.
---
Here’s a little unrelated patch for an issue I’ve stumbled upon whilst
testing the previous patch.

 lisp/org.el | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lisp/org.el b/lisp/org.el
index ae9494672..4c3c3cd78 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -12944,6 +12944,7 @@ nil."
   (while (re-search-backward re beg t)
(replace-match "")
(if (and (string-match "\\S-" (buffer-substring (point-at-bol) (point)))
+(eolp)
 (equal (char-before) ?\ ))
(backward-delete-char 1)
  (when (string-match "^[ \t]*$" (buffer-substring
-- 
2.20.1




Re: [O] [PATCH] Fix narrowed 1-line subtrees

2019-02-21 Thread Leo Vivier
e previous restriction,
`save-restriction' looks for those special characters and try to
include them all inside the new restriction.  Practically, this is
done by looking for the first and last characters with that special
property and using them as the new `point-min' and `point-max'.

This last bit is important to understand why the second example with
the :PROPERTIES: drawer didn't behave properly.  The original command
deletes the drawer from the ambiguous newline to the bottom of the
heading, which means that the newline at the end of the heading isn't
touched.  When `save-restriction' attempts to resume the previous
narrowing, since the former `point-max' has been deleted (it was the
`:' at the end of the :PROPERTIES: drawer), it looks for the first
special character. But the problem is that this first character is the
bottom of the heading, and that it has now become ambiguous.

The solution is the same: we do not touch the ambiguous newline.
Instead, we delete the newline at the end of the heading so that upon
restoring the restriction, it becomes the last special character.

Visually, instead of deleting the following bracketed region...
[START]
* Tree 1
{:PROPERTIES:
:TEST: t
:END:
}* Tree 2
-[END]-

We delete the following one:
[START]
* Tree 1{
:PROPERTIES:
:TEST: t
:END:}
* Tree 2
-[END]-

It's likely that I haven't addressed all the commands that do not play
well with the ambiguous newlines.  However, the solutions I've
presented here should be enough to address them.


---


HTH

Best,
--
Leo Vivier
English Studies & General Linguistics
Master Student, English Department
Université Rennes 2



[O] [PATCH] Fix narrowed 1-line subtrees

2019-02-21 Thread Leo Vivier
* lisp/org.el (org-add-planning-info): Ensure insertion in current
  restriction.
  (org-remove-timestamp-with-keyword): Respect ambiguous newline when
  narrowed to 1-line-subtree.
  (org-remove-empty-drawer-at): Respect ambiguous newline when
  narrowed to 1-line subtree.
  (org-entry-delete): Respect ambiguous newline when narrowed to
  1-line subtree.

* lisp/org-clock.el (org-clock-find-position): Ensure clock-drawer
  insertion in current restriction.

This patch addresses multiple issues occuring when running commands on
a 1-line subtree when the buffer is narrowed to it.  A 1-line subtree
is a subtree only containing a heading and a newline at the end.

Typical problem:
---
* Tree 1
:PROPERTIES:
:TEST: t
:END:
* Tree 2
---
With point on `Tree 1', run the following:
(progn
  (org-narrow-to-subtree)
  (org-delete-property "TEST")
  (org-back-to-heading)
  (end-of-line)
  (delete-char 1)
  (widen))

Result:
---
* Tree 1* Tree 2
---

Observation:
The newline between the two headings has been removed despite the fact
that it wasn't in the buffer restriction.

The problem is due to two things:
- The way that narrowing works in Emacs, notably how restrictions are
  restored after `save-restriction'.
- The ambiguous newline between the end of a 1-line subtree and a
  following subtree.

The solution is to stop the problematic commands from interacting with
the ambiguous newline in order to preserve the narrowed region's
`point-max'.  This is done by inserting or removing newlines from
the top of a heading rather than its bottom.

Visually, instead of deleting the following bracketed region...
---
* Tree 1
{:PROPERTIES:
:TEST: t
:END:
}* Tree 2
---

We delete the following one:
---
* Tree 1{
:PROPERTIES:
:TEST: t
:END:}
* Tree 2
---
---
Please see my reply to this message for a detailed account of the
problem and the solution.

 lisp/org-clock.el |  9 +
 lisp/org.el   | 16 +---
 2 files changed, 14 insertions(+), 11 deletions(-)

diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index b20158df6..5624af32a 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -1508,12 +1508,13 @@ line and position cursor in that line."
  (when (and org-clock-into-drawer
 (or (not (wholenump org-clock-into-drawer))
 (< org-clock-into-drawer 2)))
-   (let ((beg (point)))
- (insert ":" drawer ":\n:END:\n")
+   (let ((beg (1- (point
+ (forward-char -1)
+ (insert "\n:" drawer ":\n:END:")
  (org-indent-region beg (point))
  (org-flag-region
-  (line-end-position -1) (1- (point)) t 'org-hide-drawer)
- (forward-line -1
+  (line-end-position 0) (point) t 'org-hide-drawer)
+ (beginning-of-line
 ;; When a clock drawer needs to be created because of the
 ;; number of clock items or simply if it is missing, collect
 ;; all clocks in the section and wrap them within the drawer.
diff --git a/lisp/org.el b/lisp/org.el
index ef6e40ca9..ae9494672 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -12937,7 +12937,7 @@ nil."
   "Remove all time stamps with KEYWORD in the current entry."
   (let ((re (concat "\\<" (regexp-quote keyword) " +<[^>\n]+>[ \t]*"))
beg)
-(save-excursion
+(org-with-wide-buffer
   (org-back-to-heading t)
   (setq beg (point))
   (outline-next-heading)
@@ -12949,7 +12949,8 @@ nil."
  (when (string-match "^[ \t]*$" (buffer-substring
  (point-at-bol) (point-at-eol)))
(delete-region (point-at-bol)
-  (min (point-max) (1+ (point-at-eol))
+  (point-at-eol)
+  (delete-char -1
 
 (defvar org-time-was-given) ; dynamically scoped parameter
 (defvar org-end-time-was-given) ; dynamically scoped parameter
@@ -13046,8 +13047,8 @@ WHAT entry will also be removed."
(unless (= (skip-chars-backward " \t" p) 0)
  (delete-region (point) (line-end-position)))
 ((not what) (throw 'exit nil)) ; Nothing to do.
-(t (insert-before-markers "\n")
-   (backward-char 1)
+(t (backward-char 1)
+   (insert "\n")
(when org-adapt-indentation
  (indent-to-column (1+ 

Re: [O] [PATCH 1/2] Fix narrowing for 1-line subtrees

2019-02-20 Thread Leo Vivier
Hello,

Nicolas Goaziou  writes:

> Thank you. It looks good. Could you write a few tests about that?

I’ve never done it, but it should be pretty easy to figure out how to
write them with all the macros.  I’ll look into it.

I’ll also continue the work on the patch to figure out how to handle the
condition tree for `org-add-planing-info'.

I’ll update you when I’ve made progress.

Thanks.

Best,
-- 
Leo Vivier
English Studies & General Linguistics
Master Student, English Department
Université Rennes 2



Re: [O] [PATCH 1/2] Fix narrowing for 1-line subtrees

2019-02-19 Thread Leo Vivier
Sorry, the patch I've submitted wasn't right: it had part of another
test I was running, hence the `end-of-line'.

Here's the proper version:
[START]
lisp/org.el | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index ef6e40ca9..4514407e7 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -13046,17 +13046,17 @@ WHAT entry will also be removed."
(unless (= (skip-chars-backward " \t" p) 0)
  (delete-region (point) (line-end-position)))
 ((not what) (throw 'exit nil)) ; Nothing to do.
-(t (insert-before-markers "\n")
-   (backward-char 1)
+(t (backward-char 1)
(when org-adapt-indentation
  (indent-to-column (1+ (org-outline-level))
(when what
 ;; Insert planning keyword.
-(insert (cl-case what
-  (closed org-closed-string)
-  (deadline org-deadline-string)
-  (scheduled org-scheduled-string)
-  (otherwise (error "Invalid planning type: %s" what)))
+(insert "\n"
+(cl-case what
+   (closed org-closed-string)
+   (deadline org-deadline-string)
+   (scheduled org-scheduled-string)
+   (otherwise (error "Invalid planning type: %s" what)))
 " ")
 ;; Insert associated timestamp.
 (let ((ts (org-insert-time-stamp
-- 
2.20.1
-----[END]-

Best,
-- 
Leo Vivier
English Studies & General Linguistics
Master Student, English Department
Université Rennes 2



Re: [O] [PATCH 1/2] Fix narrowing for 1-line subtrees

2019-02-19 Thread Leo Vivier
Hello again,

Leo Vivier  writes:

> I was pleased to see that property-adding functions didn't behave badly
> with 1-line subtrees.  Maybe we could investigate those commands and
> patch their behaviour onto the problematic ones?
>
> If that sounds good to you, I could work on it and submit another patch.

I’ve investigated the problem, and I’ve stumbled upon something
interesting.

I’ve started by looking at the differences between `org-set-property'
and `org-schedule' which respectively led me to
`org-insert-property-drawer' and `org-add-planing-info'.  The
interesting difference is in the way they handle newline insertion:


`org-insert-property-drawer':
[START]
...
(insert "\n:PROPERTIES:\n:END:")
...
-[END]-


`org-add-planing-info':
[START]
...  
(insert-before-markers "\n"); Inside a cond
...
(insert (cl-case what   ; Inside a later cond
   (closed org-closed-string)
   ...
   )
 " ")
...
-[END]-


By adapting the `org-add-planing-info' to insert the newline with the
scheduling information, I could get it to insert its text *inside* the
narrowing with a 1-line subtree.

I'm providing a patch at the end of this email, but it's rough around
the edges.  Notably, I didn't have time to make it work with the
condition tree, which means that re-scheduling as well as adding a
deadline on top of a scheduled time results in spurious newlines.

Correct me if I'm wrong, but I believe we'd be departing the 'hackish'
territory with that solution, which would be great.

Here's the patch:
[START]
Move newline insertion

---
 lisp/org.el | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index ef6e40ca9..6c43d9b25 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -13046,18 +13046,19 @@ WHAT entry will also be removed."
(unless (= (skip-chars-backward " \t" p) 0)
  (delete-region (point) (line-end-position)))
 ((not what) (throw 'exit nil)) ; Nothing to do.
-(t (insert-before-markers "\n")
-   (backward-char 1)
+(t (backward-char 1)
(when org-adapt-indentation
  (indent-to-column (1+ (org-outline-level))
(when what
 ;; Insert planning keyword.
-(insert (cl-case what
-  (closed org-closed-string)
-  (deadline org-deadline-string)
-  (scheduled org-scheduled-string)
-  (otherwise (error "Invalid planning type: %s" what)))
+(insert "\n"
+(cl-case what
+   (closed org-closed-string)
+   (deadline org-deadline-string)
+   (scheduled org-scheduled-string)
+   (otherwise (error "Invalid planning type: %s" what)))
 " ")
+(end-of-line)
 ;; Insert associated timestamp.
 (let ((ts (org-insert-time-stamp
        time
-- 
2.20.1
-[END]-

HTH.

Best,
-- 
Leo Vivier
English Studies & General Linguistics
Master Student, English Department
Université Rennes 2



Re: [O] [PATCH 1/2] Fix narrowing for 1-line subtrees

2019-02-19 Thread Leo Vivier
Hello again,

Nicolas Goaziou  writes:

> Hello,
>
> It doesn't work the way `LaTeX-narrow-to-environment' works. In
> particular, AUCTeX's function /does not modify the buffer/. This is
> a big no-no, really.

I see your point, and I understand why it would be strange for narrowing
commands to modify the buffer.  I’d built this patch under three
assumptions:

1. We should only change the interactive behaviour of
  `org-narrow-to-subtree' so as to not disturb other commands/functions.
2. When called interactively, as long as our wrapper for `widen' cancels
   out what's been added by `org-narrow-to-subtree', changing the buffer
   is acceptable.
3. If the buffer were to be closed between `org-narrow-to-subtree' and
   our wrapper for `widen', the only thing you'd have is a spurious
   newline.  This wouldn't be a big deal because some commands in org
   already do that in a narrowed context [1].

That said, I completely understand your reticence and you've made me
understand that my solution was more 'hackish' than I intended it to be.

> I suggest to not use narrowing, then. Maybe try editing remotely
> a subtree, similar to what is done for footnotes. I have the feeling
> this would have its own set of issues, too.

I thought about other options before heading into this.  One of them was
to yank the subtrees to a temporary buffer to edit them and hook onto
the saving commands to update the corresponding buffer accordingly.  In
retrospect, that seems a lot more 'hackish'.  Maybe we could salvage
some of the patch for `org-capture' since it's different from narrowing,
but I've got a better idea.

> It is not about my workflow. I don't use 1-line subtrees. But anything
> related to narrowing or widening should not alter the buffer, per
> design. I may sound stubborn, but I don't think this is a way to handle
> the problem.

I'd like to suggest a middle ground which I think would be more
acceptable.  You've asked me in a previous exchange to make a list of
the commands which didn't work as expected when the buffer was narrowed
to a 1-line subtree [2].  Would it be possible to patch those commands
so that they conditionally refresh the narrowing of the buffer if the
information they add would be spawned *outside* of the restriction?

The rationale behind it is that, in Emacs, commands trying to act on
regions outside the current restriction throw an error.  Therefore, in
the context of 1-line subtrees, we could justify that conditional
behaviour by saying that it prevents your command from working outside
of the current restriction.

I was pleased to see that property-adding functions didn't behave badly
with 1-line subtrees.  Maybe we could investigate those commands and
patch their behaviour onto the problematic ones?

If that sounds good to you, I could work on it and submit another patch.

Thank you.

HTH.


Footnotes:
[1] As a quick aside, here's an example for 3. where X represents `point':
[START]
\|   * Tree
\|   |X1|2|
-[END]-
When narrowed (or at the end of a buffer), if you press :
- `point' moves to '2'.
- Table is realigned.
- Newline is added at the end of the table.

[2] We've already addressed `org-clock-out-when-done', but I've found
another one.  Although adding scheduling/deadline information works
within a 1-line subtree (the information isn't visible, but it's there
in the widened buffer), you cannot remove them from within that
environment.


Best,
-- 
Leo Vivier
English Studies & General Linguistics
Master Student, English Department
Université Rennes 2



[O] [PATCH] Fix narrowing for 1-line subtrees (squashed)

2019-02-19 Thread Leo Vivier


This is a squashed version of all the commits I’ve done on that
branch to make it easier to apply.
---
 lisp/org-capture.el | 12 ++--
 lisp/org-keys.el|  2 ++
 lisp/org.el | 69 -
 3 files changed, 67 insertions(+), 16 deletions(-)

diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index debf1808c..fbc601875 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -746,7 +746,7 @@ captured item after finalizing."
   (let ((abort-note nil))
 ;; Store the size of the capture buffer
 (org-capture-put :captured-entry-size (- (point-max) (point-min)))
-(widen)
+(org-widen)
 ;; Store the insertion point in the target buffer
 (org-capture-put :insertion-point (point))
 
@@ -1416,8 +1416,14 @@ Of course, if exact position has been required, just put 
it there."
 (defun org-capture-narrow (beg end)
   "Narrow, unless configuration says not to narrow."
   (unless (org-capture-get :unnarrowed)
-(narrow-to-region beg end)
-(goto-char beg)))
+(narrow-to-region
+ (goto-char beg)
+ (save-excursion
+   (org-end-of-subtree t t)
+   (when (and (org-at-heading-p) (not (eobp)))
+ (backward-char 1)
+ (insert "\n"))
+   (point)
 
 (defun org-capture-empty-lines-before ( n)
   "Set the correct number of empty lines before the insertion point.
diff --git a/lisp/org-keys.el b/lisp/org-keys.el
index d103957a9..26a3852b3 100644
--- a/lisp/org-keys.el
+++ b/lisp/org-keys.el
@@ -532,6 +532,8 @@ COMMANDS is a list of alternating OLDDEF NEWDEF command 
names."
   'delete-char'org-delete-char
   'delete-backward-char   'org-delete-backward-char
   'kill-line  'org-kill-line
+  'kill-region'org-kill-region
+  'widen  'org-widen
   'open-line  'org-open-line
   'yank   'org-yank
   'comment-dwim   'org-comment-dwim
diff --git a/lisp/org.el b/lisp/org.el
index ef6e40ca9..1f662a01a 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -4415,6 +4415,13 @@ If yes, offer to stop it and to save the buffer with the 
changes."
   (when (org-match-line "^[ \t]*#\\+BEGIN:[ \t]+clocktable\\>")
 (org-clocktable-shift dir n)))
 
+(defun org-tree-check-narrowing ()
+  "Check if the current buffer is a narrowed indirect subtree.
+If yes, widen the buffer."
+  (when (and (derived-mode-p 'org-mode)
+(buffer-base-buffer))
+(org-widen)))
+
 ;;;###autoload
 (defun org-clock-persistence-insinuate ()
   "Set up hooks for clock persistence."
@@ -5369,6 +5376,7 @@ The following commands are available:
   (add-hook 'before-change-functions 'org-before-change-function nil 'local)
   ;; Check for running clock before killing a buffer
   (add-hook 'kill-buffer-hook 'org-check-running-clock nil 'local)
+  (add-hook 'kill-buffer-hook 'org-tree-check-narrowing nil 'local)
   ;; Initialize macros templates.
   (org-macro-initialize-templates)
   ;; Initialize radio targets.
@@ -7392,7 +7400,9 @@ frame is not changed."
   (setq beg (point)
heading (org-get-heading 'no-tags))
   (org-end-of-subtree t t)
-  (when (org-at-heading-p) (backward-char 1))
+  (when (and (org-at-heading-p) (not (eobp)))
+  (backward-char 1)
+  (insert "\n"))
   (setq end (point)))
 (when (and (buffer-live-p org-last-indirect-buffer)
   (not (eq org-indirect-buffer-display 'new-frame))
@@ -8382,24 +8392,29 @@ If yes, remember the marker and the distance to BEG."
 (move-marker (car x) (+ beg (cdr x
   (setq org-markers-to-move nil))
 
-(defun org-narrow-to-subtree ()
-  "Narrow buffer to the current subtree."
-  (interactive)
+(defun org-narrow-to-subtree ( newline)
+  "Narrow buffer to the current subtree.
+
+When called interactively, ensures that there’s a newline at the
+end of the narrowed tree."
+  (interactive "p")
   (save-excursion
 (save-match-data
   (org-with-limited-levels
(narrow-to-region
(progn (org-back-to-heading t) (point))
(progn (org-end-of-subtree t t)
-  (when (and (org-at-heading-p) (not (eobp))) (backward-char 1))
+  (when (and (org-at-heading-p) (not (eobp)))
+ (backward-char 1)
+ (when newline (insert "\n")))
   (point)))
 
-(defun org-toggle-narrow-to-subtree ()
+(defun org-toggle-narrow-to-subtree ( newline)
   "Narrow to the subtree at point or widen a narrowed buffer."
-  (interactive)
+  (interactive "p")
   (if (buffer-narrowed-p)
-  (widen)
-(org-narrow-to-subtree)))
+  (org-widen)
+(org-narrow-to-subtree newline)))
 
 (defun org-narrow-to-block ()
   "Narrow buffer to the current block."
@@ -8411,6 +8426,15 @@ If yes, remember the marker and the distance to BEG."
(narrow-to-region (car blockp) (cdr blockp))
   (user-error "Not in a block"
 

Re: [O] [PATCH 1/2] Fix narrowing for 1-line subtrees

2019-02-19 Thread Leo Vivier
Hello,

Nicolas Goaziou  writes:

> However, I don't think this is going into a good direction. Narrowing
> should probably be the same everywhere in Emacs, including Org mode.

I understand.  The rationale behind this idea was that it would only
modify the way narrowing works for subtrees just as AUCTeX's
`LaTeX-narrow-to-environment' works for environments.  That's why I
didn't think it was a problem.

> IMO, this is very hackish. You imply that narrowing is only done
> interactively, but this is not always the case. In non-interactive
> usage, messing with newline characters could be a bad idea.

I don't think if I've implied so, and I've written the code so that it
wouldn't change non-interactive calls:

[START]
  <--->
(defun org-narrow-to-subtree ( newline)
  "Narrow buffer to the current subtree.

When called interactively, ensures that there’s a newline at the
end of the narrowed tree."
->(interactive "p")
  (save-excursion
(save-match-data
  (org-with-limited-levels
   (narrow-to-region
(progn (org-back-to-heading t) (point))
(progn (org-end-of-subtree t t)
   (when (and (org-at-heading-p) (not (eobp)))
 (backward-char 1)
->   (when newline (insert "\n")))
   (point)))
-[END]-

I've tried to touch as few commands as possible, and I haven't seen any
weird behaviours so far.  But I understand your wariness.

> In a nutshell, I suggest not going this route. Sorry for not having been
> clear about it earlier.

You don't need to apologise, I went down this route because it was an
interesting project to address my problems with 1-line subtrees.  As
I've said in the commit message, even if we address the problem of other
commands not seeing content added outside of the narrowing, we're still
left with the other problem which is that the user is not seeing those
changes.  I wasn't content with this solution, and that's what prompted
me to write this.

Could I suggest you try out this patch with its latest commit (sent on
Mon, 18 Feb 2019 18:18:47 +0100) and gauge whether it affects your
workflow negatively?  I know you’ve only said that this patch was
heading in a wrong direction rather than saying that all hell would
break loose upon applying the patch, but the later commits have tried to
iron out the kinks, and that might quell your wariness.

At any rate, thank you for time.

HTH.

Best,
-- 
Leo Vivier
English Studies & General Linguistics
Master Student, English Department
Université Rennes 2



[O] [PATCH] Fix problems

2019-02-18 Thread Leo Vivier


* lisp/org-capture.el (org-capture-narrow): Fix point position after
  narrowing.

* lisp/org-keys.el (org-remap): Remove remaps for `kill-buffer' and
  `kill-buffer-and-window'.

* lisp/org.el (org-tree-check-narrowing): Use `kill-buffer-hook'
  instead of wrappers for kill-region commands.
  (org-kill-region): Add docstring.

There was a problem in org-capture with templates which didn't specify
`%?'.  It was due to the position of the point upon exiting
`org-capture-narrow' which caused the `search-backward' and
`search-forward' at the end of `org-capture-place-entry' to potentially
act on region outside the viewport.

I've moved away from wrappers for `kill-buffer' and
`kill-buffer-and-window' in favour of a hook to `kill-buffer-hook'.
Problems would have been likely to arise with user-written commands
using `kill-buffer' instead of `org-kill-buffer' (it did for me).
Running `org-tree-check-narrowing' at `kill-buffer-hook' avoids this
problem and is a lot more convenient.

There's also a minor problem which I do not know if we can address.
When the user switches between an indirect buffer and the buffer which
spawned it, the last newline of the subtree isn't protected in the
spawning buffer.  Deleting that newline in the spawning buffer also
deletes it in the indirect buffer, thereby undermining all our efforts
to protect it.  However, if that's the only edge case we have to deal
with, I'd consider it a minor nuisance.
---
 lisp/org-capture.el | 14 +++---
 lisp/org-keys.el|  2 --
 lisp/org.el | 40 +---
 3 files changed, 20 insertions(+), 36 deletions(-)

diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index ff3134fb4..fbc601875 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -1416,14 +1416,14 @@ Of course, if exact position has been required, just 
put it there."
 (defun org-capture-narrow (beg end)
   "Narrow, unless configuration says not to narrow."
   (unless (org-capture-get :unnarrowed)
-(goto-char beg)
 (narrow-to-region
- beg
- (progn (org-end-of-subtree t t)
-(when (and (org-at-heading-p) (not (eobp)))
-  (backward-char 1)
-  (insert "\n"))
-(point)
+ (goto-char beg)
+ (save-excursion
+   (org-end-of-subtree t t)
+   (when (and (org-at-heading-p) (not (eobp)))
+ (backward-char 1)
+ (insert "\n"))
+   (point)
 
 (defun org-capture-empty-lines-before ( n)
   "Set the correct number of empty lines before the insertion point.
diff --git a/lisp/org-keys.el b/lisp/org-keys.el
index 0f4fd5b6d..26a3852b3 100644
--- a/lisp/org-keys.el
+++ b/lisp/org-keys.el
@@ -533,8 +533,6 @@ COMMANDS is a list of alternating OLDDEF NEWDEF command 
names."
   'delete-backward-char   'org-delete-backward-char
   'kill-line  'org-kill-line
   'kill-region'org-kill-region
-  'kill-buffer'org-kill-bufer
-  'kill-buffer-and-window 'org-kill-buffer-and-window
   'widen  'org-widen
   'open-line  'org-open-line
   'yank   'org-yank
diff --git a/lisp/org.el b/lisp/org.el
index ef86423e8..7846a27b7 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -4415,6 +4415,13 @@ If yes, offer to stop it and to save the buffer with the 
changes."
   (when (org-match-line "^[ \t]*#\\+BEGIN:[ \t]+clocktable\\>")
 (org-clocktable-shift dir n)))
 
+(defun org-tree-check-narrowing ()
+  "Check if the current buffer is a narrowed indirect subtree.
+If yes, widen the buffer."
+  (when (and (derived-mode-p 'org-mode)
+(buffer-base-buffer))
+(org-widen)))
+
 ;;;###autoload
 (defun org-clock-persistence-insinuate ()
   "Set up hooks for clock persistence."
@@ -5369,6 +5376,7 @@ The following commands are available:
   (add-hook 'before-change-functions 'org-before-change-function nil 'local)
   ;; Check for running clock before killing a buffer
   (add-hook 'kill-buffer-hook 'org-check-running-clock nil 'local)
+  (add-hook 'kill-buffer-hook 'org-tree-check-narrowing nil 'local)
   ;; Initialize macros templates.
   (org-macro-initialize-templates)
   ;; Initialize radio targets.
@@ -7442,27 +7450,6 @@ frame is not changed."
 (make-indirect-buffer buffer bname 'clone)
   (error (make-indirect-buffer buffer bname)
 
-(defun org-kill-buffer ( buffer-or-name)
-  "Kill the buffer specified by BUFFER-OR-NAME.
-The argument may be a buffer or the name of an existing buffer.
-Argument nil or omitted means kill the current buffer.  Return t if the
-buffer is actually killed, nil otherwise.
-
-Wrapper for org.  See `kill-buffer' for more info."
-  (interactive)
-  (when (buffer-base-buffer)
-(org-widen))
-  (kill-buffer buffer-or-name))
-
-(defun org-kill-buffer-and-window ()
-  "Kill the current buffer and delete the selected window.
-
-Wrapper for org.  See `kill-buffer-and-window' for more 

[O] [PATCH] Fix other commands for exiting narrowing (2)

2019-02-17 Thread Leo Vivier


* lisp/org.el (org-toggle-narrow-to-subtree): Different interactive
  calls and use wrapper for widen
---
Same deal as the last email.  Sorry for only noticing those commands
now; I don't use them in my workflow.

The change in `interactive' is to ensure that only the interactive calls
to `org-narrow-to-subtree' produce the last newline.

 lisp/org.el | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 292807138..ef86423e8 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -8421,12 +8421,12 @@ end of the narrowed tree."
  (when newline (insert "\n")))
   (point)))
 
-(defun org-toggle-narrow-to-subtree ()
+(defun org-toggle-narrow-to-subtree ( newline)
   "Narrow to the subtree at point or widen a narrowed buffer."
-  (interactive)
+  (interactive "p")
   (if (buffer-narrowed-p)
-  (widen)
-(org-narrow-to-subtree)))
+  (org-widen)
+(org-narrow-to-subtree newline)))
 
 (defun org-narrow-to-block ()
   "Narrow buffer to the current block."
-- 
2.20.1




[O] [PATCH] Fix other commands for exiting narrowing

2019-02-17 Thread Leo Vivier


* lisp/org.el (org-kill-buffer): Create a wrapper for kill-buffer to
  handle last newline deletion.
  (org-kill-buffer-and-window): Create a wrapper for
  kill-buffer-and-window to handle last newline deletion.

* lisp/org-keys.el (org-remap): Remap kill-buffer and
  kill-buffer-and-window to org wrappers.
---
I'd forgotten to patch the commands for exiting indirect buffers
spawned by `org-tree-to-indirect-buffer'.

This needs to be squashed with the first commit.

Sorry for the bother.
  
 lisp/org-keys.el |  2 ++
 lisp/org.el  | 21 +
 2 files changed, 23 insertions(+)

diff --git a/lisp/org-keys.el b/lisp/org-keys.el
index 26a3852b3..0f4fd5b6d 100644
--- a/lisp/org-keys.el
+++ b/lisp/org-keys.el
@@ -533,6 +533,8 @@ COMMANDS is a list of alternating OLDDEF NEWDEF command 
names."
   'delete-backward-char   'org-delete-backward-char
   'kill-line  'org-kill-line
   'kill-region'org-kill-region
+  'kill-buffer'org-kill-bufer
+  'kill-buffer-and-window 'org-kill-buffer-and-window
   'widen  'org-widen
   'open-line  'org-open-line
   'yank   'org-yank
diff --git a/lisp/org.el b/lisp/org.el
index 02130ab6a..292807138 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -7442,6 +7442,27 @@ frame is not changed."
 (make-indirect-buffer buffer bname 'clone)
   (error (make-indirect-buffer buffer bname)
 
+(defun org-kill-buffer ( buffer-or-name)
+  "Kill the buffer specified by BUFFER-OR-NAME.
+The argument may be a buffer or the name of an existing buffer.
+Argument nil or omitted means kill the current buffer.  Return t if the
+buffer is actually killed, nil otherwise.
+
+Wrapper for org.  See `kill-buffer' for more info."
+  (interactive)
+  (when (buffer-base-buffer)
+(org-widen))
+  (kill-buffer buffer-or-name))
+
+(defun org-kill-buffer-and-window ()
+  "Kill the current buffer and delete the selected window.
+
+Wrapper for org.  See `kill-buffer-and-window' for more info."
+  (interactive)
+  (when (buffer-base-buffer)
+(org-widen))
+  (kill-buffer-and-window))
+
 (defun org-set-frame-title (title)
   "Set the title of the current frame to the string TITLE."
   (modify-frame-parameters (selected-frame) (list (cons 'name title
-- 
2.20.1




[O] [PATCH 1/2] Fix narrowing for 1-line subtrees

2019-02-17 Thread Leo Vivier
* lisp/org.el (org-narrow-to-subtree): Ensure newline at end of
  subtree.
  (org-tree-to-indirect-buffer): Ensure newline at end of
  subtree.
  (org-widen): Create wrapper for `widen' to handle end newline.

* lisp/org-capture.el (org-capture-finalize): Replace `widen' with
  `org-widen'.
  (org-capture-narrow): Ensure newline at end of subtree.

* lisp/org-keys.el (org-remap): Remap `widen' to `org-widen'.

There was a problem with narrowed 1-line subtrees which caused
clocking and scheduling commands to print their modifications outside
of the current narrowing, e.g. `org-clock-in'. This also prevented
some commands from working as expected,
e.g. `org-clock-out-when-done', since the clock-drawer isn't visible.

Previous commits have addressed this problem by patching those
commands to act on a widened buffer within a `save-restriction'
environment (cf. 8fc22d464, 503ede74b, and 6872088c7) but this does
not address the original problem, namely the modifications not being
visible in the narrowed buffer.

The problem is inherent to Emacs's narrowing.  In org-mode, the
narrowing commands use `org-end-of-subtree' to retrieve the
end-position of the region to be narrowed.  However, with a 1-line
subtree, `org-end-of-subtree' moves the point to the end of the line
which is before the position where clocking and scheduling commands
print their modifications, i.e. right below the headline.

To address the problem, we need to change the way we narrow and widen
buffers in org-mode:
- We patch the narrowing commands in org-mode to always add a newline
  at the end of subtrees (not only the 1-line subtrees).  This ensures
  that clocking and scheduling commands print their modifications
  within the narrowed buffer.
- We create a wrapper for `widen' within org-mode (called `org-widen')
  which deletes the newline added when we narrowed the buffer to the
  subtree.

However, for this solution to be complete, we need to ensure that the
newlines added by the narrowing commands cannot be deleted by the
user.
---
This is an implementation of the solution I've discussed in 'Bug:
org-clock commands spawn drawer outside of narrowing' on Fri, 15 Feb
2019 09:48:00 +0100.

I've tried it with `emacs -q' and with different numbers of
blank-lines between headings, and  I haven't encountered any problem so
far.  The code doesn't make any assumption about how many lines you
should have between your headings, which means that it shouldn't
interfere with `org-blank-before-new-entry'.

If there are more idiomatic ways to write some of the functions,
please let me know.

Thank you.

 lisp/org-capture.el | 12 +---
 lisp/org-keys.el|  1 +
 lisp/org.el | 26 +-
 3 files changed, 31 insertions(+), 8 deletions(-)

diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index debf1808c..ff3134fb4 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -746,7 +746,7 @@ captured item after finalizing."
   (let ((abort-note nil))
 ;; Store the size of the capture buffer
 (org-capture-put :captured-entry-size (- (point-max) (point-min)))
-(widen)
+(org-widen)
 ;; Store the insertion point in the target buffer
 (org-capture-put :insertion-point (point))
 
@@ -1416,8 +1416,14 @@ Of course, if exact position has been required, just put 
it there."
 (defun org-capture-narrow (beg end)
   "Narrow, unless configuration says not to narrow."
   (unless (org-capture-get :unnarrowed)
-(narrow-to-region beg end)
-(goto-char beg)))
+(goto-char beg)
+(narrow-to-region
+ beg
+ (progn (org-end-of-subtree t t)
+(when (and (org-at-heading-p) (not (eobp)))
+  (backward-char 1)
+  (insert "\n"))
+(point)
 
 (defun org-capture-empty-lines-before ( n)
   "Set the correct number of empty lines before the insertion point.
diff --git a/lisp/org-keys.el b/lisp/org-keys.el
index d103957a9..90e8139b0 100644
--- a/lisp/org-keys.el
+++ b/lisp/org-keys.el
@@ -532,6 +532,7 @@ COMMANDS is a list of alternating OLDDEF NEWDEF command 
names."
   'delete-char'org-delete-char
   'delete-backward-char   'org-delete-backward-char
   'kill-line  'org-kill-line
+  'widen  'org-widen
   'open-line  'org-open-line
   'yank   'org-yank
   'comment-dwim   'org-comment-dwim
diff --git a/lisp/org.el b/lisp/org.el
index ebec2befa..3110f14ba 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -7391,7 +7391,9 @@ frame is not changed."
   (setq beg (point)
heading (org-get-heading 'no-tags))
   (org-end-of-subtree t t)
-  (when (org-at-heading-p) (backward-char 1))
+  (when (and (org-at-heading-p) (not (eobp)))
+  (backward-char 1)
+  (insert "\n"))
   (setq end (point)))
 (when (and (buffer-live-p org-last-indirect-buffer)
   (not (eq 

[O] [PATCH 2/2] Prevent deletion of newline added by narrowing

2019-02-17 Thread Leo Vivier
* lisp/org.el (org-delete-backward-char): Prevent deletion of newline
  added by narrowing
  (org-delete-char): Prevent deletion of newline added by narrowing
  (org-kill-line): Prevent deletion of newline added by narrowing
  (org-kill-region): Create wrapper for `kill-region' to prevent
  deletion of newline added by narrowing

* lisp/org-keys.el (org-remap): Remap `kill-region' to
  `org-kill-region'

This ensures that the newline added by the narrowing commands cannot
be deleted by the user.

It does so by having every interactive deletion command check whether
it would delete the last newline of a narrowed buffer.  If it would,
the new command deletes whatever the original command normally would
but keep the last newline.  If the original command would have
resulted in a movement, e.g. `org-delete-backward-char', the new
command also moves the point as if the last newline had been deleted.
---
 lisp/org-keys.el |  1 +
 lisp/org.el  | 28 
 2 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/lisp/org-keys.el b/lisp/org-keys.el
index 90e8139b0..26a3852b3 100644
--- a/lisp/org-keys.el
+++ b/lisp/org-keys.el
@@ -532,6 +532,7 @@ COMMANDS is a list of alternating OLDDEF NEWDEF command 
names."
   'delete-char'org-delete-char
   'delete-backward-char   'org-delete-backward-char
   'kill-line  'org-kill-line
+  'kill-region'org-kill-region
   'widen  'org-widen
   'open-line  'org-open-line
   'yank   'org-yank
diff --git a/lisp/org.el b/lisp/org.el
index 3110f14ba..02130ab6a 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -18851,7 +18851,11 @@ because, in this case the deletion might narrow the 
column."
 (looking-at-p ".*?|")
 (org-at-table-p))
(progn (forward-char -1) (org-delete-char 1))
-  (backward-delete-char N)
+  (if (and (eobp)
+   (save-excursion (forward-char -1)
+   (looking-at "\n")))
+  (forward-char -1)
+(backward-delete-char N))
   (org-fix-tags-on-the-fly
 
 (defun org-delete-char (N)
@@ -18868,7 +18872,9 @@ because, in this case the deletion might narrow the 
column."
  (eq (char-after) ?|)
  (save-excursion (skip-chars-backward " \t") (bolp))
  (not (org-at-table-p)))
-  (delete-char N)
+  (unless (and (save-excursion (forward-char) (eobp))
+(looking-at "\n"))
+ (delete-char N))
   (org-fix-tags-on-the-fly))
  ((looking-at ".\\(.*?\\)|")
   (let* ((update? org-table-may-need-update)
@@ -22301,8 +22307,12 @@ depending on context."
   (user-error
(substitute-command-keys
"`\\[org-kill-line]' aborted as it would kill a hidden subtree")))
-(call-interactively
- (if (bound-and-true-p visual-line-mode) 'kill-visual-line 'kill-line)))
+(unless (and (looking-at-p "\n")
+(save-excursion
+  (forward-char 1)
+  (eobp)))
+  (call-interactively
+   (if (bound-and-true-p visual-line-mode) 'kill-visual-line 'kill-line
((org-match-line org-tag-line-re)
 (let ((end (save-excursion
 (goto-char (match-beginning 1))
@@ -22314,6 +22324,16 @@ depending on context."
 (org-align-tags))
(t (kill-region (point) (line-end-position)
 
+(defun org-kill-region (beg end  region)
+  (interactive (list (mark) (point) 'region))
+  (kill-region
+   beg
+   end
+   region)
+  (save-excursion
+(when (eobp)
+   (insert "\n"
+
 (defun org-yank ( arg)
   "Yank.  If the kill is a subtree, treat it specially.
 This command will look at the current kill and check if is a single
-- 
2.20.1




Re: [O] [PATCH] org.el: Fix newline at eob in org-insert-heading

2019-02-16 Thread Leo Vivier
Hello,

Nicolas Goaziou  writes:

>> The problem is due to `eobp' returning t when point is on the last
>> character of the narrowed buffer (as explained in its docstring).
>> Since those `eobp' predicates in `org-insert-heading' are probably
>> there to ensure a newline at the end of the *file*, checking whether
>> the buffer is *narrowed* (with `buffer-narrowed-p') prior to inserting
>> the newline fixes the problem.
>
> I don't think this would be a sufficient fix, because the buffer can be
> narrowed and, yet, showing the end of the file.

Yes, this is also something that I noticed, and I’d sent another patch
that address issue as a reply to the original email.  However, not
knowing whether to submit the patch as is, squash it with the previous
one, or send it as a new thread altogether, I ended doing a clumsy job.

If you check it, you’ll see at the end of the commit message an appended
note on that issue.

> Anyway, I don't think this final newline is needed. I removed it. This
> should fix your issue. Please let me know if you encounter other
> glitches in that area.

Thank you.  I’ll let you know if I encounter anything unexpected.

Best,

P.S.: I’d sent the patches with the wrong email.  This is now resolved.
-- 
Leo Vivier
English Studies & General Linguistics
Master Student, English Department
Université Rennes 2



Re: [O] Bug: Bug: org-clock commands spawn drawer outside of narrowing [9.2.1 (9.2.1-2-gc6d37c-elpaplus @ /home/zaeph/.emacs.d/elpa/org-plus-contrib-20190204/)]

2019-02-15 Thread Leo Vivier
Hello,

I’d forgotten to CC the list in my previous message, so I’ve included
all the context from our two previous emails.

Nicolas Goaziou  writes:

> Leo Vivier  writes:
>
>> You’re right, that’s the behaviour we would expect from M-RET.  However,
>> with C-RET, the new heading should respect the content of the tree at
>> point.
>
> I disagree. C-RET is expected to move point, so it should obviously
> operate on the accessible part of the buffer. 
>
> The only other option, AFAICT, would be to automatically widen the
> buffer, which would be most surprising.
>
>> Even though this is an expected behaviour with narrowed buffers, maybe
>> we could find a way to work around this limitation.  The reason I’m
>> suggesting this is because I often find myself dealing with 1-line tree
>> which are meaningful parts of my documents.
>
> Then you ought to include the final newline character in the narrowed
> part of the buffer. It mitigate some issues you are encountering.

Including the final newline mitigates most of the problems I’m
encountering, you’re right, but I have two issues with this solution:
- ‘org-narrow-to-subtree’ does not do that by default (although it’d
  probably be easy to patch in a conditional behaviour).
- The included newline isn’t protected, meaning that the user can delete
  it without warning.

MWE:
[START]
* Inbox
** Captured task
* Tree
-[END]-

- Narrow to ‘* Captured task^J’ (i.e. including the new-line at eol).
  This is the state we’d have with a patched org-narrow-to-subtree.
- ‘(end-of-buffer)’
- ‘(delete-char 1)’
- ‘(widen)’

Result:
[START]
* Inbox
** Captured task*Tree
-[END]-

Since the line is visible in the buffer, it follows that the user is
able to delete it, but I wonder if that’s something s/he’d ever want to
do.  This goes back to the tentative solution I’ve mentioned in my
previous email.

>> I’m aware that this problem only affects people who do not have
>> empty-lines between their trees.  However, 90% of the time, those 1-line
>> trees are the result of simple org-capture templates on which no work
>> has been done.  When the time comes, I access them from the agenda with
>> ‘org-agenda-tree-to-indirect-buffer’.  I have no way to know that the
>> buffer is narrowed char-wise rather than line-wise.  So, when
>> clocking-in on that tree, it doesn’t feel right that the clock-table
>> should be spawned outside of the view-port.
>>
>
> I'm not sure about "this problem" you're talking about. You are
> encountering different "problems". Some are certainly genuine bugs, but
> not all of them, per above. In any case, please report them precisely so
> we can see if there is something to fix, piece-wise.

I’ll make sure to specify those behaviours, then.

>>  Since the problem only happens with 1-line trees, a tentative solution
>>  could be the following:
>>  - When evaluating ‘org-narrow-to-subtree’ or
>>‘org-agenda-tree-to-indirect-buffer’
>>1. Check whether the tree being considered is a 1-line tree.
>>2. If t: Add a newline at the end of the heading.
>>   (This bypasses the narrowing limitation.)
>>3. Store the result of the check in a local variable.
>>  - When evaluating ‘widen’ inside commands like ‘org-capture-finalize’ 
>>1. Check whether the local variable mentioned above is set and true.
>>2. If t: Remove newline at the end of the narrowed buffer if it still
>>   exists.
>>
>>  If this solution seems sound, I could work on it and submit a patch.
>>
>>>> - `org-clock-out-when-done` isn’t respected since the drawer is not
>>>>   visible
>>>
>>> This is a bug. I fixed it.
>>
>>Thank you for the fix.

Thanks for your help.

Best,
-- 
Leo Vivier
English Studies & General Linguistics
Master Student, English Department
Université Rennes 2



Re: [O] org-clock: Custom shortcuts for C-u C-c C-x C-i

2019-02-13 Thread Leo Gaspard
Hi Michaël,

Michaël Cadilhac  writes:
> This is not possible out of the box; can you say a bit more about how
> you expect to indicate which tasks are to be always present?

I would be thinking of something like defining a list of key -> link to
a task (that may be generated with org-id's task ID, [[*foobar]] links
or whatever) in my `init.el`.

> A quick-and-dirty way to implement something along these lines is to
> modify org-clock-history-push to always keep a selected set of markers
> in org-clock-history.

Hmm… That sounds like it'd work, but would have a pretty terrible UX. I
guess I'll go with just using custom shortcuts for now, then, if there's
no easy way to integrate it with C-ucxi. (I don't feel like I'm ready to
dive into too intricate elisp yet)

Thank you for your feedback!
Cheers,
  Leo



[O] Bug: Bug: org-clock commands spawn drawer outside of narrowing [9.2.1 (9.2.1-2-gc6d37c-elpaplus @ /home/zaeph/.emacs.d/elpa/org-plus-contrib-20190204/)]

2019-02-11 Thread Leo Vivier
Hello,

Version info:
- Emacs : GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
  3.22.30), of 2018-07-05
- Package: Org mode version 9.2.1 (9.2.1-2-gc6d37c-elpaplus)

The bug only happens in narrowed org-mode buffers when the tree at
point (or targeted by the resolving) is a single line not followed by a
blank line.

I was able to replicate the problem with `emacs -q`.

MWE:
[START]
* Tree 1
* Tree 2
-[END]-

- Narrow to ‘Tree 1’l
- Clock in.

Observations:
- No clock drawer visible in the narrowed buffer.
- Feedback in the minibuffer that the clock was started.
- Widening the buffer confirms the presence of the buffer where it
  should be.

Whilst the observations would lead one to think that everything ‘Just
Works™’, it causes a slew of problems.  Two examples:
- After clocking in, adding a new heading ‘Subtree’ bellow ‘Tree 1’
  would make the drawer belong to ‘Subtree’ instead of ‘Tree 1’
- `org-clock-out-when-done` isn’t respected since the drawer is not
  visible

It seems to be part of a larger set of bugs related to single-line
trees, such as the one I’d reported before and which was addressed in
503ede74bc0a1db59fd2fb7bac0bf1ba7352d15b.

I tried to fix it on my own by tracking down the problem with edebug,
and that led me to the `save-restriction` used in `org-clock-in`,
`org-clock-out`, and `org-clock-resolve-clock`.  Those calls to
`save-restriction` are sometimes embedded into macros, such as
`org-with-wide-buffer` or `org-with-point-at`.

I initially thought that replacing those calls in favour of a `widen`
followed by a `org-narrow-to-subtree` would refresh the bounds of the
narrowing.  This proved to be a lot more finicky than I anticipated, and
I’d hate to break anything.

Would you be able to look into it?

Thank you for your time,
-- 
Leo Vivier
English Studies & General Linguistics
Master Student, English Department
Université Rennes 2



[O] org-clock: Custom shortcuts for C-u C-c C-x C-i

2019-02-11 Thread Leo Gaspard
Hello,

When I run C-u C-c C-x C-i I get a choice between the interrupted task,
the current task, the default task and recent tasks.

I however wonder whether it's possible to add in custom shortcuts to
fixed tasks? This would help me easily clock into my “IRC”, “Mails”
etc. tasks, to and from which I frequently switch.

Do you have any idea how to accomplish that? I haven't been able to find
anything in the manual [1].

[1] https://orgmode.org/org.html#Clocking-commands

Cheers, and thank you once again for this great piece of software!
  Leo



[O] [PATCH] org.el: Fix newline at eob in org-insert-heading

2019-02-11 Thread Leo Vivier
* lisp/org.el (org-insert-heading): Check if narrowed before inserting
newline at eob

When narrowed into an org-buffer (e.g. when capturing), adding a new
heading with C- or M- on the last line of a
buffer (i.e. that not without a newline at the end) would result in
the insertion of a newline at the bottom of the narrowed capture
buffer.

- C-: `org-insert-heading-respect-content'
- M-: `org-meta-return'

Both functions use `org-insert-heading' in their definitions.

The problem is due to `eobp' returning t when point is on the last
character of the narrowed buffer (as explained in its docstring).
Since those `eobp' predicates in `org-insert-heading' are probably
there to ensure a newline at the end of the *file*, checking whether
we are at the end of the *widened* buffer prior to inserting the
newline fixes the problem.

The patch I'd originally submitted failed to address narrowed buffer
whose `(max-pos)` was also that of the widened buffer.  Rather than
using `(buffer-narrowed-p)`, I opted for a `(widen)` followed by
`(eobp)`.

TINYCHANGE
---
I was able to replicate the problem with `emacs -q`, so the problem
doesn't seem to come from custom options in my own setup. 

The problematic lines were inserted in the following commit:
b16feed40c7f519ada0cd9315251dcc257be31d2 .  Their goal was to C-
more predictable, and I don't think I've modified that behaviour in a
any way.

Let me know if you'd rather have me squash the changes.

 lisp/org.el | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 7e74c2199..fef13f818 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -7542,8 +7542,9 @@ unconditionally."
   (unless (and blank? (org-previous-line-empty-p))
(org-N-empty-lines-before-current (if blank? 1 0)))
   (insert stars " ")
-  (when (and (eobp)
- (not (buffer-narrowed-p)))
+  (when (save-restriction
+  (widen)
+  (eobp))
 (save-excursion (insert "\n")))
   ;; When INVISIBLE-OK is non-nil, ensure newly created headline
   ;; is visible.
@@ -7572,15 +7573,17 @@ unconditionally."
   (when blank? (insert "\n"))
   (insert "\n" stars " ")
   (when (org-string-nw-p split) (insert split))
-  (when (and (eobp)
-  (not (buffer-narrowed-p)))
+  (when (save-restriction
+   (widen)
+   (eobp))
  (save-excursion (insert "\n")
(t
 (end-of-line)
 (when blank? (insert "\n"))
 (insert "\n" stars " ")
-(when (and (eobp)
-(not (buffer-narrowed-p)))
+(when (save-restriction
+   (widen)
+   (eobp))
(save-excursion (insert "\n"))
  ;; On regular text, turn line into a headline or split, if
  ;; appropriate.
-- 
2.20.1




[O] [PATCH] org.el: Fix newline at eob in org-insert-heading

2019-02-11 Thread Leo Vivier
* lisp/org.el (org-insert-heading): Check if narrowed before inserting
newline at eob

When narrowed into an org-buffer (e.g. when capturing), adding a new
heading with C- or M- on the last line of a
buffer (i.e. that not without a newline at the end) would result in
the insertion of a newline at the bottom of the narrowed capture
buffer.

- C-: `org-insert-heading-respect-content'
- M-: `org-meta-return'

Both functions use `org-insert-heading' in their definitions.

The problem is due to `eobp' returning t when point is on the last
character of the narrowed buffer (as explained in its docstring).
Since those `eobp' predicates in `org-insert-heading' are probably
there to ensure a newline at the end of the *file*, checking whether
the buffer is *narrowed* (with `buffer-narrowed-p') prior to inserting
the newline fixes the problem.

TINYCHANGE
---
 lisp/org.el | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index e2258749b..7e74c2199 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -7542,7 +7542,9 @@ unconditionally."
   (unless (and blank? (org-previous-line-empty-p))
(org-N-empty-lines-before-current (if blank? 1 0)))
   (insert stars " ")
-  (when (eobp) (save-excursion (insert "\n")))
+  (when (and (eobp)
+ (not (buffer-narrowed-p)))
+(save-excursion (insert "\n")))
   ;; When INVISIBLE-OK is non-nil, ensure newly created headline
   ;; is visible.
   (unless invisible-ok
@@ -7570,12 +7572,16 @@ unconditionally."
   (when blank? (insert "\n"))
   (insert "\n" stars " ")
   (when (org-string-nw-p split) (insert split))
-  (when (eobp) (save-excursion (insert "\n")
+  (when (and (eobp)
+  (not (buffer-narrowed-p)))
+ (save-excursion (insert "\n")
(t
 (end-of-line)
 (when blank? (insert "\n"))
 (insert "\n" stars " ")
-(when (eobp) (save-excursion (insert "\n"))
+(when (and (eobp)
+(not (buffer-narrowed-p)))
+   (save-excursion (insert "\n"))
  ;; On regular text, turn line into a headline or split, if
  ;; appropriate.
  ((bolp)
-- 
2.20.1




Re: [O] Closing a task yesterday (or changing the day cutoff to 4am)

2019-02-02 Thread Leo Gaspard
Uwe Koloska  writes:
> Maybe the variable 'org-extend-today-until' can help.

Indeed, thank you!



Re: [O] Closing a task yesterday (or changing the day cutoff to 4am)

2019-02-02 Thread Leo Gaspard
Marcin Borkowski  writes:
> You do realize you are not the first one to have that problem, don't
> you?  Have you seen `org-agenda-todo-yesterday'?

Thank you! Sounds like it'll combo nicely with `org-extend-today-until`
pointed out by Uwe, to slowly make checking tasks the day before less
and less convenient and push the sleep schedule the right way.

>> Anyway, thank you for org-mode, that allows me to be mildly annoyed at
>> things I wouldn't even have considered might become an issue someday
>> with programs I used before!
>
> Not sure whether this is a compliment, but I like it:-).

It's definitely meant to be! :)



[O] Closing a task yesterday (or changing the day cutoff to 4am)

2019-02-01 Thread Leo Gaspard
Hello!

I have a few tasks marked as `:STYLE: habit`. And I relatively often
finish one of those daily habits after midnight.

Yet, I'd like to count it as having been finished the day before, so
that day switch time happens while I sleep.

I do understand that the best fix to this problem would be to fix my
sleep schedule and to go to sleep before midnight, but, assuming I can't
fix this up, do you know if there is a workaround to either:
 * Make org-mode consider the day to switch at something like 4am
 * Automatically close a task as though it was the day before, 23:59

Currently my workaround is to close the task then manually fixup the
`SCHEDULED`, `:LAST_REPEAT:` and `:LOGBOOK:` lines to set them to the
day before, 23:59, but it's being… quite painful.

Anyway, thank you for org-mode, that allows me to be mildly annoyed at
things I wouldn't even have considered might become an issue someday
with programs I used before!

Cheers,
  Leo



Re: [O] Making an agenda that includes scheduled-for-later tasks?

2019-01-25 Thread Leo Gaspard
Stig Brautaset  writes:
> Does changing your "E" entry to this help at all?
>
> ,
> | ("E" "Effortless tasks"
> |  todo '("TODO" "WAITING")
> |  ((org-agenda-overriding-header "Effortless tasks")
> |   (org-agenda-skip-function '(org-agenda-skip-entry-if 'regexp 
> ":Effort:" 'todo '("APPT")))
> |   (org-agenda-todo-ignore-scheduled nil)
> |   (org-agenda-todo-ignore-deadlines nil)
> |   (org-agenda-todo-ignore-timestamp nil)
> `

Thank you, it worked great! I wonder whether the documentation of
=org-agenda-custom-commands= could be expanded around the =settings=
parameter, so as to make it easier to find this solution by oneself? I
don't know myself the list of settings that could go there, though, so
couldn't really write it myself unfortunately :/

> By the way, the documentation for the `org-agenda-custom-commands'
> variable says that the third entry should be "a single keyword for TODO
> keyword searches", so the '("TODO" "WAITING") you have may be partly why
> things are not working how you expect? You may want to try a compound
> one like this:

> ,
> | ("E" "Effortless tasks"
> |  ((todo "TODO")
> |   (todo "WAITING"))
> |  ((org-agenda-overriding-header "Effortless tasks")
> |   (org-agenda-skip-function '(org-agenda-skip-entry-if 'regexp 
> ":Effort:" 'todo '("APPT")))
> |   (org-agenda-todo-ignore-scheduled nil)
> |   (org-agenda-todo-ignore-deadlines nil)
> |   (org-agenda-todo-ignore-timestamp nil)
> `

This works, however it splits the =TODO= and =WAITING= tasks in two
different sections in the display. I think Nick's solution is a bit
closer to what I tried to do here, as it mixes the two keywords in one.

Thank you!
  Leo



Re: [O] Making an agenda that includes scheduled-for-later tasks?

2019-01-25 Thread Leo Gaspard
Nick Dokos  writes:
>tags "TODO=\"TODO\"|TODO=\"WAITING\""

Thank you! This one worked great :)



Re: [O] Making an agenda that includes scheduled-for-later tasks?

2019-01-25 Thread Leo Gaspard
Hello all!

Just trying to bump this question: How does one make an agenda view that
includes tasks that are already scheduled for later?

(more details in the quoted mail below)

Cheers,
  Leo

Leo Gaspard  writes:

> Hello all!
>
> I am trying to make an agenda view of all tasks that don't have the
> :Effort: property set, including tasks that are scheduled for later.
>
> My init.el files includes the following lines (of interest is the "E"
> agenda):
> ```
> (setq org-agenda-custom-commands
>   '(("U" "Unscheduled tasks"
>todo '("TODO" "WAITING")
>((org-agenda-overriding-header "Unscheduled tasks")
> (org-agenda-skip-function '(org-agenda-skip-entry-if 'scheduled
>   ("E" "Effortless tasks"
>todo '("TODO" "WAITING")
>((org-agenda-overriding-header "Effortless tasks")
> (org-agenda-skip-function '(org-agenda-skip-entry-if 'regexp 
> ":Effort:" 'todo '("APPT")))
> ```
>
> However, for some reason only tasks that are either not scheduled or
> scheduled for some time in the past show up in this agenda. This makes
> it useless, as the point is to remember to put in efforts for every
> task *before* they are scheduled (and thus started)
>
> Do you have an idea what I could have missed?
>
> Thanking you in advance,
>   Leo
>
> PS: Also, I've noticed setting =todo '("TODO" "WAITING")= is apparently
> not enough to get it to ignore the APPT-tagged items, so I've added the
> filter to =org-agenda-skip-entry-if=. If you have an idea what I'm doing
> wrong…



[O] Making an agenda that includes scheduled-for-later tasks?

2019-01-16 Thread Leo Gaspard
Hello all!

I am trying to make an agenda view of all tasks that don't have the
:Effort: property set, including tasks that are scheduled for later.

My init.el files includes the following lines (of interest is the "E"
agenda):
```
(setq org-agenda-custom-commands
  '(("U" "Unscheduled tasks"
 todo '("TODO" "WAITING")
 ((org-agenda-overriding-header "Unscheduled tasks")
  (org-agenda-skip-function '(org-agenda-skip-entry-if 'scheduled
("E" "Effortless tasks"
 todo '("TODO" "WAITING")
 ((org-agenda-overriding-header "Effortless tasks")
  (org-agenda-skip-function '(org-agenda-skip-entry-if 'regexp 
":Effort:" 'todo '("APPT")))
```

However, for some reason only tasks that are either not scheduled or
scheduled for some time in the past show up in this agenda. This makes
it useless, as the point is to remember to put in efforts for every
task *before* they are scheduled (and thus started)

Do you have an idea what I could have missed?

Thanking you in advance,
  Leo

PS: Also, I've noticed setting =todo '("TODO" "WAITING")= is apparently
not enough to get it to ignore the APPT-tagged items, so I've added the
filter to =org-agenda-skip-entry-if=. If you have an idea what I'm doing
wrong…



Re: [O] “Fuzzy” times (“evening”, “morning”, “night”…)

2018-12-09 Thread Leo Gaspard
Hi Richard,

Richard Lawrence  writes:
> What about just adding a tag (:evening:, :morning:, etc.) to represent a
> fuzzy time, with a plain date stamp, like <2018-12-04>?
>
> That would allow you to easily create a custom agenda view containing
> just entries with fuzzy times (if they have a timestamp with just a
> date, you can even filter for those that are coming up in the next
> couple of days).  Then when it's convenient, you can look at this agenda
> view and schedule things that are still fuzzy more precisely.

This sounds like a good idea, thanks! Especially combined with Ken
Mankoff's, so that the event still is shown in the overall agenda at an
approximately correct hour so I don't schedule two things at the same
(fuzzy) time :)

With your two ideas it should make a quite good workaround, thank you!

Cheers,
  Leo



Re: [O] “Fuzzy” times (“evening”, “morning”, “night”…)

2018-12-09 Thread Leo Gaspard
Ken Mankoff  writes:
> On 2018-12-08 at 09:47 -0800, Leo Gaspard  wrote:
>> However, I think it may be a good idea to allow eg. this kind of
>> timestamps:
>> <2018-02-04 Tue evening> That would be handled as though it
>> was eg. <2018-02-04 Tue 18:00-22:00> (which would be configurable), so
>> that it would be both semantically correct (the time is still fuzzy)
>> and correctly displayed (eg. on an agenda)
>> [...]
>> What do you think about this idea? Is there a better way to do what
>> I'm trying to do with current tools?
>
>
> I think this would be a neat feature. But as a first pass which can work 
> immediately, what about using one of the multiple text expansion packages 
> that are Org-agnostic to achieve this: Yasnippets or abbrev mode, for example?
>
> This doesn't maintain the "semantics (time still fuzzy)", but does let you 
> define and enter time ranges in a simpler way.

Hmm… I guess some abbreviation or command could add the fuzzy time and
add a comment to indicate that the time is fuzzy should work as a
temporary workaround indeed, thank you for the idea :)



[O] “Fuzzy” times (“evening”, “morning”, “night”…)

2018-12-08 Thread Leo Gaspard
Hello,

In the process of migrating all my self-organization to org-mode, I
noticed there is something that cannot currently be encoded in
timestamps: fuzzy times, where an appointment is made for “Dec 4, Tue,
evening” but with the hours not yet fixed.

Currently my way of handling this has been to mark the tasks with time
spans approx. correct and add a comment to fix them.

However, I think it may be a good idea to allow eg. this kind of
timestamps:
<2018-02-04 Tue evening>
That would be handled as though it was eg. <2018-02-04 Tue 18:00-22:00>
(which would be configurable), so that it would be both semantically
correct (the time is still fuzzy) and correctly displayed (eg. on an
agenda)

To be perfectly honest, my ulterior motive here is to auto-generate
tasks “Decide of an exact time for [task]” a few days before the
timestamp. However, I haven't investigated yet whether that'd actually
be doable and I'm still pretty new to the lisp/emacs/org-mode
ecosystems, so this may be completely impossible.

What do you think about this idea? Is there a better way to do what I'm
trying to do with current tools?

Cheers,
Leo



Re: [O] Bug: ‘(org-resolve-clocks)’ picks the wrong target for placing a new clock-drawer when ‘org-clock-out-remove-zero-time-clocks’ is set to t [9.1.14 (9.1.14-9-g131531-elpa @ ~/.emacs.d/elpa/or

2018-12-06 Thread Leo Vivier

Hello,

Thank you for your quick patch.
Since I wasn’t able to solve it on my own, I’ll take a look at 
your solution to understand what you did.


Have a great day.

Best,

Nicolas Goaziou writes:


Hello,

Leo Vivier  writes:


Hello,

There seems to be a bad interaction between 
‘(org-resolve-clocks)’ and
‘org-clock-out-remove-zero-time-clocks’ set to t. Whilst the 
right
tree is targeted by ‘(org-resolve-clocks)’ to delete the 
clock-line
and clock-drawer, it adds a new clock-drawer in the next tree 
rather

than on the one being acted on.

I was able to replicate this problem with ‘emacs -Q’.


DESCRIPTION:


I use org-clock regularly, and recently re-discovered
‘org-clock-out-remove-zero-time-clocks’. When I forget to clock 
an

item, I run the following commands in quick succession:
# --
(org-clock-in)
(org-resolve-clocks)
: g 10  (For indicating that I ‘got back’ 10 min 
ago)

# --


Because those commands are run in quick succession, the time 
between
‘(org-clock-in)’ and ‘(org-resolve-clocks)’ is usually equal to 
0 min.
Therefore, when ‘(org-resolve-clocks)’ calls ‘(org-clock-out)’ 
after
pressing , the clock-line is deleted, and if the 
clock-drawer

was created by ‘(org-clock-in)’, it also gets deleted.


The problem occurs in this context (‘|’ represents ‘(point)’):
# --
* Subtree 1
** Item|
* Subtree 2
# --
‘Item’ is the subtree we want to clock in the past. ‘Subtrees 1 
& 2’

are regular subtrees without any newlines separating them (the
white-space is important).
Please note that I was only able to get ‘(org-resolve-clocks)’ 
to
trigger in an agenda-file with already had clocking info. I 
recommend
that you try the snippet in one of your own agenda-files rather 
than

trying it in a blank buffer.


Fixed. Thank you.

Regards,



--
Leo Vivier
English Studies & General Linguistics
Master Student, English Department
Université Rennes 2



[O] Bug: ‘(org-resolve-clocks)’ picks the wrong target for placing a new clock-drawer when ‘org-clock-out-remove-zero-time-clocks’ is set to t [9.1.14 (9.1.14-9-g131531-elpa @ ~/.emacs.d/elpa/org-2018

2018-12-02 Thread Leo Vivier
ibly remove zero time clocks.  However, do not 
add

  ;; a note associated to the CLOCK line in this case.
  (cond ((and org-clock-out-remove-zero-time-clocks
  (= (+ h m) 0))
 (setq remove t)
 (delete-region (line-beginning-position)
(line-beginning-position 2)))
(org-log-note-clock-out
 (org-add-log-setup
  'clock-out nil nil nil
		  (concat "# Task: " (org-get-heading t) 
		  "\n\n"

  (when org-clock-mode-line-timer
(cancel-timer org-clock-mode-line-timer)
(setq org-clock-mode-line-timer nil))
  (when org-clock-idle-timer
(cancel-timer org-clock-idle-timer)
(setq org-clock-idle-timer nil))
  (setq global-mode-string
(delq 'org-mode-line-string global-mode-string))
  (setq frame-title-format org-frame-title-format-backup)
  (when org-clock-out-switch-to-state
(save-excursion
  (org-back-to-heading t)
  (let ((org-clock-out-when-done nil))
(cond
 ((functionp org-clock-out-switch-to-state)
  (let ((case-fold-search nil))
(looking-at org-complex-heading-regexp))
		  (let ((newstate (funcall 
		  org-clock-out-switch-to-state

   (match-string 2
(when newstate (org-todo newstate
 ((and org-clock-out-switch-to-state
		   (not (looking-at (concat org-outline-regexp 
		   "[ \t]*"

org-clock-out-switch-to-state
"\\>"
  (org-todo org-clock-out-switch-to-state))
  (force-mode-line-update)
  (message (concat "Clock stopped at %s after "
			   (org-duration-from-minutes (+ (* 60 h) 
			   m)) "%s")

   te (if remove " => LINE REMOVED" ""))
  (run-hooks 'org-clock-out-hook)
  (unless (org-clocking-p)
(setq org-clock-current-task nil)))
# --


There’s another ‘(save restriction)’ in 
‘(org-clock-remove-empty-clock-drawer)’, but I figured that since 
it is a ‘(save-restriction)’ within another one, it shouldn’t 
matter.

# --
(defun org-clock-remove-empty-clock-drawer ()
 "Remove empty clock drawers in current subtree."
->(save-excursion
   (org-back-to-heading t)
   (org-map-tree
(lambda ()
  (let ((drawer (org-clock-drawer-name))
 (case-fold-search t))
 (when drawer
	   (let ((re (format "^[ \t]*:%s:[ \t]*$" (regexp-quote 
	   drawer)))

 (end (save-excursion (org-end-of-subtree
 (while (re-search-forward re end t)
   (org-remove-empty-drawer-at (point))
# ------


I’m going to investigate further to see if I can fix it reliably 
on my own, but in the meantime, would you have any idea on how to 
fix it?


Thanks for taking the time to look at my report.

HTH,
--
Leo Vivier
English Studies & General Linguistics
Master Student, English Department
Université Rennes 2



Re: [O] Setting timestamp from end time and an interval

2018-11-30 Thread Leo Gaspard
Does anyone else find interest in this, or am I the only one having this
want? Does anyone have a better idea of syntax to do this “negative
interval”? `11am+-00:30` looks kind of weird, but `-` is already taken.

Also, I often find myself inputting minutes in those intervals. Do you
think a syntax like `11am+15'` would make sense, instead of
`11am+00:15`, which is less nice to type?

Cheers,
  Leo

Leo Gaspard  writes:

> Hello,
>
> I find myself often working intervals “backwards”, eg. when planning
> transportation: I need to be there at XX:YY, thus need to depart 35min
> before.
>
> Org-mode has this great feature that when typing `11:12+00:35` it
> automatically computes the interval 11:12-11:47.
>
> What I'm wondering is, whether there'd be interest in having
> eg. `11:47+-00:35`, that'd create the same interval but from an *end*
> time and interval duration.
>
> What do you think about this? Is there already a way of doing this I
> don't know of?
>
> Cheers,
> Leo



[O] Setting timestamp from end time and an interval

2018-11-16 Thread Leo Gaspard
Hello,

I find myself often working intervals “backwards”, eg. when planning
transportation: I need to be there at XX:YY, thus need to depart 35min
before.

Org-mode has this great feature that when typing `11:12+00:35` it
automatically computes the interval 11:12-11:47.

What I'm wondering is, whether there'd be interest in having
eg. `11:47+-00:35`, that'd create the same interval but from an *end*
time and interval duration.

What do you think about this? Is there already a way of doing this I
don't know of?

Cheers,
Leo



[O] Sum clocks into a custom property

2018-11-12 Thread Leo Alekseyev
I am using org-invoice.el, which expects either CLOCKSUM or WORK properties
to exist in an item; these properties contain some time duration record in
HH:MM format.

I can't figure out how to generate those properties from a series of clock
entries with any built-in user-facing functions, so I want to do it
programmatically -- I can get the sum of the clock entries
via (org-clock-sum-current-item), but how do I convert them to HH:MM format
and insert it as a property?


Re: [O] [feature] Handle recurrence in <> and [] dates

2018-11-10 Thread Leo Gaspard
Nicolas Goaziou  writes:
> Org didn't handle repeaters in inactive time stamps. This is now fixed
> (in master). Thank you.

Great, thank you!



Re: [O] Tasks performed on a certain day

2018-11-07 Thread Leo Gaspard
Ken Mankoff  writes:

> What about passive date stamps?
>
> TODO Thing
> 
>
> ?

That's exactly what I was looking for! I hadn't seen an example with
TODO coupled with <> dates, and didn't think it'd have a special
behavior.

Thank you and Marcin for this solution!

Cheers,
  Leo



Re: [O] Tasks performed on a certain day

2018-11-06 Thread Leo Gaspard
Eric S Fraga  writes:
> On Tuesday,  6 Nov 2018 at 22:59, Leo Gaspard wrote:
>> It is a task, so I want to be able to mark it as done and not see it for
>> the rest of the day. But at the same time I can't SCHEDULE <> it,
>> because otherwise if I don't do it the right day then it still bothers
>> me the day after, at which I can't do it any longer any way.
>
> what if you add a, for instance, MISSED task indicator, equivalent to
> DONE so that you can record that you didn't do the task and then move
> on to the next scheduled time?

I was hoping for something that would automatically mark the task as
missed (well, I don't care about the task being marked as missed
actually, just about it no longer appearing on my agenda), but I guess
if it's not possible then this can do. Thank you :)



Re: [O] [feature] Handle recurrence in <> and [] dates

2018-11-06 Thread Leo Gaspard
Hi Julius,

Julius Dittmar  writes:
> if you want a task to re-open at a later date upon closing, add a line of
> :REPEAT_TO_STATE: TODO
> to the PROPERTIES drawer of that task.

Well, I guess I stated my problem poorly, sorry :)

Here is a translated example task from my .org file:

*** TODO Check bank report
SCHEDULED: <2000-02-10 Thu +1m>

Dated [2000-01-01 Sat +1m]

The point of this “Dated” field being to tell me to which report I
should be looking, given I sometimes am a month late or so in checking
my reports, and just put them in the (physical) drawer as I receive
them.

This “Dated” field is exactly what I would like to see updated when I
mark the task as done (like the SCHEDULED date), but it looks like it
doesn't move.

Is there a trick to do this?

Cheers,
  Leo



[O] Tasks performed on a certain day

2018-11-06 Thread Leo Gaspard
Hello world,

I am trying to figure out a way to represent, in org-mode, tasks that
should be performed exactly on one day of the week. For instance, taking
out the garbage.

It is a task, so I want to be able to mark it as done and not see it for
the rest of the day. But at the same time I can't SCHEDULE <> it,
because otherwise if I don't do it the right day then it still bothers
me the day after, at which I can't do it any longer any way.

Does anyone have a trick to handle this kind of “on-this-date task” with
org-mode?

Cheers,
  Leo



Re: [O] [feature] Handle recurrence in <> and [] dates

2018-11-06 Thread Leo Gaspard
Hello all!

It's been ~2 weeks so I hope you'll forgive me bumping my post :)

Do you have an opinion about this idea?
Cheers,
  Leo

Leo Gaspard  writes:

> Hello all!
>
> I have been using org-mode for a few days (switching over from
> todo.txt [1]), and for the time being my experience has been great!
>
> There is a single thing I found weird up to now: it seems that
> recurrence tags in <> and [] “tags” don't get bumped when a task is
> completed and has a recurrence set in its SCHEDULED or DEADLINE date.
>
> The reason I'd like this is because I have monthly bank statements,
> which come in the next month, and I'd like to store the bank statement's
> date in a [] “tag” so that I can easily know which statement I'm
> supposed to handle, even though this date is neither a SCHEDULED (as I
> don't have the statement yet at the date it's produced) nor a DEADLINE
> (for the same reason).
>
> What do you think about this?
>
> Anyway, thanks a lot for the great work!
>
> Cheers,
>   Leo
>
>
> [1] http://todotxt.org/



Re: [O] Full-width characters break column display

2018-11-02 Thread Leo Gaspard
Nicolas Goaziou  writes:
> The problem is that 
>
>   (string-width "何か")
>
> equals
>
>   (string-width "")
>
> i.e, 4 characters, but both strings do not have the same length
> visually.
>
> As long as the two sexps above disagree, it seems difficult to support
> this.

Oh. OK, so now I feel stupid: I was convinced full-width chars were
twice the width of half-width chars… and it turns out the names are
treacherous, and they are actually not.

I guess this is a font / display issue then, and not an org-mode
issue.

Sorry for having bothered you and thank you!
  Leo



[O] How to generate CLOCKSUM property from time ranges?

2018-11-01 Thread Leo Alekseyev
Greetings all,
I am looking into using `org-invoice` to generate some invoices. It uses
the CLOCKSUM property, which according to the docs gets auto-generated when
the clock entries are summed in a subtree.

Concretely, docs say: "CLOCKSUM: The sum of CLOCK intervals in the
subtree.  ‘org-clock-sum’ must be run first to compute the values in the
current buffer."  However, `org-clock-sum` is a non-interactive function,
and evaluating it by hand doesn't do anything for me.

Org-clock-report is able to generate the table with total subtree sums, but
doesn't set the CLOCKSUM property.

Question: how do I get CLOCKSUM property generated and stored in a subtree
with timestamps so that org-invoice functions can pick it up?
--Leo


Re: [O] Full-width characters break column display

2018-11-01 Thread Leo Gaspard
Nicolas Goaziou  writes:
>> Small issue I've been having with org-mode: full-width characters
>> (eg. 何か) appear to be breaking column display.
>
> Org tables assume a fixed-width font.  You need to use one, if such
> thing exists for these characters.

Well, it is fixed-width, but twice the width of spaces and vertical
characters.

Using it with regular English makes it look like th
is, which I guess you'll grant me is not really usable :)

I wonder if it'd be possible to support full-width chars for CJK script?



[O] Full-width characters break column display

2018-11-01 Thread Leo Gaspard
Hello,

Small issue I've been having with org-mode: full-width characters
(eg. 何か) appear to be breaking column display.

Does anyone know of a workaround for this?

Cheers, and thank you for making org-mode as great as I'm currently
discovering it is!
Leo



[O] [feature] Handle recurrence in <> and [] dates

2018-10-22 Thread Leo Gaspard
Hello all!

I have been using org-mode for a few days (switching over from
todo.txt [1]), and for the time being my experience has been great!

There is a single thing I found weird up to now: it seems that
recurrence tags in <> and [] “tags” don't get bumped when a task is
completed and has a recurrence set in its SCHEDULED or DEADLINE date.

The reason I'd like this is because I have monthly bank statements,
which come in the next month, and I'd like to store the bank statement's
date in a [] “tag” so that I can easily know which statement I'm
supposed to handle, even though this date is neither a SCHEDULED (as I
don't have the statement yet at the date it's produced) nor a DEADLINE
(for the same reason).

What do you think about this?

Anyway, thanks a lot for the great work!

Cheers,
  Leo


[1] http://todotxt.org/



Re: [O] Bug: Modifying org-latex-pdf-process doesn't modify the async export behaviour

2018-04-07 Thread Leo Vivier

Hello,

Thank you for pointing me in the right direction. I've created another 
init file just for async-export, and not only have I got it to work, but 
it's also quite a lot faster than it used to be.


All that remains now is to find a way to re-write my function. My 
knowledge of elisp if fairly limited, and I don't see how to communicate 
with the background process other than by writing the value of my 
toggle-variable to a file. I guess I could also make a modularise 
async-init.el and control which module is loaded from the main init.el.


At any rate, thank you for your prompt reply.

Best,

On 07/04/18 09:59, Nicolas Goaziou wrote:

Hello,

Leo Vivier <leo.viv...@gmail.com> writes:


I've encountered an issue trying to write a function to toggle between
two org-latex-pdf-process states (short & long). The function works as
intended when using synchronous export (the PDF is created with the
appropriate number of steps), but it doesn't work with asynchronous
export (org-latex-pdf-process isn't grabbed past the first run).


[...]


I've tried appending (org-reload) to my function, but it didn't work.
I've also tried modifying org-latex-pdf-process on a fresh emacs
session prior to any async export, and I can confirm that it grabs the
latest state of org-latex-pdf-process. I'd surmise that async export
has a process running in the background, but I don't know how to force
it to reload.


The background process doesn't use whatever configuration is loaded in
current Emacs. Instead it loads a configuration file. See
`org-export-async-init-file'.

You may also use local variables in your document, or switch async
configuration files.

Regards,



--
Leo Vivier
English Studies & General Linguistics
Master Student, English Department
Rennes 2



[O] Bug: Modifying org-latex-pdf-process doesn't modify the async export behaviour

2018-04-06 Thread Leo Vivier

Hi,

I've encountered an issue trying to write a function to toggle between 
two org-latex-pdf-process states (short & long). The function works as 
intended when using synchronous export (the PDF is created with the 
appropriate number of steps), but it doesn't work with asynchronous 
export (org-latex-pdf-process isn't grabbed past the first run).


Here's my function:
# --
(defvar zaeph/org-latex-pdf-process-mode)
(defun zaeph/toggle-org-latex-pdf-process ()
  "Toggle the number of steps in the xelatex PDF process."
  (interactive)
  (if (or (not (bound-and-true-p zaeph/org-latex-pdf-process-mode))
  (string= zaeph/org-latex-pdf-process-mode "short"))
  (progn (setq org-latex-pdf-process '("xelatex -shell-escape\
-interaction 
nonstopmode\
-output-directory 
%o %f"

   "biber %b"
   "xelatex -shell-escape\
-interaction 
nonstopmode\
-output-directory 
%o %f"

   "xelatex -shell-escape\
-interaction 
nonstopmode\
-output-directory 
%o %f")

   zaeph/org-latex-pdf-process-mode 'long)
 (message "XeLaTeX process mode: Long"))
(progn (setq org-latex-pdf-process '("xelatex -shell-escape\
  -interaction nonstopmode\
  -output-directory %o %f")
 zaeph/org-latex-pdf-process-mode 'short)
   (message "XeLaTeX process mode: Short"
(zaeph/toggle-org-latex-pdf-process)
# --

I've tried appending (org-reload) to my function, but it didn't work.
I've also tried modifying org-latex-pdf-process on a fresh emacs session 
prior to any async export, and I can confirm that it grabs the latest 
state of org-latex-pdf-process. I'd surmise that async export has a 
process running in the background, but I don't know how to force it to 
reload.


Would you have any idea?

Thanks.

Best,
--
Leo Vivier
English Studies & General Linguistics
Master Student, English Department
Rennes 2



[O] Bug: org-tables: Broken alignment when using numbers of different lengths [9.1.5 (9.1.5-1-gb3ddb0-elpa @ .emacs.d/elpa/org-20171225/)]

2018-02-04 Thread Leo Vivier

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See

http://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.

Hi there,

This is my first bug report, so please bear with me if I'm doing
anything wrong.
I also think I've sent an HTML version previously, so sorry about that.

I've updated org-mode yesterday, and the tables do not seem to align
properly anymore.

In a minimal setup, just loading org-mode from MELPA, I've tried
entering the following table:
| foo | 1 |
| bar | 10 |
When I press  in the table, visually, the table loses its alignment
(one space gets removed from at the right of the `1').

It gets worse with three lines. The following lines, for instance:
| foo | 1 |
| bar | 10 |
| test | 100 |
When I press , the separator between the two columns disappears,
and the alignment gets screwed up as well.

There definitely seems to be something going on with the length of the
strings. I've tried setting the alignment with  and , but it
doesn't resolve the problem.

(Since it's my first bug report, I also want to thank everyone, and hope
that I can join the community.)

--


Emacs : GNU Emacs 25.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.26)
of 2017-12-04
Package: Org mode version 9.1.5 (9.1.5-1-gb3ddb0-elpa @ 
/home/zaeph/.emacs.d/elpa/org-20171225/)


current state:
==
(setq
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-occur-hook '(org-first-headline-recenter)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-confirm-shell-link-function 'yes-or-no-p
org-after-todo-state-change-hook '(org-clock-out-if-current)
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-babel-pre-tangle-hook '(save-buffer)
org-mode-hook '(#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook
org-show-block-all append local]
5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook
org-babel-show-result-all append local]
5]
org-babel-result-hide-spec
org-babel-hide-all-hashes)
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 
"\n\n(fn ENTRY)"]

org-archive-hook '(org-attach-archive-delete-maybe)
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-hide-drawers org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-confirm-elisp-link-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-link-parameters '(("id" :follow org-id-open)
("rmail" :follow org-rmail-open :store
org-rmail-store-link)
("mhe" :follow org-mhe-open :store
org-mhe-store-link)
("irc" :follow org-irc-visit :store
org-irc-store-link)
("info" :follow org-info-open :export
org-info-export :store org-info-store-link)
("gnus" :follow org-gnus-open :store
org-gnus-store-link)
("docview" :follow org-docview-open :export
org-docview-export :store
org-docview-store-link)
("bibtex" :follow org-bibtex-open :store
org-bibtex-store-link)
("bbdb" :follow org-bbdb-open :export
org-bbdb-export :complete
org-bbdb-complete-link :store
org-bbdb-store-link)
("w3m" :store org-w3m-store-link)
("file+sys") ("file+emacs")
("doi" :follow org--open-doi-link)
("elisp" :follow org--open-elisp-link)
("file" :complete org-file-complete-link)
("ftp" :follow
(lambda (path)
(browse-url (concat "ftp:" path)))
)
("help" :follow org--open-help-link)
("http" :follow
(lambda (path)
(browse-url (concat "http:" path)))
)
("https" :follow
(lambda (path)
(browse-url (concat "https:" path)))
)
("mailto" :follow
(lambda (path)
(browse-url (concat "mailto:; path)))
)
("news" :follow
(lambda (path)
(browse-url (concat "news:; path)))
)
("shell" :follow org--open-shell-link))
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
)
--
Leo Vivier
English Studies & General Linguistics
Language Scholar, French Department
Reed College



[O] Bug: org-tables: Broken alignment when using numbers of different lengths [9.1.5 (9.1.5-1-gb3ddb0-elpa @ .emacs.d/elpa/org-20171225/)]

2018-02-04 Thread Leo Vivier



Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See

http://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.

Hi there,

This is my first bug report, so please bear with me if I'm doing
anything wrong.

I've updated org-mode yesterday, and the tables do not seem to align
properly anymore.

In a minimal setup, just loading org-mode from MELPA, I've tried
entering the following table:
| foo | 1 |
| bar | 10 |
When I press  in the table, visually, the table loses its alignment
(one space gets removed from at the right of the `1').

It gets worse with three lines. The following lines, for instance:
| foo | 1 |
| bar | 10 |
| test | 100 |
When I press , the separator between the two columns disappears,
and the alignment gets screwed up as well.

There definitely seems to be something going on with the length of the
strings. I've tried setting the alignment with  and , but it
doesn't resolve the problem.

(Since it's my first bug report, I also want to thank everyone, and hope
that I can join the community.)

--


Emacs : GNU Emacs 25.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.26)
of 2017-12-04
Package: Org mode version 9.1.5 (9.1.5-1-gb3ddb0-elpa @ 
/home/zaeph/.emacs.d/elpa/org-20171225/)


current state:
==
(setq
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-occur-hook '(org-first-headline-recenter)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-confirm-shell-link-function 'yes-or-no-p
org-after-todo-state-change-hook '(org-clock-out-if-current)
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-babel-pre-tangle-hook '(save-buffer)
org-mode-hook '(#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook
org-show-block-all append local]
5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook
org-babel-show-result-all append local]
5]
org-babel-result-hide-spec
org-babel-hide-all-hashes)
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 
"\n\n(fn ENTRY)"]

org-archive-hook '(org-attach-archive-delete-maybe)
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-hide-drawers org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-confirm-elisp-link-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-link-parameters '(("id" :follow org-id-open)
("rmail" :follow org-rmail-open :store
org-rmail-store-link)
("mhe" :follow org-mhe-open :store
org-mhe-store-link)
("irc" :follow org-irc-visit :store
org-irc-store-link)
("info" :follow org-info-open :export
org-info-export :store org-info-store-link)
("gnus" :follow org-gnus-open :store
org-gnus-store-link)
("docview" :follow org-docview-open :export
org-docview-export :store
org-docview-store-link)
("bibtex" :follow org-bibtex-open :store
org-bibtex-store-link)
("bbdb" :follow org-bbdb-open :export
org-bbdb-export :complete
org-bbdb-complete-link :store
org-bbdb-store-link)
("w3m" :store org-w3m-store-link)
("file+sys") ("file+emacs")
("doi" :follow org--open-doi-link)
("elisp" :follow org--open-elisp-link)
("file" :complete org-file-complete-link)
("ftp" :follow
(lambda (path)
(browse-url (concat "ftp:" path)))
)
("help" :follow org--open-help-link)
("http" :follow
(lambda (path)
(browse-url (concat "http:" path)))
)
("https" :follow
(lambda (path)
(browse-url (concat "https:" path)))
)
("mailto" :follow
(lambda (path)
(browse-url (concat "mailto:; path)))
)
("news" :follow
(lambda (path)
(browse-url (concat "news:; path)))
)
("shell" :follow org--open-shell-link))
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
)
--
Leo Vivier
English Studies & General Linguistics
Language Scholar, French Department
Reed College



[O] Bug: org-git-link.el broken [9.0.5 (release_9.0.5 @ /home/leo/.emacs.d/elisp/org-mode.git/lisp/)]

2017-03-22 Thread Leo Alekseyev
org-store-link fails inside org-git-link if org-git-link is enabled with
(require 'org-git-link)

>From what I can tell in the debugger, the code walks up the directory tree
looking for .git files in a parent directory.  However, when I am inside
e.g. "~/foo.el", at some point the code will execute (org-git-split-dirpath
"~/")  (org-git-link.el line 129), which evaluates to (nil, "~").  dir will
subsequently be set to nil on line 132, which results in an error.


Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 http://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.




Emacs  : GNU Emacs 26.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version
3.18.9)
 of 2017-03-20
Package: Org mode version 9.0.5 (release_9.0.5 @
/home/leo/.emacs.d/elisp/org-mode.git/lisp/)

current state:
==
(setq
 org-babel-results-keyword "results"
 org-src-mode-hook '((lambda nil (auto-save-mode t)) (lambda nil
(define-key org-src-mode-map " @" (quote
org-src-do-key-sequence-at-code-block)))
 org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
 org-after-todo-state-change-hook '(org-clock-out-if-current)
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 org-edit-src-content-indentation 0
 org-src-tab-acts-natively t
 org-agenda-files '("~/My Dropbox/notes.org/memos.txt")
 org-shiftup-final-hook '(windmove-up)
 org-cycle-include-plain-lists nil
 org-mode-hook '(er/add-org-mode-expansions turn-on-font-lock flyspell-mode
 (lambda nil (auto-fill-mode t) (setq adaptive-fill-regexp
nil) (setq comment-start nil))
 (closure
  (org-inlinetask-min-level org-mode-abbrev-table
org-mode-syntax-table buffer-face-mode-face org-mode-map org-tbl-menu
org-org-menu
   org-struct-menu org-entities org-last-state
org-id-track-globally org-clock-start-time texmathp-why remember-data-file
   org-agenda-tags-todo-honor-ignore-options
iswitchb-temp-buflist calc-embedded-open-mode calc-embedded-open-formula
   calc-embedded-close-formula align-mode-rules-list
org-emphasis-alist org-emphasis-regexp-components
org-export-registered-backends
   org-modules org-babel-load-languages t)
  nil (add-hook (quote change-major-mode-hook) (quote
org-show-block-all) (quote append) (quote local)))
 (closure
  (org-bracket-link-regexp org-src-window-setup *this*
org-babel-confirm-evaluate-answer-no org-src-preserve-indentation
org-src-lang-modes
   org-edit-src-content-indentation
org-babel-library-of-babel t)
  nil (add-hook (quote change-major-mode-hook) (quote
org-babel-show-result-all) (quote append) (quote local)))
 org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-outline-path-complete-in-steps nil
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-shiftdown-final-hook '(windmove-down)
 org-babel-pre-tangle-hook '(save-buffer)
 org-file-apps '(("\\.nb\\'" .
"/opt/Wolfram/Mathematica/8.0/Executables/Mathematica %s") ("\\.xoj\\'" .
"xournal %s") ("\\.pdf\\'" . "evince %s")
 (" \\.pdf::\\([0-9]+\\)\\'" . "evince %s -p %1")
(auto-mode . emacs) ("\\.x?html?\\'" . default) ("\\.nb\\'" . "mathematica
%s"))
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
 org-hide-leading-stars t
 org-babel-load-languages '((R . t) (shell . t) (python . t) (perl . t) (C
. t) (matlab . t) (latex . t) (scheme . t) (scala . t) (ruby . t) (sqlite .
t)
(java . t) (js . t) (elasticsearch . t))
 org-shiftright-final-hook '(windmove-right)
 org-occur-hook '(org-first-headline-recenter)
 outline-minor-mode-hook '(th-outline-minor-mode-init
   (lambda nil (define-key outline-minor-mode-map
(kbd "TAB") (quote org-cycle))
(define-key outline-minor-mode-map [(tab)]
(quote org-cycle))
(define-key outline-minor-mode-map [(shift
tab)] (quote org-global-cycle))
(define-key outline-minor-mode-map [backtab]
(quote org-global-cycle)))
   )
 org-structure-template-alist '(("s" "#+begin_src ?\n\n#+end_src" "\n\n")
("e" "#+begin_example\n

Re: [O] how to speed up an org-mode file?

2016-07-10 Thread Leo Noordhuizen
Yes. You obviously have ample resources in that area!

Op zo 10 jul. 2016 21:05 schreef Sharon Kimble <boudic...@skimble.plus.com>:

> Leo Noordhuizen <leo.noordhui...@gmail.com> writes:
>
> > Maybe an (too ?) obvious suggestion: Get more memory ?
>
> I'm working on a computer with 16g of ram and 31g of swap, which would
> be adequate for almost anything I think. At the moment getting more ram
> isn't a viable option, I have to stick with what I've already got.
>
> Thanks
> Sharon.
> >
> > On Sun, 10 Jul 2016 at 16:37 Sharon Kimble <boudic...@skimble.plus.com>
> wrote:
> >
> > I'm working on an org-mode file about cancer which is 945.1kb, is
> > converted to a tex file of 1.0mb and a pdf of 2.0mb with 505 pages.
> The
> > conversion is done through this code snippet '(global-set-key (kbd
> > "s-#") 'org-latex-export-to-latex)'. There is no problem with the
> > conversion to tex or conversion to pdf.
> >
> > However, the org-mode file is increasingly slowing down and becoming
> > difficult to move about within the file, and also enter new
> information
> > within it.
> >
> > How then can I speed it up within the org file please?
> >
> --
> A taste of linux = http://www.sharons.org.uk
> TGmeds = http://www.tgmeds.org.uk
> Debian 8.4, fluxbox 1.3.7, emacs 25.0.95
>


Re: [O] how to speed up an org-mode file?

2016-07-10 Thread Leo Noordhuizen
Maybe an (too ?) obvious suggestion: Get more memory ?

On Sun, 10 Jul 2016 at 16:37 Sharon Kimble 
wrote:

>
> I'm working on an org-mode file about cancer which is 945.1kb, is
> converted to a tex file of 1.0mb and a pdf of 2.0mb with 505 pages. The
> conversion is done through this code snippet '(global-set-key (kbd
> "s-#") 'org-latex-export-to-latex)'. There is no problem with the
> conversion to tex or conversion to pdf.
>
> However, the org-mode file is increasingly slowing down and becoming
> difficult to move about within the file, and also enter new information
> within it.
>
> How then can I speed it up within the org file please?
>
> Thanks
> Sharon.
> --
> A taste of linux = http://www.sharons.org.uk
> TGmeds = http://www.tgmeds.org.uk
> Debian 8.4, fluxbox 1.3.7, emacs 25.0.95
>


[O] Bug: C-o yanks on newline in one org-mode buffer [8.2.10 (release_8.2.10 @ c:/Program Files/emacs-24.5/share/emacs/24.5/lisp/org/)]

2016-03-25 Thread Leo J Buchignani III
I previously submitted this bug here:
https://lists.gnu.org/archive/html/emacs-orgmode/2015-12/msg00515.html

I was advised to update my versions.

A while later, I updated to the latest standard Org Mode + Emacs
combination, and redid
my .emacs file mostly from scratch. Then I encountered the bug again.

I assume it is a bug since it appears to have no documentation and
serves no likely use.

Bug arose while writing an 82-line text heading in a 3027-line 2.3M text
.org file titled "di]ks81-ca.org". Text was mostly random thought
snippets about psychology with basic outlining, to give an idea of the
document structure and composition. Lots of top level headings;
nesting not that deep. I had about 6 panes open.

Normally, C-o opens a blank newline as expected.

Bug behavior:
With point at the beginning of a line, C-o yanks snippet
With point elsewhere, C-o behaves normally.

Snippet is a 7-word fragment of the text I was just writing. I
suspect I C-k killed the fragment immediately before the bug appeared.
Snippet is
always the same, regardless of kill-ring.

Bug appears only in the "di]ks81-ca.org" buffer; not in other .org files
or other Emacs modes.

Bug vanishes when I execute M-x org-mode in that buffer, reloading Org
Mode. Thus I conclude it must be an Org Mode bug.

I suspect it has something to do with working in >1M org files.

Cheers,
Leo

Emacs  : GNU Emacs 24.5.1 (i686-pc-mingw32)
 of 2015-04-11 on LEG570
Package: Org-mode version 8.2.10 (release_8.2.10 @ c:/Program
Files/emacs-24.5/share/emacs/24.5/lisp/org/)

current state:
==
(setq
 org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point
org-babel-execute-safely-maybe)
 org-tab-first-hook '(org-hide-block-toggle-maybe
org-src-native-tab-command-maybe
  org-babel-hide-result-toggle-maybe org-babel-header-arg-expand)
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
  org-cycle-hide-inline-tasks org-cycle-show-empty-lines
  org-optimize-window-after-visibility-change)
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-speed-command-hook '(org-speed-command-default-hook
org-babel-speed-command-hook)
 org-babel-pre-tangle-hook '(save-buffer)
 org-occur-hook '(org-first-headline-recenter)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-id-link-to-org-use-id t
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 org-mode-hook '((lambda nil (visual-line-mode -1))
 #[nil "\300\301\302\303\304$\207"
   [org-add-hook change-major-mode-hook org-show-block-all
append local] 5]
 #[nil "\300\301\302\303\304$\207"
   [org-add-hook change-major-mode-hook org-babel-show-result-all append
local]
   5]
 org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-from-is-user-regexp nil
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
 org-after-todo-state-change-hook '(org-clock-out-if-current)
 org-confirm-shell-link-function 'yes-or-no-p
 )



[O] Bug: Strange C-o behavior in Org-Mode [7.8.11]

2015-12-19 Thread Leo J Buchignani III
* Strange C-o behavior in Org-Mode

** VERSION INFO

I am using ErgoEmacs. I cannot tell whether this behavior is due to
ErgoEmacs or Org-Mode.

GNU Emacs 24.2.1 (i386-mingw-nt6.1.7601) of 2012-08-28 on MARVIN
ErgoEmacs distribution 2.0.0

** PROBLEM DESCRIPTION

Intermittently, C-o will alter its normal behavior.

Normally, C-o opens a new blank line. This is apparently what it does for
everyone.

Occasionally, however, C-o behaves differently.
1. If C-o is executed at the beginning of a line, it pastes a one-line text
string and adds a newline at the end
2. If C-o is executed anywhere else, it behaves normally.

I suspect the text string is a single line I've previously grabbed with
C-k. However, I cannot consistently reproduce via this method. IIRC, the
text string is always a recent, familiar piece of text, possibly from the
same file.

Moreover, this behavior is limited to a single .org file. When one .org
file is affected, other .org files do not exhibit the behavior.

I do not THINK the behavior occurs except in org-mode, although since I
almost always am using org-mode when using Emacs, I cannot say for sure.

As a result, once a .org file is "bugged", I have to either avoid using
C-o, or kill the unwanted text string every time it appears.

A quick search of my .emacs file for "C-o" turns up nothing. I don't recall
ever deliberately fiddling with such a setting. ErgoEmacs does generate a
lot of funky keybinds. However, I have disabled those, and in any case
ErgoEmacs wants C-o to replace C-x C-f, which is unrelated to my problem.

I realize that this is not an ideal bug report. I am a non-technical user,
and cannot reliably reproduce the bug anyway. Call this a shot in the dark.

** SOLUTION

Refreshing org-mode with M-x org-mode eliminates the problem. I just
discovered this easy fix, so it's not much of a nuisance anymore. Still,
I'm curious, and this is already written!


Emacs  : GNU Emacs 24.2.1 (i386-mingw-nt6.1.7601) of 2012-08-28 on MARVIN
ErgoEmacs distribution 2.0.0
Package: Org-mode version 7.8.11

current state:
==
(setq
 org-export-blocks '((src org-babel-exp-src-block nil) (export-comment
org-export-blocks-format-comment t) (ditaa org-export-blocks-format-ditaa
nil)
 (dot org-export-blocks-format-dot nil))
 org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point
org-babel-execute-safely-maybe)
 org-src-fontify-natively t
 org-export-preprocess-before-selecting-backend-code-hook
'(org-beamer-select-beamer-code)
 org-tab-first-hook '(org-hide-block-toggle-maybe
org-src-native-tab-command-maybe org-babel-hide-result-toggle-maybe)
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
org-cycle-show-empty-lines org-optimize-window-after-visibility-change)
 org-agenda-custom-commands '(("x" "Agenda sorted by priority first" agenda
"" ((org-agenda-sorting-strategy (quote (priority-up))
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-speed-command-hook '(org-speed-command-default-hook
org-babel-speed-command-hook)
 org-babel-pre-tangle-hook '(save-buffer)
 org-occur-hook '(org-first-headline-recenter)
 org-export-interblocks '((src org-babel-exp-non-block-elements))
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-catch-invisible-edits t
 org-export-latex-format-toc-function 'org-export-latex-format-toc-default
 org-export-preprocess-before-normalizing-links-hook
'(org-remove-file-link-modifiers)
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 org-export-first-hook '(org-beamer-initialize-open-trackers)
 org-mode-hook '(er/add-org-mode-expansions #[nil
"\300\301\302\303\304$\207" [org-add-hook change-major-mode-hook
org-show-block-all append local] 5]
 #[nil "\300\301\302\303\304$\207" [org-add-hook
change-major-mode-hook org-babel-show-result-all append local] 5]
 org-babel-result-hide-spec org-babel-hide-all-hashes
soft-wrap-lines)
 org-export-latex-final-hook '(org-beamer-amend-header org-beamer-fix-toc
org-beamer-auto-fragile-frames org-beamer-place-default-actions-for-lists)
 org-export-latex-after-initial-vars-hook '(org-beamer-after-initial-vars)
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
 org-after-todo-state-change-hook '(org-clock-out-if-current)
 org-confirm-shell-link-function 'yes-or-no-p
 )


Re: [O] Help needed on delegating some maintainance tasks (was: Org maintainance)

2015-05-29 Thread Leo Ufimtsev
If you send out this email again next year when I have graduated from 
university, I'd be down with helping out with things ^_^.

- Original Message -
 From: Robert Klein rokl...@roklein.de
 To: Bastien b...@gnu.org
 Cc: emacs-orgmode@gnu.org
 Sent: Saturday, May 23, 2015 2:56:32 PM
 Subject: Re: [O] Help needed on delegating some maintainance tasks (was: Org 
 maintainance)
 
 On Sat, 23 May 2015 10:47:49 +0200
 Bastien b...@gnu.org wrote:
 
  Hi all,
  
  I need help on these maintainance tasks :
  
  1. Watching the emacs-diffs mailing list and backport changes on Org
 in the local Org repository (2 hours per month).
  
  2. Adding public keys on the orgmode.org server for org-mode and worg
 contributers (1 hour per month).
  
  3. Maintaining the orgmode.org server and taking care of errors when
 updating Worg (1 hour per month).
  
  4. Merging the last stable release into Emacs repository.  (1 hour
 every release).
  
  5. Releasing Org (.5 hour every release).
  
 
 I'd like to help with 3 but would need an introduction.
 
 Best regards
 Robert
 
 

-- 
Leo Ufimtsev | Intern Software Engineer @ Eclipse Team



Re: [O] org-notmuch: how to open-link-at-point in other window?

2015-05-21 Thread Leo Ufimtsev
I usually use my mouse and right click on the link. 

C-c C-o opens things in a new application. E.g a picture is opened in my image 
editing application. 

Right clicking opens in the right window. C-u C-c C-o also opens images in the 
right side window.

In emacs, Window and Frame mean something different. By window, are you 
specifically referring to a new plane, split screen style, on the right hand 
side?

As a note, http://emacs.stackexchange.com/ is often a good place for questions 
that have a specific, usually straight forward answer.

Thank you

Leo 

- Original Message -
 From: Gregor Zattler telegr...@gmx.net
 To: emacs-orgmode emacs-orgmode@gnu.org
 Sent: Thursday, May 21, 2015 9:09:13 AM
 Subject: [O] org-notmuch: how to open-link-at-point in other window?
 
 Dear org-moders,
 
 I want to open-link-at-point (C-c C-o) in other window.  With
 file links this is standard behaviour (at least with my
 configuration).  But I don’t know how to do so with notmuch:
 links.  Universal argument won’t help.
 
 Any ideas?
 
 I think there should be key bindings for opening in same window,
 other window, other frames regardless of the type of link opened.
 Is this doable?
 
 How about:
 
 | open in same window  |   C-c C o |
 | open in other window | C-c 4 C-c C o |
 | open in other frame  | C-c 5 C-c C o |
 
 ?
 
 Ciao, Gregor
 --
  -... --- .-. . -.. ..--.. ...-.-
 
 

-- 
Leo Ufimtsev | Intern Software Engineer @ Eclipse Team



  1   2   3   4   5   6   >