Ihor Radchenko <[email protected]> writes:
> "J.D. Smith" <[email protected]> writes:
>
>>> I have played a bit with nested emphasis like
>>> [[foo][bar *baz* az]] and the defaults can make things a bit confusing
>>> when editing the link description. Maybe there should be several cursor
>>> shapes depending on the depth level? Although it is probably going to be
>>> confusing.
>>
>> Yeah I see: exactly the same ambiguity occurs "one level down". How
>> deeply can emphasis/links/etc. be nested?
>
> In practice, down to max number of markup elements.
> Potentially, infinitely, if we add inline special blocks.
>
>> An idea to solve this that picks up on the new "topmost behavior": use
>> two overlays. The main overlay would cover the topmost entity and
>> override the cursor-sensor to govern visibility and cursor type. The
>> second overlay would be brought in (if face appearance changes are
>> requested) to modify the face for the /innermost/ entity at point. In
>> your example, you'd see `baz' underlined (only) when "inside" it,
>> otherwise, the entire link would be underlined.
>
> Sounds reasonable.
> Changing faces is probably the most appropriate indicator in such
> scenario. Also, revealing hidden markup symbols.
> Cursor shape is harder to make intuitive.
Agreed. I have updated `org-inside' to handle nested entities, by
targeting the :face (only) appearance change to the innermost relevant
entity. I use a secondary overlay, brought in as needed. This only
works on v31+, since that is where the `moved' sensor event has become
available. Adding this for <=v30 would require quite a workaround, so I
think this is a reasonable compromise. In earlier versions it works
like before: outermost only.
In terms of "revealing" the hidden components, I apply that only to the
outermost hidden-contents entity at point (and everything inside it).
Too much flashing otherwise I feel.
Along the way I also realized my window-parameter based state was less
reliable than expected, since many window-altering commands can lose
window parameters. This caused various subtle state corruption. I have
switched from window-backed to a buffer-local store of state
(e.g. overlays). This has the advantage that /only/ a buffer local
`window-buffer-change-functions' hook is needed: no global hooks (again
in v31+).
I have also removed the org-fold binding for the "unwanted side effects"
reason we discussed.
Jens, if you have the stomach for it, this new version could use some
testing w.r.t. window state management, etc. I believe the basic
sensor/enter/exit mechanism should be unchanged.
>> As far as the defaults, I've been using:
>>
>> '(org-inside-appearance '(:cursor bar :face (:underline "magenta") :unhide
>> nil))
>>
>> for a few weeks and generally like it. We'd need some appropriate org
>> color or face.
>
> One idea is inheriting from secondary-selection.
I've created a new face `org-inside-face' which by default inherits from
secondary-selection, and turned it on by default. This may be too heavy
of a default, since as you mouse through, the selection tends to turn on
and off for entities you visit only incidentally. Perhaps an underline
the color of `secondary-selections's background would be a good lighter
weight option?
Regarding having `org-inside-toggle-hidden' (now, C-c C-c) operative by
default, one idea would be to add it to the org keymap. If it is
invoked inside a hidden-contents entity while `org-inside-mode' is
disabled, turn on `org-inside-mode' in the buffer and print a message to
the user ("org-inside-mode enabled in foobar.org; M-x org-inside-mode to
disable").
