[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#17511: 24.4.50; `line-move-ignore-invisible': doc and purpose not cl
bug#17511: 24.4.50; `line-move-ignore-invisible': doc and purpose not clear
Sat, 17 May 2014 18:02:30 +0300
> Date: Sat, 17 May 2014 07:45:44 -0700 (PDT)
> From: Drew Adams <address@hidden>
> Cc: address@hidden
> Thanks for improving this.
Can this bug be closed, then?
> > > 1. The doc string says only that `next-line' and `previous-line' ignore
> > > invisible lines. What does it mean for these commands to "ignore
> > > invisible lines" - what does "ignore" mean here? What's the
> > > user-visible BEHAVIOR difference between a nil and a non-nil value?
> > > Why/when might a user change the value to nil?
> > I changed the doc string to this:
> > "Non-nil means commands that move by lines ignore invisible newlines.
> > When this option is non-nil, \\[next-line], \\[previous-line], \\[move-end-
> > of-line], and \\[move-beginning-of-line] behave
> > as if newlines that are invisible didn't exist, and count
> > only visible newlines. Thus, moving across across 2 newlines
> > one of which is invisible will be counted as a one-line move.
> > Also, a non-nil value causes invisible text to be ignored when
> > counting columns for the purposes of keeping point in the same
> > column by \\[next-line] and \\[previous-line].
> > Outline mode sets this."
> > I hope this answers all of your questions in #1.
> Very good; thanks.
> (I don't think there should be a blank line after the first line,
> but maybe that is just a mail artifact.)
It's not; it's a standard formatting of a doc string, AFAIK.
> > > 2. The doc string speaks of invisible lines. But (elisp) `Invisible
> > > Text' speaks of "invisible newlines" (not lines), which is presumably
> > > something different (newline chars vs lines of any chars except newline,
> > > possibly including the separating newlines). Are both true? Which?
> > I think the doc string now clarifies this as well.
> Yes, thanks. But the manual speaks only of invisible newlines, and to
> me this part is not clear.
The doc string now speaks about that as well. What's not clear about
that? A newline is just a character, and as such can be invisible.
> And whenever we speak of newlines (especially
> where we are also talking about doing something wrt lines in general),
> we should say "newline characters" or "newline chars". A "newline" as
> such doesn't really exist in our vocabulary (or at least it shouldn't),
> and some people might read it as meaning a "new line".
I'd never suspect this could be a source of confusion in Emacs. The
Control-J characters in the buffer terminate lines of text and are
therefore also called newlines.
> > > 5. After saying that we provide option `line-move-ignore-invisible'
> > > specifically to let you prevent line motion commands from ignoring
> > > invisible newlines (whatever that might mean!), this node says that if
> > > ANY command ends with point in a certain position relative to invisible
> > > text, then the cursor is automatically moved past that stretch of
> > > invisible text (one direction or the other). How is this related to the
> > > previous text about line motion commands and
> > > `line-move-ignore-invisible'?
> > It isn't related to line-move-ignore-invisible. It is related to the
> > broader issue described by that node, which is invisible text in
> > general.
> Yes, I sensed that. I found (find) the juxtaposition confusing.
> Maybe separate the two discussions better, and perhaps give an example
> of interaction (or lack thereof) between the two.
It's a separate paragraph already, and I removed the leading
"However", which might hint on some too tight relation.