unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Ihor Radchenko <yantar92@posteo.net>
Cc: 62048@debbugs.gnu.org
Subject: bug#62048: 30.0.50; Non-nil `line-spacing' takes precendence over 'line-height t text property
Date: Sat, 11 Mar 2023 14:28:51 +0200	[thread overview]
Message-ID: <83pm9fwjy4.fsf@gnu.org> (raw)
In-Reply-To: <87r0tvwnl9.fsf@localhost> (message from Ihor Radchenko on Sat, 11 Mar 2023 11:10:10 +0000)

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: 62048@debbugs.gnu.org
> Date: Sat, 11 Mar 2023 11:10:10 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Observed: top of the image is displayed
> >> Expected: bottom of the image is partially revealed
> >
> > I don't understand the expectation.  Scrolling by vscroll only happens
> > when before the scroll some part of the image is visible, which is not
> > what happens here.
> >
> > If you want to change that, feel free to hack on the code in
> > simple.el, but there was no intent to cover this particular use case,
> > and the code is already quite complicated (to say the least).
> > ...
> > You should always keep in mind that Emacs has no idea about what's
> > beyond the window, for display purposes.  There's no way of saying
> > whether a given 'display property whose value is an image spec will be
> > taller than the window, except by actually displaying that image (or
> > at least simulating the display internally).  So you expect something
> > that it is far from easy to do.
> >
> > Scrolling commands were never meant to allow smooth scrolling through
> > tall screen lines.
> 
> What if the code instead tries to vscroll standard line height first and
> only then decide if we want to scroll further, displaying tall line?

You mean, use vscroll even for lines whose height is the same as the
default font?  That'd be a waste, no?

And how do you propose to "decide if we want to scroll further"?

> > What do you want to customize, and in what terms?
> 
> I was referring to
> 
> >> 	      (if (and (< arg 0)
> >> 		       (< (point) (window-start))
> >> 		       (> lh winh))
> >> 		  (set-window-vscroll
> >> 		   nil
> >> 		   (- lh dlh) t)))
> 
> May we allow users to customize ~(> lh winh)~ condition?

I don't mind, but make sure some other place in this set of twisty
little passages don't assume we test against the window's height.

> Also, on the initial report. Is it possible to increase default
> buffer-wise line-spacing via text property? (AFAIU, decreasing is
> impossible).

The mechanism for overriding doesn't depend on the value, it depends
on the hierarchy of settings, as the ELisp manual describes.  When the
manual says "However, no matter what you specify, the actual line
height can never be less than the default", it means the default
height described in the previous paragraph:

     The height of the line contents is the maximum height of any
  character or image on that display line, including the final newline if
  there is one.  (A display line that is continued doesn’t include a final
  newline.)  That is the default line height, if you do nothing to specify
  a greater height.  (In the most common case, this equals the height of
  the corresponding frame’s default font, see *note Frame Font::.)





      reply	other threads:[~2023-03-11 12:28 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-08 12:18 bug#62048: 30.0.50; Non-nil `line-spacing' takes precendence over 'line-height t text property Ihor Radchenko
2023-03-08 17:31 ` Eli Zaretskii
2023-03-08 18:26   ` Ihor Radchenko
2023-03-08 19:50     ` Eli Zaretskii
2023-03-08 20:39       ` Ihor Radchenko
2023-03-09  6:54         ` Eli Zaretskii
2023-03-09  9:13           ` Ihor Radchenko
2023-03-09  9:47             ` Eli Zaretskii
2023-03-09 10:55               ` Ihor Radchenko
2023-03-09 12:16                 ` Eli Zaretskii
2023-03-11 11:10                   ` Ihor Radchenko
2023-03-11 12:28                     ` Eli Zaretskii [this message]

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=83pm9fwjy4.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=62048@debbugs.gnu.org \
    --cc=yantar92@posteo.net \
    /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).