Eli Zaretskii writes: >> From: Akib Azmain Turja >> Cc: Eli Zaretskii , 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