[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: invisible
From: |
martin rudalics |
Subject: |
Re: invisible |
Date: |
Sat, 01 Dec 2007 10:44:13 +0100 |
User-agent: |
Mozilla Thunderbird 1.0 (Windows/20041206) |
>>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).
- Re: invisible,
martin rudalics <=