From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Fill column indicator functionality Date: Fri, 15 Mar 2019 16:24:23 +0200 Message-ID: <83va0kz04o.fsf@gnu.org> References: <20190309132207.w2ho3j6p5on6fyzw@Ergus> <838sxo87gc.fsf@gnu.org> <20190311104814.kp2nv6arv47hcykz@Ergus> <83y35l4ee0.fsf@gnu.org> <20190312152928.73o4b5fk4paz7wm5@Ergus> <834l883w15.fsf@gnu.org> <20190312192017.fkfd4h5gsbdue5q3@Ergus> <83imwm3fxf.fsf@gnu.org> <20190313200225.dpqrw7xthkj47fqw@Ergus> <83bm2e35a1.fsf@gnu.org> <20190314030224.l5zseslncw3xc5ox@Ergus> <835zsm2c2s.fsf@gnu.org> <303612d8-e691-f753-84c9-f462d88262b6@gmail.com> <83d0ms1to4.fsf@gnu.org> <32B82860-3C7D-41CC-BD2F-8114BBA170B8@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="59256"; mail-complaints-to="usenet@blaine.gmane.org" Cc: alp.tekin.aker@gmail.com, emacs-devel@gnu.org To: Mattias =?utf-8?Q?Engdeg=C3=A5rd?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 15 15:34:32 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h4nup-000FJN-Tq for ged-emacs-devel@m.gmane.org; Fri, 15 Mar 2019 15:34:32 +0100 Original-Received: from localhost ([127.0.0.1]:56263 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h4nuo-0001jN-N4 for ged-emacs-devel@m.gmane.org; Fri, 15 Mar 2019 10:34:30 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:46669) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h4nlO-0002nl-MR for emacs-devel@gnu.org; Fri, 15 Mar 2019 10:24:47 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:41193) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h4nlN-0008JT-VK; Fri, 15 Mar 2019 10:24:46 -0400 Original-Received: from [176.228.60.248] (port=1936 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h4nlN-00058G-28; Fri, 15 Mar 2019 10:24:45 -0400 In-reply-to: <32B82860-3C7D-41CC-BD2F-8114BBA170B8@acm.org> (message from Mattias =?utf-8?Q?Engdeg=C3=A5rd?= on Fri, 15 Mar 2019 14:30:55 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:234159 Archived-At: > From: Mattias Engdegård > Date: Fri, 15 Mar 2019 14:30:55 +0100 > Cc: emacs-devel > > Terminal emulators often treat box-drawing characters specially, either drawing the lines themselves or extending parts of the glyphs in case there would be gaps. Even XTerm does this, mainly to supplement missing glyphs. > > Being its own terminal emulator, Emacs could do the same to avoid gaps in horizontal and vertical lines that should connect. Unfortunately, this is not currently possible, not without significant changes in how the Emacs display engine works internally. The display routines are currently called in a way that doesn't allow them to have a window-global view of the display, not even a way of knowing what's on the previous and the next screen lines. In fact, the display routines need to do their job even if the information about the layout of adjacent screen lines is not available at all, and redisplay optimizations frequently make use of this property, by starting a new redisplay cycle on a specific line, doing part of the layout, then throwing out the results. About the only thing the display routines can rely on is the window-start point and the window pixel dimensions. Even the vertical coordinate of a line on which the display routine was called is frequently unknown. > The details are fairly window-system-specific but do not have to be implemented everywhere at once. I don't think I understand what you are saying here. My point was that we have xfns.c/xterm.c for X, w32fns.c/w32term.c for w32, and nsfns.m/nsterm.m for NS. Any line drawing that doesn't end up as part f some glyph must be implemented in each of these back-ends, because the APIs used for such drawing are different.