Re: feature/icomplete-vertical

["João Távora" <joaotavora@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> >> That's odd, I've been C-x C-f'ing to directories with "a lot" of files
>> >> and I don't notice any problems.  What size of "lot" did you have in
>> >> mind?
>> >
>> > More than can be displayed, one candidate on each line, by the frame's
>> > dimensions, I guess.
>> 
>> I've certainly got more than that, and the problem doesn't happen.
>
> Then either you truncate the candidate's (i.e., don't show all of it),
> or your code isn't working properly.

Well, it's not my code, it's Gregory's.  I just evaluated it and it
seems to be working decently for the day or so.  But I'm fine to admit
there may be corner cases where it would fail, I just haven't detected
those failures.

>> > The code which displays the min-window is more-or-less the generic
>> > Emacs window-display code, it doesn't care that not all of the stuff
>> > fits in the window.
>> That's the code that honours max-mini-window-height, right?
> Yes.  Followed by the normal window redisplay.
>> Though that doesn't seem to be what's kicking in here, I believe it
>> should be.
> Not sure I can parse this properly.  What exactly isn't "kicking in"?

Don't worry. I meant I have that variable set to 3, but I'm seeing a
6-line-high minibuffer prompt, so something in Gregory's code seems to
be overriding it.  By "should be" I'm stating that that overriding
shouldn't happen, i.e. I'm searching for a better solution.

>> Anyway, I think it's reasonable to suggest I think, that whoever is
>> truncating the display has someway of notifying the client (whoever
>> requested the display), that truncation happened, or is about to happen.
>
> I think whoever truncates the display is the same as the client.
> Unless I misunderstand what you mean by "truncate".

Truncation is being given something to display, such as here:

  (let ((minibuffer-setup-hook (lambda ()
                                 (insert (format "one\ntwo\nthree\nfour")))))
    (read-minibuffer "hey"))

and _not_ actually displaying it becasue of some window size constraint.

> There are ways.  They aren't necessarily easy, but if your application
> does care about not everything being visible in a window, the
> application must do something about it, because the "normal" Emacs
> display doesn't treat partial display of a buffer as something
> special, since that is what happens all the time in Emacs.

Right.  But is there a very large cost in implementing a mechanism of
notification that applications can optionally subscribe to take action
when this common thing happens to them?

> Not sure what should be canonical here.  AFAIU, just using
> window-text-pixel-size and comparing with the window dimensions is all
> that's needed.

Thanks, but I don't understand how that could help here.  The docstring
says:

   This function exists to allow Lisp programs to adjust the dimensions
   of WINDOW to the buffer text it needs to display.

But we need a subtly different use which would be:

   This function exists to allow Lisp programs to adjust the buffer text
   so that it fits visually in WINDOW.

I don't know how to use the function to do this.  In other words, I have
some buffer text and I would like to know:

1) If it fits in WINDOW;
2) If it doesn't, where is the cutoff, as a text position.

I'm re-reading the docstring to see it this is possible, but I don't
think the function is tailored for this use case.  Anyway, if that
function existed it would be what I called the canonical solution for
this case.

João