[NonGNU ELPA] New packages: corfu-doc and corfu-doc-terminal

[NonGNU ELPA] New packages: corfu-doc and corfu-doc-terminal

[Akib Azmain Turja]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1: Patch --]
[-- Type: text/x-patch, Size: 822 bytes --]

From 5d2ae7bd9b6d00f39704828fbe27c28b699b3e4f Mon Sep 17 00:00:00 2001
From: Akib Azmain Turja <akib@disroot.org>
Date: Sat, 28 May 2022 18:59:36 +0600
Subject: [PATCH] * elpa-packages (corfu-doc, corfu-doc-terminal): New packages

---
 elpa-packages | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/elpa-packages b/elpa-packages
index aa62452..1465bc1 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -79,6 +79,10 @@
 
  ("coffee-mode"		:url "https://github.com/defunkt/coffee-mode")
 
+ ("corfu-doc"           :url "https://github.com/galeo/corfu-doc")
+
+ ("corfu-doc-terminal"  :url "https://codeberg.org/akib/emacs-corfu-doc-terminal")
+
  ("corfu-terminal"      :url "https://codeberg.org/akib/emacs-corfu-terminal")
 
  ("crux"		:url "https://github.com/bbatsov/crux"
-- 
2.34.0


[-- Attachment #1.2: Type: text/plain, Size: 912 bytes --]


I would like to submit these two packages to NonGNU ELPA: corfu-doc and
corfu-doc-terminal.

corfu-doc shows a documentation popup for the selected candidate in
Corfu.  It uses child frame to do this.  The author said that he signed
and sent the papers but hasn't received any reply, so this package can't
be add to ELPA right now.  In the meantime, I would like submit this
here.

corfu-doc-terminal advises corfu-doc to use Popon, so that corfu-doc
works also on non-graphical (terminal) displays.  As corfu-doc isn't a
part of Emacs, I can't publish it to ELPA (as it depends on corfu-doc
and uses some code adapted from corfu-doc).  Maybe I can do that in the
future when corfu-doc becomes a part of Emacs, if law allows me to do
so.

-- 
Akib Azmain Turja

This message is signed by me with my GnuPG key.  It's fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [NonGNU ELPA] New packages: corfu-doc and corfu-doc-terminal

[Philip Kaludercic]

Akib Azmain Turja <akib@disroot.org> writes:

> I would like to submit these two packages to NonGNU ELPA: corfu-doc
> and corfu-doc-terminal.
>
> corfu-doc shows a documentation popup for the selected candidate in
> Corfu.  It uses child frame to do this.  The author said that he
> signed and sent the papers but hasn't received any reply, so this
> package can't be add to ELPA right now.  In the meantime, I would like
> submit this here.

Maybe this should be investigated, this kind of behaviour is not
supposed to happen.

> corfu-doc-terminal advises corfu-doc to use Popon, so that corfu-doc
> works also on non-graphical (terminal) displays.  As corfu-doc isn't a
> part of Emacs, I can't publish it to ELPA (as it depends on corfu-doc
> and uses some code adapted from corfu-doc).  Maybe I can do that in
> the future when corfu-doc becomes a part of Emacs, if law allows me to
> do so.

To my knowledge, there is inherently no issue in having an GNU ELPA
package depend on a package in NonGNU ELPA, unless the user has NonGNU
ELPA disabled or uses an older version of Emacs.

But if you have copied code from corfu-doc, then that would be an issue
(depending on how much code/how significant of a contribution we are
talking about).

Re: [NonGNU ELPA] New packages: corfu-doc and corfu-doc-terminal

[Stefan Monnier]

Akib Azmain Turja [2022-05-28 19:15:33] wrote:
> corfu-doc shows a documentation popup for the selected candidate in
> Corfu.  It uses child frame to do this.  The author said that he signed
> and sent the papers but hasn't received any reply,

Looks like there's been some communication mishap, but I see Yuwei Tian
in the FSF's `copyright.list` file, so his copyright paperwork seems to
be in order.

> so this package can't be added to ELPA right now.

I think it can :-)

> corfu-doc-terminal advises corfu-doc to use Popon, so that corfu-doc
> works also on non-graphical (terminal) displays.  As corfu-doc isn't a
> part of Emacs, I can't publish it to ELPA (as it depends on corfu-doc
> and uses some code adapted from corfu-doc).

As Philip said, it's OK for a GNU ELPA package to depend on a NonGNU
ELPA package (it's not our first choice, admittedly, but it's only an
annoyance rather than an obstacle).  BTW, it would be good to develop
some kind of API such that corfu, corfu-doc and others can call a "show
this thing" function and the result is shown either with child-frames or
with `popon` (or with any other replacement such as `popup`, tooltips,
a using a plain old window, ...), without having to rely on advice?

Any chance you could look into that, maybe getting feedback from the
authors of corfu, company, popup, and other related packages?


        Stefan

Re: [NonGNU ELPA] New packages: corfu-doc and corfu-doc-terminal

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 3062 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Akib Azmain Turja [2022-05-28 19:15:33] wrote:
>> corfu-doc shows a documentation popup for the selected candidate in
>> Corfu.  It uses child frame to do this.  The author said that he signed
>> and sent the papers but hasn't received any reply,
>
> Looks like there's been some communication mishap, but I see Yuwei Tian
> in the FSF's `copyright.list` file, so his copyright paperwork seems to
> be in order.
>
>> so this package can't be added to ELPA right now.
>
> I think it can :-)
>
>> corfu-doc-terminal advises corfu-doc to use Popon, so that corfu-doc
>> works also on non-graphical (terminal) displays.  As corfu-doc isn't a
>> part of Emacs, I can't publish it to ELPA (as it depends on corfu-doc
>> and uses some code adapted from corfu-doc).
>
> As Philip said, it's OK for a GNU ELPA package to depend on a NonGNU
> ELPA package (it's not our first choice, admittedly, but it's only an
> annoyance rather than an obstacle).  BTW, it would be good to develop
> some kind of API such that corfu, corfu-doc and others can call a "show
> this thing" function and the result is shown either with child-frames or
> with `popon` (or with any other replacement such as `popup`, tooltips,
> a using a plain old window, ...), without having to rely on advice?
>
> Any chance you could look into that, maybe getting feedback from the
> authors of corfu, company, popup, and other related packages?
>
>
>         Stefan
>

That's a great idea, but has a problem, Popon or popup.el don't work
like windows and frames.  popup.el seems to be useful mainly for menus,
though I maybe wrong.  Popon is more generalized and minimal, so it
requires manual handling of the text.

In windows and frames (which actually contains windows), Emacs does all
the heavy lifting (scrolling, line truncation, line wrapping, word
wrapping, just to name a few) using its C code.  Doing this in Emacs
Lisp isn't very efficient (especially when you don't have Emacs with
native compilation support, such as I).

And even if someone does this, many packages won't use it, either
because the author don't get the convenience of child frames in that
API, or the author wants to add his/her package to the base Emacs
distribution, so he/she doesn't want to add any dependencies.  (For
example, I asked Corfu's author if it is possible to add corfu-terminal
to Corfu as an extension, but he said no just because of the extra Popon
dependency, which I intentionally extracted out of corfu-terminal to let
others use it)

I think the best solution will be to implement child frames in terminal.
AFAIK, ncurses has a concept of floating window, which we can use to
render the frame.  Doing this will solve all floating popup related
problems.  Then all packages will use this standard (child) frame API to
show popup.

-- 
Akib Azmain Turja

This message is signed by me with my GnuPG key.  It's fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [NonGNU ELPA] New packages: corfu-doc and corfu-doc-terminal

[Stefan Monnier]

> That's a great idea, but has a problem, Popon or popup.el don't work
> like windows and frames.  popup.el seems to be useful mainly for menus,
> though I maybe wrong.  Popon is more generalized and minimal, so it
> requires manual handling of the text.

That's the point of the design of the API: to provide an interface that
is sufficiently restricted that it can work with various implementation
choices (while still being useful enough).

> example, I asked Corfu's author if it is possible to add corfu-terminal
> to Corfu as an extension, but he said no just because of the extra Popon
> dependency, which I intentionally extracted out of corfu-terminal to let
> others use it)

But once the API is available corfu can make use of it without adding
a dependency on `popon`.

> I think the best solution will be to implement child frames in terminal.
> AFAIK, ncurses has a concept of floating window, which we can use to
> render the frame.  Doing this will solve all floating popup related
> problems.  Then all packages will use this standard (child) frame API to
> show popup.

We already have code which does this kind of thing, to draw menus in
tty frames.  IIUC the implementation currently relies on the fact that
no ELisp is run while those overlaid menus are drawn, so it may require
a fair bit of surgery, but indeed implementing something like
popup/popon at a lower level is probably the better choice in the
long run.  Nobody has taken on this challenge yet, tho.

In any case, this API that I think we should design should hopefully
make it possible to use such a C-level implementation if/when it's
available.


        Stefan

Re: [NonGNU ELPA] New packages: corfu-doc and corfu-doc-terminal

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 1795 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> example, I asked Corfu's author if it is possible to add corfu-terminal
>> to Corfu as an extension, but he said no just because of the extra Popon
>> dependency, which I intentionally extracted out of corfu-terminal to let
>> others use it)
>
> But once the API is available corfu can make use of it without adding
> a dependency on `popon`.

But that would need Corfu to add a dependency that API, unless that API
is a part of Emacs distribution.

>
>> I think the best solution will be to implement child frames in terminal.
>> AFAIK, ncurses has a concept of floating window, which we can use to
>> render the frame.  Doing this will solve all floating popup related
>> problems.  Then all packages will use this standard (child) frame API to
>> show popup.
>
> We already have code which does this kind of thing, to draw menus in
> tty frames.  IIUC the implementation currently relies on the fact that
> no ELisp is run while those overlaid menus are drawn, so it may require
> a fair bit of surgery, but indeed implementing something like
> popup/popon at a lower level is probably the better choice in the
> long run.  Nobody has taken on this challenge yet, tho.

Yeah, it is probably better to spend the effort here unless we drop
text display support.  But most people are afraid of C (including me; if
I try to do this, I would spent more than 95% of time to actually figure
out what's the code doing).  And my internet speed is slow, so cloning
the entire repository is probably not possible for me right now.  Will a
shallow clone help?

-- 
Akib Azmain Turja

This message is signed by me with my GnuPG key.  It's fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [NonGNU ELPA] New packages: corfu-doc and corfu-doc-terminal

[Stefan Monnier]

Akib Azmain Turja [2022-05-29 02:27:34] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> example, I asked Corfu's author if it is possible to add corfu-terminal
>>> to Corfu as an extension, but he said no just because of the extra Popon
>>> dependency, which I intentionally extracted out of corfu-terminal to let
>>> others use it)
>>
>> But once the API is available corfu can make use of it without adding
>> a dependency on `popon`.
>
> But that would need Corfu to add a dependency that API,

Most likely it could use this API without depending on it (i.e. use it
if available and fallback on the existing code if not).

> unless that API is a part of Emacs distribution.

That'd be the plan, yes.

> Yeah, it is probably better to spend the effort here

No: even if/when we'll get C-level support for such things in ttys,
there will *still* be a need for an API that lets packages like corfu
stop worrying about whether the output goes to a tty or a GUI.


        Stefan

Re: [NonGNU ELPA] New packages: corfu-doc and corfu-doc-terminal

[Eli Zaretskii]

> From: Akib Azmain Turja <akib@disroot.org>
> Cc: emacs-devel@gnu.org, Yuwei Tian <ibluefocus@outlook.com>
> Date: Sat, 28 May 2022 22:30:46 +0600
> 
> I think the best solution will be to implement child frames in terminal.
> AFAIK, ncurses has a concept of floating window, which we can use to
> render the frame.

The difficulty in implementing child frames on TTY are not because
Emacs cannot draw on TTY at arbitrary coordinates, it's because there
are fundamental design principles on which TTY display is based.  I'd
actually recommend to implement child frames on TTY as a special kind
of window that is free of the "normal" window geometry restrictions.

Re: [NonGNU ELPA] New packages: corfu-doc and corfu-doc-terminal

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 1259 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Akib Azmain Turja <akib@disroot.org>
>> Cc: emacs-devel@gnu.org, Yuwei Tian <ibluefocus@outlook.com>
>> Date: Sat, 28 May 2022 22:30:46 +0600
>> 
>> I think the best solution will be to implement child frames in terminal.
>> AFAIK, ncurses has a concept of floating window, which we can use to
>> render the frame.
>
> The difficulty in implementing child frames on TTY are not because
> Emacs cannot draw on TTY at arbitrary coordinates, it's because there
> are fundamental design principles on which TTY display is based.  I'd
> actually recommend to implement child frames on TTY as a special kind
> of window that is free of the "normal" window geometry restrictions.

I can't understand.  Emacs uses ncurses, and ncurses uses a single type
for both root window (the ncurses window covering the whole terminal; I
can't remember the name ncurses uses for this) and other windows.  Does
Emacs assume while render a frame that its drawing on the root window or
is it impossible to tell ncurses precisely which window to draw above?

-- 
Akib Azmain Turja

This message is signed by me with my GnuPG key.  It's fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [NonGNU ELPA] New packages: corfu-doc and corfu-doc-terminal

[Eli Zaretskii]

> From: Akib Azmain Turja <akib@disroot.org>
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org, ibluefocus@outlook.com
> Date: Sun, 29 May 2022 02:40:07 +0600
> 
> >> I think the best solution will be to implement child frames in terminal.
> >> AFAIK, ncurses has a concept of floating window, which we can use to
> >> render the frame.
> >
> > The difficulty in implementing child frames on TTY are not because
> > Emacs cannot draw on TTY at arbitrary coordinates, it's because there
> > are fundamental design principles on which TTY display is based.  I'd
> > actually recommend to implement child frames on TTY as a special kind
> > of window that is free of the "normal" window geometry restrictions.
> 
> I can't understand.  Emacs uses ncurses, and ncurses uses a single type
> for both root window (the ncurses window covering the whole terminal; I
> can't remember the name ncurses uses for this) and other windows.  Does
> Emacs assume while render a frame that its drawing on the root window or
> is it impossible to tell ncurses precisely which window to draw above?

First, Emacs uses ncurses in a very limited manner.  Basically, it
just uses the functions that move the cursor and turn on/off various
attributes, like bold, inverse video, and colors.  I think the only
significant API from ncurses we use is tputs.  Emacs certainly does
NOT use any window-related facilities of ncurses; instead, it manages
the windows by itself.

Next, you need to understand how the Emacs display works on TTY
terminals.  The basis for the Emacs display (on both GUI and TTY
terminals) is a canvas-like model of what should be on the glass,
called "glyph matrix".  A glyph matrix is a 2-dimensional array where
each element corresponds to a character position on the screen (on GUI
terminals, we can also show display elements other than characters:
images, stretches of whitespace, xwidgets, etc.).  When performing
redisplay, Emacs first generates the up-to-date contents of the glyph
matrix, and then redraws the portions of the screen where the actual
screen contents differ from what the glyph matrix says.

Now, on GUI displays, each _window_ (not frame!) has its own glyph
matrix, and redisplay proceeds by walking the window tree and updating
each window which for some reason needs to be redrawn, partially or
fully.  By contrast, on TTY displays, the glyph matrices of the
windows are actually sub-matrices of a larger frame glyph matrix.  So
in TTY redisplay, when Emacs updates the glyph matrices of the
individual windows, it indirectly updates the glyph matrix of the
frame that is the parent of those windows.  Then the entire frame is
updated on the screen by comparing the frame glyph matrix to what is
actually on display.

I hope you now see why I suggested to treat child frames on TTY as
special kinds of windows: if we do that, we "just" need to support
windows whose glyph matrix partially overlaps those of the other
windows, and make sure we update the glyph matrices of the child
frame's windows _after_ we are done with all the windows of the parent
frame.  This way, the frame glyph matrix that is eventually used to
update what's on the glass will correctly reflect what should be on
the screen.

Stefan mentioned the TTY menus as a possible model for implementing
child frames, but I don't think I agree: the implementation of TTY
menus only works well because selecting from a menu is a single user
operation, during which the display is not important, so it is
effectively kept outdated.  We cannot do that for child frames.

HTH

Implementing child frames on terminal

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 2290 bytes --]


Eli Zaretskii <eliz@gnu.org> writes:

> I suggested to treat child frames on TTY as
> special kinds of windows: if we do that, we "just" need to support
> windows whose glyph matrix partially overlaps those of the other
> windows, and make sure we update the glyph matrices of the child
> frame's windows _after_ we are done with all the windows of the parent
> frame.  This way, the frame glyph matrix that is eventually used to
> update what's on the glass will correctly reflect what should be on
> the screen.

Your idea is good, but until the child frame crosses the edges of it's
parent.  Then it'll cause a segmentation fault (the best case) or
continue without any symptom and corrupt your files or something else
silently (the worst case).

I think we should somehow render the child frame glyph matrix before
processing it's parents.  Then we can copy the it's glyph matrix to it's
parent's one.  And, in case the child frame doesn't cross parent's
edges, we can use a floating window (as you suggested) as an
optimization (although I don't think we need this optimization, since
terminal don't usually have many characters).

And the final question, what should we do when the child frame crosses
it's parent's edges, but doesn't cross the display?  Should we clip it
(like most window systems) [1] or not (like NS) [2]?

  +----------------------+        +----------------------+
  |frame 1               |        |frame 1               |
  |parent nil            |        |parent nil            |
  |  +-------------+     |        |  +-------------+     |
  |  |frame 2      |     |        |  |frame 2      |     |
  |  |parent 1     |     |        |  |parent 1     |     |
  |  | +-----------|     |        |  | +--------------+  |
  |  | |frame 3    |     |        |  | |frame 3       |  |
  |  | |parent 2   |     |        |  | |parent 2      |  |
  |  | +-----------|     |        |  | +--------------+  |
  |  +-------------+     |        |  +-------------+     |
  +----------------------+        +----------------------+

            [1]                             [2]

-- 
Akib Azmain Turja

This message is signed by me with my GnuPG key.  It's fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Implementing child frames on terminal

[Po Lu]

Akib Azmain Turja <akib@disroot.org> writes:

> Your idea is good, but until the child frame crosses the edges of it's
> parent.  Then it'll cause a segmentation fault (the best case) or
> continue without any symptom and corrupt your files or something else
> silently (the worst case).

Fixing that (assuming you clip the contents of the child frame to the
parent) sounds easier than what you propose further on here:

> I think we should somehow render the child frame glyph matrix before
> processing it's parents.  Then we can copy the it's glyph matrix to it's
> parent's one.  And, in case the child frame doesn't cross parent's
> edges, we can use a floating window (as you suggested) as an
> optimization (although I don't think we need this optimization, since
> terminal don't usually have many characters).

Re: Implementing child frames on terminal

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 1295 bytes --]

Po Lu <luangruo@yahoo.com> writes:

> Akib Azmain Turja <akib@disroot.org> writes:
>
>> Your idea is good, but until the child frame crosses the edges of it's
>> parent.  Then it'll cause a segmentation fault (the best case) or
>> continue without any symptom and corrupt your files or something else
>> silently (the worst case).
>
> Fixing that (assuming you clip the contents of the child frame to the
> parent) sounds easier than what you propose further on here:
>
>> I think we should somehow render the child frame glyph matrix before
>> processing it's parents.  Then we can copy the it's glyph matrix to it's
>> parent's one.  And, in case the child frame doesn't cross parent's
>> edges, we can use a floating window (as you suggested) as an
>> optimization (although I don't think we need this optimization, since
>> terminal don't usually have many characters).

Really?  It looks like it would require to modify whole redisplay logic
to make sure whether a glyph is inside edges and write to it only if it
is.  That sounds more tedious to me.  However, maybe it's easier to do
but I don't know how to.

-- 
Akib Azmain Turja

This message is signed by me with my GnuPG key.  It's fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Implementing child frames on terminal

[Po Lu]

Akib Azmain Turja <akib@disroot.org> writes:

> Really?  It looks like it would require to modify whole redisplay logic
> to make sure whether a glyph is inside edges and write to it only if it
> is.  That sounds more tedious to me.  However, maybe it's easier to do
> but I don't know how to.

I guess you could allocate the individual rows in the child frame's
desired matrix separately,then copy them to the parent frame's desired
matrix after the results of `display_line' are written to a row of the
child frame's desired matrix, and then skip actual updates on the child
frame entirely (thus eliminating use of its current matrix), relying on
`update_frame' to DTRT on the parent.

But I don't know enough about the frame-based redisplay to tell you
precisely how to do that, or even if it's feasible or not.

Re: Implementing child frames on terminal

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  monnier@iro.umontreal.ca,
>   emacs-devel@gnu.org,  ibluefocus@outlook.com
> Date: Tue, 12 Jul 2022 17:44:58 +0800
> 
> Akib Azmain Turja <akib@disroot.org> writes:
> 
> > Really?  It looks like it would require to modify whole redisplay logic
> > to make sure whether a glyph is inside edges and write to it only if it
> > is.  That sounds more tedious to me.  However, maybe it's easier to do
> > but I don't know how to.
> 
> I guess you could allocate the individual rows in the child frame's
> desired matrix separately,then copy them to the parent frame's desired
> matrix after the results of `display_line' are written to a row of the
> child frame's desired matrix, and then skip actual updates on the child
> frame entirely (thus eliminating use of its current matrix), relying on
> `update_frame' to DTRT on the parent.

That'd be a step in the wrong direction, I think.  The whole idea of
TTY display is that glyphs written to the glyph rows of a window's
matrix "miraculously" end up in the frame's glyph matrix.  This avoids
a costly copying of glyphs by allocating the glyphs of windows from
the glyphs of the frame glyph matrix, and allows the last stage of
redisplay to optimize the writes of the entire frame, as opposed to
doing that window by window, which will surely be less optimal.

I see no reason yet to abandon this trick.

Re: Implementing child frames on terminal

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> That'd be a step in the wrong direction, I think.  The whole idea of
> TTY display is that glyphs written to the glyph rows of a window's
> matrix "miraculously" end up in the frame's glyph matrix.  This avoids
> a costly copying of glyphs by allocating the glyphs of windows from
> the glyphs of the frame glyph matrix, and allows the last stage of
> redisplay to optimize the writes of the entire frame, as opposed to
> doing that window by window, which will surely be less optimal.
>
> I see no reason yet to abandon this trick.

I think you're right.  I don't understand the frame-based redisplay very
well, thanks.

Re: Implementing child frames on terminal

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: akib@disroot.org,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org,
>   ibluefocus@outlook.com
> Date: Tue, 12 Jul 2022 21:38:23 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > That'd be a step in the wrong direction, I think.  The whole idea of
> > TTY display is that glyphs written to the glyph rows of a window's
> > matrix "miraculously" end up in the frame's glyph matrix.  This avoids
> > a costly copying of glyphs by allocating the glyphs of windows from
> > the glyphs of the frame glyph matrix, and allows the last stage of
> > redisplay to optimize the writes of the entire frame, as opposed to
> > doing that window by window, which will surely be less optimal.
> >
> > I see no reason yet to abandon this trick.
> 
> I think you're right.  I don't understand the frame-based redisplay very
> well, thanks.

Which part is difficult to understand?

Re: Implementing child frames on terminal

[Eli Zaretskii]

> From: Akib Azmain Turja <akib@disroot.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, monnier@iro.umontreal.ca,
>  emacs-devel@gnu.org, ibluefocus@outlook.com
> Date: Tue, 12 Jul 2022 14:35:31 +0600
> 
> > Fixing that (assuming you clip the contents of the child frame to the
> > parent) sounds easier than what you propose further on here:
> >
> >> I think we should somehow render the child frame glyph matrix before
> >> processing it's parents.  Then we can copy the it's glyph matrix to it's
> >> parent's one.  And, in case the child frame doesn't cross parent's
> >> edges, we can use a floating window (as you suggested) as an
> >> optimization (although I don't think we need this optimization, since
> >> terminal don't usually have many characters).
> 
> Really?  It looks like it would require to modify whole redisplay logic
> to make sure whether a glyph is inside edges and write to it only if it
> is.

Actually, the current redisplay code does this all the time: that's
how we know when to continue or truncate a too-long line, or where to
wrap a long line under visual-line-mode.

Re: Implementing child frames on terminal

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 2066 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Akib Azmain Turja <akib@disroot.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>, monnier@iro.umontreal.ca,
>>  emacs-devel@gnu.org, ibluefocus@outlook.com
>> Date: Tue, 12 Jul 2022 14:35:31 +0600
>> 
>> > Fixing that (assuming you clip the contents of the child frame to the
>> > parent) sounds easier than what you propose further on here:
>> >
>> >> I think we should somehow render the child frame glyph matrix before
>> >> processing it's parents.  Then we can copy the it's glyph matrix to it's
>> >> parent's one.  And, in case the child frame doesn't cross parent's
>> >> edges, we can use a floating window (as you suggested) as an
>> >> optimization (although I don't think we need this optimization, since
>> >> terminal don't usually have many characters).
>> 
>> Really?  It looks like it would require to modify whole redisplay logic
>> to make sure whether a glyph is inside edges and write to it only if it
>> is.
>
> Actually, the current redisplay code does this all the time: that's
> how we know when to continue or truncate a too-long line, or where to
> wrap a long line under visual-line-mode.
>

But this problem is different than that.  In your too-long line case,
redisplay code checks whether a glyph is inside the window.  But for
child frames, it needs to check whether a glyph is inside the parent
frame (i.e. safe to write to), write it if it is and always assume
that it was written successfully.

For example, if we have a 30 chars wide child frames displaying a 40
chars wide line and the child frame's left edge is 20 char away from
it's parent right edge, the redisplay code has to write the first 20
chars to the glyph matrix and don't write the next 10 chars, but still
think that they were written, and finally truncate the last 10 chars or
wrap it depending on the value of "truncate-lines".

-- 
Akib Azmain Turja

This message is signed by me with my GnuPG key.  It's fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Implementing child frames on terminal

[Eli Zaretskii]

> From: Akib Azmain Turja <akib@disroot.org>
> Cc: luangruo@yahoo.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org,
>  ibluefocus@outlook.com
> Date: Tue, 12 Jul 2022 20:21:02 +0600
> 
> >> Really?  It looks like it would require to modify whole redisplay logic
> >> to make sure whether a glyph is inside edges and write to it only if it
> >> is.
> >
> > Actually, the current redisplay code does this all the time: that's
> > how we know when to continue or truncate a too-long line, or where to
> > wrap a long line under visual-line-mode.
> >
> 
> But this problem is different than that.  In your too-long line case,
> redisplay code checks whether a glyph is inside the window.  But for
> child frames, it needs to check whether a glyph is inside the parent
> frame (i.e. safe to write to), write it if it is and always assume
> that it was written successfully.
> 
> For example, if we have a 30 chars wide child frames displaying a 40
> chars wide line and the child frame's left edge is 20 char away from
> it's parent right edge, the redisplay code has to write the first 20
> chars to the glyph matrix and don't write the next 10 chars, but still
> think that they were written, and finally truncate the last 10 chars or
> wrap it depending on the value of "truncate-lines".

The way redisplay of a window works, it starts by determining how wide
can each screen line be before it overflows the right edge of the
window.  The result of this is the member of 'struct it' called
'last_visible_x'.  It is computed once (see init_iterator), and then
used everywhere when we need to decide whether there's place in the
screen line for one more glyph.

So to support the above, we'd just need to modify the calculation of
last_visible_x in init_iterator such that it takes into consideration
the edge of the parent frame.  And that shouldn't be hard, given that
we know the offset of the child frame from its parent frame.

Re: Implementing child frames on terminal

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 3269 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> But this problem is different than that.  In your too-long line case,
>> redisplay code checks whether a glyph is inside the window.  But for
>> child frames, it needs to check whether a glyph is inside the parent
>> frame (i.e. safe to write to), write it if it is and always assume
>> that it was written successfully.
>> 
>> For example, if we have a 30 chars wide child frames displaying a 40
>> chars wide line and the child frame's left edge is 20 char away from
>> it's parent right edge, the redisplay code has to write the first 20
>> chars to the glyph matrix and don't write the next 10 chars, but still
>> think that they were written, and finally truncate the last 10 chars or
>> wrap it depending on the value of "truncate-lines".
>
> The way redisplay of a window works, it starts by determining how wide
> can each screen line be before it overflows the right edge of the
> window.  The result of this is the member of 'struct it' called
> 'last_visible_x'.  It is computed once (see init_iterator), and then
> used everywhere when we need to decide whether there's place in the
> screen line for one more glyph.
>
> So to support the above, we'd just need to modify the calculation of
> last_visible_x in init_iterator such that it takes into consideration
> the edge of the parent frame.  And that shouldn't be hard, given that
> we know the offset of the child frame from its parent frame.
>

What do you mean?  Set last_visible_x to the last x position not
clipped?  That won't work, since last_visible_x has no effect on
margins AFAIK.  Same for first_visible_x.

I have another idea, we can make the glyph matrix memory larger than the
top-level (i.e. not a child) frame:

--8<---------------cut here---------------start------------->8---
+--------------------------------------+
|+------------------------------------+|
||                                    ||<<< glyph matrix memory
||<<< frame glyph matrix              ||
||                                    ||
||                                    ||
||                                    ||
||    +-----------------------------+ ||
||    |<<< child frame glyph matrix | ||
||    |                             | ||
|+----|.............................|-+|
|     |                             |  |
|     +-----------------------------+  |
+--------------------------------------+
--8<---------------cut here---------------end--------------->8---

According to the figure above, rendering glyphs for part of child frame
outside the top-level frame's edges won't cause any error because it
will write to allocated memory, but still those glyph won't appear on
the glass because they are outside the glyph matrix of the top-level
frame.  This technique won't allow to clip a nested child frame to the
edges of it parent (which is also a child frame) and also wastes some
memory, however.

Do you have a list of functions that directly writes to glyph matrix?
It is much easier to work with function than to work with dynamic
memory.

-- 
Akib Azmain Turja

This message is signed by me with my GnuPG key.  It's fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Implementing child frames on terminal

[Eli Zaretskii]

> From: Akib Azmain Turja <akib@disroot.org>
> Cc: luangruo@yahoo.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org,
>  ibluefocus@outlook.com
> Date: Wed, 13 Jul 2022 20:33:52 +0600
> 
> > The way redisplay of a window works, it starts by determining how wide
> > can each screen line be before it overflows the right edge of the
> > window.  The result of this is the member of 'struct it' called
> > 'last_visible_x'.  It is computed once (see init_iterator), and then
> > used everywhere when we need to decide whether there's place in the
> > screen line for one more glyph.
> >
> > So to support the above, we'd just need to modify the calculation of
> > last_visible_x in init_iterator such that it takes into consideration
> > the edge of the parent frame.  And that shouldn't be hard, given that
> > we know the offset of the child frame from its parent frame.
> >
> 
> What do you mean?  Set last_visible_x to the last x position not
> clipped?  That won't work, since last_visible_x has no effect on
> margins AFAIK.  Same for first_visible_x.

You mean, the display margins?  If that is the problem that bothers
you, then yes, the functions in dispnew.c that calculate the
dimensions of each window will have to take the clipping into account.
And again, this calculation happens just once, in the beginning of a
redisplay cycle, and only if needed (i.e. only when the previously
calculated dimensions no longer fit).

But last_visible_x will still need to be adjusted as I outlined,
because no one said that the clipping happens on the margin (and most
windows don't have margins anyway).

> I have another idea, we can make the glyph matrix memory larger than the
> top-level (i.e. not a child) frame:
> 
> --8<---------------cut here---------------start------------->8---
> +--------------------------------------+
> |+------------------------------------+|
> ||                                    ||<<< glyph matrix memory
> ||<<< frame glyph matrix              ||
> ||                                    ||
> ||                                    ||
> ||                                    ||
> ||    +-----------------------------+ ||
> ||    |<<< child frame glyph matrix | ||
> ||    |                             | ||
> |+----|.............................|-+|
> |     |                             |  |
> |     +-----------------------------+  |
> +--------------------------------------+
> --8<---------------cut here---------------end--------------->8---
> 
> According to the figure above, rendering glyphs for part of child frame
> outside the top-level frame's edges won't cause any error because it
> will write to allocated memory, but still those glyph won't appear on
> the glass because they are outside the glyph matrix of the top-level
> frame.

Why produce glyphs that will never get written to the glass?  It's
just a waste of cycles.  And it isn't for free: we'd need to have code
that checks whether a glyph should or shouldn't be written to the
screen, because writing it outside of the terminal could have bad
effects.

> Do you have a list of functions that directly writes to glyph matrix?
> It is much easier to work with function than to work with dynamic
> memory.

They are too many, but you can start from the PRODUCE_GLYPHS macro.

Re: Implementing child frames on terminal

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 4529 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Akib Azmain Turja <akib@disroot.org>
>> Cc: luangruo@yahoo.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org,
>>  ibluefocus@outlook.com
>> Date: Wed, 13 Jul 2022 20:33:52 +0600
>> 
>> > The way redisplay of a window works, it starts by determining how wide
>> > can each screen line be before it overflows the right edge of the
>> > window.  The result of this is the member of 'struct it' called
>> > 'last_visible_x'.  It is computed once (see init_iterator), and then
>> > used everywhere when we need to decide whether there's place in the
>> > screen line for one more glyph.
>> >
>> > So to support the above, we'd just need to modify the calculation of
>> > last_visible_x in init_iterator such that it takes into consideration
>> > the edge of the parent frame.  And that shouldn't be hard, given that
>> > we know the offset of the child frame from its parent frame.
>> >
>> 
>> What do you mean?  Set last_visible_x to the last x position not
>> clipped?  That won't work, since last_visible_x has no effect on
>> margins AFAIK.  Same for first_visible_x.
>
> You mean, the display margins?  If that is the problem that bothers
> you, then yes, the functions in dispnew.c that calculate the
> dimensions of each window will have to take the clipping into account.
> And again, this calculation happens just once, in the beginning of a
> redisplay cycle, and only if needed (i.e. only when the previously
> calculated dimensions no longer fit).
>
> But last_visible_x will still need to be adjusted as I outlined,

I don't think so.  I tried to hard-code last_visible_x to 40.  Then I
compiled and started Emacs and found that the lines of *scratch* buffer
wrapped at 39th column (and the 40th column being the continuation
glyph).

> because no one said that the clipping happens on the margin

It may happen.

> (and most
> windows don't have margins anyway).

Really?  It seems that line numbers are also unaffected by that
last_visible_x.

>
>> I have another idea, we can make the glyph matrix memory larger than the
>> top-level (i.e. not a child) frame:
>> 
>> --8<---------------cut here---------------start------------->8---
>> +--------------------------------------+
>> |+------------------------------------+|
>> ||                                    ||<<< glyph matrix memory
>> ||<<< frame glyph matrix              ||
>> ||                                    ||
>> ||                                    ||
>> ||                                    ||
>> ||    +-----------------------------+ ||
>> ||    |<<< child frame glyph matrix | ||
>> ||    |                             | ||
>> |+----|.............................|-+|
>> |     |                             |  |
>> |     +-----------------------------+  |
>> +--------------------------------------+
>> --8<---------------cut here---------------end--------------->8---
>> 
>> According to the figure above, rendering glyphs for part of child frame
>> outside the top-level frame's edges won't cause any error because it
>> will write to allocated memory, but still those glyph won't appear on
>> the glass because they are outside the glyph matrix of the top-level
>> frame.
>
> Why produce glyphs that will never get written to the glass?  It's
> just a waste of cycles.  And it isn't for free: we'd need to have code
> that checks whether a glyph should or shouldn't be written to the
> screen, because writing it outside of the terminal could have bad
> effects.

IIUC, we won't need additional code.  Because those garbage glyphs are
outside of the frame's glyph matrix, so the terminal display code won't
notice them at all.

I think we are all trying to do premature optimization.  Do we bother
whether a character is clipped on X?  AFAIK no, and that's more costly
than doing the same on terminal.  I think we should first make it work
and then talk about optimizations, that's better than rejecting all the
proposed ideas claiming they are inefficient.

Or is there any real reason to optimize?

>
>> Do you have a list of functions that directly writes to glyph matrix?
>> It is much easier to work with function than to work with dynamic
>> memory.
>
> They are too many, but you can start from the PRODUCE_GLYPHS macro.

Thanks.

-- 
Akib Azmain Turja

This message is signed by me with my GnuPG key.  It's fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Implementing child frames on terminal

[Eli Zaretskii]

> From: Akib Azmain Turja <akib@disroot.org>
> Cc: luangruo@yahoo.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org,
>  ibluefocus@outlook.com
> Date: Wed, 13 Jul 2022 23:55:09 +0600
> 
> > You mean, the display margins?  If that is the problem that bothers
> > you, then yes, the functions in dispnew.c that calculate the
> > dimensions of each window will have to take the clipping into account.
> > And again, this calculation happens just once, in the beginning of a
> > redisplay cycle, and only if needed (i.e. only when the previously
> > calculated dimensions no longer fit).
> >
> > But last_visible_x will still need to be adjusted as I outlined,
> 
> I don't think so.  I tried to hard-code last_visible_x to 40.  Then I
> compiled and started Emacs and found that the lines of *scratch* buffer
> wrapped at 39th column (and the 40th column being the continuation
> glyph).

Right.  You just discovered that setting last_visible_x is not the
only thing that should be done.  But I never said it's the only thing,
just that it is _one_ thing that needs to be done.  Changing the code
which produces the continuation/truncation glyphs to support child
frames is not hard, but it does need some coding.  And there really is
no way around that, because that's how Emacs display works.

Remember: this all came out of discussions about the design of child
frames on TTY displays, where you expressed doubt that we could easily
"clip" child frames where needed.  But that basic design is just the
beginning; there's more to this than meets the eye.

> It seems that line numbers are also unaffected by that
> last_visible_x.

Yes, they are.  From maybe_produce_line_number:

  /* We must leave space for 2 glyphs for continuation and truncation,
     and at least one glyph for buffer text.  */
  int width_limit =
    tem_it.last_visible_x - tem_it.first_visible_x
    - 3 * FRAME_COLUMN_WIDTH (it->f);
  [...]
      PRODUCE_GLYPHS (&tem_it);

      /* Stop producing glyphs, and refrain from producing the line
	 number, if we don't have enough space on this line.  */
      if (tem_it.current_x >= width_limit)
	{
	  it->lnum_width = 0;
	  it->lnum_pixel_width = 0;
	  bidi_unshelve_cache (itdata, false);
	  inhibit_free_realized_faces = save_free_realized_faces;
	  return;
	}

> > Why produce glyphs that will never get written to the glass?  It's
> > just a waste of cycles.  And it isn't for free: we'd need to have code
> > that checks whether a glyph should or shouldn't be written to the
> > screen, because writing it outside of the terminal could have bad
> > effects.
> 
> IIUC, we won't need additional code.  Because those garbage glyphs are
> outside of the frame's glyph matrix, so the terminal display code won't
> notice them at all.
> 
> I think we are all trying to do premature optimization.  Do we bother
> whether a character is clipped on X?

On X, the clipping is a given.  But on text-mode terminal there's no
clipping: if you write one character too many on a line, it will
generally wrap to the next line.

> Or is there any real reason to optimize?

It isn't an optimization, it's safe coding.

Re: Implementing child frames on terminal

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 4105 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Akib Azmain Turja <akib@disroot.org>
>> Cc: luangruo@yahoo.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org,
>>  ibluefocus@outlook.com
>> Date: Wed, 13 Jul 2022 23:55:09 +0600
>> 
>> > You mean, the display margins?  If that is the problem that bothers
>> > you, then yes, the functions in dispnew.c that calculate the
>> > dimensions of each window will have to take the clipping into account.
>> > And again, this calculation happens just once, in the beginning of a
>> > redisplay cycle, and only if needed (i.e. only when the previously
>> > calculated dimensions no longer fit).
>> >
>> > But last_visible_x will still need to be adjusted as I outlined,
>> 
>> I don't think so.  I tried to hard-code last_visible_x to 40.  Then I
>> compiled and started Emacs and found that the lines of *scratch* buffer
>> wrapped at 39th column (and the 40th column being the continuation
>> glyph).
>
> Right.  You just discovered that setting last_visible_x is not the
> only thing that should be done.  But I never said it's the only thing,
> just that it is _one_ thing that needs to be done.  Changing the code
> which produces the continuation/truncation glyphs to support child
> frames is not hard, but it does need some coding.  And there really is
> no way around that, because that's how Emacs display works.
>
> Remember: this all came out of discussions about the design of child
> frames on TTY displays, where you expressed doubt that we could easily
> "clip" child frames where needed.  But that basic design is just the
> beginning; there's more to this than meets the eye.
>
>> It seems that line numbers are also unaffected by that
>> last_visible_x.
>
> Yes, they are.  From maybe_produce_line_number:
>
>   /* We must leave space for 2 glyphs for continuation and truncation,
>      and at least one glyph for buffer text.  */
>   int width_limit =
>     tem_it.last_visible_x - tem_it.first_visible_x
>     - 3 * FRAME_COLUMN_WIDTH (it->f);
>   [...]
>       PRODUCE_GLYPHS (&tem_it);
>
>       /* Stop producing glyphs, and refrain from producing the line
> 	 number, if we don't have enough space on this line.  */
>       if (tem_it.current_x >= width_limit)
> 	{
> 	  it->lnum_width = 0;
> 	  it->lnum_pixel_width = 0;
> 	  bidi_unshelve_cache (itdata, false);
> 	  inhibit_free_realized_faces = save_free_realized_faces;
> 	  return;
> 	}
>
>> > Why produce glyphs that will never get written to the glass?  It's
>> > just a waste of cycles.  And it isn't for free: we'd need to have code
>> > that checks whether a glyph should or shouldn't be written to the
>> > screen, because writing it outside of the terminal could have bad
>> > effects.
>> 
>> IIUC, we won't need additional code.  Because those garbage glyphs are
>> outside of the frame's glyph matrix, so the terminal display code won't
>> notice them at all.
>> 
>> I think we are all trying to do premature optimization.  Do we bother
>> whether a character is clipped on X?
>
> On X, the clipping is a given.  But on text-mode terminal there's no
> clipping: if you write one character too many on a line, it will
> generally wrap to the next line.

There is definitely a misunderstanding here.  Nothing is going to write
outside of the terminal, because the size of the top-level frame's
matrix is the same as the size of the terminal.

My idea is that we write the glyphs to the glyph matrix anyway, and then
decide which glyphs to show on the glass later.

>
>> Or is there any real reason to optimize?
>
> It isn't an optimization, it's safe coding.

You misunderstood my question.  I meant: is there any real reason to
share the glyph memory of the parent and the child frame?  We can just
copy the visible part of child frame matrix to parent frame matrix,
which IMHO won't cause any noticeable slowdown compared to X.

-- 
Akib Azmain Turja

This message is signed by me with my GnuPG key.  It's fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Implementing child frames on terminal

[Eli Zaretskii]

> From: Akib Azmain Turja <akib@disroot.org>
> Cc: luangruo@yahoo.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org,
>  ibluefocus@outlook.com
> Date: Thu, 14 Jul 2022 13:14:18 +0600
> 
> You misunderstood my question.  I meant: is there any real reason to
> share the glyph memory of the parent and the child frame?

Yes: the last stage of TTY redisplay uses only the frame glyph matrix,
it doesn't use glyph matrices of the windows.  For child frames, this
translates into using only the frame matrix of the topmost frame.  (As
I proposed at the beginning of this discussion, I would not even
maintain frame matrices for child frames, only window matrices.)

> We can just copy the visible part of child frame matrix to parent
> frame matrix, which IMHO won't cause any noticeable slowdown
> compared to X.

As I explained earlier, I don't understand why would we want to incur
this slowdown, however unnoticeable.  Unlike on GUI displays, TTYs
have a fixed number and positions of character cells, and not to use
this fact sounds silly to me, especially since the existing code
already does that.

Re: Implementing child frames on terminal

[Eli Zaretskii]

> From: Akib Azmain Turja <akib@disroot.org>
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org, ibluefocus@outlook.com
> Date: Tue, 12 Jul 2022 09:19:28 +0600
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I suggested to treat child frames on TTY as
> > special kinds of windows: if we do that, we "just" need to support
> > windows whose glyph matrix partially overlaps those of the other
> > windows, and make sure we update the glyph matrices of the child
> > frame's windows _after_ we are done with all the windows of the parent
> > frame.  This way, the frame glyph matrix that is eventually used to
> > update what's on the glass will correctly reflect what should be on
> > the screen.
> 
> Your idea is good, but until the child frame crosses the edges of it's
> parent.  Then it'll cause a segmentation fault (the best case) or
> continue without any symptom and corrupt your files or something else
> silently (the worst case).

I suspect there's a misunderstanding here: when I said "frame glyph
matrix", I meant that in the sense it is used in dispnew.c -- the
glyph matrix describing the frame that is the parent of all the other
windows and child frames.  That frame cannot possibly be "crossed",
because it by definition has the full dimensions of the TTY display.

> And the final question, what should we do when the child frame crosses
> it's parent's edges, but doesn't cross the display?  Should we clip it
> (like most window systems) [1] or not (like NS) [2]?

The former, I think.  But maybe we could make it customizable.  The
difference from the code POV is not that big.

Re: Implementing child frames on terminal

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> And the final question, what should we do when the child frame crosses
>> it's parent's edges, but doesn't cross the display?  Should we clip it
>> (like most window systems) [1] or not (like NS) [2]?
>
> The former, I think.  But maybe we could make it customizable.  The
> difference from the code POV is not that big.

If so, then someone should implement the same on X.  (I'm not
volunteering, IMO child frames are a misfeature that could be
implemented with undecorated frames entirely in Lisp.)

It isn't fair to have a GUI feature that works in a TTY, but not under
X.

Re: Implementing child frames on terminal

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Akib Azmain Turja <akib@disroot.org>,  monnier@iro.umontreal.ca,
>   emacs-devel@gnu.org,  ibluefocus@outlook.com
> Date: Tue, 12 Jul 2022 21:40:35 +0800
> 
> It isn't fair to have a GUI feature that works in a TTY, but not under
> X.

But it does work on GUI displays, just not on all of them.

(And why is it important whether we clip or don't clip child frames in
those cases?)

Re: Implementing child frames on terminal

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> But it does work on GUI displays, just not on all of them.

But we don't have the ability to control whether or not clipping is
performed on any of them, at present.

> (And why is it important whether we clip or don't clip child frames in
> those cases?)

Someone might want a popup implemented as a child frame to extend past
the bounds of the parent, for example.

Re: Implementing child frames on terminal

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: akib@disroot.org,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org,
>   ibluefocus@outlook.com
> Date: Tue, 12 Jul 2022 21:54:34 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > (And why is it important whether we clip or don't clip child frames in
> > those cases?)
> 
> Someone might want a popup implemented as a child frame to extend past
> the bounds of the parent, for example.

Why would they want that?

Re: Implementing child frames on terminal

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Why would they want that?

I don't know.  It's an idea I saw floating around in a forum.

Re: Implementing child frames on terminal

[Stefan Monnier]

>> Someone might want a popup implemented as a child frame to extend past
>> the bounds of the parent, for example.
> Why would they want that?

I can imagine a situation where a tty frame is split into two windows
and some company/corfu-style completion wants to popup a child-frame to
show completion candidates (basically like a menu), and if the
completion is near the split between the two windows, it would be
natural for that child-frame to extend into the other window if that can
make its contents more readable.  It would even feel odd if that
child-window were restricted to fit within its "parent" window.

In a sense it's already bad enough that such child-frames will be
restricted to stay within the confines of the text terminal ;-)

BTW We currently see "the same" with your menubar code in ttys, where the
menus aren't restricted to live within one of the existing windows
either, instead they're overlayed above the windows without regards for
the existing window splits.


        Stefan

Re: Implementing child frames on terminal

[Po Lu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I can imagine a situation where a tty frame is split into two windows
> and some company/corfu-style completion wants to popup a child-frame to
> show completion candidates (basically like a menu), and if the
> completion is near the split between the two windows, it would be
> natural for that child-frame to extend into the other window if that can
> make its contents more readable.  It would even feel odd if that
> child-window were restricted to fit within its "parent" window.

But we're talking about frames that are children of other _frames_, not
windows, right?

Re: Implementing child frames on terminal

[Stefan Monnier]

Po Lu [2022-07-14 11:34:53] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I can imagine a situation where a tty frame is split into two windows
>> and some company/corfu-style completion wants to popup a child-frame to
>> show completion candidates (basically like a menu), and if the
>> completion is near the split between the two windows, it would be
>> natural for that child-frame to extend into the other window if that can
>> make its contents more readable.  It would even feel odd if that
>> child-window were restricted to fit within its "parent" window.
>
> But we're talking about frames that are children of other _frames_, not
> windows, right?

Ah, you're right.  Sorry 'bout the noise.


        Stefan

Re: Implementing child frames on terminal

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Po Lu <luangruo@yahoo.com>,  akib@disroot.org,  emacs-devel@gnu.org,
>   ibluefocus@outlook.com
> Date: Wed, 13 Jul 2022 21:55:16 -0400
> 
> >> Someone might want a popup implemented as a child frame to extend past
> >> the bounds of the parent, for example.
> > Why would they want that?
> 
> I can imagine a situation where a tty frame is split into two windows
> and some company/corfu-style completion wants to popup a child-frame to
> show completion candidates (basically like a menu), and if the
> completion is near the split between the two windows, it would be
> natural for that child-frame to extend into the other window if that can
> make its contents more readable.  It would even feel odd if that
> child-window were restricted to fit within its "parent" window.

Such popups must be limited in their height anyway, so I see no
problem in limiting them to their parent frame.

(I also don't think child frames are the right basis for implementing
such popups: they will look ugly.  Emacs frames are not suited for
emulating GUI dialog widgets.)

> BTW We currently see "the same" with your menubar code in ttys, where the
> menus aren't restricted to live within one of the existing windows
> either, instead they're overlayed above the windows without regards for
> the existing window splits.

But they never cross the frame's border, which is what this discussion
is about.  More importantly, I very much doubt that we'd want the
child frames on TTYs to have the same limitations as TTY menus must
abide by.

Re: Implementing child frames on terminal

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> (I also don't think child frames are the right basis for implementing
> such popups: they will look ugly.  Emacs frames are not suited for
> emulating GUI dialog widgets.)

I agree with that, but unfortunately child frames are already being
widely used for implementing popups.

Re: Implementing child frames on terminal

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 1944 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: Po Lu <luangruo@yahoo.com>,  akib@disroot.org,  emacs-devel@gnu.org,
>>   ibluefocus@outlook.com
>> Date: Wed, 13 Jul 2022 21:55:16 -0400
>> 
>> >> Someone might want a popup implemented as a child frame to extend past
>> >> the bounds of the parent, for example.
>> > Why would they want that?
>> 
>> I can imagine a situation where a tty frame is split into two windows
>> and some company/corfu-style completion wants to popup a child-frame to
>> show completion candidates (basically like a menu), and if the
>> completion is near the split between the two windows, it would be
>> natural for that child-frame to extend into the other window if that can
>> make its contents more readable.  It would even feel odd if that
>> child-window were restricted to fit within its "parent" window.
>
> Such popups must be limited in their height anyway, so I see no
> problem in limiting them to their parent frame.
>
> (I also don't think child frames are the right basis for implementing
> such popups: they will look ugly.  Emacs frames are not suited for
> emulating GUI dialog widgets.)

What?  Completion popup is a misuse of child frame?  Then what its
supposed to do?

>
>> BTW We currently see "the same" with your menubar code in ttys, where the
>> menus aren't restricted to live within one of the existing windows
>> either, instead they're overlayed above the windows without regards for
>> the existing window splits.
>
> But they never cross the frame's border, which is what this discussion
> is about.  More importantly, I very much doubt that we'd want the
> child frames on TTYs to have the same limitations as TTY menus must
> abide by.

-- 
Akib Azmain Turja

This message is signed by me with my GnuPG key.  It's fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Implementing child frames on terminal

[Eli Zaretskii]

> From: Akib Azmain Turja <akib@disroot.org>
> Cc: luangruo@yahoo.com, emacs-devel@gnu.org, ibluefocus@outlook.com
> Date: Thu, 14 Jul 2022 12:53:32 +0600
> 
> > (I also don't think child frames are the right basis for implementing
> > such popups: they will look ugly.  Emacs frames are not suited for
> > emulating GUI dialog widgets.)
> 
> What?  Completion popup is a misuse of child frame?  Then what its
> supposed to do?

What is "it" in this case?

Re: Implementing child frames on terminal

[Akib Azmain Turja]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Akib Azmain Turja <akib@disroot.org>
>> Cc: luangruo@yahoo.com, emacs-devel@gnu.org, ibluefocus@outlook.com
>> Date: Thu, 14 Jul 2022 12:53:32 +0600
>> 
>> > (I also don't think child frames are the right basis for implementing
>> > such popups: they will look ugly.  Emacs frames are not suited for
>> > emulating GUI dialog widgets.)
>> 
>> What?  Completion popup is a misuse of child frame?  Then what its
>> supposed to do?
>
> What is "it" in this case?
>

Child frame.  What child frame is supposed to do?
<#secure method=pgpmime mode=sign>

-- 
Akib Azmain Turja

Find me on Mastodon at @akib@hostux.social.

This message is signed by me with my GnuPG key.  It's fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

Re: Implementing child frames on terminal

[Eli Zaretskii]

> From: Akib Azmain Turja <akib@disroot.org>
> Cc: monnier@iro.umontreal.ca,  luangruo@yahoo.com,  emacs-devel@gnu.org,
>   ibluefocus@outlook.com
> Date: Thu, 14 Jul 2022 18:07:34 +0600
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Akib Azmain Turja <akib@disroot.org>
> >> Cc: luangruo@yahoo.com, emacs-devel@gnu.org, ibluefocus@outlook.com
> >> Date: Thu, 14 Jul 2022 12:53:32 +0600
> >> 
> >> > (I also don't think child frames are the right basis for implementing
> >> > such popups: they will look ugly.  Emacs frames are not suited for
> >> > emulating GUI dialog widgets.)
> >> 
> >> What?  Completion popup is a misuse of child frame?  Then what its
> >> supposed to do?
> >
> > What is "it" in this case?
> >
> 
> Child frame.  What child frame is supposed to do?

Then I don't understand the question.  The obvious answer is "display
a child frame", but somehow I don't think this is the answer you were
waiting for.

Re: Implementing child frames on terminal

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 535 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> Child frame.  What child frame is supposed to do?
>
> Then I don't understand the question.  The obvious answer is "display
> a child frame", but somehow I don't think this is the answer you were
> waiting for.
>

I intended to ask:  What is the intended use-case of child frame?

-- 
Akib Azmain Turja

Find me on Mastodon at @akib@hostux.social.

This message is signed by me with my GnuPG key.  It's fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Implementing child frames on terminal

[Eli Zaretskii]

> From: Akib Azmain Turja <akib@disroot.org>
> Cc: monnier@iro.umontreal.ca,  luangruo@yahoo.com,  emacs-devel@gnu.org,
>   ibluefocus@outlook.com
> Date: Thu, 14 Jul 2022 19:52:28 +0600
> 
> >> Child frame.  What child frame is supposed to do?
> >
> > Then I don't understand the question.  The obvious answer is "display
> > a child frame", but somehow I don't think this is the answer you were
> > waiting for.
> >
> 
> I intended to ask:  What is the intended use-case of child frame?

I don't know.

Re: Implementing child frames on terminal

[Po Lu]

Akib Azmain Turja <akib@disroot.org> writes:

> I intended to ask:  What is the intended use-case of child frame?

I think it's displaying multiple frames in a single frame, thereby
making the parent frame a "virtual root window" containing smaller
toplevel windows (that contain buffers), which is a GUI pattern seen in
many other programs.

Re: Implementing child frames on terminal

[Stefan Monnier]

Po Lu [2022-07-15 10:37:39] wrote:
> Akib Azmain Turja <akib@disroot.org> writes:
>> I intended to ask:  What is the intended use-case of child frame?
> I think it's displaying multiple frames in a single frame, thereby
> making the parent frame a "virtual root window" containing smaller
> toplevel windows (that contain buffers), which is a GUI pattern seen in
> many other programs.

That describes what it does rather than what it's use for.


        Stefan

Re: Implementing child frames on terminal

[Po Lu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> That describes what it does rather than what it's use for.

No, Emacs has a built in (but rather crude) window manager for those
child frames: see the `drag-internal-border', `drag-with-header-line'
and `drag-with-mode-line' frame parameters.

Re: Implementing child frames on terminal

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1345 bytes --]

On Fri, Jul 15, 2022 at 12:24:21PM +0800, Po Lu wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> > That describes what it does rather than what it's use for.
> 
> No, Emacs has a built in (but rather crude) window manager for those
> child frames: see the `drag-internal-border', `drag-with-header-line'
> and `drag-with-mode-line' frame parameters.

I think we are seeing the debris of one of those strange "UI battles"
which raged our little software world for so long, stemming from such
perception things as "is the application the window? If yes, can that
window have a little world of its own inside itself?"

The end is a monster, where you get all of it: an application has more
than one window with lots of little windows in them. With the advent
of the browser, the snake starts eating itself again (with separate,
untrusted, potentially mutually hostile things hopefully confined to
their "tabs".

For a historical reminder, I'd recommend Wikipedia's description of
"MDI", the "Multiple-Document Interface" [1]. Fads come and go :-)

(Now you could say it's cruel calling it a fad. It was an experiment
in UI design, and as such, legitimate. It became a fad as soon as
the Marketing Dept. entered the picture)

Cheers

[1] https://en.wikipedia.org/wiki/Multiple-document_interface
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Implementing child frames on terminal

[Po Lu]

Akib Azmain Turja <akib@disroot.org> writes:

> What?  Completion popup is a misuse of child frame?  Then what its
> supposed to do?

IMNSHO child frame support (on X) is actually a misfeature, and
completions should be implemented with an override-redirect toplevel
window instead.

The reasoning behind this conclusion is the sheer amount of code we
spend trying to force toolkits (GTK in particular, but also Xt) and the
X server (in the case of the X input extension) to play nice with
supposedly "toplevel" windows being a child of an actual toplevel
window.

Re: Implementing child frames on terminal

[Akib Azmain Turja]

Po Lu <luangruo@yahoo.com> writes:

> Akib Azmain Turja <akib@disroot.org> writes:
>
>> What?  Completion popup is a misuse of child frame?  Then what its
>> supposed to do?
>
> IMNSHO child frame support (on X) is actually a misfeature, and
> completions should be implemented with an override-redirect toplevel
> window instead.

"override-redirect toplevel window"?  I can't understand.

>
> The reasoning behind this conclusion is the sheer amount of code we
> spend trying to force toolkits (GTK in particular, but also Xt) and the
> X server (in the case of the X input extension) to play nice with
> supposedly "toplevel" windows being a child of an actual toplevel
> window.
<#secure method=pgpmime mode=sign>

-- 
Akib Azmain Turja

Find me on Mastodon at @akib@hostux.social.

This message is signed by me with my GnuPG key.  It's fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

Re: Implementing child frames on terminal

[Tassilo Horn]

Po Lu <luangruo@yahoo.com> writes:

>> What?  Completion popup is a misuse of child frame?  Then what its
>> supposed to do?
>
> IMNSHO child frame support (on X) is actually a misfeature, and
> completions should be implemented with an override-redirect toplevel
> window instead.
>
> The reasoning behind this conclusion is the sheer amount of code we
> spend trying to force toolkits (GTK in particular, but also Xt) and
> the X server (in the case of the X input extension) to play nice with
> supposedly "toplevel" windows being a child of an actual toplevel
> window.

Interesting.  What would the child-frame using programmer loose when
switching to override-redirect toplevel windows?  I guess their position
would be absolute instead of relative to the (then not existent) parent
frame and they wouldn't reposition themselves when the parent moves.
The first issue could be amended with functions computing positions
relative to some given frame and the second isn't too big of a deal.

Bye,
Tassilo

Re: Implementing child frames on terminal

[Stefan Monnier]

> (I also don't think child frames are the right basis for implementing
> such popups: they will look ugly.  Emacs frames are not suited for
> emulating GUI dialog widgets.)

AFAIK that's the main use of child frames, tho, and the main motivation
for implementing child frames in ttys (to replace things like `popon.el`).


        Stefan

Re: Implementing child frames on terminal

[Akib Azmain Turja]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> (I also don't think child frames are the right basis for implementing
>> such popups: they will look ugly.  Emacs frames are not suited for
>> emulating GUI dialog widgets.)
>
> AFAIK that's the main use of child frames, tho, and the main motivation
> for implementing child frames in ttys (to replace things like `popon.el`).
>
>
>         Stefan
>

Exactly.
<#secure method=pgpmime mode=sign>

-- 
Akib Azmain Turja

Find me on Mastodon at @akib@hostux.social.

This message is signed by me with my GnuPG key.  It's fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

Re: Implementing child frames on terminal

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 1099 bytes --]

Po Lu <luangruo@yahoo.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> And the final question, what should we do when the child frame crosses
>>> it's parent's edges, but doesn't cross the display?  Should we clip it
>>> (like most window systems) [1] or not (like NS) [2]?
>>
>> The former, I think.  But maybe we could make it customizable.  The
>> difference from the code POV is not that big.
>
> If so, then someone should implement the same on X.  (I'm not
> volunteering, IMO child frames are a misfeature that could be
> implemented with undecorated frames entirely in Lisp.)

It's easy:

Don't use the parent frame parameter and calculate the position of the
frame yourself.

>
> It isn't fair to have a GUI feature that works in a TTY, but not under
> X.

It's fair, as long as the feature is available on free software systems.
But it's obviously good to support the feature on other platforms.

-- 
Akib Azmain Turja

This message is signed by me with my GnuPG key.  It's fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [NonGNU ELPA] New packages: corfu-doc and corfu-doc-terminal

[Stefan Monnier]

[-- Attachment #1: Type: text/plain, Size: 643 bytes --]

Hi,

Akib just suggested we add `corfu-doc` to NonGNU ELPA but it seems like
you have signed the copyright paperwork so we could add it to GNU ELPA.
I think that would be a great addition.
Are you OK with it?

This assumes you'll be careful to make sure future contributors have
signed copyright paperwork as well, and also you'll need to change the
Copyright line in the file (which is a way to state that you consider
this file as covered by the copyright assignment you recently signed).

Also, while I'm here, I attach a patch resulting from my superficial
reading of your code.

Thank you for your contribution to Emacs,


        Stefan

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: corfu-doc.patch --]
[-- Type: text/x-diff, Size: 3837 bytes --]

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000000..39090e0af5
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,3 @@
+*.elc
+/corfu-doc-autoloads.el
+/corfu-doc-pkg.el
diff --git a/corfu-doc.el b/corfu-doc.el
index eed0bbbaaa..014804e4f7 100644
--- a/corfu-doc.el
+++ b/corfu-doc.el
@@ -1,6 +1,6 @@
 ;;; corfu-doc.el --- Documentation popup for Corfu -*- lexical-binding: t -*-
 
-;; Copyright (C) 2021-2022 Yuwei Tian
+;; Copyright (C) 2021-2022  Free Software Foundation, Inc.
 
 ;; Author: Yuwei Tian <ibluefocus@NOSPAM.gmail.com>
 ;; URL: https://github.com/galeo/corfu-doc
@@ -44,14 +44,12 @@
 
 (defcustom corfu-doc-auto t
   "Display documentation popup automatically."
-  :type 'boolean
-  :group 'corfu-doc)
+  :type 'boolean)
 
 (defcustom corfu-doc-delay 0.1
   "The number of seconds to wait before displaying the documentation popup."
   :type 'float
-  :safe #'floatp
-  :group 'corfu-doc)
+  :safe #'floatp)
 
 (defcustom corfu-doc-hide-threshold 0.2
   "Threshold value to hide the documentation popup when browsing candidates.
@@ -60,28 +58,24 @@ When the selected candidate is changed, if the value of `corfu-doc-delay'
 is greater than this threshold value, the documentation popup frame will
 be hided immediately. Else, just clear the doc frame content."
   :type 'float
-  :safe #'floatp
-  :group 'corfu-doc)
+  :safe #'floatp)
 
 (defcustom corfu-doc-max-width 60
   "The max width of the corfu doc frame in characters."
   :type 'integer
-  :safe #'integerp
-  :group 'corfu-doc)
+  :safe #'integerp)
 
 (defcustom corfu-doc-max-height 10
   "The max height of the corfu doc frame in characters."
   :type 'integer
-  :safe #'integerp
-  :group 'corfu-doc)
+  :safe #'integerp)
 
 (defcustom corfu-doc-resize-frame t
   "Non-nil means resize the corfu doc frame automatically.
 
 If this is nil, do not resize corfu doc frame automatically."
   :type 'boolean
-  :safe #'booleanp
-  :group 'corfu-doc)
+  :safe #'booleanp)
 
 (defcustom corfu-doc-display-within-parent-frame nil
   "Display the doc frame within the parent frame.
@@ -100,8 +94,7 @@ still being visible themselves.
 
 Please see \"(elisp) Child Frames\" in Emacs manual for details."
   :type 'boolean
-  :safe #'booleanp
-  :group 'corfu-doc)
+  :safe #'booleanp)
 
 (defvar corfu-doc--frame nil
   "Doc frame.")
@@ -443,12 +436,14 @@ FWIDTH and FHEIGHT."
   :global t
   :group 'corfu
   (cond
-    (corfu-doc-mode
-     (advice-add 'corfu--popup-show :after #'corfu-doc--popup-show)
-     (advice-add 'corfu--popup-hide :after #'corfu-doc--popup-hide))
-    (t
-     (advice-remove 'corfu--popup-show #'corfu-doc--popup-show)
-     (advice-remove 'corfu--popup-hide #'corfu-doc--popup-hide))))
+   (corfu-doc-mode
+    (corfu-doc--manual-popup-show)
+    (advice-add 'corfu--popup-show :after #'corfu-doc--popup-show)
+    (advice-add 'corfu--popup-hide :after #'corfu-doc--popup-hide))
+   (t
+    (corfu-doc--popup-hide)
+    (advice-remove 'corfu--popup-show #'corfu-doc--popup-show)
+    (advice-remove 'corfu--popup-hide #'corfu-doc--popup-hide))))
 
 (defun corfu-doc--popup-support-p ()
   (display-graphic-p))
@@ -528,18 +523,7 @@ corfu doc mode is turned on and `corfu-doc-auto' is set to Non-nil."
     (advice-add 'corfu--popup-show :after #'corfu-doc--popup-show)))
 
 ;;;###autoload
-(defun toggle-corfu-doc-mode (&optional arg)
-  "Toggles corfu doc mode on or off.
-With optional ARG, turn corfu doc mode on if and only if ARG is positive."
-  (interactive "P")
-  (if (null arg)
-      (setq arg (if corfu-doc-mode -1 1))
-    (setq arg (prefix-numeric-value arg)))
-  (if (> arg 0)
-      (corfu-doc--manual-popup-show)
-    (corfu-doc--popup-hide))
-  (corfu-doc-mode arg))
-
+(define-obsolete-function-alias 'toggle-corfu-doc-mode #'corfu-doc-mode "0.7")
 
 (provide 'corfu-doc)
 ;;; corfu-doc.el ends here

Re: [NonGNU ELPA] New packages: corfu-doc and corfu-doc-terminal

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 457 bytes --]


Congratulations, Yuwei Tian.  Your copyright assignment is done.

Now, Yuwei Tian and Daniel Mendler, do you want to add corfu-doc to
Corfu as an extension now?  If so, I think corfu-doc should be published
directly on ELPA as a part of Corfu instead of adding to NonGNU ELPA for
a few days.

-- 
Akib Azmain Turja

This message is signed by me with my GnuPG key.  It's fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [NonGNU ELPA] New packages: corfu-doc and corfu-doc-terminal

[Philip Kaludercic]

Akib Azmain Turja <akib@disroot.org> writes:

> Congratulations, Yuwei Tian.  Your copyright assignment is done.
>
> Now, Yuwei Tian and Daniel Mendler, do you want to add corfu-doc to
> Corfu as an extension now?  If so, I think corfu-doc should be
> published directly on ELPA as a part of Corfu instead of adding to
> NonGNU ELPA for a few days.

Do I misunderstand something, or why is adding corfu-doc to corfu (a GNU
ELPA) package opposed to adding it as a separate package to NonGNU ELPA?

Re: [NonGNU ELPA] New packages: corfu-doc and corfu-doc-terminal

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 931 bytes --]

Philip Kaludercic <philipk@posteo.net> writes:

> Akib Azmain Turja <akib@disroot.org> writes:
>
>> Congratulations, Yuwei Tian.  Your copyright assignment is done.
>>
>> Now, Yuwei Tian and Daniel Mendler, do you want to add corfu-doc to
>> Corfu as an extension now?  If so, I think corfu-doc should be
>> published directly on ELPA as a part of Corfu instead of adding to
>> NonGNU ELPA for a few days.
>
> Do I misunderstand something, or why is adding corfu-doc to corfu (a GNU
> ELPA) package opposed to adding it as a separate package to NonGNU ELPA?

I don't know, its their (Yuwei Tian and Daniel Mendler) plan to do so.
See these (sorry for any nonfree JS):

https://github.com/minad/corfu/issues/103
https://github.com/galeo/corfu-doc/issues/8

-- 
Akib Azmain Turja

This message is signed by me with my GnuPG key.  It's fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [NonGNU ELPA] New packages: corfu-doc and corfu-doc-terminal

[Daniel Mendler]

On 5/28/22 22:31, Akib Azmain Turja wrote:
> Philip Kaludercic <philipk@posteo.net> writes:
> 
>> Akib Azmain Turja <akib@disroot.org> writes:
>>
>>> Congratulations, Yuwei Tian.  Your copyright assignment is done.
>>>
>>> Now, Yuwei Tian and Daniel Mendler, do you want to add corfu-doc to
>>> Corfu as an extension now?  If so, I think corfu-doc should be
>>> published directly on ELPA as a part of Corfu instead of adding to
>>> NonGNU ELPA for a few days.
>>
>> Do I misunderstand something, or why is adding corfu-doc to corfu (a GNU
>> ELPA) package opposed to adding it as a separate package to NonGNU ELPA?
> 
> I don't know, its their (Yuwei Tian and Daniel Mendler) plan to do so.
> See these (sorry for any nonfree JS):
> 
> https://github.com/minad/corfu/issues/103
> https://github.com/galeo/corfu-doc/issues/8

Yes, this will happen eventually if Yuwei is still interested. But there
is no guarantee that this is going to happen soon or in a few days.
Corfu-doc currently comes with its own child frame implementation.
Instead it should make use of the Corfu implementation, which may need
some refactoring such that it can be used also by corfu-doc. This is
important to avoid unnecessary code duplication.

Daniel

Re: [NonGNU ELPA] New packages: corfu-doc and corfu-doc-terminal

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 1713 bytes --]

Daniel Mendler <mail@daniel-mendler.de> writes:

> On 5/28/22 22:31, Akib Azmain Turja wrote:
>> Philip Kaludercic <philipk@posteo.net> writes:
>> 
>>> Akib Azmain Turja <akib@disroot.org> writes:
>>>
>>>> Congratulations, Yuwei Tian.  Your copyright assignment is done.
>>>>
>>>> Now, Yuwei Tian and Daniel Mendler, do you want to add corfu-doc to
>>>> Corfu as an extension now?  If so, I think corfu-doc should be
>>>> published directly on ELPA as a part of Corfu instead of adding to
>>>> NonGNU ELPA for a few days.
>>>
>>> Do I misunderstand something, or why is adding corfu-doc to corfu (a GNU
>>> ELPA) package opposed to adding it as a separate package to NonGNU ELPA?
>> 
>> I don't know, its their (Yuwei Tian and Daniel Mendler) plan to do so.
>> See these (sorry for any nonfree JS):
>> 
>> https://github.com/minad/corfu/issues/103
>> https://github.com/galeo/corfu-doc/issues/8
>
> Yes, this will happen eventually if Yuwei is still interested. But there
> is no guarantee that this is going to happen soon or in a few days.
> Corfu-doc currently comes with its own child frame implementation.
> Instead it should make use of the Corfu implementation, which may need
> some refactoring such that it can be used also by corfu-doc. This is
> important to avoid unnecessary code duplication.
>
> Daniel

It looks like it would take much time to add corfu-doc to corfu.  In the
meanwhile, can we add corfu-doc in GNU ELPA and corfu-doc-terminal to
NonGNU ELPA?

-- 
Akib Azmain Turja

Find me on Mastodon at @akib@hostux.social.

This message is signed by me with my GnuPG key.  It's fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [NonGNU ELPA] New packages: corfu-doc and corfu-doc-terminal

[Philip Kaludercic]

Akib Azmain Turja <akib@disroot.org> writes:

> Daniel Mendler <mail@daniel-mendler.de> writes:
>
>> On 5/28/22 22:31, Akib Azmain Turja wrote:
>>> Philip Kaludercic <philipk@posteo.net> writes:
>>> 
>>>> Akib Azmain Turja <akib@disroot.org> writes:
>>>>
>>>>> Congratulations, Yuwei Tian.  Your copyright assignment is done.
>>>>>
>>>>> Now, Yuwei Tian and Daniel Mendler, do you want to add corfu-doc to
>>>>> Corfu as an extension now?  If so, I think corfu-doc should be
>>>>> published directly on ELPA as a part of Corfu instead of adding to
>>>>> NonGNU ELPA for a few days.
>>>>
>>>> Do I misunderstand something, or why is adding corfu-doc to corfu (a GNU
>>>> ELPA) package opposed to adding it as a separate package to NonGNU ELPA?
>>> 
>>> I don't know, its their (Yuwei Tian and Daniel Mendler) plan to do so.
>>> See these (sorry for any nonfree JS):
>>> 
>>> https://github.com/minad/corfu/issues/103
>>> https://github.com/galeo/corfu-doc/issues/8
>>
>> Yes, this will happen eventually if Yuwei is still interested. But there
>> is no guarantee that this is going to happen soon or in a few days.
>> Corfu-doc currently comes with its own child frame implementation.
>> Instead it should make use of the Corfu implementation, which may need
>> some refactoring such that it can be used also by corfu-doc. This is
>> important to avoid unnecessary code duplication.
>>
>> Daniel
>
> It looks like it would take much time to add corfu-doc to corfu.  In the
> meanwhile, can we add corfu-doc in GNU ELPA and corfu-doc-terminal to
> NonGNU ELPA?

There seems to be no opposition to this idea, I'd just appreciate a
reminder of who has signed the CA and the URLs to the current
repositories (I cannot seem to find everything in my MUA's history).

Re: [NonGNU ELPA] New packages: corfu-doc and corfu-doc-terminal

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 2213 bytes --]

Philip Kaludercic <philipk@posteo.net> writes:

> Akib Azmain Turja <akib@disroot.org> writes:
>
>> Daniel Mendler <mail@daniel-mendler.de> writes:
>>
>>> On 5/28/22 22:31, Akib Azmain Turja wrote:
>>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>> 
>>>>> Akib Azmain Turja <akib@disroot.org> writes:
>>>>>
>>>>>> Congratulations, Yuwei Tian.  Your copyright assignment is done.
>>>>>>
>>>>>> Now, Yuwei Tian and Daniel Mendler, do you want to add corfu-doc to
>>>>>> Corfu as an extension now?  If so, I think corfu-doc should be
>>>>>> published directly on ELPA as a part of Corfu instead of adding to
>>>>>> NonGNU ELPA for a few days.
>>>>>
>>>>> Do I misunderstand something, or why is adding corfu-doc to corfu (a GNU
>>>>> ELPA) package opposed to adding it as a separate package to NonGNU ELPA?
>>>> 
>>>> I don't know, its their (Yuwei Tian and Daniel Mendler) plan to do so.
>>>> See these (sorry for any nonfree JS):
>>>> 
>>>> https://github.com/minad/corfu/issues/103
>>>> https://github.com/galeo/corfu-doc/issues/8
>>>
>>> Yes, this will happen eventually if Yuwei is still interested. But there
>>> is no guarantee that this is going to happen soon or in a few days.
>>> Corfu-doc currently comes with its own child frame implementation.
>>> Instead it should make use of the Corfu implementation, which may need
>>> some refactoring such that it can be used also by corfu-doc. This is
>>> important to avoid unnecessary code duplication.
>>>
>>> Daniel
>>
>> It looks like it would take much time to add corfu-doc to corfu.  In the
>> meanwhile, can we add corfu-doc in GNU ELPA and corfu-doc-terminal to
>> NonGNU ELPA?
>
> There seems to be no opposition to this idea, I'd just appreciate a
> reminder of who has signed the CA and the URLs to the current
> repositories (I cannot seem to find everything in my MUA's history).

Did you want these?

  Author: Yuwei Tian (MELPA says so)
  Repository: https://github.com/galeo/corfu-doc/

-- 
Akib Azmain Turja

Find me on Mastodon at @akib@hostux.social.

This message is signed by me with my GnuPG key.  It's fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [NonGNU ELPA] New packages: corfu-doc and corfu-doc-terminal

[Philip Kaludercic]

Akib Azmain Turja <akib@disroot.org> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> There seems to be no opposition to this idea, I'd just appreciate a
>> reminder of who has signed the CA and the URLs to the current
>> repositories (I cannot seem to find everything in my MUA's history).
>
> Did you want these?
>
>   Author: Yuwei Tian (MELPA says so)
>   Repository: https://github.com/galeo/corfu-doc/

Yes, and from what I understand the main repository for
corfu-doc-terminal is
https://codeberg.org/akib/emacs-corfu-doc-terminal, or is this just a
mirror?  You are the sole contributor, and haven't/can't sign the CA,
right?

Re: [NonGNU ELPA] New packages: corfu-doc and corfu-doc-terminal

[Akib Azmain Turja]

[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]

Philip Kaludercic <philipk@posteo.net> writes:

> Akib Azmain Turja <akib@disroot.org> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>> There seems to be no opposition to this idea, I'd just appreciate a
>>> reminder of who has signed the CA and the URLs to the current
>>> repositories (I cannot seem to find everything in my MUA's history).
>>
>> Did you want these?
>>
>>   Author: Yuwei Tian (MELPA says so)
>>   Repository: https://github.com/galeo/corfu-doc/
>
> Yes, and from what I understand the main repository for
> corfu-doc-terminal is
> https://codeberg.org/akib/emacs-corfu-doc-terminal, or is this just a
> mirror?

No, it's the main repository, and I don't maintain any mirror.

> You are the sole contributor, and haven't/can't sign the CA,
> right?
>

Yes.

-- 
Akib Azmain Turja

Find me on Mastodon at @akib@hostux.social.

This message is signed by me with my GnuPG key.  It's fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [NonGNU ELPA] New packages: corfu-doc and corfu-doc-terminal

[Stefan Monnier]

>   Author: Yuwei Tian (MELPA says so)
>   Repository: https://github.com/galeo/corfu-doc/

FYI: I'm taking care of this one.


        Stefan