Re: Binding RET to org-return-and-maybe-indent

[Jarmo Hurri]

Hello Kévin.

Kévin Le Gouguec  writes:

> RET indentation is something that has been introduced recently on the
> master branch (which will become Org 9.4 soon).  In Org 9.3, with your
> example, RET does not indent, while C-j does.

I was wondering why this bothered me! Such a little thing can have a
drastic effect on your workflow when it is repeated so many times.

> As ORG-NEWS notes, if you want RET to stop indenting, you can disable
> electric-indent-mode in org-mode-hook:

Thanks, I now located this feature change description in ORG-NEWS.

>> But would changing the binding of RET cause issues elsewhere?
>
> I can't think of any bad side-effect, but my imagination might be
> lacking.  The only downside I can think of is that RET will become
> redundant with C-j.

Now I have two options. I will start by disabling electric-indent-mode
in org. If that causes weird side effects, then I will rebind RET.

Thank you for your most complete answer.

All the best, and stay safe.

Jarmo

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

[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
> .  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] Use completing-read-multiple for org-set-tags-command

[Kyle Meyer]

Clemens writes:

> Now that I know that completion works for multiple tags with default 
> completion I'm unsure if it is worth to proceed with this. I wondered 
> how this would go unnoticed for such a long time in org and now I know 
> that the failure was on my part. On the other hand switching to 
> `completing-read-multiple` would improve the situation for completion 
> frameworks which handle it correctly and would also be more idiomatic 
> for this use case.

Yeah, I'm also undecided.  I'm open to the idea of moving from
org-tags-completion-function to crm for the reason you give, but, with
any proposal for that, I think it'd be important to see an inspection of
the current call sites (only a handful) and an analysis of whether we
can retain the current behavior.

Then again, this isn't the only place that passes a function for
completing-read's COLLECTION argument: there's also
org-agenda-filter-completion-function.  At a glance I think it would be
harder to replace with crm.

But perhaps we could at least avoid some confusion by explicitly
documenting spots where completion frameworks may interact with the
intended completion functionality.

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

[Kyle Meyer]

Leo Vivier writes:

> Subject: [PATCH] org: Remove useless example in docstring
>
> * lisp/org.el (org-find-olp): Remove useless example in docstring

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

I also added a TINYCHANGE cookie based on your status listed at
.  You're bumping up
against the tiny change threshold, so please consider submitting the
copyright assignment paperwork.

Capture with (moving) attachment?

[Tim Landscheidt]

Hi,

I have a capture template to file items to a list:

| ("i" "inventory" entry
|  (file "~/Desktop/Agenda/Inventar.org")
|  "* %^{Name}" :immediate-finish t)

Currently, when I want to file an item with an associated
image, I open the directory of the images with dired, visit
the image file, use the capture to add an item, kill the im-
age buffer, use M-0 w in dired to copy the file's name,
switch to the org file, use C-c C-a m to attach the image by
moving the file, and then switch back to the dired buffer.
Lather, rinse, repeat, until the directory with the images
is empty.

What I want to do instead is open the image file (via dir-
ed), have the capture do the attaching by itself (if it is
called in an image-mode buffer) and then kill the image
buffer.  (Emacs does not care if the file associated with
the buffer is deleted in the mean time.)

First idea was to use %(EXP) to set
org-capture-after-finalize-hook to attach the file, but that
hook is called in the original (image) buffer.
org-capture-before-finalize-hook on the other hand is called
in a CAPTURE-Inventar.org buffer (with no associated file),
same with org-capture-prepare-finalize-hook.  (I also would
like to perform the attaching only *after* the item has suc-
cessfully been filed to avoid misfiling/deleting image
files.)

There are other ways to achieve this in this particular case
(capture, visit the org file, go to (point-max),
(org-attach-attach file nil 'mv), maybe even replace capture
with an (insert (format "* %s\n" (read-string, but are
there general solutions for this issue that will work, well,
more generally?

TIA,
Tim

Re: Reposting Elgantt announcement

[Russell Adams]

On Wed, Jul 22, 2020 at 11:00:53AM -0400, Jeff Filipovits wrote:
> Thanks for reposting. I am the author. If anyone wants to help get
> this into shape to go on MELPA that would be great. I am a bit
> burned out on the project at the moment. Coding is is a hobby and
> there are a lot of gaps in my knowledge with regard to getting it
> cleaned up and finalized. Otherwise, I hope it works for anyone
> who tries it!

For a hobby effort it's quite impressive! I hope you find others that want to
help it progress. Gantt charts have been a long standing request regarding Org
data.


--
Russell Adamsrlad...@adamsinfoserv.com

PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/

Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: Reposting Elgantt announcement

[Jeff Filipovits]

Thanks for reposting. I am the author. If anyone wants to help get 
this into shape to go on MELPA that would be great. I am a bit 
burned out on the project at the moment. Coding is is a hobby and 
there are a lot of gaps in my knowledge with regard to getting it 
cleaned up and finalized. Otherwise, I hope it works for anyone 
who tries it!


Russell Adams  writes:


All,

I saw a cool Org related project come up on Reddit, but no 
announcement
here. This is a repost for community interest, I claim no 
credit.


This addon does interactive Gantt charts from Org files. Kudos 
to

"legalnonsense" for a neat way to visualize Org data!

See his screencast:

https://i.redd.it/t2wt8sytf9c51.gif

Original post:

https://www.reddit.com/r/emacs/comments/hve0dy/ann_elgantt_gantt_chartcalendar_for_orgmode/

Source:

https://github.com/legalnonsense/elgantt/



--
Russell Adams 
rlad...@adamsinfoserv.com


PGP Key ID: 0x1160DCB3 
http://www.adamsinfoserv.com/


Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 
DCB3



--
Jeff Filipovits
Spears & Filipovits, LLC
1126 Ponce de Leon Avenue
Atlanta, GA 30306
678.237.9302 (direct)
j...@civil-rights.law

All emails confidential to the fullest extent of the law.

Re: Binding RET to org-return-and-maybe-indent

[Kévin Le Gouguec]

Jarmo Hurri  writes:

> Is there any downside to binding RET to org-return-and-maybe-indent?
>
> I want to remove RET indentation in org mode. For example
>
> # ---
> * Demo of indentation
>   - when I press return at the end of the word THIS
>   - I get indentation
> # ---

RET indentation is something that has been introduced recently on the
master branch (which will become Org 9.4 soon).  In Org 9.3, with your
example, RET does not indent, while C-j does.

As ORG-NEWS notes, if you want RET to stop indenting, you can disable
electric-indent-mode in org-mode-hook:

#+begin_src emacs-lisp
(add-hook 'org-mode-hook (lambda () (electric-indent-mode -1)))
#+end_src

> However, if I call org-return-and-maybe-indent at the same point, I do
> not get indentation.
>
> But would changing the binding of RET cause issues elsewhere?

I can't think of any bad side-effect, but my imagination might be
lacking.  The only downside I can think of is that RET will become
redundant with C-j.

Re: [PATCH] Use completing-read-multiple for org-set-tags-command

[Clemens]

Now that I know that completion works for multiple tags with default 
completion I'm unsure if it is worth to proceed with this. I wondered 
how this would go unnoticed for such a long time in org and now I know 
that the failure was on my part. On the other hand switching to 
`completing-read-multiple` would improve the situation for completion 
frameworks which handle it correctly and would also be more idiomatic 
for this use case.

Binding RET to org-return-and-maybe-indent

[Jarmo Hurri]

Hello.

Is there any downside to binding RET to org-return-and-maybe-indent?

I want to remove RET indentation in org mode. For example

# ---
* Demo of indentation
  - when I press return at the end of the word THIS
  - I get indentation
# ---

However, if I call org-return-and-maybe-indent at the same point, I do
not get indentation.

But would changing the binding of RET cause issues elsewhere?

I am running Org mode version 9.3.7 (release_9.3.7-694-g7069dc).

Jarmo

Reposting Elgantt announcement

[Russell Adams]

All,

I saw a cool Org related project come up on Reddit, but no announcement
here. This is a repost for community interest, I claim no credit.

This addon does interactive Gantt charts from Org files. Kudos to
"legalnonsense" for a neat way to visualize Org data!

See his screencast:

https://i.redd.it/t2wt8sytf9c51.gif

Original post:

https://www.reddit.com/r/emacs/comments/hve0dy/ann_elgantt_gantt_chartcalendar_for_orgmode/

Source:

https://github.com/legalnonsense/elgantt/



--
Russell Adamsrlad...@adamsinfoserv.com

PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/

Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

When auto-fill breaks a link into multiple lines, the link is no longer displayed as a link

[Philip Blagoveschensky]

Sometimes org-mode breaks links into multiple lines: sometimes Auto-Fill 
 does this, sometimes me invoking org-fill-paragraph does this. When it 
happens, org-mode displays them incorrectly, but only after I reload the 
file (see the attached screenshot, there's a newline symbol before the 
word "field"). How do I either


- Make it stop breaking links?
- Make it display them correctly even if they are broken?

I've been told that they are supposed to be displayed as links even when 
multiline, and that something in my configuration must be broken. Does 
anyone know what causes this?


Emacs  : GNU Emacs 26.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.5)
 of 2019-09-23, modified by Debian
Package: Org mode version 9.3.6 (9.3.6-elpa @ 
/home/username/.emacs.d/elpa/org-9.3.6/)


Also, I use org-roam 1.2.0.
--
Regards,
Philip Blagoveschensky

Re: [PATCH] Use completing-read-multiple for org-set-tags-command

[Clemens]

Sorry, I just figured out you get indeed completion after the first tag 
my sandbox wasn't clean (usually that shouldn't affect the completion 
behavior but somehow it did, I have to check why). In this case your are 
also right that `org-tags-completion-function` need to be adjusted. My 
patch still is useful to make frameworks which support 
`completing-read-multiple` automatically work though while the current 
approach is tightly integrated with the default completion.


I will do some more work and report back.

Re: [PATCH] Use completing-read-multiple for org-set-tags-command

[Clemens]

With the built-in completion, org-set-tags-command already supports
completing multiple tags. 


Interesting, I couldn't figure out how. I tried with emacs -Q (v 26.3) 
and I get only completion for the first tag. If you try to get 
completion after entering the first you get an [no match] message. Maybe 
I'm doing something wrong? How do you get completion after the first tag 
with default completion?



So that aim reduces to using
completing-read-multiple because other completion libraries are more
likely to play nicely with crm.

At the moment that's not mentioned in the commit message (and, less
importantly, it wasn't mentioned in the message introducing the patch),
but in my view that aim should be the emphasis of the commit message.
It'd be good to note the popular completion libraries that don't work
out of the box with the current approach, and whether they do after this
patch.


As described above my initial aim was really to get completion after 
entering the first tag (that is mentioned in my message introducing the 
patch but it is a good idea to mention it also in the commit). 
Completion frameworks automatically benefit from this if they support 
`completing-read-multiple`.



It's also probably worth mentioning why org-tags-completion-function is
still passed as the completion function to completing-read-multiple, as
the completion function's main purpose of completing multiple tags could
now be fulfilled by completing-read-multiple alone.  And what about the
other spots that use org-tags-completion-function?


I haven't looked at `org-tags-completion-function` in detail will have 
to check if something could be adjusted there, too. I thought usages in 
other spots wouldn't be affected and should automatically work with the 
new enhanced behavior. I will look into that, had you something specific 
in mind?


Thanks for your review and help!

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

[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