From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Ergus Newsgroups: gmane.emacs.devel Subject: Re: Fill column indicator functionality Date: Mon, 11 Mar 2019 11:48:14 +0100 Message-ID: <20190311104814.kp2nv6arv47hcykz@Ergus> References: <8736p0nznz.fsf@tcd.ie> <837eebsmaj.fsf@gnu.org> <87sgwvco1l.fsf@Ergus.i-did-not-set--mail-host-address--so-tickle-me> <83r2cel3qf.fsf@gnu.org> <20190211165636.ch5x4wb2ibdt2dzy@Ergus> <83ef8el03u.fsf@gnu.org> <20190308185744.a4vnfoab5wdvqyny@Ergus> <83y35p871q.fsf@gnu.org> <20190309132207.w2ho3j6p5on6fyzw@Ergus> <838sxo87gc.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="38126"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: NeoMutt/20180716 Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 11 11:59:03 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 1h3Ie7-0009ol-6t for ged-emacs-devel@m.gmane.org; Mon, 11 Mar 2019 11:59:03 +0100 Original-Received: from localhost ([127.0.0.1]:59578 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h3Ie6-0006Ln-3l for ged-emacs-devel@m.gmane.org; Mon, 11 Mar 2019 06:59:02 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:42625) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h3Ids-00065J-V2 for emacs-devel@gnu.org; Mon, 11 Mar 2019 06:58:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h3ITl-0005N0-12 for emacs-devel@gnu.org; Mon, 11 Mar 2019 06:48:21 -0400 Original-Received: from sonic302-20.consmr.mail.ir2.yahoo.com ([87.248.110.83]:46620) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h3ITk-0005Lx-Nj for emacs-devel@gnu.org; Mon, 11 Mar 2019 06:48:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1552301299; bh=a4JkfHiDuigjOztN4jeDpr6AYh+zMsFSypfXwQRBJmE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=TkeW/MFHFchQAzhIMbRXvqnxD59/AjoCYHmfol6Wm0RCp7/z5OzuJlXjEKLLjdvFxsG0Kn9poEPZht8ig/hzqoGFskdszmZSj3av0hfXxHae2ZlFZIwn9KdOPtjzF+gcn0iq61s60KZBnbPfJ48iaQpMSTNLmzC6KmLtSJw64OosazkHsKc/IutONl5kXeuEcnvieQ25ZyU4Ol/dSGBXXKjODUxo/CaviZ1xjwkDCvY+6xbqMzpdFuHDphJ9rpP9Kpyy7+0Pqkwt2g//Ecm7gr67qIiEJisPR9lRYW7AkYvIKKx4WL2snLGrtbFfz6yK3tvwUpENotbRlP2JgqSv0Q== X-YMail-OSG: K8TsEIsVM1ln1cgyTyeva1qH0NvS5U462jSJsQMrzIDjn9r_4g.PSacIIh6L5vc jPUHniCNxejbB59MtGGwMv6Y7df684uFOFJhOhi4llji324I3EW26yRKGfEQRlD0ngWZ5FNVTtOI N_F1q_eaOlGpsjdxnnkPdEWDOmQzuHZY6Ap9sxqFAAum6ACehNBnhtB3ikM0ZpLcLCTnrqWO8wK7 E4KgYh4BGAudCzhYX8XeMfo0YJ6KoCGvRf7L0Q5hEIKT7OY4Ah72AfNYU0fZQigThBf2h8TZAnVA tXUQZmJ3F41V5B2l5jIqlc8D1TgEblcFT6cK3EafhXj_n6zF6U.2OL5PhfJhXb5Keij2PyVoKQVX Fh7QO9xJcyJkmmEV.mK3DI0dxU9s3Pq3r4q8KIbq3Oz0M7WTT9jChx1v765uC.H_xtuy.thrTq4o O1874n7gTaD2OwJ.oRbUt6OKTIuM9okVIVPnXEyDP4mWveOdDZVSkvJbcAj8ANYoUx2nnZ1WEWUG l8xtBtBJPWTebJ7MYq32Kc0vviafeA6ZQxTjALkbV.alyPY.J4AMb82ZwQ3W8gY.2gMqU6ywCa8e lxZ_ro_t0ncOJQsA69r3.KivYeJeoSfTbLPvTF3vYFyF2RaENSx_LpvfS2oG6U8EOtOpQpvuz7ID q7eJXfAAAmE4TkHKJKvOd.dQng.4r2FYbeDBpjvCjkIY3hR6Z16.95d0cnRoTy0G4miiYOXjLuQF mOcwZoqRAaM9wE0OMTvIWYQiZc6CLjcXwT1LjUr6yaIUGaQFsd9FcNsfyny93MJEei21N4uSOM_D Y7zvcw87nElbKESQVqFVwKGynHUXfy_CDVSw6wAUzm Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ir2.yahoo.com with HTTP; Mon, 11 Mar 2019 10:48:19 +0000 Original-Received: from 84.88.54.69 (EHLO Ergus) ([84.88.54.69]) by smtp424.mail.ir2.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 157e5534401bee7195ed4c169a1adad8; Mon, 11 Mar 2019 10:48:16 +0000 (UTC) Content-Disposition: inline In-Reply-To: <838sxo87gc.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 87.248.110.83 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:234063 Archived-At: Hi again: I have a simple version for the column indicator line. There are still missing functionalities like R2L or multiple columns indicator implementations, but I don't want to go very complex on this in the first try. I have 2 questions: 1) In the graphical implementation I generated the column following the Eli suggestions with something like: struct font *font = face->font ? face->font : FRAME_FONT (f); it->char_to_display = '|'; int stretch_ascent = (((it->ascent + it->descent) * FONT_BASE (font)) / FONT_HEIGHT (font)); memset (&it->position, 0, sizeof it->position); it->avoid_cursor_p = true; it->face_id = merge_faces (it->w, Qline_number, 0, DEFAULT_FACE_ID); it->start_of_box_run_p = false; append_stretch_glyph (it, Qnil, width, it->ascent + it->descent, stretch_ascent); PRODUCE_GLYPHS (it); it->position = saved_pos; it->avoid_cursor_p = saved_avoid_cursor; it->face_id = saved_face_id; it->start_of_box_run_p = saved_box_start; it->char_to_display = saved_char; The problem is that in this case if (setq show-trailing-whitespace t) the whitespaces aren't highlighted if they are not longer that the line; in term mode (with the loop) it works fine. The function highlight_trailing_whitespace checks for glyph->type == STRETCH_GLYPH so I am missing something. 2) What name do you suggest for this mode? I propose display-column-indicator. Thanks in advance. Ergus On Sat, Mar 09, 2019 at 04:10:11PM +0200, Eli Zaretskii wrote: >> Date: Sat, 9 Mar 2019 14:22:09 +0100 >> From: Ergus >> Cc: emacs-devel@gnu.org >> >> >You are on the right track. But I'd suggest to do this inside the >> >function extend_face_to_end_of_line. It is called near that label, >> >but you will see that it's called in several more places; I expect at >> >least some of them to need the same changes. >> > >> Hi Eli, I just finished a working version (pretty simple as a proof of >> concept). That works in terminal mode. But in graphical mode we should >> look for another approach because extend_face_to_end_of_line returns in: >> >> if (FRAME_WINDOW_P (f) >> && MATRIX_ROW_DISPLAYS_TEXT_P (it->glyph_row) >> && face->box == FACE_NO_BOX >> && FACE_COLOR_TO_PIXEL (face->background, f) == FRAME_BACKGROUND_PIXEL (f) >> #ifdef HAVE_WINDOW_SYSTEM >> && !face->stipple >> #endif >> && !it->glyph_row->reversed_p) >> return; >> >> So it don't write until the line end. > >Yes, you need to add one more condition to that 'if', so that it >doesn't return when this feature is in effect. > >> In graphical mode maybe it is better to do this change writing directly >> a vertical line in the windows' frame background. > >I don't think we can do this in Emacs, the background is just a color >for us. > >> That way it will be maybe more efficient because we only do it >> once. > >If it were possible, it still could not be done once, because every >redisplay would have to redraw it. > >> But I don't know if this is possible-recommended. > >It's not possible with what we have in Emacs today. > >> BTW: Is it possible to generate a single wider glyph instead of doing a >> loop?. > >Yes, of course: you produce a single stretch glyph of a suitable >width. Look at what the code does in the "row->reversed_p" case. > >> >Which data structures? there are quite a few of them, so please be >> >more specific. >> > >> glyph <-> it: why this looks so complex? > >For 2 main reasons: > > . the 'it' structure needs to keep track of several state variables, > which affect more than one glyph, and it needs to do that without > relying on the glyphs, because sometimes these functions are > called with it->glyph_row set to NULL (when we need to simulate > display without displaying anything, see move_it_to > > . the 'it' structure instance is discarded once the glyphs are > produced, so if we need to record information about the glyphs, we > need to keep it with the glyphs themselves > >> Because "it" has too many properties I can't understand their >> functionalities and sometimes I think I could reinvent the wheel. > >The comments in dispextern.h should help. If they are not enough, we >can add more comments, but you need to point out the missing >information. >