From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: xdisp.c's struct it questions. Date: Sat, 3 Oct 2015 16:38:00 +0000 Message-ID: <20151003163800.GB4509@acm.fritz.box> References: <20151003154835.GA4509@acm.fritz.box> <83r3lc2au2.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1443890229 19178 80.91.229.3 (3 Oct 2015 16:37:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 3 Oct 2015 16:37:09 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 03 18:36:53 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZiPno-0002Fz-4s for ged-emacs-devel@m.gmane.org; Sat, 03 Oct 2015 18:36:52 +0200 Original-Received: from localhost ([::1]:39268 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZiPnn-0008GF-8Q for ged-emacs-devel@m.gmane.org; Sat, 03 Oct 2015 12:36:51 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49260) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZiPnZ-0008G5-LB for emacs-devel@gnu.org; Sat, 03 Oct 2015 12:36:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZiPnW-0005Z0-FP for emacs-devel@gnu.org; Sat, 03 Oct 2015 12:36:37 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:14354) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZiPnW-0005YZ-5j for emacs-devel@gnu.org; Sat, 03 Oct 2015 12:36:34 -0400 Original-Received: (qmail 13460 invoked by uid 3782); 3 Oct 2015 16:36:32 -0000 Original-Received: from acm.muc.de (p5B147E4E.dip0.t-ipconnect.de [91.20.126.78]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 03 Oct 2015 18:36:31 +0200 Original-Received: (qmail 6038 invoked by uid 1000); 3 Oct 2015 16:38:00 -0000 Content-Disposition: inline In-Reply-To: <83r3lc2au2.fsf@gnu.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x X-Received-From: 193.149.48.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:190796 Archived-At: Hello, Eli, Thanks for such a rapid and useful answer. On Sat, Oct 03, 2015 at 07:09:09PM +0300, Eli Zaretskii wrote: > > Date: Sat, 3 Oct 2015 15:48:36 +0000 > > From: Alan Mackenzie > > I'm trying to get some stuff in xdisp.c working. It's hard. > My sympathies. Please consider recording in the comments everything > you learn that isn't already there. Let's take something positive and > useful from your ordeal ;-) I'll see what I can manage. > > I'm currently looking at routines like `move_it_to', which is described > > as "Move IT forward until it satisfies one or more of the criteria in > > TO_CHARPOS, TO_X, TO_Y, and TO_VPOS." > > What I can't find anywhere is a description of what it means for a > > "struct it" to _be_ somewhere. There are around 100 fields in struct > > it, and several of them record locations, coordinates, etc., in one way > > and another. Which of these fields are changed when move_it_to is > > called? > It depends on the criteria. For TO_CHARPOS, the goal value is in > it->pos.charpos; for TO_X, it's in it->current_x; for TO_Y, it's in > it->current_y; and for TO_VPOS, it's in it->vpos. OK. > Also note that the criteria is actually tested to "reach or exceed" > the goal values, i.e. do not expect to always get an exact equality, > only "greater or equal". Ah. Hmm. OK. That's rather important! In fact, that's exactly what seems to be happening to me. So these routines are only for use in contexts where it only matters that a particular range/position is _covered_, rather than reached exactly. Would `reseat' (or one of its variants) be the right function to put a struct it _exactly_ at a particular position? -- Alan Mackenzie (Nuremberg, Germany).