Re: invisible

[martin rudalics]

>>I don't know.  `line-move-ignore-invisible' is a user option (although I
>>fail to see how it's useful).  `(global-)disable-point-adjustment' is not.
>
>
> global-disable-point-adjustment *is* a user option.

OK.  But according to the Elisp manual it's a "plain" variable and it's
not customizable.  Also `line-move-ignore-invisible' is an option that
applies to C-n/C-p exclusively.  `global-disable-point-adjustment', on
the other hand, applies to all commands.

>>IIUC a user might want to set `line-move-ignore-invisible' to nil
>>in order to have C-n/C-p stop at or near invisible newlines.  In order
>>to make this possible I set `disable-point-adjustment' to t.  I do this
>>because for this particular goal the adjustment step is too clever.  But
>>I don't see how replacing the one by the negation of the other would
>>solve the problem.
>
>
> I must be missing something: the relationship is pretty obvious to me
> since your code sets disable-point-adjustment to t (i.e. forces Emacs to
> behave as if global-disable-point-adjustment were t for this one
> command) if and only if line-move-ignore-invisible is nil.

Because I'm not allowed to disable point-adjustment for the normal
`line-move-ignore-invisible' t case.  What shall I do if someone wants
to disable point-adjustment for the `line-move-ignore-invisible' t case
too?  We have

line-move-ignore-invisible => disable-point-adjustment

but not

disable-point-adjustment => line-move-ignore-invisible

or what am I missing?

>>Because I wanted to emphasize that this is for interactive use only
>>and `interactive-p' is tested in next-/previous-line.  If for whatever
>>reason people want to use next-/previous-line in a function, they
>>should be allowed to disable point-adjustment as they like.  But I do
>>not have a strong opinion about this, let's see whether my patch DTRT
>>at all.  As Richard mentioned earlier adjusting one thing here breaks
>>another ...
>
>
> Since those functions are discouraged in Elisp code anyway I don't think
> it matters much.

Neither do I.  But why do these have an `interactive-p' check in the
first place?  BTW, there are a few instances where packages do rely on
next-/previous-line (I've just checked in a corresponding fix for
blackbox.el).