emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: invisible


From: Stefan Monnier
Subject: Re: invisible
Date: Mon, 26 Nov 2007 10:29:36 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (gnu/linux)

>> If you have a conrete situation where the current behavior is
>> problematic, firsyt you need to understand how those things work:
>> there are 2 places where invisibility impacts movement:
>> - when combined with `intangible', it impacts every single movement of
>> `point', including within elisp functions.  This may "do the right
>> thing" in some sense, but it tends to break a lot of code, and
>> it can be terribly difficult to write code that works in the face of
>> intangible properties.  So I highly recommend against the use of
>> `intangible' except for those rare cases where it's *really*
>> absolutely needed.

> Intangible text was never mentioned in this thread.

Great.  (I had no idea because the thread was just too big for
me to follow it)

> This thread is about `line-move-ignore-invisible' - an option defined in
> simple.el with the following doc-string:

>         *Non-nil means C-n and C-p ignore invisible lines.
>         Outline mode sets this.

> Either this option makes sense - then we have to talk about C-n/C-p
> _and_ invisible text - or it doesn't.  In the latter case let's remove
> the option and the problem is resolved.

It makes sense and we need to keep it.  But it interacts with point
adjustment.  So try and reproduce the bug first with
disable-point-adjustment so as to eliminate a variable.

[ We could also dispense with the variable and use
disable-point-adjustment for it, but then one wouldn't be able to
disable one without disabling the other which is sometimes inconvenient
while debugging.  ]

> I never use "those things" hence I don't care about whether these
> qualify as "serious symptoms".

You use point-adjustment all the time since it's enabled by default.

> I just reacted to a couple of problems
> reported by others.  One of these was

I wasn't ranting against you.  Sorry.  It was against this thread with
its umpteen recipes.

>        "the cursor stays put, i.e., C-p is a no-op here"

Great: a clear bug.  Thanks for helping.

> *** simple.el.~1.888.~        Sat Nov 10 09:23:20 2007
> --- simple.el Sun Nov 18 16:02:42 2007
> ***************
> *** 3862,3868 ****
>            (save-excursion
>              ;; Like end-of-line but ignores fields.
>              (skip-chars-forward "^\n")
> !            (while (and (not (eobp)) (invisible-p (point)))
>                (goto-char (next-char-property-change (point)))
>                (skip-chars-forward "^\n"))
>              (point))))
> --- 3862,3869 ----
>            (save-excursion
>              ;; Like end-of-line but ignores fields.
>              (skip-chars-forward "^\n")
> !            (while (and line-move-ignore-invisible
> !                        (not (eobp)) (invisible-p (point)))
>                (goto-char (next-char-property-change (point)))
>                (skip-chars-forward "^\n"))
>              (point))))

Looks good.

> ***************
> *** 3940,3948 ****
>   This function works only in certain cases,
>   because what we really need is for `move-to-column'
>   and `current-column' to be able to ignore invisible text."

This text seems odd: AFAIK they *do* ignore invisible text.  Does it
want to say that they sould ignore the `invisible' text property?

>   This function works only in certain cases,
>   because what we really need is for `move-to-column'
>   and `current-column' to be able to ignore invisible text."
> !   (cond
> !    ((zerop col)
> !     (beginning-of-line))
> !    (line-move-ignore-invisible
>       (move-to-column col))
> +    (t
> +     ;; Tedious.
> +     (save-restriction
> +       (narrow-to-region (line-beginning-position) (line-end-position))
> +       (move-to-column col))))
>   
>     (when (and line-move-ignore-invisible
>            (not (bolp)) (invisible-p (1- (point))))

The docstring of line-move-to-column is too vague: it doesn't say what
it intends to do, really: "considering invisibility" is not much help.
If someone knows what it intends to do, really, maybe we can figure out
how to fix it (probably the best fix will be to change the C code).


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]