Re: [O] [RFC] Change visibility for bracket links

[Aaron Ecay]

Hi Nicolas,

2016ko urriak 13an, Nicolas Goaziou-ek idatzi zuen:
> 
> Hello,
> 
> Aaron Ecay <address@hidden> 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