From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: Emacs mode for GDB - 2 questions Date: 01 Jun 2002 02:12:24 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: <5xu1onrh5j.fsf@kfs2.cua.dk> References: <15604.58207.654159.768423@nick.uklinux.net> <200205301705.g4UH54W13563@aztec.santafe.edu> <15606.38559.603367.869040@nick.uklinux.net> <200205312127.g4VLRd915638@aztec.santafe.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1022886712 1040 127.0.0.1 (31 May 2002 23:11:52 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 31 May 2002 23:11:52 +0000 (UTC) Cc: nick@nick.uklinux.net, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17DvYl-0000Ge-00 for ; Sat, 01 Jun 2002 01:11:51 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17DvsG-0007Xq-00 for ; Sat, 01 Jun 2002 01:32:00 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17DvYx-0000Ko-00; Fri, 31 May 2002 19:12:03 -0400 Original-Received: from mail.filanet.dk ([195.215.206.179]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 17DvYc-0000Gr-00; Fri, 31 May 2002 19:11:43 -0400 Original-Received: from kfs2.cua.dk.cua.dk (unknown [10.1.82.3]) by mail.filanet.dk (Postfix) with SMTP id 73C467C017; Fri, 31 May 2002 23:11:40 +0000 (GMT) Original-To: rms@gnu.org In-Reply-To: <200205312127.g4VLRd915638@aztec.santafe.edu> Original-Lines: 69 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:4536 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:4536 Richard Stallman writes: > With a large array, if the top line was in the buffer it would scroll out of > view. I would like to be able to enter the three digits (0,5,2 in this case) > into the header line. > > That feature makes sense well enough, but as I said, it would > be difficult to implement. There are obvious alternative ways to accomplish the same effect (e.g. click on the header-line and use the mini-buffer to enter the numbers). To me that seems like a more logical approach than editing the numbers directly in the header line -- when and how do you then determine what numbers to actually use -- and how do you change, e.g. the 5 to 10? do you delete the 5 first and then enter 1 and 0 (giving 2 interrim data values in the middle field). I'd definitely prefer to use the minibuffer for this kind of input. > > But I have another idea for implementing it. Suppose that line were > actually a separate window, with its mode line disabled, showing just > one line of some buffer. That way you could indeed select it and edit > it as usual. You could make the parts that should not really be edited > read-only. > Such modeline-less windows may be useful for other purposes, so we should try adding them to see what use people can find for them. > This would require a new feature in the C code, but since it would > only affect the setting up of window structure, not redisplay, > it would be far easier. It might actually be feasible. > Yes, I think this would be a fairly trivial change. > We would need to decide on the UI for selection of these special > windows. For the UI, just set mode-line-format to nil to remove the modeline. > > This leads to a further idea. Suppose that every mode line (and every > header line) were actually a separate window, and formatting of mode > line elements was done by converting them into text in a buffer. That > would be elegant in some ways. The usage of memory for this would > be acceptable nowadays. Sounds complicated -- and of limited use. I don't think it is worth the efforts. > > This would make it possible to copy text from a mode line or header > line by dragging the mouse across it, for example. We already has other uses for clicking in and dragging of the modeline. Adding cut and paste to that list makes it more complicated to use. Someone suggested to add a function to get the current mode line contents as a string. With that function, we could make a "hot-spot" in the modeline (e.g. click mouse-3 on the buffer name) to copy it to the kill-ring. For the rare cases where you need to get the mode line contents, I think that would be an acceptable solution. > > What do people think? > I like the idea of modeline-less windows, but the idea of using buffers to format the mode line seems like overkill to me.