[RFC] Change visibility for bracket links

[RFC] Change visibility for bracket links

[Nicolas Goaziou]

[-- Attachment #1: Type: text/plain, Size: 1516 bytes --]

Hello,

I'd like to make the following change to bracket links display (i.e.,
when `org-highlight-links' contains `bracket', which is the default).

Basically, I want to leave a visible pair of brackets around the link,
i.e.,

  [[uri][description]]

is displayed as

  [description]

instead of

  description

and

  [[uri]]

is displayed as

  [uri]

instead of

  uri

The rationale behind this suggestion is that editing a mostly invisible
link is unintuitive when point is at the boundaries of its visible part.

More precisely, in the following visible part of a link

  description

if point hits "d" from the right, changes happen in the description of
the link, but if point comes from the left, changes happen before the
link. 

I guess I could get used to it, but sometimes, the link happens to be at
column 0. In this case, the only way to "come from the left" is to move
to the previous line and go past the newline character. This is, IMO,
very annoying, notwithstanding the fact that it is impossible to realize
at the beginning of the buffer.

Leaving a pair of brackets, OTOH, disambiguates the situation. Editing
before the opening bracket makes changes before the link. Conversely,
editing after the former makes changes to the uri or the description,
whichever is displayed.

The cost a little more visual clutter, but it seems very acceptable to
me. I attach a quick patch for testing.

Feedback welcome.

Regards,

-- 
Nicolas Goaziou                                                0x80A93738

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Change-bracket-links-visibility.patch --]
[-- Type: text/x-diff, Size: 4080 bytes --]

From 768d77be335e1e5e0a4afa9bf7dbd89f9c5ab65e Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
Date: Wed, 5 Oct 2016 17:22:15 +0200
Subject: [PATCH] Change bracket links visibility

* lisp/org.el (org-activate-bracket-links): Leave a pair of brackets
  around bracket links so as to facilitate editing them.
---
 lisp/org.el | 49 ++++++++++++++++++-------------------------------
 1 file changed, 18 insertions(+), 31 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 6d5201b..25f48e3 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -6199,41 +6199,34 @@ by a #."
 			  (t
 			   `(:uri ,(format "%s:%s" type path)))))
 	   (activate-func (org-link-get-parameter type :activate-func))
-	   ;; invisible part
-	   (ip (list 'invisible (or
-				 (org-link-get-parameter type :display)
-				 'org-link)
-		     'face face
-		     'keymap keymap
-		     'mouse-face mouse-face
-		     'font-lock-multiline t
-		     'help-echo help
-		     'htmlize-link htmlize-link))
-	   ;; visible part
+	   ;; Visible part.
 	   (vp (list 'keymap keymap
 		     'face face
 		     'mouse-face mouse-face
 		     'font-lock-multiline t
 		     'help-echo help
-		     'htmlize-link htmlize-link)))
+		     'htmlize-link htmlize-link))
+	   ;; Invisible part.
+	   (ip (append (list 'invisible
+			     (or (org-link-get-parameter type :display)
+				 'org-link))
+		       vp)))
       ;; We need to remove the invisible property here.  Table narrowing
       ;; may have made some of this invisible.
       (org-remove-flyspell-overlays-in (match-beginning 0) (match-end 0))
       (remove-text-properties (match-beginning 0) (match-end 0)
 			      '(invisible nil))
-      (if (match-end 3)
+      (if (match-end 2)
 	  (progn
-	    (add-text-properties (match-beginning 0) (match-beginning 3) ip)
-	    (org-rear-nonsticky-at (match-beginning 3))
-	    (add-text-properties (match-beginning 3) (match-end 3) vp)
-	    (org-rear-nonsticky-at (match-end 3))
-	    (add-text-properties (match-end 3) (match-end 0) ip)
+	    (add-text-properties (match-beginning 0) (match-beginning 2) ip)
+	    (add-text-properties (match-beginning 2) (match-end 2) vp)
+	    (add-text-properties (match-end 2) (match-end 0) ip)
+	    ;; The following is needed so as characters inserted after
+	    ;; the closing bracket do not enter the link.
 	    (org-rear-nonsticky-at (match-end 0)))
-	(add-text-properties (match-beginning 0) (match-beginning 1) ip)
-	(org-rear-nonsticky-at (match-beginning 1))
-	(add-text-properties (match-beginning 1) (match-end 1) vp)
-	(org-rear-nonsticky-at (match-end 1))
-	(add-text-properties (match-end 1) (match-end 0) ip)
+	(add-text-properties (match-beginning 0) (1+ (match-beginning 0)) ip)
+	(add-text-properties (1+ (match-beginning 0)) (1+ (match-end 1)) vp)
+	(add-text-properties (1+ (match-end 1)) (match-end 0) ip)
 	(org-rear-nonsticky-at (match-end 0)))
       (when activate-func
 	(funcall activate-func link-start link-end path bracketp))
@@ -23762,10 +23755,7 @@ beyond the end of the headline."
 	    ;; point was already at beginning of line and command is
 	    ;; repeated.
 	    (when (and (= (point) pos) (eq last-command this-command))
-	      (goto-char after-bullet))))))))
-  (setq disable-point-adjustment
-        (or (not (invisible-p (point)))
-            (not (invisible-p (max (point-min) (1- (point))))))))
+	      (goto-char after-bullet)))))))))
 
 (defun org-end-of-line (&optional arg)
   "Go to the end of the line.
@@ -23802,10 +23792,7 @@ the cursor is already beyond the end of the headline."
 	  ;; If element is hidden, `move-end-of-line' would put point
 	  ;; after it.  Use `end-of-line' to stay on current line.
 	  (call-interactively 'end-of-line))
-	 (t (call-interactively move-fun))))))
-  (setq disable-point-adjustment
-        (or (not (invisible-p (point)))
-            (not (invisible-p (max (point-min) (1- (point))))))))
+	 (t (call-interactively move-fun)))))))
 
 (define-key org-mode-map "\C-a" 'org-beginning-of-line)
 (define-key org-mode-map "\C-e" 'org-end-of-line)
-- 
2.9.3

Re: [RFC] Change visibility for bracket links

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 2209 bytes --]

Le mercredi 5 octobre 2016, Nicolas Goaziou <mail@nicolasgoaziou.fr> a
écrit :

> Hello,
>
> I'd like to make the following change to bracket links display (i.e.,
> when `org-highlight-links' contains `bracket', which is the default).
>
> Basically, I want to leave a visible pair of brackets around the link,
> i.e.,
>
>   [[uri][description]]
>
> is displayed as
>
>   [description]
>
> instead of
>
>   description
>
> and
>
>   [[uri]]
>
> is displayed as
>
>   [uri]
>
> instead of
>
>   uri
>
>
+1

Very good suggestion.

Rainer

The rationale behind this suggestion is that editing a mostly invisible
> link is unintuitive when point is at the boundaries of its visible part.
>
> More precisely, in the following visible part of a link
>
>   description
>
> if point hits "d" from the right, changes happen in the description of
> the link, but if point comes from the left, changes happen before the
> link.
>
> I guess I could get used to it, but sometimes, the link happens to be at
> column 0. In this case, the only way to "come from the left" is to move
> to the previous line and go past the newline character. This is, IMO,
> very annoying, notwithstanding the fact that it is impossible to realize
> at the beginning of the buffer.
>
> Leaving a pair of brackets, OTOH, disambiguates the situation. Editing
> before the opening bracket makes changes before the link. Conversely,
> editing after the former makes changes to the uri or the description,
> whichever is displayed.
>
> The cost a little more visual clutter, but it seems very acceptable to
> me. I attach a quick patch for testing.
>
> Feedback welcome.
>
> Regards,
>
> --
> Nicolas Goaziou                                                0x80A93738
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax (F):       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

[-- Attachment #2: Type: text/html, Size: 2911 bytes --]

Re: [RFC] Change visibility for bracket links

[Marco Wahl]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> I'd like to make the following change to bracket links display (i.e.,
> when `org-highlight-links' contains `bracket', which is the default).
>
> Basically, I want to leave a visible pair of brackets around the link,
> i.e.,
>
>   [[uri][description]]
>
> is displayed as
>
>   [description]

> [omission]

> The cost a little more visual clutter, but it seems very acceptable to
> me. I attach a quick patch for testing.
>
> Feedback welcome.

+1

I think there is an issue with the coloring when writing text
immediately to the right of a file link.  E.g.

[[file:shot.png]]text


Regards,
-- 
Marco

Re: [RFC] Change visibility for bracket links

[Detlef Steuer]

Am Wed, 05 Oct 2016 17:40:08 +0200
schrieb Nicolas Goaziou <mail@nicolasgoaziou.fr>:

> Hello,
> 
> I'd like to make the following change to bracket links display (i.e.,
> when `org-highlight-links' contains `bracket', which is the default).
> 
> Basically, I want to leave a visible pair of brackets around the link,
> i.e.,
> 
>   [[uri][description]]
> 
> is displayed as
> 
>   [description]
> 
> instead of
> 
>   description
> 
> and
> 
>   [[uri]]
> 
> is displayed as
> 
>   [uri]
> 
> instead of
> 
>   uri

+1

Detlef

> 
> The rationale behind this suggestion is that editing a mostly
> invisible link is unintuitive when point is at the boundaries of its
> visible part.
> 
> More precisely, in the following visible part of a link
> 
>   description
> 
> if point hits "d" from the right, changes happen in the description of
> the link, but if point comes from the left, changes happen before the
> link. 
> 
> I guess I could get used to it, but sometimes, the link happens to be
> at column 0. In this case, the only way to "come from the left" is to
> move to the previous line and go past the newline character. This is,
> IMO, very annoying, notwithstanding the fact that it is impossible to
> realize at the beginning of the buffer.
> 
> Leaving a pair of brackets, OTOH, disambiguates the situation. Editing
> before the opening bracket makes changes before the link. Conversely,
> editing after the former makes changes to the uri or the description,
> whichever is displayed.
> 
> The cost a little more visual clutter, but it seems very acceptable to
> me. I attach a quick patch for testing.
> 
> Feedback welcome.
> 
> Regards,
> 

Re: [RFC] Change visibility for bracket links

[Nicolas Goaziou]

[-- Attachment #1: Type: text/plain, Size: 297 bytes --]

Marco Wahl <marcowahlsoft@gmail.com> writes:

> I think there is an issue with the coloring when writing text
> immediately to the right of a file link.  E.g.
>
> [[file:shot.png]]text

You are right. I didn't check the patch thoroughly. Here is an update,
which should be more robust.

Regards,


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Change-bracket-links-visibility.patch --]
[-- Type: text/x-diff, Size: 5912 bytes --]

From 518363a2b794fc21d28987dd59a65c0efa1d9ce4 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
Date: Wed, 5 Oct 2016 17:22:15 +0200
Subject: [PATCH] Change bracket links visibility

* lisp/org.el (org-activate-bracket-links): Leave a pair of brackets
  around bracket links so as to facilitate editing them.  Small
  refactoring.
(org-beginning-of-line):
(org-end-of-line): Remove workaround bug #14346, since the original
report cannot be reproduced.

* testing/lisp/test-org.el (test-org/beginning-of-line): Fix test.
---
 lisp/org.el              | 66 +++++++++++++++++++++---------------------------
 testing/lisp/test-org.el |  4 +--
 2 files changed, 31 insertions(+), 39 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 6d5201b..fcc60d3 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -6163,7 +6163,6 @@ by a #."
 			(match-string-no-properties 2 hl))))
 	   (link-start (match-beginning 0))
 	   (link-end (match-end 0))
-	   (bracketp t)
 	   (help-echo (org-link-get-parameter type :help-echo))
 	   (help (cond
 		  ((stringp help-echo)
@@ -6199,44 +6198,43 @@ by a #."
 			  (t
 			   `(:uri ,(format "%s:%s" type path)))))
 	   (activate-func (org-link-get-parameter type :activate-func))
-	   ;; invisible part
-	   (ip (list 'invisible (or
-				 (org-link-get-parameter type :display)
-				 'org-link)
-		     'face face
-		     'keymap keymap
-		     'mouse-face mouse-face
-		     'font-lock-multiline t
-		     'help-echo help
-		     'htmlize-link htmlize-link))
-	   ;; visible part
+	   ;; Visible part.
 	   (vp (list 'keymap keymap
 		     'face face
 		     'mouse-face mouse-face
 		     'font-lock-multiline t
 		     'help-echo help
-		     'htmlize-link htmlize-link)))
-      ;; We need to remove the invisible property here.  Table narrowing
-      ;; may have made some of this invisible.
+		     'htmlize-link htmlize-link))
+	   ;; Invisible part.
+	   (ip (append (list 'invisible
+			     (or (org-link-get-parameter type :display)
+				 'org-link))
+		       vp)))
+      ;; We need to remove the invisible property here.  Table
+      ;; narrowing may have made some of this invisible.
       (org-remove-flyspell-overlays-in (match-beginning 0) (match-end 0))
       (remove-text-properties (match-beginning 0) (match-end 0)
 			      '(invisible nil))
-      (if (match-end 3)
+      (if (match-end 2)
 	  (progn
-	    (add-text-properties (match-beginning 0) (match-beginning 3) ip)
-	    (org-rear-nonsticky-at (match-beginning 3))
-	    (add-text-properties (match-beginning 3) (match-end 3) vp)
-	    (org-rear-nonsticky-at (match-end 3))
-	    (add-text-properties (match-end 3) (match-end 0) ip)
-	    (org-rear-nonsticky-at (match-end 0)))
-	(add-text-properties (match-beginning 0) (match-beginning 1) ip)
-	(org-rear-nonsticky-at (match-beginning 1))
-	(add-text-properties (match-beginning 1) (match-end 1) vp)
-	(org-rear-nonsticky-at (match-end 1))
-	(add-text-properties (match-end 1) (match-end 0) ip)
-	(org-rear-nonsticky-at (match-end 0)))
+	    (add-text-properties (match-beginning 0) (match-beginning 2) ip)
+	    (add-text-properties (match-beginning 2) (match-end 2) vp)
+	    (add-text-properties (match-end 2) (match-end 0) ip)
+	    ;; Make sure text after the visible closing bracket gets
+	    ;; past the whole link.
+	    (add-text-properties (match-end 2) (match-end 0)
+				 `(rear-nonsticky ,ip))
+	    (add-text-properties (match-end 2) (match-end 0)
+				 `(front-sticky ,ip)))
+	(add-text-properties (match-beginning 0) (1+ (match-beginning 0)) ip)
+	(add-text-properties (1+ (match-beginning 0)) (1+ (match-end 1)) vp)
+	(add-text-properties (1+ (match-end 1)) (match-end 0) ip)
+	;; Make sure text after the visible closing bracket gets past
+	;; the whole link.
+	(add-text-properties (match-end 1) (match-end 0) `(rear-nonsticky ,ip))
+	(add-text-properties (match-end 1) (match-end 0) `(front-sticky ,ip)))
       (when activate-func
-	(funcall activate-func link-start link-end path bracketp))
+        (funcall activate-func link-start link-end path t))
       t)))
 
 (defun org-activate-dates (limit)
@@ -23762,10 +23760,7 @@ beyond the end of the headline."
 	    ;; point was already at beginning of line and command is
 	    ;; repeated.
 	    (when (and (= (point) pos) (eq last-command this-command))
-	      (goto-char after-bullet))))))))
-  (setq disable-point-adjustment
-        (or (not (invisible-p (point)))
-            (not (invisible-p (max (point-min) (1- (point))))))))
+	      (goto-char after-bullet)))))))))
 
 (defun org-end-of-line (&optional arg)
   "Go to the end of the line.
@@ -23802,10 +23797,7 @@ the cursor is already beyond the end of the headline."
 	  ;; If element is hidden, `move-end-of-line' would put point
 	  ;; after it.  Use `end-of-line' to stay on current line.
 	  (call-interactively 'end-of-line))
-	 (t (call-interactively move-fun))))))
-  (setq disable-point-adjustment
-        (or (not (invisible-p (point)))
-            (not (invisible-p (max (point-min) (1- (point))))))))
+	 (t (call-interactively move-fun)))))))
 
 (define-key org-mode-map "\C-a" 'org-beginning-of-line)
 (define-key org-mode-map "\C-e" 'org-end-of-line)
diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el
index 56ccfd6..29d933b 100644
--- a/testing/lisp/test-org.el
+++ b/testing/lisp/test-org.el
@@ -2491,10 +2491,10 @@ http://article.gmane.org/gmane.emacs.orgmode/21459/"
   ;; asterisk.
   (should
    (org-test-with-temp-text "*<point>"
-     (let ((org-special-ctrl-a/e t)) (org-beginning-of-line))))
+     (let ((org-special-ctrl-a/e t)) (org-beginning-of-line) t)))
   (should
    (org-test-with-temp-text "*<point>"
-     (let ((org-special-ctrl-a/e nil)) (org-beginning-of-line)))))
+     (let ((org-special-ctrl-a/e nil)) (org-beginning-of-line) t))))
 
 (ert-deftest test-org/end-of-line ()
   "Test `org-end-of-line' specifications."
-- 
2.9.3

Re: [RFC] Change visibility for bracket links

[David A. Gershman]

Not bad, but could it be customizable via variable giving the user the
choice?


>On October 5, 2016 8:40:08 AM PDT, Nicolas Goaziou
><mail@nicolasgoaziou.fr> wrote:
>>Hello,
>>
>>I'd like to make the following change to bracket links display (i.e.,
>>when `org-highlight-links' contains `bracket', which is the default).
>>
>>Basically, I want to leave a visible pair of brackets around the link,
>>i.e.,
>>
>>  [[uri][description]]
>>
>>is displayed as
>>
>>  [description]
>>
>>instead of
>>
>>  description
>>
>>and
>>
>>  [[uri]]
>>
>>is displayed as
>>
>>  [uri]
>>
>>instead of
>>
>>  uri
>>
>>The rationale behind this suggestion is that editing a mostly
>invisible
>>link is unintuitive when point is at the boundaries of its visible
>>part.
>>
>>More precisely, in the following visible part of a link
>>
>>  description
>>
>>if point hits "d" from the right, changes happen in the description of
>>the link, but if point comes from the left, changes happen before the
>>link. 
>>
>>I guess I could get used to it, but sometimes, the link happens to be
>>at
>>column 0. In this case, the only way to "come from the left" is to
>move
>>to the previous line and go past the newline character. This is, IMO,
>>very annoying, notwithstanding the fact that it is impossible to
>>realize
>>at the beginning of the buffer.
>>
>>Leaving a pair of brackets, OTOH, disambiguates the situation. Editing
>>before the opening bracket makes changes before the link. Conversely,
>>editing after the former makes changes to the uri or the description,
>>whichever is displayed.
>>
>>The cost a little more visual clutter, but it seems very acceptable to
>>me. I attach a quick patch for testing.
>>
>>Feedback welcome.
>>
>>Regards,

-- 
David A. Gershman, CISSP
dagershman@dagertech.net

Re: [RFC] Change visibility for bracket links

[Nicolas Goaziou]

Hello,

"David A. Gershman" <dagershman@dagertech.net> writes:

> Not bad, but could it be customizable via variable giving the user the
> choice?

Thank you for your feedback.

I guess we could introduce a variable to let users shoot them in the
foot, but is there any incentive to do so? I mean, the clutter is
minimal, and the current state can be very annoying at times (ever tried
to start a buffer with a bracket link?).


Regards,

-- 
Nicolas Goaziou                                                0x80A93738

Re: [RFC] Change visibility for bracket links

[David A. Gershman]

On 10/05/2016 03:26 PM, Nicolas Goaziou wrote:
> Hello,
>
> "David A. Gershman" <dagershman@dagertech.net> writes:
>
>> Not bad, but could it be customizable via variable giving the user the
>> choice?
> Thank you for your feedback.
>
> I guess we could introduce a variable to let users shoot them in the
> foot, but is there any incentive to do so? I mean, the clutter is
> minimal, and the current state can be very annoying at times (ever tried
> to start a buffer with a bracket link?).
>
>
Actually, no I haven't. :)

I have no problem with the brackets, I just think they "break up" the
flow of reading we're familiar with.  Dare I say many people are use to
a web-like experience when having hyper links in text.  From your
description, the existence of the brackets are more for precise edits
without having to fudge with point.  I have fallen victim to that, but
admit, I prefer "clean" links.

If you do add the variable, by all means, have the new [format] be the
default.  Let people like me do the additional work of changing their
config.  It gives us a chance of being the geniuses who know how to help
others if/when they ask on the list. *evil laugh*


--David

Re: [RFC] Change visibility for bracket links

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 1562 bytes --]

On 2016-10-05 20:16, David A. Gershman wrote:
> On 10/05/2016 03:26 PM, Nicolas Goaziou wrote:
>> Hello,
>>
>> "David A. Gershman" <dagershman@dagertech.net> writes:
>>
>>> Not bad, but could it be customizable via variable giving the user the
>>> choice?
>> Thank you for your feedback.
>>
>> I guess we could introduce a variable to let users shoot them in the
>> foot, but is there any incentive to do so? I mean, the clutter is
>> minimal, and the current state can be very annoying at times (ever tried
>> to start a buffer with a bracket link?).
>>
>>
> Actually, no I haven't. :)
> 
> I have no problem with the brackets, I just think they "break up" the
> flow of reading we're familiar with.  Dare I say many people are use to
> a web-like experience when having hyper links in text.  From your
> description, the existence of the brackets are more for precise edits
> without having to fudge with point.  I have fallen victim to that, but
> admit, I prefer "clean" links.

What about having our cake and eating it too? :)  We could do just the same as what prettify-symbols-mode does with its prettify-symbols-unprettify-at-point variable.  Namely, we could show the brackets when point is at the edge of a link, and hide them otherwise.  The same trick could be applied to subscripts (I have working code for that for a different project, at https://github.com/cpitclaudel/company-coq/blob/master/company-coq.el#L4287).

Wouldn't this preserve the flow of reading, while allowing for easier editing?

Cheers,
Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [RFC] Change visibility for bracket links

[Eric S Fraga]

On Thursday,  6 Oct 2016 at 00:27, Clément Pit--Claudel wrote:
> What about having our cake and eating it too? :) We could do just the
> same as what prettify-symbols-mode does with its
> prettify-symbols-unprettify-at-point variable.

This would be nice.

In any case, Nicolas, I am fully in favour of your proposed
change.  Editing links has always been very frustrating for me and your
suggestion would make it much easier.

Thanks,
eric

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.1.1, Org release_8.3.6-1131-gd68497

Re: [RFC] Change visibility for bracket links

[William Denton]

On 6 October 2016, Eric S Fraga wrote:

> In any case, Nicolas, I am fully in favour of your proposed
> change.  Editing links has always been very frustrating for me and your
> suggestion would make it much easier.

+1 from me too.

Bil
-- 
William Denton :: Toronto, Canada :: https://www.miskatonic.org/
Caveat lector.

Re: [RFC] Change visibility for bracket links

[Nicolas Goaziou]

Hello,

Clément Pit--Claudel <clement.pit@gmail.com> writes:

> What about having our cake and eating it too? :) We could do just the
> same as what prettify-symbols-mode does with its
> prettify-symbols-unprettify-at-point variable. Namely, we could show
> the brackets when point is at the edge of a link, and hide them
> otherwise. The same trick could be applied to subscripts (I have
> working code for that for a different project, at
> https://github.com/cpitclaudel/company-coq/blob/master/company-coq.el#L4287).
>
> Wouldn't this preserve the flow of reading, while allowing for easier
> editing?

I have the feeling that it would cause some visual "jumping" when the
link is very different (e.g., wider) than its visible pars. Some links
tend to be very long. So showing the full link is not an option.

I don't know about showing only the brackets. Would you want to provide
a mock-up ?

Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [RFC] Change visibility for bracket links

[Adam Porter]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> I'd like to make the following change to bracket links display (i.e.,
> when `org-highlight-links' contains `bracket', which is the default).
>
> Basically, I want to leave a visible pair of brackets around the link,

Hi Nicolas,

I understand the motivation for making this change, but I respectfully
request that this be made configurable.  I much prefer the "clean" links
without visible brackets, and adding them would seem like a regression
to me.  I'm guessing that many current Org users would also prefer to
keep the brackets invisible.

Thanks for your work on Org.

Re: [RFC] Change visibility for bracket links

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 594 bytes --]

On 2016-10-07 22:38, Adam Porter wrote:
> I understand the motivation for making this change, but I respectfully
> request that this be made configurable.  I much prefer the "clean" links
> without visible brackets, and adding them would seem like a regression
> to me.  I'm guessing that many current Org users would also prefer to
> keep the brackets invisible.

Adam, what do you think of my earlier suggestion (displaying the brackets when the pointer is on them, hiding them otherwise? (In the style of prettify-symbols-mode with unprettify-symbol-at-point)

Cheers,
Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [RFC] Change visibility for bracket links

[Adam Porter]

Clément Pit--Claudel <clement.pit@gmail.com> writes:

Hi Clément,

> Adam, what do you think of my earlier suggestion (displaying the
> brackets when the pointer is on them, hiding them otherwise? (In the
> style of prettify-symbols-mode with unprettify-symbol-at-point)

Sorry, I missed that in the thread.  That sounds like a great idea!

Re: [RFC] Change visibility for bracket links

[Nick Dokos]

Clément Pit--Claudel <clement.pit@gmail.com> writes:

> On 2016-10-07 22:38, Adam Porter wrote:
>> I understand the motivation for making this change, but I respectfully
>> request that this be made configurable.  I much prefer the "clean" links
>> without visible brackets, and adding them would seem like a regression
>> to me.  I'm guessing that many current Org users would also prefer to
>> keep the brackets invisible.
>
> Adam, what do you think of my earlier suggestion (displaying the
> brackets when the pointer is on them, hiding them otherwise? (In the
> style of prettify-symbols-mode with unprettify-symbol-at-point)
>

I don't particularly care whether the brackets are shown or not, but I
dislike things that change the visual appearance as you roll over
them. The web is full of such things and they drive me bananas: you
are trying to read something and you roll over something in the text
that changes its appearance, possibly shifting the text that you are
reading and leaving you to chase it around the page - good bye,
concentration.  Even if you do it by just switching visibility on the
brackets, it's distracting when you are reading; it might be helpful
when composing but I'm not convinced even for that.

If this proposal is considered at all, *please* make it optional.

My 2 cents.

Thanks!
-- 
Nick

Re: [RFC] Change visibility for bracket links

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 1773 bytes --]

On 2016-10-10 10:17, Nick Dokos wrote:
> Clément Pit--Claudel <clement.pit@gmail.com> writes:
> 
>> On 2016-10-07 22:38, Adam Porter wrote:
>>> I understand the motivation for making this change, but I respectfully
>>> request that this be made configurable.  I much prefer the "clean" links
>>> without visible brackets, and adding them would seem like a regression
>>> to me.  I'm guessing that many current Org users would also prefer to
>>> keep the brackets invisible.
>>
>> Adam, what do you think of my earlier suggestion (displaying the
>> brackets when the pointer is on them, hiding them otherwise? (In the
>> style of prettify-symbols-mode with unprettify-symbol-at-point)
>>
> 
> I don't particularly care whether the brackets are shown or not, but I
> dislike things that change the visual appearance as you roll over
> them. 

Note that by pointer I meant point, not mouse; IOW, pointing on something with your mouse would not change anything display-wise.
I'm not sure what you meant by roll-over.

> The web is full of such things and they drive me bananas: you
> are trying to read something and you roll over something in the text
> that changes its appearance, possibly shifting the text that you are
> reading and leaving you to chase it around the page - good bye,
> concentration.  Even if you do it by just switching visibility on the
> brackets, it's distracting when you are reading; it might be helpful
> when composing but I'm not convinced even for that.

Agreed.  I'd be curious to get feedback from users of prettify-symbols-mode, too.  And to know whether your objections apply as strongly to just revealing the brackets when the point is on them (not when they are being moused over) 

Cheers,
Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [RFC] Change visibility for bracket links

[Nick Dokos]

Clément Pit--Claudel <clement.pit@gmail.com> writes:

> On 2016-10-10 10:17, Nick Dokos wrote:
>> Clément Pit--Claudel <clement.pit@gmail.com> writes:
>> 
>>> On 2016-10-07 22:38, Adam Porter wrote:
>>>> I understand the motivation for making this change, but I respectfully
>>>> request that this be made configurable.  I much prefer the "clean" links
>>>> without visible brackets, and adding them would seem like a regression
>>>> to me.  I'm guessing that many current Org users would also prefer to
>>>> keep the brackets invisible.
>>>
>>> Adam, what do you think of my earlier suggestion (displaying the
>>> brackets when the pointer is on them, hiding them otherwise? (In the
>>> style of prettify-symbols-mode with unprettify-symbol-at-point)
>>>
>> 
>> I don't particularly care whether the brackets are shown or not, but I
>> dislike things that change the visual appearance as you roll over
>> them. 
>
> Note that by pointer I meant point, not mouse; IOW, pointing on
> something with your mouse would not change anything display-wise.
> I'm not sure what you meant by roll-over.
>

Either mouse-over or "point-over" (to coin a phrase): changing the
visual appearance "explosively" is bad IMO. Subtler changes might be
more acceptable but I think it would require some research and
user-customizable behaviour to satisfy different needs - in short, I'm
not sure it's worth it but as long as I can turn it off, I'm OK with
it: there are plenty of things in org that I've never used, in some
cases consciously, in others because of ignorance, but if somebody
finds them useful and they are not tripping me up constantly, their
existence does not bother me.

>> The web is full of such things and they drive me bananas: you
>> are trying to read something and you roll over something in the text
>> that changes its appearance, possibly shifting the text that you are
>> reading and leaving you to chase it around the page - good bye,
>> concentration.  Even if you do it by just switching visibility on the
>> brackets, it's distracting when you are reading; it might be helpful
>> when composing but I'm not convinced even for that.
>
> Agreed.  I'd be curious to get feedback from users of
> prettify-symbols-mode, too.  And to know whether your objections apply
> as strongly to just revealing the brackets when the point is on them
> (not when they are being moused over)
>

I don't think that's any different: using emacs on the console only allows
"point-over" but if the mechanism is distracting, then I want to be able
to turn it off there too.

-- 
Nick

Re: [RFC] Change visibility for bracket links

[Daniele Nicolodi]

On 05/10/16 09:40, Nicolas Goaziou wrote:
> Hello,
> 
> I'd like to make the following change to bracket links display (i.e.,
> when `org-highlight-links' contains `bracket', which is the default).
> 
> Basically, I want to leave a visible pair of brackets around the link,

I don't like the brackets. If you must please make this configurable.

> The rationale behind this suggestion is that editing a mostly invisible
> link is unintuitive when point is at the boundaries of its visible part.

I use org-insert-link [C-c C-l] to edit links. I think this solved your
problem with the difficulty in editing the link description.

Cheers,
Daniele

Re: [RFC] Change visibility for bracket links

[Rasmus]

Hi Nicolas,

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Feedback welcome.

I don't like this proposal.  Links are already highlighted with a separate
face, org-link.  That is enough IMO.  It makes Org look more cluttered,
and personally I value having a good writing experience, including a crisp
display of the buffer (these days I even use variable-pitch for the
majority of text in my Org buffers).

Clément suggestion of a using something akin to prettify symbols mode is
great, though.  We could limit the length of the url being shown.  It can
always be edited with e.g. "C-c ’" or, as currently, "C-c C-l".

Thanks,
Rasmus

-- 
Sådan en god dansk lagereddike kan man slet ikke bruge mere

Re: [RFC] Change visibility for bracket links

[Rasmus]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> Clément Pit--Claudel <clement.pit@gmail.com> writes:
>
>> What about having our cake and eating it too? :) We could do just the
>> same as what prettify-symbols-mode does with its
>> prettify-symbols-unprettify-at-point variable. Namely, we could show
>> the brackets when point is at the edge of a link, and hide them
>> otherwise. The same trick could be applied to subscripts (I have
>> working code for that for a different project, at
>> https://github.com/cpitclaudel/company-coq/blob/master/company-coq.el#L4287).
>>
>> Wouldn't this preserve the flow of reading, while allowing for easier
>> editing?
>
> I have the feeling that it would cause some visual "jumping" when the
> link is very different (e.g., wider) than its visible pars. Some links
> tend to be very long. So showing the full link is not an option.

We can limit it to a certain number of characters and expand it, like when
the width of table columns is limited.

BTW: I don’t find that prettify-symbols-mode with (setq
prettify-symbols-unprettify-at-point 'right-edge) ruins the reading flow.
On the contrary, I would love to port org-entities to use this
functionality for at display in buffers.

Rasmus

-- 
Together we will make the possible totalllly impossible!

Re: [RFC] Change visibility for bracket links

[Nicolas Goaziou]

Hello,

Rasmus <rasmus@gmx.us> writes:

> I don't like this proposal.  Links are already highlighted with a separate
> face, org-link.  That is enough IMO.  It makes Org look more cluttered,
> and personally I value having a good writing experience, including a crisp
> display of the buffer (these days I even use variable-pitch for the
> majority of text in my Org buffers).

A "good writing experience" includes a "good editing experience", or so
I think. I'm suggesting to solve some problems related to the latter,
under certain circumstances I explained in my original post. 

The `org-link' face is not enough, as pointed out, because it's not
a matter of making the links stand out in the buffer.

> Clément suggestion of a using something akin to prettify symbols mode is
> great, though.  We could limit the length of the url being shown.  It can
> always be edited with e.g. "C-c ’" or, as currently, "C-c C-l".

The problem is not really about editing the link itself, but editing
around the link. The problem also arises for the text just before or
just after the link. "C-c C-l" cannot help here.

I cannot tell, however, if Clément's suggestion is good or not. This is
why I'd like to see a mock of the result, if anyone wants to implement
one.

Regards,

-- 
Nicolas Goaziou

Re: [RFC] Change visibility for bracket links

[Nicolas Goaziou]

Hello,

Daniele Nicolodi <daniele@grinta.net> writes:

> I use org-insert-link [C-c C-l] to edit links. I think this solved your
> problem with the difficulty in editing the link description.

No, it doesn't. The problem also arises with text _around_ the link
itself, which can be painful to edit. You could try, e.g., to start an
empty buffer with and try to add anything before it (no M-x visible-mode
or M-: allowed).

Regards,

-- 
Nicolas Goaziou

Re: [RFC] Change visibility for bracket links

[Nicolas Goaziou]

Correcting myself,

> No, it doesn't. The problem also arises with text _around_ the link
> itself, which can be painful to edit. You could try, e.g., to start an
> empty buffer with and try to add anything before it (no M-x visible-mode
                 ^^^^
               a bracket link

Re: [RFC] Change visibility for bracket links

[Rasmus]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> A "good writing experience" includes a "good editing experience", or so
> I think. I'm suggesting to solve some problems related to the latter,
> under certain circumstances I explained in my original post. 

I agree there’s a problem, but I find the proposed solution potentially
annoying...

> The `org-link' face is not enough, as pointed out, because it's not
> a matter of making the links stand out in the buffer.

I see.

>> Clément suggestion of a using something akin to prettify symbols mode is
>> great, though.  We could limit the length of the url being shown.  It can
>> always be edited with e.g. "C-c ’" or, as currently, "C-c C-l".
>
> The problem is not really about editing the link itself, but editing
> around the link. The problem also arises for the text just before or
> just after the link. "C-c C-l" cannot help here.

It is a problem.  It's also a problem with super/subscripts as pointed out
earlier.

> I cannot tell, however, if Clément's suggestion is good or not. This is
> why I'd like to see a mock of the result, if anyone wants to implement
> one.

Here’s a quick-and-dirty "mockup" in Emacs 25.1.  It doesn’t work
properly, obviously, but try to move the cursor from left-to-right to get
a taste of what it could be like.  Of course, the behavior could be
tweaked, e.g. characters displayed etc...

(progn 
  (setq prettify-symbols-alist
	'(("[[https://www.very-long-links-that-might-be-obnoxious-when-exampned.org/][" . " ")
	  ("]]" . " "))
	prettify-symbols-unprettify-at-point 'right-edge)
  (prettify-symbols-mode)
  (insert "\ntext before [[https://www.very-long-links-that-might-be-obnoxious-when-exampned.org/][my description]] text after\n"))

Rasmus

-- 
However beautiful the theory, one should occasionally look at the evidence

Re: [RFC] Change visibility for bracket links

[Nicolas Goaziou]

Hello,

Rasmus <rasmus@gmx.us> writes:

> I agree there’s a problem, but I find the proposed solution potentially
> annoying...

I understand. I thought the advantages would mitigate the drawbacks. In
any case, I'd rather have a solution, active by default, and a way to
disable it than no solution at all.

> It is a problem.  It's also a problem with super/subscripts as pointed out
> earlier.

Exactly. Ideally, the chosen solution could be applied to
sub/superscripts too.

> Here’s a quick-and-dirty "mockup" in Emacs 25.1.  It doesn’t work
> properly, obviously, but try to move the cursor from left-to-right to get
> a taste of what it could be like.  Of course, the behavior could be
> tweaked, e.g. characters displayed etc...
>
> (progn 
>   (setq prettify-symbols-alist
> 	'(("[[https://www.very-long-links-that-might-be-obnoxious-when-exampned.org/][" . " ")
> 	  ("]]" . " "))
> 	prettify-symbols-unprettify-at-point 'right-edge)
>   (prettify-symbols-mode)
>   (insert "\ntext before [[https://www.very-long-links-that-might-be-obnoxious-when-exampned.org/][my description]] text after\n"))

Thank you. However, if I eval this in an Org buffer, the new line is
properly inserted but nothing happens when point goes past the link.

Am I missing something?

Also, it doesn't seem to understand Org syntax, i.e., any "]]" would be
prettified, even if they do not belong to an Org link.

Regards,

-- 
Nicolas Goaziou

Re: [RFC] Change visibility for bracket links

[Rasmus]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:


>> Here’s a quick-and-dirty "mockup" in Emacs 25.1.  It doesn’t work
>> properly, obviously, but try to move the cursor from left-to-right to get
>> a taste of what it could be like.  Of course, the behavior could be
>> tweaked, e.g. characters displayed etc...
>>
>> (progn 
>>   (setq prettify-symbols-alist
>> 	'(("[[https://www.very-long-links-that-might-be-obnoxious-when-exampned.org/][" . " ")
>> 	  ("]]" . " "))
>> 	prettify-symbols-unprettify-at-point 'right-edge)
>>   (prettify-symbols-mode)
>>   (insert "\ntext before [[https://www.very-long-links-that-might-be-obnoxious-when-exampned.org/][my description]] text after\n"))
>
> Thank you. However, if I eval this in an Org buffer, the new line is
> properly inserted but nothing happens when point goes past the link.
>
> Am I missing something?
>
> Also, it doesn't seem to understand Org syntax, i.e., any "]]" would be
> prettified, even if they do not belong to an Org link.

No, I meant for it eval in the *scratch* buffer.  It merely shows how it
might look with a similar mechanism to prettify-symbols-mode.  Of course,
it lacks all care to details that would make it nice.

I suspect it would suffers from the jumping that Nick, and I guess you as
well, was advocating against...

Here’s a recording of my screen:

       https://webmshare.com/6wqWB

(I hope the site isn’t annoying; it works fine in Fx with uBlock and I
tried in the chromium as well w/o any ad-blocking).

Rasmus

-- 
And when I’m finished thinking, I have to die a lot

Re: [RFC] Change visibility for bracket links

[Daniele Nicolodi]

On 10/12/16 4:37 AM, Nicolas Goaziou wrote:
> Hello,
> 
> Daniele Nicolodi <daniele@grinta.net> writes:
> 
>> I use org-insert-link [C-c C-l] to edit links. I think this solved your
>> problem with the difficulty in editing the link description.
> 
> No, it doesn't. The problem also arises with text _around_ the link
> itself, which can be painful to edit. You could try, e.g., to start an
> empty buffer with and try to add anything before it (no M-x visible-mode
> or M-: allowed).

I just tried: going to the beginning of the line with C-a (by default
bound to org-beginning-of-line in org-mode) puts the cursor in a
position where you can insert text before the link, without it being
part of the link description.

Does this solve your problem? :)

Cheers,
Daniele

Re: [RFC] Change visibility for bracket links

[Nicolas Goaziou]

Hello,

Daniele Nicolodi <daniele@grinta.net> writes:

> I just tried: going to the beginning of the line with C-a (by default
> bound to org-beginning-of-line in org-mode) puts the cursor in a
> position where you can insert text before the link, without it being
> part of the link description.

Interesting. It doesn't work in Org 8.3.6.

I unleashed my bisecting powers (!) and discovered I had introduced
a regression during 8.3.3 release.

This is now fixed and C-a puts point before the link, again. Thank you.

> Does this solve your problem? :)

Not really. It makes my example more bearable, but using C-a is still
a workaround, and there are also many other dances to perform in various
other cases. So, I still think there is an usability issue that needs to
be fixed.

As another data point, `org-hide-emphasis-markers' is nil by default,
because emphasized text can be a pain to edit when this variable is
non-nil. I don't think links should go the opposite way.

Regards,

-- 
Nicolas Goaziou

Re: [RFC] Change visibility for bracket links

[Rasmus]

Hi,

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

>   [[uri][description]]
>
> is displayed as
>
>   [description]
>
> instead of
>
>   description
>
> and
>
>   [[uri]]
>
> is displayed as
>
>   [uri]
>
> instead of
>
>   uri

How about showing boundaries only when the cursor is near "hidden" text?
This would also work for emphasized text when org-hide-emphasis-markers is
non-nil.  When the cursor is far away from a link it is only using its
respective face, namely org-link or bold or whatever.  Example, where "|"
is the cursor:

      Pre| text description post text
                ^^^^^^^^^^^
                a link, org-link face

      Pre| text bold text text
                ^^^^^^^^^
                bold face

But when the cursor is next to the link or emphasized text markers are
shown.

      Pre text |[description] post text
      Pre text |*bold text* post text

It would not cause much jumping.  Of course, for people who wants to avoid
jumping altogether org-hide-emphasis-markers could be set to nil.  It
would arguably make org-hide-emphasis-markers more useful for emphasized
text as well.

Rasmus

-- 
Hooray!

Re: [RFC] Change visibility for bracket links

[Rasmus]

Hi,

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

>   [[uri][description]]
>
> is displayed as
>
>   [description]
>
> instead of
>
>   description
>
> and
>
>   [[uri]]
>
> is displayed as
>
>   [uri]
>
> instead of
>
>   uri

How about showing boundaries only when the cursor is near "hidden" text?
This would also work for emphasized text when org-hide-emphasis-markers is
non-nil.  When the cursor is far away from a link it is only using its
respective face, namely org-link or bold or whatever.  Example, where "|"
is the cursor:

      Pre| text description post text
                ^^^^^^^^^^^
                a link, org-link face

      Pre| text bold text text
                ^^^^^^^^^
                bold face

But when the cursor is next to the link or emphasized text markers are
shown.

      Pre text |[description] post text
      Pre text |*bold text* post text

It would not cause much jumping.  Of course, for people who wants to avoid
jumping altogether org-hide-emphasis-markers could be set to nil.  It
would arguably make org-hide-emphasis-markers more useful for emphasized
text as well.

Rasmus

Re: [RFC] Change visibility for bracket links

[Aaron Ecay]

Hi Nicolas, hi all,

2016ko urriak 13an, Nicolas Goaziou-ek idatzi zuen:

[...]


> Not really. It makes my example more bearable, but using C-a is still
> a workaround, and there are also many other dances to perform in various
> other cases. So, I still think there is an usability issue that needs to
> be fixed.

FWIW, I agree.  On the other hand, many people object to the brackets.
My understanding of the problem is that when link fontification is
turned on, it is impossible to tell between the two marked positions
when point is in in a link like:

 [[http://google.com][Search]]
^  ^

My suggestion is that we solve the problem in a different way: by
changing the color of the cursor when the text is inside the link.
So, the cursor would be the default grey color at the first ^ above,
and red at the second ^?  (Of course, the color we use for the cursor
in links could be changed by customization).  It looks like such an
effect is achievable by combining the cursor-sensor-functions text
property with set-cursor-color.

WDYT?

-- 
Aaron Ecay

Re: [RFC] Change visibility for bracket links

[Nicolas Goaziou]

Hello,

Rasmus <rasmus@gmx.us> writes:

> No, I meant for it eval in the *scratch* buffer.  It merely shows how it
> might look with a similar mechanism to prettify-symbols-mode.  Of course,
> it lacks all care to details that would make it nice.
>
> I suspect it would suffers from the jumping that Nick, and I guess you as
> well, was advocating against...

Exactly. IMO, this jumping is much more disturbing than a static pair of
additional square brackets.

> Here’s a recording of my screen:
>
>        https://webmshare.com/6wqWB

I understand what `prettify-symbols-mode' is. My real problem is
understanding how it can help with links in Org. In particular, I'd like
to see it, or any other mechanism, turn

  [[http://orgmode.org][Org mode]]

displayed as

  Org mode

into

  [Org mode]

when point is near _any_ of the boundaries and doesn't trigger anything
on anything not related to an Org link.

I don't know if that would be sufficient to make it useful, but it needs
to be as subtle as possible. We already have a not-so-subtle solution
with visible square brackets.


Regards,

-- 
Nicolas Goaziou

Re: [RFC] Change visibility for bracket links

[Nicolas Goaziou]

Hello,

Aaron Ecay <aaronecay@gmail.com> writes:

> FWIW, I agree.  On the other hand, many people object to the brackets.

I don't mind adding a variable.

> My understanding of the problem is that when link fontification is
> turned on, it is impossible to tell between the two marked positions
> when point is in in a link like:
>
>  [[http://google.com][Search]]
> ^  ^
>
> My suggestion is that we solve the problem in a different way: by
> changing the color of the cursor when the text is inside the link.
> So, the cursor would be the default grey color at the first ^ above,
> and red at the second ^?  (Of course, the color we use for the cursor
> in links could be changed by customization).  It looks like such an
> effect is achievable by combining the cursor-sensor-functions text
> property with set-cursor-color.
>
> WDYT?

That would only partly solve the problem. Cursor's color would tell you
where you are, but the dance (e.g., C-a or backward-forward) is still
needed to effectively move to the other side.

Regards,

-- 
Nicolas Goaziou

Re: [RFC] Change visibility for bracket links

[Michael Brand]

Hi Nicolas

On Thu, Oct 13, 2016 at 2:35 PM, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
>
> Aaron Ecay <aaronecay@gmail.com> writes:
>
>> FWIW, I agree.  On the other hand, many people object to the brackets.
>
> I don't mind adding a variable.

Or maybe add new value(s) to org-descriptive-links to avoid yet
another defcustom and first of all to have it in that one variable
that when set to nil turns off any mechanism that hides anything in
links already?

Michael

Re: [RFC] Change visibility for bracket links

[Nick Dokos]

Rasmus <rasmus@gmx.us> writes:

> Hi,
>
> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>
>>   [[uri][description]]
>>
>> is displayed as
>>
>>   [description]
>>
>> instead of
>>
>>   description
>>
>> and
>>
>>   [[uri]]
>>
>> is displayed as
>>
>>   [uri]
>>
>> instead of
>>
>>   uri
>
> How about showing boundaries only when the cursor is near "hidden" text?
> This would also work for emphasized text when org-hide-emphasis-markers is
> non-nil.  When the cursor is far away from a link it is only using its
> respective face, namely org-link or bold or whatever.  Example, where "|"
> is the cursor:
>
>       Pre| text description post text
>                 ^^^^^^^^^^^
>                 a link, org-link face
>
>       Pre| text bold text text
>                 ^^^^^^^^^
>                 bold face
>
> But when the cursor is next to the link or emphasized text markers are
> shown.
>
>       Pre text |[description] post text
>       Pre text |*bold text* post text
>
> It would not cause much jumping.  Of course, for people who wants to avoid
> jumping altogether org-hide-emphasis-markers could be set to nil.  It
> would arguably make org-hide-emphasis-markers more useful for emphasized
> text as well.
>

I'm worried that this would be computationally prohibitive.

-- 
Nick

Re: [RFC] Change visibility for bracket links

[Rasmus]

Hi Nick,

Nick Dokos <ndokos@gmail.com> writes:

> I'm worried that this would be computationally prohibitive.

I guess something like ‘prettify-symbols--post-command-hook’ could be
used.  When point is within the range of
prettify-symbols--current-symbol-bounds it shows the emphasis marker by
removing the ‘invisible’ text property.  When it leaves, it reapplies the
’invisible’ text property.

As I have not tried to actually code this so I haven’t got a clue whether
my "model" is too simplified to work out in practice.

Rasmus

-- 
This space is left intentionally blank

Re: [RFC] Change visibility for bracket links

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 700 bytes --]

On 2016-10-13 12:13, Nick Dokos wrote:
>> >
>> > But when the cursor is next to the link or emphasized text markers are
>> > shown.
>> >
>> >       Pre text |[description] post text
>> >       Pre text |*bold text* post text
>> >
>> > It would not cause much jumping.  Of course, for people who wants to avoid
>> > jumping altogether org-hide-emphasis-markers could be set to nil.  It
>> > would arguably make org-hide-emphasis-markers more useful for emphasized
>> > text as well.
>> >
> I'm worried that this would be computationally prohibitive.

I think we have evidence to the contrary: prettify-symbols-mode works fine, even with unprettify-at-point.  Doesn't it?

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [RFC] Change visibility for bracket links

[Nick Dokos]

Clément Pit--Claudel <clement.pit@gmail.com> writes:

> On 2016-10-13 12:13, Nick Dokos wrote:
>>> >
>>> > But when the cursor is next to the link or emphasized text markers are
>>> > shown.
>>> >
>>> >       Pre text |[description] post text
>>> >       Pre text |*bold text* post text
>>> >
>>> > It would not cause much jumping.  Of course, for people who wants to avoid
>>> > jumping altogether org-hide-emphasis-markers could be set to nil.  It
>>> > would arguably make org-hide-emphasis-markers more useful for emphasized
>>> > text as well.
>>> >
>> I'm worried that this would be computationally prohibitive.
>
> I think we have evidence to the contrary: prettify-symbols-mode works
> fine, even with unprettify-at-point.  Doesn't it?
>

I don't know: I've never used it, so I haven't done any performance
measurements on it. But I worry (about a lot of things, not just this :-) ).

-- 
Nick

Re: [RFC] Change visibility for bracket links

[Daniele Nicolodi]

On 10/13/16 6:07 AM, Nicolas Goaziou wrote:
> Daniele Nicolodi <daniele@grinta.net> writes:
> 
>> Does this solve your problem? :)
> 
> Not really. It makes my example more bearable, but using C-a is still
> a workaround, and there are also many other dances to perform in various
> other cases. So, I still think there is an usability issue that needs to
> be fixed.
> 
> As another data point, `org-hide-emphasis-markers' is nil by default,
> because emphasized text can be a pain to edit when this variable is
> non-nil. I don't think links should go the opposite way.

Hi Nicolas,

I understand the problem and I agree that editing links and text around
them is not always straightforward.  However I think that what you are
proposing is a change in behavior that does not strictly solve a
technical problem.  As such, I believe, having the [ ] markers should be
an option, and probably not enabled by default.

Cheers,
Daniele

Re: Change visibility for bracket links

[Gregor Zattler]

Hi Nicolas, org-mode users and developers,
* Nicolas Goaziou <mail@nicolasgoaziou.fr> [13. Okt. 2016]:
> Aaron Ecay <aaronecay@gmail.com> writes:
>> My understanding of the problem is that when link fontification is
>> turned on, it is impossible to tell between the two marked positions
>> when point is in in a link like:
>>
>>  [[http://google.com][Search]]
>> ^  ^
>>
>> My suggestion is that we solve the problem in a different way: by
>> changing the color of the cursor when the text is inside the link.
>> So, the cursor would be the default grey color at the first ^ above,
>> and red at the second ^?  (Of course, the color we use for the cursor
>> in links could be changed by customization).  It looks like such an
>> effect is achievable by combining the cursor-sensor-functions text
>> property with set-cursor-color.
>>
>> WDYT?
> 
> That would only partly solve the problem. Cursor's color would tell you
> where you are, but the dance (e.g., C-a or backward-forward) is still
> needed to effectively move to the other side.

But this is a cursor movment problem then.  How about
org-beginning-of-link, org-end-of-link (this already works with
org-next-link as some kind of a substitute of org-beginning-of-link)?


Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-

Re: [RFC] Change visibility for bracket links

[Nicolas Goaziou]

Hello,

Michael Brand <michael.ch.brand@gmail.com> writes:

> Or maybe add new value(s) to org-descriptive-links to avoid yet
> another defcustom and first of all to have it in that one variable
> that when set to nil turns off any mechanism that hides anything in
> links already?

I'm fine with that, too.

Regards,

-- 
Nicolas Goaziou

Re: [RFC] Change visibility for bracket links

[Nicolas Goaziou]

Hello,

Daniele Nicolodi <daniele@grinta.net> writes:

> However I think that what you are proposing is a change in behavior
> that does not strictly solve a technical problem.

This is a change in display. I don't think it affects very much, if at
all, any "behavior", except that editing link is much more predictable.

> As such, I believe, having the [ ] markers should be an option, and
> probably not enabled by default.

On the contrary, I firmly believe this, as an option, should be enabled
by default, to be on par with everything else in Org (emphasis, macros,
sub/superscript...).

Besides, there should be little surprise with default values. I think
there are plenty of them with current display method.

Eventually, manual has a section called "Clean view" where such things
could be discussed at length. There is no "Crowded view" node, tho.


Regards,

-- 
Nicolas Goaziou

Re: [RFC] Change visibility for bracket links

[William Denton]

On 13 October 2016, Daniele Nicolodi wrote:

> As such, I believe, having the [ ] markers should be an option, and probably 
> not enabled by default.

After seeing further conversation I've changed my mind, and don't like the idea 
of [ ] markers around links, so FWIW I agree with Daniele.

Bill
-- 
William Denton :: Toronto, Canada :: https://www.miskatonic.org/
Caveat lector.

Re: [RFC] Change visibility for bracket links

[Aaron Ecay]

Hi Nicolas,

2016ko urriak 13an, Nicolas Goaziou-ek idatzi zuen:
> 
> Hello,
> 
> Aaron Ecay <aaronecay@gmail.com> writes:
> 
>> FWIW, I agree.  On the other hand, many people object to the brackets.
> 
> I don't mind adding a variable.

I think that org in general has too many customization variables.  Of
course, for each of them there is some user(s) who regard it as very
important to their workflow.  So, we should think hard before
introducing new ones about whether there is a way to accomplish what we
want which does not need a variable.  (Of course, sometimes this goal is
not possible and a new defcustom is needed.)


[...]

>> WDYT?
> 
> That would only partly solve the problem. Cursor's color would tell you
> where you are, but the dance (e.g., C-a or backward-forward) is still
> needed to effectively move to the other side.

Yes: the point will always be in only one of the two positions indicated
in my previous mail.  And some command(s) will always be needed to move
between the two.  AFAICT this remains true under any scenario: the status
quo, the proposal for visible brackets, or the one for distinctive cursor
color.  The question as I understood it is finding a display mechanism
that communicates the information about which of the two positions point
is in when it is relevant, without being obtrusive during other
editing.  You also pointed out the importance of making the commands
needed as obvious as possible.

I think the bracket proposal satisfies the goal of perspicuous commands,
but not of presenting the information only when relevant.  Changing point
color satisfies the presentation criteria, but the movement commands
would not be very obvious.

The suggestion of hiding and showing markers based on point motion,
raised in another subthread, is interesting.  It might be the best of
both worlds.  I would like to try out a POC implementation.  (I believe
I can predict the effect of either the brackets or the cursor colors on
my editing experience, but not necessarily the other.)

-- 
Aaron Ecay

Re: [RFC] Change visibility for bracket links

[Joost Kremers]

On Mon, Oct 10 2016, Clément Pit--Claudel wrote:
> Agreed.  I'd be curious to get feedback from users of 
> prettify-symbols-mode, too.  And to know whether your objections 
> apply as strongly to just revealing the brackets when the point 
> is on them (not when they are being moused over) 

I don't use prettify-symbols-mode, but I am a fairly heavy user of 
AUCTeX's TeX-fold-mode, which hides all sorts of LaTeX code (and 
can be customised to hide even more in quite sophisticated ways). 
For example, it shows

    This is some \textit{emphasised} text.

as 

    This is some emphasised text.

with the word "emphasised" in a different colour (to indicate that 
it's been folded) and with whatever fontification the argument of 
the \textit macro gets (italicised by default). 

Now, TeX-fold-mode has the behaviour you mention: as soon as you 
move point (not the mouse cursor) "into" some folded text, it gets 
unfolded (with | indicating point):

    This is some |\textit{emphasised} text.

with the part "\textit{emphasised}" highlighted to indicate that 
it's actuall folded.

Personally, I'm a *big* fan of this behaviour, even though I use 
visual-line-mode in my LaTeX buffers, which means that when text 
is temporarily unfolded, the paragraph may rewrap (and wrap back 
when point leaves the unfolded text causing it to be folded 
again). Since there is visual feedback (from the font colour) that 
some word or stretch of text is folded, I know that the text will 
unfold when I move point into it, so I don't find it distracting. 
The fact that the rest of the paragraph may rewrap is also not an 
issue for me, because I'm not actually focussing on that part of 
the text.

Personally, I've also always found it annoying in Org that editing 
around links (or emphasis etc. with `org-hide-emphasis-markers' 
set to t) is unpredictable and I never really understood why 
functionality similar to TeX-fold-mode hadn't been implemented. I 
thinks it's a very straightforward and easy to understand method 
for indicating which character point is actually on, making 
editing much more comfortable.

Just my €0.02, of course.


-- 
Joost Kremers
Life has its moments

Re: [RFC] Change visibility for bracket links

[Thomas S. Dye]

Aloha Joost,

Joost Kremers writes:

> On Mon, Oct 10 2016, Clément Pit--Claudel wrote:
>> Agreed.  I'd be curious to get feedback from users of 
>> prettify-symbols-mode, too.  And to know whether your objections 
>> apply as strongly to just revealing the brackets when the point 
>> is on them (not when they are being moused over) 
>
> I don't use prettify-symbols-mode, but I am a fairly heavy user of 
> AUCTeX's TeX-fold-mode, which hides all sorts of LaTeX code (and 
> can be customised to hide even more in quite sophisticated ways). 
> For example, it shows
>
>     This is some \textit{emphasised} text.
>
> as 
>
>     This is some emphasised text.
>
> with the word "emphasised" in a different colour (to indicate that 
> it's been folded) and with whatever fontification the argument of 
> the \textit macro gets (italicised by default). 
>
> Now, TeX-fold-mode has the behaviour you mention: as soon as you 
> move point (not the mouse cursor) "into" some folded text, it gets 
> unfolded (with | indicating point):
>
>     This is some |\textit{emphasised} text.
>
> with the part "\textit{emphasised}" highlighted to indicate that 
> it's actuall folded.
>
> Personally, I'm a *big* fan of this behaviour, even though I use 
> visual-line-mode in my LaTeX buffers, which means that when text 
> is temporarily unfolded, the paragraph may rewrap (and wrap back 
> when point leaves the unfolded text causing it to be folded 
> again). Since there is visual feedback (from the font colour) that 
> some word or stretch of text is folded, I know that the text will 
> unfold when I move point into it, so I don't find it distracting. 
> The fact that the rest of the paragraph may rewrap is also not an 
> issue for me, because I'm not actually focussing on that part of 
> the text.
>
> Personally, I've also always found it annoying in Org that editing 
> around links (or emphasis etc. with `org-hide-emphasis-markers' 
> set to t) is unpredictable and I never really understood why 
> functionality similar to TeX-fold-mode hadn't been implemented. I 
> thinks it's a very straightforward and easy to understand method 
> for indicating which character point is actually on, making 
> editing much more comfortable.
>
> Just my €0.02, of course.

Agreed.  Also, mousing over the folded text shows the unfolded text in
the minibuffer.

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: [RFC] Change visibility for bracket links

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 2360 bytes --]

On 2016-10-13 08:30, Nicolas Goaziou wrote:
> I understand what `prettify-symbols-mode' is. My real problem is
> understanding how it can help with links in Org. In particular, I'd like
> to see it, or any other mechanism, turn
> 
>   [[http://orgmode.org][Org mode]]
> 
> displayed as
> 
>   Org mode
> 
> into
> 
>   [Org mode]
> 
> when point is near _any_ of the boundaries and doesn't trigger anything
> on anything not related to an Org link.
> 
> I don't know if that would be sufficient to make it useful, but it needs
> to be as subtle as possible. We already have a not-so-subtle solution
> with visible square brackets.

Hey Nicolas,

Something like this?

    (defvar-local org-show-link--beg nil)
    (defvar-local org-show-link--end nil)

    (defun org-show-link--reveal-at-point (&rest _)
      "Possibly reveal link markup around point."
      (unless (and org-show-link--beg org-show-link--end)
        (setq org-show-link--beg (make-marker)
              org-show-link--end (make-marker)))
      (when (and (marker-position org-show-link--beg)
                 (marker-position org-show-link--end))
        (unless (<= org-show-link--beg (point) org-show-link--end)
          (save-excursion (font-lock-fontify-region org-show-link--beg org-show-link--end))
          (set-marker org-show-link--beg nil)
          (set-marker org-show-link--end nil)))
      (save-excursion
        (when (org-in-regexp org-bracket-link-regexp 1)
          (set-marker org-show-link--beg (match-beginning 0))
          (set-marker org-show-link--end (match-end 0))
          (with-silent-modifications
            (remove-text-properties (match-beginning 2) (1+ (match-beginning 2)) '(invisible))
            (remove-text-properties (1- (match-end 2)) (match-end 2) '(invisible)))))
      (message "%S" org-show-link--end))

    (defun org-show-link-setup ()
      (add-hook 'post-command-hook #'org-show-link--reveal-at-point t t))

    (add-hook 'org-mode-hook #'org-show-link-setup)

Running it before opening an Org buffer with links should be enough to make it work (links brackets will be hidden until point is next to or inside the link).  It's a quick draft, of course — there are still small issues.  But it should give an idea of what my original proposal was about.

Cheers,
Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [RFC] Change visibility for bracket links

[Stig Brautaset]

Clément Pit--Claudel <clement.pit@gmail.com> writes:

> On 2016-10-13 08:30, Nicolas Goaziou wrote:
>> I understand what `prettify-symbols-mode' is. My real problem is
>> understanding how it can help with links in Org. In particular, I'd like
>> to see it, or any other mechanism, turn
>> 
>>   [[http://orgmode.org][Org mode]]
>> 
>> displayed as
>> 
>>   Org mode
>> 
>> into
>> 
>>   [Org mode]
>> 
>> when point is near _any_ of the boundaries and doesn't trigger anything
>> on anything not related to an Org link.
>> 
>> I don't know if that would be sufficient to make it useful, but it needs
>> to be as subtle as possible. We already have a not-so-subtle solution
>> with visible square brackets.
>
> Hey Nicolas,
>
> Something like this?
>
>     (defvar-local org-show-link--beg nil)
>     (defvar-local org-show-link--end nil)
>
>     (defun org-show-link--reveal-at-point (&rest _)
>       "Possibly reveal link markup around point."
>       (unless (and org-show-link--beg org-show-link--end)
>         (setq org-show-link--beg (make-marker)
>               org-show-link--end (make-marker)))
>       (when (and (marker-position org-show-link--beg)
>                  (marker-position org-show-link--end))
>         (unless (<= org-show-link--beg (point) org-show-link--end)
>           (save-excursion (font-lock-fontify-region org-show-link--beg org-show-link--end))
>           (set-marker org-show-link--beg nil)
>           (set-marker org-show-link--end nil)))
>       (save-excursion
>         (when (org-in-regexp org-bracket-link-regexp 1)
>           (set-marker org-show-link--beg (match-beginning 0))
>           (set-marker org-show-link--end (match-end 0))
>           (with-silent-modifications
>             (remove-text-properties (match-beginning 2) (1+ (match-beginning 2)) '(invisible))
>             (remove-text-properties (1- (match-end 2)) (match-end 2) '(invisible)))))
>       (message "%S" org-show-link--end))
>
>     (defun org-show-link-setup ()
>       (add-hook 'post-command-hook #'org-show-link--reveal-at-point t t))
>
>     (add-hook 'org-mode-hook #'org-show-link-setup)
>
> Running it before opening an Org buffer with links should be enough to
> make it work (links brackets will be hidden until point is next to or
> inside the link). It's a quick draft, of course — there are still
> small issues. But it should give an idea of what my original proposal
> was about.

I love this! I have had problems with editing links at the start of
lines etc, and this seems to solve it. I would love something similar
for *bold* and /italics/ too.

Stig