Re: [O] Bug: Archiving items with org-attach-archive-delete set to 'query' always asks for confirmation

[Luciano Passuello]

Hello Kyle,

That worked perfectly for all my basic test cases.
Thanks!
On Fri, Aug 10, 2018 at 10:44 PM Kyle Meyer  wrote:
>
> Luciano Passuello  writes:
>
> > When I set org-attach-archive-delete to query, Org is supposed to ask
> > me for confirmation when archiving entries with attachments. However,
> > I am always asked for confirmation,  regardless if the item has
> > attachments in the first place. This is to me clearly undesirable
> > behavior.
>
> I agree, that doesn't sound desirable (though I've never used this
> feature, so perhaps I'm missing something).
>
> > Looking at the source code for org-attach, at line 573, that's indeed
> > what code tells us.
> > https://code.orgmode.org/bzg/org-mode/src/master/lisp/org-attach.el
> >
> > My uninformed suggestion is to call org-attach-delete-all without the
> > force parameter, using the confirmation code already in
> > org-attach-delete-all.
>
> That would cover the org-attach-archive-delete=query case, but it'd also
> ask for confirmation in the org-attach-archive-delete=t case.
>
> How about this?
>
> -- >8 --
> Subject: [PATCH] org-attach: Don't query unnecessarily about archiving
>
> * lisp/org-attach.el (org-attach-archive-delete-maybe): Don't query
> about deleting attachments if the entry doesn't have any attachments.
> ---
>  lisp/org-attach.el | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/lisp/org-attach.el b/lisp/org-attach.el
> index 192815f4f..53389f782 100644
> --- a/lisp/org-attach.el
> +++ b/lisp/org-attach.el
> @@ -574,10 +574,8 @@ (defun org-attach-archive-delete-maybe ()
>"Maybe delete subtree attachments when archiving.
>  This function is called by `org-archive-hook'.  The option
>  `org-attach-archive-delete' controls its behavior."
> -  (when (if (eq org-attach-archive-delete 'query)
> -   (yes-or-no-p "Delete all attachments? ")
> - org-attach-archive-delete)
> -(org-attach-delete-all t)))
> +  (when org-attach-archive-delete
> +(org-attach-delete-all (not (eq org-attach-archive-delete 'query)
>
>
>  ;; Attach from dired.
> --
> 2.18.0
>

[O] Bug: Archiving items with org-attach-archive-delete set to 'query' always asks for confirmation

[Luciano Passuello]

Hello,

When I set org-attach-archive-delete to query, Org is supposed to ask
me for confirmation when archiving entries with attachments. However,
I am always asked for confirmation,  regardless if the item has
attachments in the first place. This is to me clearly undesirable
behavior.

Looking at the source code for org-attach, at line 573, that's indeed
what code tells us.
https://code.orgmode.org/bzg/org-mode/src/master/lisp/org-attach.el

My uninformed suggestion is to call org-attach-delete-all without the
force parameter, using the confirmation code already in
org-attach-delete-all.

Unfortunately, I'm not skilled enough in Elisp or knowledgeable in Org
source code to provide a reasonable patch.

Thanks!

Re: [O] Lint multiple files at once

[Luciano Passuello]

Hi Nick,

Thank you very much, it works!
Being an elips newbie, it helped me a lot reading and understanding
your code snippet.
Next step is beautify the output, and send it to a buffer/file. I'll
try to do that myself as a learning exercise.

Regards




On Wed, Oct 11, 2017 at 10:48 PM, Nick Dokos <ndo...@gmail.com> wrote:
> Luciano Passuello <lucia...@litemind.com> writes:
>
>> Hello all,
>>
>> I love org-lint, but I couldn't find an easy way to get a report on
>> multiple files.
>> I'd like to analyze all files in a folder, getting all problems found
>> using a single command.
>>
>> Any suggestions?
>>
>
> Here's one way:
>
> --8<---cut here---start->8---
> (defun org-lint-dir (directory)
>   (let* ((files (directory-files directory t ".*\\.org$")))
> (org-lint-list files)))
>
> (defun org-lint-list (files)
>   (cond (files
>  (org-lint-file (car files))
>  (org-lint-list (cdr files)
>
> (defun org-lint-file (file)
>   (let ((buf)
> (lint))
> (setq buf (find-file-noselect file))
> (with-current-buffer buf (if (setq lint (org-lint)) (print (list file 
> lint))
>
> (org-lint-dir "/home/nick/lib/org")
> --8<---cut here---end--->8---
>
> --
> Nick
>
>

[O] Lint multiple files at once

[Luciano Passuello]

Hello all,

I love org-lint, but I couldn't find an easy way to get a report on
multiple files.
I'd like to analyze all files in a folder, getting all problems found
using a single command.

Any suggestions?

Re: [O] Insert heading above current one

[Luciano Passuello]

On Sat, Sep 30, 2017 at 5:21 PM, Nicolas Goaziou  wrote:
> M-RET and C-RET/C-u M-RET are
> different beasts, just don't expect them to behave exactly the same.

And then you hit exactly the heart of our discussion right there.
Im my line of reasoning, org-insert-heading and
org-insert-heading-respect-content should behave exactly the same,
except for the fact that org-insert-heading-respect-content should,
well, respect the content; Other than that, they should be 100%
symmetric.

> I stand on my ground: current behaviour is better.
Given we're not striving for behavior symmetry, I can see your point.

Regards,

Re: [O] Insert heading above current one

[Luciano Passuello]

Hello,

On Sat, Sep 30, 2017 at 4:29 AM, Nicolas Goaziou  wrote:
> OTOH, if we force the previous behaviour, as you suggest, there is no
> way to insert a new headline after the current subtree when point is at
> the beginning of a headline. A feature is lost.

Isn't that consistent with the regular org-insert-heading (M-RET)?
When cursor is in the beginning of a headline, there's no way to
create a heading below that line (using standard M-RET). It will
always create it above. So, having the cursor in the beginning of the
line overrides the standard behavior. Unless we move the cursor
somewhere else, that feature is also lost.

I see no reason why C-RET should behave differently, even if only for
consistency reasons.

> And I agree it should be deprecated. If there is no objection, I'll
> remove it.

I'm too much of a n00b to foresee all consequences of such
deprecation, so I prefer not to give my opinion here.
Doing a quick search on "org-insert-heading-respect-content t" I see
some people do find value in it.

Regards,
Luciano.

Re: [O] Insert heading above current one

[Luciano Passuello]

Hi, thanks for the replies!

>> To add, I also think that the earlier behavior made sense, if the point is
>> at bolp, insert before, else insert after.
>
> I think the current behaviour makes more sense, if the command is called
> with an universal argument. Indeed, what would be the point of using an
> universal argument if you get the exact same behaviour as without it?

I also think the earlier behavior made more sense. The variable
org-insert-heading-respect-content (or the universal argument)
controls how a new headline is inserted BELOW the current header
(either add immediately after the current line or down below). I don't
see how this variable should alter the behavior of adding a heading
ABOVE the current header (ie. "respecting content" or not has no
effect here, above is always above).

> Out of curiosity is there any to set this variable to something else
> than nil? There are already comfortable keybindings to set this
> temporarily (C-RET and C-u M-RET). Why would one have M-RET to behave
> exactly as C-RET? And even if there was a good reason to do so, why not
> simply re-binding M-RET in that case?

You have a good point. Looking this way, the
org-insert-heading-respect-content variable is indeed of little use.
But since the variable does exist (even though perhaps it should be
deprecated?), it should behave correctly.
And I just don't see how the behavior of adding a header above the
current line should be impacted by it.

Thanks!
Luciano.

[O] Insert heading above current one

[Luciano Passuello]

Hello everybody, first message here.

According to org-insert-heading documentation: "If point is at the
beginning of a heading, insert a new heading or a new headline above
the current one."

I like this behavior very much, and in orgmode 8.x, calling
org-insert-heading at the beginning of a line indeed creates a heading
before the current one, even when org-insert-heading-respect-content
is set.

For orgmode 9.x, this only works when org-insert-heading-respect-content is nil.
I find this annoying, because I like to have
org-insert-heading-respect-content non-nil AND to be able to insert a
heading before the current one.

Is that by design or a bug? I couldn't find any mention to the new
behavior in the Changes  page.

Thanks!