all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dgutov@yandex.ru>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: bug#9782: 24.0.90; move-to-window-line not taking header line into account
Date: Tue, 07 May 2013 11:41:00 +0400	[thread overview]
Message-ID: <5188B00C.2080600@yandex.ru> (raw)
In-Reply-To: <83txmfebzp.fsf@gnu.org>

On 07.05.2013 6:54, Eli Zaretskii wrote:
>> One might think that `move-to-window-line' is also window-relative and
>> thus agnostic to the header line (that naturally follows if we consider
>> the header line a part of the window).
>
> "Line" is a line of text, and move-to-window-line was written to go to
> a line of text.

The question is how they're numbered. One might imagine that the 
"zeroth" line is covered by the header, so the first one visible is 
number one.

Note I'm not really arguing in favor in that change, since it won't help 
me get rid of the version check for 24.1-24.3 anyway.

>> We still need to compare the column values to see if the click happened
>> exactly inside the rectangle, not to the right or left of it.
>
> Doesn't the overlay cover the entire rectangle?
>
>> And in `company-select-mouse', we need the row values to find out which
>> rectangle line was clicked (which candidate to select)
>
> Isn't each rectangle a different string?
>

There's just one overlay, and it covers all of them (plus all text on 
the sides). Maybe what you're suggesting would be an improvement (I see 
dropdown-list.el also does that), but the current approach works fast 
enough, and it would have the advantage in a hypothetical situation when 
some of the text we need to "draw on" is already rendered via `display' 
property.

>> Taking the above into account, I think having a header-line-aware
>> version of `move-to-window-line' instead would be best.
>
> ??? But you don't want to _move_ anywhere, AFAIU.  You want to compute
> a window-relative screen line number of a given position (I used point
> in the above example, but that can be replaced by any buffer
> position).  So how does move-to-window-line fit that bill?  Its
> return value is undocumented, so you cannot really rely on that.

I mean fixing the row number <-> line number discrepancy from the other 
side, by making a wrapper for `move-to-window-line', the only function 
of the bunch that deals with line numbers. It's used in 
`company-pseudo-tooltip-show'.

>> Like suggested before, it would adjust the argument by 1 if
>> emacs-version >= "24", and the header line is present.
>
> The function move-to-window-line is implemented in C, so it is
> pointless to make it sensitive to Emacs version.

The wrapper will need to check the version because Emacs 23 and earlier 
don't need the adjustment.



  reply	other threads:[~2013-05-07  7:41 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-18 12:03 bug#9782: 24.0.90; move-to-window-line not taking header line into account David Engster
2011-10-18 14:00 ` Eli Zaretskii
2011-10-18 14:23   ` David Engster
2011-10-18 16:00     ` Eli Zaretskii
2013-05-04 21:12       ` Dmitry Gutov
2013-05-05  2:47         ` Eli Zaretskii
2013-05-05  2:59           ` Dmitry Gutov
2013-05-05 15:53             ` Eli Zaretskii
2013-05-06  3:38               ` Dmitry Gutov
2013-05-06 16:38                 ` Eli Zaretskii
2013-05-07  1:26                   ` Dmitry Gutov
2013-05-07  2:54                     ` Eli Zaretskii
2013-05-07  7:41                       ` Dmitry Gutov [this message]
2013-05-07 16:50                         ` Eli Zaretskii
2013-05-07 17:19                           ` Dmitry Gutov
2014-08-15 23:33                             ` Dmitry Gutov
2014-08-16  8:03                               ` Eli Zaretskii
2014-08-16  8:27                                 ` Dmitry Gutov
2014-08-16 11:12                                   ` Eli Zaretskii
2014-08-19  4:51                                     ` Dmitry Gutov

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

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

  git send-email \
    --in-reply-to=5188B00C.2080600@yandex.ru \
    --to=dgutov@yandex.ru \
    --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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.