Jens Schmidt <[email protected]> writes:
> "J.D. Smith" <[email protected]> writes:
>
> Thanks for the next changes. I think I still have a number of things
> I'd like to check and/or discuss, but that could take some time, so I
> decided to do things in smaller portions. In particular since there is
> one completely new issue that I'm not sure how difficult it is to handle
> - see below.
>
>
> * C-c C-c Hook Afterthoughts
>
>>> That is my problem as well - I know that having o-i-t-h feels good on
>>> C-c C-c, but I'm not sure how it feels in the org-reveal context.
>>
>> Yes! It feels super natural on C-c C-c. I think I'll put it there and
>> see how people like it; done now.
>
> Thanks. On second thought I remembered that in, say, 2-3% of my C-C C-c
> usage with my mode (which has the visibility toggle on C-c C-c as well)
> I get annoyed like "hey, I wanted to toggle the checkbox of the list
> item here, not visibility". For others the ratio may be different, and
> Emacs users tend to be conservative w.r.t. their muscle memory.
Interesting. Does that happen for other contexts?
> Maybe you should provide at least a custom variable to easily turn the
> hook addition off? Most likely users can disable the hook addition
> using the minor mode hook, but that might be too incovenient for the
> average Org mode user. But then again I just might be too pessimistic,
> and waiting for other users' input is probably really TRT here.
It's of course easy to leave it out and suggest adding to the hook;
let's see what others prefer.
>
> * Another Sticky Bar Cursor
>
>>> Thanks for working on these, too, but here I'm also interested to see
>>> what exactly you have implemented, so I'll postpone my comments.
>>
>> Take a look, thanks for all the careful attention.
>
> Not at all. I'm just an evil reviewer that looks at your code with the
> intention to find its weak spots and then rub it in. Here is one that I
> came up after reading about window parameters:
>
> Start with the usual incantation ("make repro", o-h-e-m (I've set the
> default to true already in Org's sources!), open test file, o-i-m, move
> into emphasis and ensure cursor is bar). Then:
>
> + C-x t 2
> + C-x t o
> + M-x org-inside-mode RET
> + C-x t o
> -> Cursor stays bar.
I can't reproduce this. The cursor is removed for either; maybe it's a
recent change. I don't use inbuilt tabs but the native ones in my
build, which are just frames.
> * More Nitpicks
>
> More nitpicks, and no need for you to comment on these: If you think
> they're OK for you, implement them, otherwise leave as they are. If you
> think that I haven't understood something right, you might be right.
>
>
> (cl-destructuring-bind ( &key cursor face unhide
> &aux (inside-p (and beg end)))
> org-inside-appearance
>
> That INSIDE-P feels strange there, couldn't it be moved it into the
> following `let*'?
Fair enough, though it bumps the inner let over one more. Done.
>
> (org-element-lineage ctx '(link bold code italic verbatim
> underline strike-through) t)))
>
> I think the agreed upon indentation for data would be like this
> (bug#21922):
>
> (org-element-lineage ctx '( link bold code italic verbatim
> underline strike-through) t)))
>
Indeed, done.
> (defsubst org-inside--restore-cursor (win)
>
> Probably also care about `pending-cursor-type' here?
I suppose that's worth doing. This is an invention in this package,
btw. I needed it because another package of mine, the smooth pixel
scrolling package `ultra-scroll' also saves/restores cursor (hiding it
during scroll), and if cursor hiding commences from "inside", but then
falls "outside", it would restore the wrong cursor. But it may catch on
so worth including.
Seems like we're converging here; would be useful to get a few more
people testing.
