From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Line height issues with display-line-number-mode Date: Wed, 08 May 2019 11:04:57 -0400 Message-ID: References: <6fd496f0-7dd5-6c0e-5121-b618e7dca831@gmail.com> <83sgtqi02k.fsf@gnu.org> <83r29ahyz2.fsf@gnu.org> <83pnouhwxs.fsf@gnu.org> <83ef59igzc.fsf@gnu.org> <83tve5ghyd.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="206340"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Eli Zaretskii , Emacs developers To: Noam Postavsky Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 08 17:05:48 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 1hOO8g-000rY0-Ll for ged-emacs-devel@m.gmane.org; Wed, 08 May 2019 17:05:46 +0200 Original-Received: from localhost ([127.0.0.1]:38748 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hOO8f-0002DU-I4 for ged-emacs-devel@m.gmane.org; Wed, 08 May 2019 11:05:45 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:35849) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hOO7w-0001nM-HH for emacs-devel@gnu.org; Wed, 08 May 2019 11:05:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hOO7v-0005VZ-FY for emacs-devel@gnu.org; Wed, 08 May 2019 11:05:00 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:47347) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hOO7v-0005VH-AH; Wed, 08 May 2019 11:04:59 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id x48F4vjT013841; Wed, 8 May 2019 11:04:57 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 23F776ABF4; Wed, 8 May 2019 11:04:57 -0400 (EDT) In-Reply-To: (Noam Postavsky's message of "Wed, 8 May 2019 10:13:36 -0400") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6542=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6542> : inlines <7074> : streams <1820937> : uri <2841980> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 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:236294 Archived-At: > We tried this in magit, getting the line to extend to the edge of the > window is not so obvious. But we did get something working in the end. > Here it is as a patch against describe-symbol: > > --- i/lisp/help-fns.el > +++ w/lisp/help-fns.el > @@ -1257,7 +1257,17 @@ describe-symbol > (progn (skip-chars-backward " \t\n") (point))) > (insert "\n\n" > (eval-when-compile > - (propertize "\n" 'face '(:height 0.1 :inverse-video t))) > + (propertize > + "\n" 'face '(:underline t) > + 'display `(space > + :align-to > + (+ (0 . right) > + ,(min (window-hscroll) > + (- (line-end-position) > + (line-beginning-position))))) > + ;; This prevents the cursor from being rendered at the > + ;; edge of the window. > + 'cursor t)) That align-to computation looks brittle (and still incorrect, I think) and it hardcodes into the text-property a value which can change later (window-hscroll), so it's rather problematic. Also, in the case of *vc-log* this would basically turn the "0.1" thick black line into a thinner black line with a thicker "white" line above, and that white line looks a bit odd there. I guess strike-through would look a bit better. So, I'm not sure it's a good alternative (both in terms of code and in terms of aesthetics) for log-edit-mode. Stefan