From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Patch to highlight current line number [nlinum.el] Date: Mon, 18 Jul 2016 13:09:10 -0400 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1468862712 4431 80.91.229.3 (18 Jul 2016 17:25:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 18 Jul 2016 17:25:12 +0000 (UTC) Cc: code.falling@gmail.com, Emacs developers To: Kaushal Modi Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 18 19:25:04 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bPCHv-00088d-Hr for ged-emacs-devel@m.gmane.org; Mon, 18 Jul 2016 19:25:03 +0200 Original-Received: from localhost ([::1]:49175 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPCHu-0000W0-Dd for ged-emacs-devel@m.gmane.org; Mon, 18 Jul 2016 13:25:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44624) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPC0V-0006iJ-EB for emacs-devel@gnu.org; Mon, 18 Jul 2016 13:07:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bPC0Q-0006wh-AU for emacs-devel@gnu.org; Mon, 18 Jul 2016 13:07:02 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:56865) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPC0Q-0006wL-3N for emacs-devel@gnu.org; Mon, 18 Jul 2016 13:06:58 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BLFgA731xV/3mcpUVcgxBUXoJQhVW9FoV1BAICgTw9EAEBAQEBAQGBCkEFg10BAQMBViMFCws0EhQYDSQuiAkIzyMBAQEHAgEfizqFBQeELQWQNI5jhmmHLWSFLoFFI4IKHIFuIjEBgkYBAQE X-IPAS-Result: A0BLFgA731xV/3mcpUVcgxBUXoJQhVW9FoV1BAICgTw9EAEBAQEBAQGBCkEFg10BAQMBViMFCws0EhQYDSQuiAkIzyMBAQEHAgEfizqFBQeELQWQNI5jhmmHLWSFLoFFI4IKHIFuIjEBgkYBAQE X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="248407022" Original-Received: from 69-165-156-121.dsl.teksavvy.com (HELO ceviche.home) ([69.165.156.121]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Jul 2016 13:06:56 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 8AF62662FA; Mon, 18 Jul 2016 13:09:10 -0400 (EDT) In-Reply-To: (Kaushal Modi's message of "Mon, 18 Jul 2016 15:28:04 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:205817 Archived-At: > I see what you mean. I tried that. If I wanted to do something like that, > C-x 4 c (indirect buffer cloning) seems like a good solution. Indirect buffers are very messy. They work fine until they don't. >> Sorry, the problem didn't jump at me. They look pretty good. > Do you mean that the commented code to remove text properties from > last/current lines should have worked? Yes. Well not "should have worked" but more "can't see any obvious reason why it wouldn't do the right thing". > Here is a longish gif video (1 min 20 secs) demonstrating the issue I see > when removing text properties from the whole visible window vs just > curr+last lines: http://i.imgur.com/GN3zTlJ.gifv It looks like the (remove-text-properties last-line-beg last-line-end '(fontified)) doesn't do its job, indeed. AFAICT it seems to work correctly when moving down but not when moving up, so maybe it's just an off-by-one error somewhere. BTW, Elisp generally works better with positions than with line numbers. Is there a particular reason why you keep the nlinum--current-* (which I think of nlinum--last-*) as a line-number rather than as a buffer-position (probably a marker), or is it just how it turned out? I'm asking because I'm thinking that without using markers it could prove tricky to de-highlight the right line-number after buffer modifications (since it could still say "line 178" for a little while (e.g. jit-lock-context-time) while it's actually now the 200th line). So I think a marker might work better. >> > +(defvar-local nlinum--last-line 0 >> > + "Store line number where the point was before it moved to the current >> > line.") >> No reason to keep this as a global var (but I'd rename >> nlinum--current-line to nlinum--last-line). > Correct. nlinum--last-line does not need to be a defvar; I have now made it > a let-bound var. Thanks. > I did not understand why nlinum--current-line should be renamed as > nlinum--last-line; because that var is storing the current line number > and we are using that to highlight the current line number. Its usefulness as a global variable runs from the end of a call to nlinum--current-line-update to the beginning of the next. During that time it holds the line-number that was current in the last call. >> +(defun nlinum--current-line-update () >> > + "Update current line number, flush text properties for last and current >> > line." >> Actually, it shouldn't (and doesn't) flush text-properties. It should >> only update the current-line highlighting or cause it to be >> updated later. > I did not understand this too. I refer to the remove-text-properties action > as "flushing". That's an internal detail of how it works and if we change it to work differently there's no reason to think that it would affect the callers, so it needn't be documented in the docstring. And of course it doesn't "flush text properties": it flushes one particular property (this nitpick is actually the detail that made me re-read the docstring and think harder about what it said ;-). Stefan