unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Keith David Bershatsky <esq@lawlist.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Debugging printing to stderr prior glyph row values ....
Date: Thu, 23 May 2019 15:01:09 -0700	[thread overview]
Message-ID: <m2v9y0u8yi.wl%esq@lawlist.com> (raw)

Thank you for mentioning the 4th case; i.e., when a row ends at ZV, but does have glyphs.  Testing for a differential between the start/end row bytepos, coupled with the row->ends_at_zv_p flag being true, appears to be sufficient for that particular case.

The multiple fake cursors feature places fake cursors at particular buffer positions from BEGV to ZV.  The crosshairs feature takes it one step further and draws fake cursors extending beyond ZV until the vertical ruler stops at the top of the mode-line.  As to the multiple fake cursors feature, there is a need to distinguish between a row containing _only_ ZV and subsequent rows so that fake cursors are not drawn there.

The test for row->ends_at_zv_p would be useful for a row containing _only_ ZV (last point in the buffer) if it were the only row with that flag enabled.  As far as I can tell, a row with _only_ ZV (last point in the buffer) is identical to rows that follow it because their ends_at_zv_p flag is true also.  I have not yet been able to figure out a way to programmatically distinguish between 2, 3 and 4 in the following example:

1.  Every good boy deserves fudge.¶
2.  ZV<==
3.  [one or more ' ' space glyphs]
4.  [one or more ' ' space glyphs]
5.  Mode-Line

When the crashing sporadically occurred yesterday, I tried during a couple of crash sessions to call "pgrowx row - 1" and "pgrowx (row - 1)" from gdb, but gdb appeared to produce the output for ROW instead of ROW - 1.  I have now added the following definition in the code so that I can call "pgrowx previous_row" from gdb.

  struct glyph_row *previous_row = row - 1;

I spent several minutes this afternoon trying to make Emacs crash doing things similar to yesterday, but have not yet had any luck getting Emacs to crash ... I will keep trying ...

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

> Date: [05-23-2019 11:38:25] <23 May 2019 21:38:25 +0300>
> From: Eli Zaretskii <eliz@gnu.org>
> To: Keith David Bershatsky <esq@lawlist.com>
> CC: emacs-devel@gnu.org
> Subject: Re: Debugging printing to stderr prior glyph row values ....
> 
> > Date:  Thu, 23 May 2019 10:23:03 -0700
> > From:  Keith David Bershatsky <esq@lawlist.com>
> > Cc:  emacs-devel@gnu.org
> >
> > I will add a test for the `used` row member to ensure that it is positive.  The crashing reported in the initial post only happens somtimes, so I'll need to do some further testing.
> 
> Did you look at the problematic row with the GDB command "pgrowx"?
> It's important to understand what kind of glyphs are in that row and
> how many of them do you have there.
> 
> > I am looking to programmatically distinguish between the following three types of consecutive rows:  (1) the penultimate row _not_ ending in ZV that immediately precedes a row with _only_ ZV; (2) the last row that contains _only_ ZV; and, (3) rows that follow a row with _only_ ZV.
> 
> There's a 4th case: when a row ends at ZV, but does have glyphs.  This
> happens, for example, when visiting a file that doesn't end in a
> newline.
> 
> > A better method of determining row_at_zv_p (without consulting ROW - 1) would be appreciated, if such a test exists.
> 
> I don't understand why you don't just look at the ends_at_zv_p flag,
> that's what it's for.



             reply	other threads:[~2019-05-23 22:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-23 22:01 Keith David Bershatsky [this message]
  -- strict thread matches above, loose matches on Subject: below --
2019-05-24 14:56 Debugging printing to stderr prior glyph row values Keith David Bershatsky
2019-05-24  0:03 Keith David Bershatsky
2019-05-24  6:45 ` Eli Zaretskii
2019-05-23 17:23 Keith David Bershatsky
2019-05-23 18:38 ` Eli Zaretskii
2019-05-23  4:14 Keith David Bershatsky
2019-05-23 14:43 ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m2v9y0u8yi.wl%esq@lawlist.com \
    --to=esq@lawlist.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).