From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs terminology (not again!?) Date: Sat, 18 Jan 2014 12:52:52 +0200 Message-ID: <83ppnpk1dn.fsf@gnu.org> References: <877gact76s.fsf@gnu.org> <34c8c13b-c5c6-4e5a-9248-b09d5d1936da@default> <87eh4hkq6c.fsf@fencepost.gnu.org> <52D9E005.6030509@dancol.org> <52D9EEDD.9060109@dancol.org> <83wqhxk7sm.fsf@gnu.org> <874n51y8i6.fsf@fencepost.gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1390042388 25633 80.91.229.3 (18 Jan 2014 10:53:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 18 Jan 2014 10:53:08 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 18 11:53:14 2014 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 1W4TWb-0005kT-Ui for ged-emacs-devel@m.gmane.org; Sat, 18 Jan 2014 11:53:14 +0100 Original-Received: from localhost ([::1]:41915 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W4TWb-0007KW-LU for ged-emacs-devel@m.gmane.org; Sat, 18 Jan 2014 05:53:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34450) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W4TWS-0007K9-Su for emacs-devel@gnu.org; Sat, 18 Jan 2014 05:53:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W4TWN-0008W5-2U for emacs-devel@gnu.org; Sat, 18 Jan 2014 05:53:04 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:59523) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W4TWG-0008VL-OM; Sat, 18 Jan 2014 05:52:52 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MZL00200FAIJ500@a-mtaout22.012.net.il>; Sat, 18 Jan 2014 12:52:51 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MZL002JHFK2FS40@a-mtaout22.012.net.il>; Sat, 18 Jan 2014 12:52:51 +0200 (IST) In-reply-to: <874n51y8i6.fsf@fencepost.gnu.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:168664 Archived-At: > From: David Kastrup > Date: Sat, 18 Jan 2014 09:55:13 +0100 > > > It is a UI design decision in Emacs to always show point on screen. > > But nothing prevents us from writing a mode that leaves point off > > screen, or even abandoning that decision if we want (and I'm not > > saying we do). The infrastructure is there, check out the vscroll > > thingy and window-vscroll. > > That scrolls "graphically" Yes, I don't see how this is important for the issue at hand. On a text terminal, each character counts as a single pixel. > (no idea whether it works on text terminals): It doesn't currently, but that's just because no one bothered to implement that. > basically it displaces your screen window by a given distance. Yes. > There is no concept of a "window start" in terms of a text position > that can move away from point A window start is just a buffer position, so I'm not following your argument here. > and no real way to implement that. ??? Why not? Perhaps you mean no way to implement that easily, or maybe in Lisp alone. > Also I don't think you can mouse-mark a vscrolled off-screen region > (which would require not setting point when drag-marking a region, but > that seems conceivable) and paste it somewhere afterwards. Indeed, exposing such functionality will need a lot of supporting code and features. But that happens with every such endeavor: e.g., when I introduced menus on a TTY, quite a few of the changes I needed were because some places hard-coded the assumption that TTYs cannot possibly have any menus. Simply lifting that condition was all that was needed. > It would be possible to experiment around with some of those things. > Judging from my experience with pre-21.1 code (in connection with > preview-latex), this would lead to quite a number of problem reports, > just because it is an area that has been minimally exercised. Nothing > wrong with that: cleaning out bugs is always a good idea. But it means > that anybody experimenting with user interface design around that > functionality would be well-advised to compile Emacs from Git and be in > close communication with the developer list. Even when "nominally" > Emacs has all the functionality he'll be needing. Very true.