* commit 4e864643 breaks org-return
@ 2015-10-22 16:57 Stefan-W. Hahn
2015-10-23 20:07 ` Stefan-W. Hahn
0 siblings, 1 reply; 8+ messages in thread
From: Stefan-W. Hahn @ 2015-10-22 16:57 UTC (permalink / raw)
To: emacs-orgmode
Hello,
commit 4e864643bdb6bba3e000ea51fb746a26e40b1f77
Author: Nicolas Goaziou <mail@nicolasgoaziou.fr>
Date: Sun Oct 18 09:36:15 2015 +0200
changes the behaviour of org-return when positioned right after a link with
org-return-follows-link set to t.
The test shows the scenario which now goes wrong:
#+BEGIN_SRC elisp
(should-not
(org-test-with-temp-text "Link [[target]]<point> <<target>>"
(let ((org-return-follows-link t)
(org-link-search-must-match-exact-headline nil))
(org-return))
(org-looking-at-p "<<target>>")))
#+END_SRC
Behaviour before was to open a new line. Same for links in task headline or
any other link.
With kind regards,
Stefan
--
Stefan-W. Hahn It is easy to make things.
It is hard to make things simple.
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: commit 4e864643 breaks org-return
2015-10-22 16:57 commit 4e864643 breaks org-return Stefan-W. Hahn
@ 2015-10-23 20:07 ` Stefan-W. Hahn
2015-10-23 22:34 ` Nicolas Goaziou
0 siblings, 1 reply; 8+ messages in thread
From: Stefan-W. Hahn @ 2015-10-23 20:07 UTC (permalink / raw)
To: emacs-orgmode
Mail von Stefan-W. Hahn, Thu, 22 Oct 2015 at 18:57:08 +0200:
Hello,
> commit 4e864643bdb6bba3e000ea51fb746a26e40b1f77
> Author: Nicolas Goaziou <mail@nicolasgoaziou.fr>
> Date: Sun Oct 18 09:36:15 2015 +0200
>
> changes the behaviour of org-return when positioned right after a link with
> org-return-follows-link set to t.
the following patch seems to repair the behaviour:
#+BEGIN_SRC elisp
diff --git a/lisp/org.el b/lisp/org.el
index a5183aa..3d527ac 100755
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -21354,7 +21354,9 @@ (defun org-return (&optional indent)
((and org-return-follows-link
(or (org-at-timestamp-p t)
(org-at-date-range-p t)
- (org-in-regexp org-any-link-re)))
+ (org-in-regexp org-any-link-re))
+ (< (point)
+ (org-element-property :end context)))
(call-interactively #'org-open-at-point))
;; Insert newline in heading, but preserve tags.
((and (not (bolp))
#+END_SRC elisp
With kind regards,
Stefan
--
Stefan-W. Hahn It is easy to make things.
It is hard to make things simple.
^ permalink raw reply related [flat|nested] 8+ messages in thread* Re: commit 4e864643 breaks org-return
2015-10-23 20:07 ` Stefan-W. Hahn
@ 2015-10-23 22:34 ` Nicolas Goaziou
2015-10-24 6:48 ` Stefan-W. Hahn
0 siblings, 1 reply; 8+ messages in thread
From: Nicolas Goaziou @ 2015-10-23 22:34 UTC (permalink / raw)
To: Stefan-W. Hahn; +Cc: emacs-orgmode
Hello,
"Stefan-W. Hahn" <stefan.hahn@s-hahn.de> writes:
> Mail von Stefan-W. Hahn, Thu, 22 Oct 2015 at 18:57:08 +0200:
>
> Hello,
>
>> commit 4e864643bdb6bba3e000ea51fb746a26e40b1f77
>> Author: Nicolas Goaziou <mail@nicolasgoaziou.fr>
>> Date: Sun Oct 18 09:36:15 2015 +0200
>>
>> changes the behaviour of org-return when positioned right after a link with
>> org-return-follows-link set to t.
>
> the following patch seems to repair the behaviour:
But is the current behaviour broken in the first place? At least it is
consistent with `org-open-at-point' (C-c C-o).
>
> #+BEGIN_SRC elisp
> diff --git a/lisp/org.el b/lisp/org.el
> index a5183aa..3d527ac 100755
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -21354,7 +21354,9 @@ (defun org-return (&optional indent)
> ((and org-return-follows-link
> (or (org-at-timestamp-p t)
> (org-at-date-range-p t)
> - (org-in-regexp org-any-link-re)))
> + (org-in-regexp org-any-link-re))
> + (< (point)
> + (org-element-property :end context)))
This wouldn't cut it because CONTEXT is wrong when, e.g., point is in
a comment. I think you're after the VISUALLY argument from
`org-in-regexp'. But then, it would require to turn
`org-at-date-range-p' and `org-at-timestamp-p' into `org-in-regexp'
calls.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: commit 4e864643 breaks org-return
2015-10-23 22:34 ` Nicolas Goaziou
@ 2015-10-24 6:48 ` Stefan-W. Hahn
2015-10-25 16:41 ` Behaviour of org-open-at-point and org-return (was commit 4e864643 breaks org-return) Stefan-W. Hahn
2015-11-01 23:19 ` commit 4e864643 breaks org-return Simon Thum
0 siblings, 2 replies; 8+ messages in thread
From: Stefan-W. Hahn @ 2015-10-24 6:48 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: emacs-orgmode
Mail von Nicolas Goaziou, Sat, 24 Oct 2015 at 00:34:54 +0200:
Hello,
> >> commit 4e864643bdb6bba3e000ea51fb746a26e40b1f77
> >> Author: Nicolas Goaziou <mail@nicolasgoaziou.fr>
> >> Date: Sun Oct 18 09:36:15 2015 +0200
> >>
> >> changes the behaviour of org-return when positioned right after a link with
> >> org-return-follows-link set to t.
> >
> > the following patch seems to repair the behaviour:
>
> But is the current behaviour broken in the first place? At least it is
> consistent with `org-open-at-point' (C-c C-o).
Yes. Yes.
Before commit 4e86464 the behaviour was:
[[link][description]]x
with cursor at x hitting <RET> I got a line opened with cursor positioned
at the beginning of the new line (or indented).
But you are right, org-open-at-point with cursor at position x jumps
to the link. This behaviour is not changed with the commit but I think
this is also not the right behaviour. If you go with the mouse over the x
then you don't get any popup from the link. For this you have to
go at least over the last character "]" of the link resp. the visual "n"
of the description. Even if you describe-text-properties with cursor at x
you don't get any hint of the link. You have to go over the "]" (resp. "n")
to see the link hint.
From my point of view the commit 4e86464 changes the behaviour of org-return
in a manner of which I think is not natural. org-open-at-point is, in my
opinion, wrong in the same way because description says:
"... When point is on a link, follow it."
And being with cursor at x is obviously not "on a link".
Any opinions from you or other org'ers?
With kind regards,
Stefan
--
Stefan-W. Hahn It is easy to make things.
It is hard to make things simple.
^ permalink raw reply [flat|nested] 8+ messages in thread* Behaviour of org-open-at-point and org-return (was commit 4e864643 breaks org-return)
2015-10-24 6:48 ` Stefan-W. Hahn
@ 2015-10-25 16:41 ` Stefan-W. Hahn
2015-10-28 14:02 ` Matt Lundin
2015-10-31 22:38 ` Nicolas Goaziou
2015-11-01 23:19 ` commit 4e864643 breaks org-return Simon Thum
1 sibling, 2 replies; 8+ messages in thread
From: Stefan-W. Hahn @ 2015-10-25 16:41 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: emacs-orgmode
Mail von Stefan-W. Hahn, Sat, 24 Oct 2015 at 08:48:47 +0200:
Hello,
as I observed there is a change in behaviour of org-return from on
commit 4e864643bdb6bba3e000ea51fb746a26e40b1f77
Author: Nicolas Goaziou <mail@nicolasgoaziou.fr>
Date: Sun Oct 18 09:36:15 2015 +0200
for timestamps, date ranges and any link.
The same change of behaviour was done for org-open-at-point from on
commit d75fa9febc676af4893fba9e4d53d5babbb801aa
Author: Nicolas Goaziou <n.goaziou@gmail.com>
Date: Sun Mar 2 10:32:51 2014 +0100
for timestamp, any link and footnote-reference (perhaps other I'm not sure).
For example of a link:
[[link][description]]x
If cursor was at position x the old behaviour of org-return (hitting <RET>)
was to open a new line, and position the cursor at the beginning of the new
line. The old behaviour of org-open-at-point was to say "no link".
For me this seems consistent because if you go with the cursor over
position x you see no hint and mouse-click do nothing. You have to go
over the link to see face changing and be able to mouse-click top follow
the link.
Additonally description of org-open-at-point say "... When point is on a
link, follow it....", not "on or after".
Also if you insert a link by yanking or org-insert-link cursor is positioned
directly after inserted link, cursor pos x s.o. With old behaviour you can
behaviour you can straight hit <RET> to get a newline. With new behaviour
you have to add space before <RET> or call open-line and position the
cursor.
For me the new behaviour seems inconsistend itself because everytime
I want to get a new line I noew have to check if cursor is positioned
right after a timestamp, or link. Or I have to shutoff org-return-follows-link.
Are there any other org'ers with opinions about this behaviour?
I'm really interested in your and others opinion about this behaviours
before building some workarounds for me personally. (Perhaps I have overseen
something in the big pictures?)
With kind regards,
Stefan
P.S. Excue me if not being subtle enough, its difficult to me beeing subtle
in a foreign language.
--
Stefan-W. Hahn It is easy to make things.
It is hard to make things simple.
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Behaviour of org-open-at-point and org-return (was commit 4e864643 breaks org-return)
2015-10-25 16:41 ` Behaviour of org-open-at-point and org-return (was commit 4e864643 breaks org-return) Stefan-W. Hahn
@ 2015-10-28 14:02 ` Matt Lundin
2015-10-31 22:38 ` Nicolas Goaziou
1 sibling, 0 replies; 8+ messages in thread
From: Matt Lundin @ 2015-10-28 14:02 UTC (permalink / raw)
To: Stefan-W. Hahn; +Cc: emacs-orgmode, Nicolas Goaziou
"Stefan-W. Hahn" <stefan.hahn@s-hahn.de> writes:
>
> For example of a link:
>
> [[link][description]]x
>
> If cursor was at position x the old behaviour of org-return (hitting <RET>)
> was to open a new line, and position the cursor at the beginning of the new
> line. The old behaviour of org-open-at-point was to say "no link".
>
> For me this seems consistent because if you go with the cursor over
> position x you see no hint and mouse-click do nothing. You have to go
> over the link to see face changing and be able to mouse-click top follow
> the link.
> Additonally description of org-open-at-point say "... When point is on a
> link, follow it....", not "on or after".
>
> Also if you insert a link by yanking or org-insert-link cursor is positioned
> directly after inserted link, cursor pos x s.o. With old behaviour you can
> behaviour you can straight hit <RET> to get a newline. With new behaviour
> you have to add space before <RET> or call open-line and position the
> cursor.
I can confirm this bug. It affected me when I was trying to enter
scheduling information:
E.g., if I insert the following with org-time-stamp...
<2015-10-28 Wed>
^
...the cursor is located after the time stamp (as shown). But if I hit
return to create a new line and enter a new data (text, a time stamp,
etc.), I am taken unexpectedly to the agenda.
Best,
Matt
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Behaviour of org-open-at-point and org-return (was commit 4e864643 breaks org-return)
2015-10-25 16:41 ` Behaviour of org-open-at-point and org-return (was commit 4e864643 breaks org-return) Stefan-W. Hahn
2015-10-28 14:02 ` Matt Lundin
@ 2015-10-31 22:38 ` Nicolas Goaziou
1 sibling, 0 replies; 8+ messages in thread
From: Nicolas Goaziou @ 2015-10-31 22:38 UTC (permalink / raw)
To: Stefan-W. Hahn; +Cc: emacs-orgmode
Hello
"Stefan-W. Hahn" <stefan.hahn@s-hahn.de> writes:
> as I observed there is a change in behaviour of org-return from on
>
> commit 4e864643bdb6bba3e000ea51fb746a26e40b1f77
> Author: Nicolas Goaziou <mail@nicolasgoaziou.fr>
> Date: Sun Oct 18 09:36:15 2015 +0200
>
> for timestamps, date ranges and any link.
>
> The same change of behaviour was done for org-open-at-point from on
>
> commit d75fa9febc676af4893fba9e4d53d5babbb801aa
> Author: Nicolas Goaziou <n.goaziou@gmail.com>
> Date: Sun Mar 2 10:32:51 2014 +0100
>
> for timestamp, any link and footnote-reference (perhaps other I'm not sure).
>
> For example of a link:
>
> [[link][description]]x
>
> If cursor was at position x the old behaviour of org-return (hitting <RET>)
> was to open a new line, and position the cursor at the beginning of the new
> line. The old behaviour of org-open-at-point was to say "no link".
>
> For me this seems consistent because if you go with the cursor over
> position x you see no hint and mouse-click do nothing. You have to go
> over the link to see face changing and be able to mouse-click top follow
> the link.
>
> Additonally description of org-open-at-point say "... When point is on a
> link, follow it....", not "on or after".
>
> Also if you insert a link by yanking or org-insert-link cursor is positioned
> directly after inserted link, cursor pos x s.o. With old behaviour you can
> behaviour you can straight hit <RET> to get a newline. With new behaviour
> you have to add space before <RET> or call open-line and position the
> cursor.
>
> For me the new behaviour seems inconsistend itself because everytime
> I want to get a new line I noew have to check if cursor is positioned
> right after a timestamp, or link. Or I have to shutoff
> org-return-follows-link.
Fixed in both `org-return' and `org-open-at-point'. Thank you.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: commit 4e864643 breaks org-return
2015-10-24 6:48 ` Stefan-W. Hahn
2015-10-25 16:41 ` Behaviour of org-open-at-point and org-return (was commit 4e864643 breaks org-return) Stefan-W. Hahn
@ 2015-11-01 23:19 ` Simon Thum
1 sibling, 0 replies; 8+ messages in thread
From: Simon Thum @ 2015-11-01 23:19 UTC (permalink / raw)
To: Stefan-W. Hahn, Nicolas Goaziou; +Cc: emacs-orgmode
Yes, absolutely, it's annnoying. This probably is the bug I reported a
day ago.
But in the past I observed this a bit differently:
Your description is correct, but there is/was a workaround: If you go to
x from the line below (i.e. press cursor left from the beginning of the
next line) it does/did not trigger. Any fix should probably be tested
against that trick too.
Cheers,
Simon
On 10/24/15 06:48, Stefan-W. Hahn wrote:
> Mail von Nicolas Goaziou, Sat, 24 Oct 2015 at 00:34:54 +0200:
>
> Hello,
>
>>>> commit 4e864643bdb6bba3e000ea51fb746a26e40b1f77
>>>> Author: Nicolas Goaziou <mail@nicolasgoaziou.fr>
>>>> Date: Sun Oct 18 09:36:15 2015 +0200
>>>>
>>>> changes the behaviour of org-return when positioned right after a link with
>>>> org-return-follows-link set to t.
>>>
>>> the following patch seems to repair the behaviour:
>>
>> But is the current behaviour broken in the first place? At least it is
>> consistent with `org-open-at-point' (C-c C-o).
>
> Yes. Yes.
>
> Before commit 4e86464 the behaviour was:
>
> [[link][description]]x
>
> with cursor at x hitting <RET> I got a line opened with cursor positioned
> at the beginning of the new line (or indented).
>
> But you are right, org-open-at-point with cursor at position x jumps
> to the link. This behaviour is not changed with the commit but I think
> this is also not the right behaviour. If you go with the mouse over the x
> then you don't get any popup from the link. For this you have to
> go at least over the last character "]" of the link resp. the visual "n"
> of the description. Even if you describe-text-properties with cursor at x
> you don't get any hint of the link. You have to go over the "]" (resp. "n")
> to see the link hint.
>
> From my point of view the commit 4e86464 changes the behaviour of org-return
> in a manner of which I think is not natural. org-open-at-point is, in my
> opinion, wrong in the same way because description says:
> "... When point is on a link, follow it."
> And being with cursor at x is obviously not "on a link".
>
> Any opinions from you or other org'ers?
>
> With kind regards,
> Stefan
>
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2015-10-31 23:20 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-10-22 16:57 commit 4e864643 breaks org-return Stefan-W. Hahn
2015-10-23 20:07 ` Stefan-W. Hahn
2015-10-23 22:34 ` Nicolas Goaziou
2015-10-24 6:48 ` Stefan-W. Hahn
2015-10-25 16:41 ` Behaviour of org-open-at-point and org-return (was commit 4e864643 breaks org-return) Stefan-W. Hahn
2015-10-28 14:02 ` Matt Lundin
2015-10-31 22:38 ` Nicolas Goaziou
2015-11-01 23:19 ` commit 4e864643 breaks org-return Simon Thum
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).