From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: Line number in mode-line with column-number-mode on in GNU Emacs 23.x Date: Fri, 25 Dec 2009 16:46:10 +0200 Message-ID: <83fx6z5cy5.fsf@gnu.org> References: <4B974CC3-BEDC-4F8A-BF11-89D641233662@Web.DE> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1261752305 1890 80.91.229.12 (25 Dec 2009 14:45:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 25 Dec 2009 14:45:05 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Dec 25 15:44:58 2009 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NOBPV-0004U3-Ru for geh-help-gnu-emacs@m.gmane.org; Fri, 25 Dec 2009 15:44:58 +0100 Original-Received: from localhost ([127.0.0.1]:50806 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NOBPV-0006OE-Sq for geh-help-gnu-emacs@m.gmane.org; Fri, 25 Dec 2009 09:44:57 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NOBP9-0006O1-PY for help-gnu-emacs@gnu.org; Fri, 25 Dec 2009 09:44:35 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NOBP4-0006NY-8F for help-gnu-emacs@gnu.org; Fri, 25 Dec 2009 09:44:34 -0500 Original-Received: from [199.232.76.173] (port=51616 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NOBP4-0006NV-2I for help-gnu-emacs@gnu.org; Fri, 25 Dec 2009 09:44:30 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:42498) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NOBP3-0006yG-IY for help-gnu-emacs@gnu.org; Fri, 25 Dec 2009 09:44:29 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0KV700300Q56CX00@a-mtaout20.012.net.il> for help-gnu-emacs@gnu.org; Fri, 25 Dec 2009 16:43:52 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.127.236.58]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KV7000TYQ93ZVB0@a-mtaout20.012.net.il> for help-gnu-emacs@gnu.org; Fri, 25 Dec 2009 16:43:52 +0200 (IST) In-reply-to: <4B974CC3-BEDC-4F8A-BF11-89D641233662@Web.DE> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by monty-python.gnu.org: Solaris 10 (beta) X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:70857 Archived-At: > From: Peter Dyballa > Date: Fri, 25 Dec 2009 11:51:58 +0100 > > In compilation mode it happens that the line number is substituted to > "??" although I've set line-number-display-limit to nil, i.e., GNU > Emacs should not stop counting. I also set line-number-display-limit- > width (first) to 625, although some lines can be as long as a few > 10,000 characters (later set to 62,500, but no change). The code seems to remember that a window had long lines, and once that happens, this window will not have line numbers, until you switch to another buffer. Is that your case -- that you enlarged line-number-display-limit-width only _after_ you saw "??" instead of a line number? If so, does it help to switch to a different buffer and then switch back to the original one in the same window? Failing that, I don't see any explanation for what you report. Perhaps try stepping with a debugger through decode_mode_spec, or submit a bug report with a clear recipe to reproduce this behavior. > Is there a way to force display of the line number? I don't see one, except enlarging line-number-display-limit-width to a very large number (but not too large -- Emacs multiplies it by about 100 (depending on your window height), and if the result overflows, you get the opposite of what you wanted. Maybe we should allow nil as a value, meaning unlimited line width. > Is it suppressed because of duration of high CPU load? This code runs during redisplay, so it's not a good idea for it to be too slow. But I never profiled this, so I have no idea if it really can be slow for long lines.