From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: What improvements would be truly useful? Date: Tue, 06 Mar 2018 19:08:05 +0200 Message-ID: <83zi3lqgi2.fsf@gnu.org> References: <87inaiss6l.fsf@web.de> <6FCF6ACA-4F29-4B6B-BE9D-D7130C6E9495@gnu.org> <87fu5moe4c.fsf@web.de> <877eqyocro.fsf@web.de> <83zi3uz4nb.fsf@gnu.org> <0b1dd3fa-e0b0-ed20-a256-dd92d1c1826f@dancol.org> <8bc3c4c7-dfc7-987a-95e7-bd309e2326c6@cs.ucla.edu> <03118DC0-39DA-4AB5-980E-A33809B9A5EE@raeburn.org> <86578165-1b41-e75c-7180-84d8edefc44b@grinta.net> <83o9k2s4xw.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1520356023 5440 195.159.176.226 (6 Mar 2018 17:07:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 6 Mar 2018 17:07:03 +0000 (UTC) Cc: daniele@grinta.net, emacs-devel@gnu.org To: Yuri Khan Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 06 18:06:58 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1etG3B-0000Ek-JD for ged-emacs-devel@m.gmane.org; Tue, 06 Mar 2018 18:06:53 +0100 Original-Received: from localhost ([::1]:57104 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1etG5E-0005iL-AJ for ged-emacs-devel@m.gmane.org; Tue, 06 Mar 2018 12:09:00 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47623) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1etG4Z-0005g4-GG for emacs-devel@gnu.org; Tue, 06 Mar 2018 12:08:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1etG4V-00081L-FD for emacs-devel@gnu.org; Tue, 06 Mar 2018 12:08:19 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51487) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1etG4V-00081G-Bq; Tue, 06 Mar 2018 12:08:15 -0500 Original-Received: from [176.228.60.248] (port=1956 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1etG4U-0006h9-RS; Tue, 06 Mar 2018 12:08:15 -0500 In-reply-to: (message from Yuri Khan on Tue, 6 Mar 2018 14:48:39 +0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:223346 Archived-At: > From: Yuri Khan > Date: Tue, 6 Mar 2018 14:48:39 +0700 > Cc: Daniele Nicolodi , Emacs developers > > One architectural decision that I would call baroque is the input model. Then we have different interpretations of what "architecture" means in this context. To me, architecture of a program such as Emacs is its model-view-controller structure, the single-threaded operation, etc. Input model is a lower-level design and implementation layer. > In Emacs, the input model is that of the character terminal: the input > is a sequence of characters. The repertoire of Unicode characters is > extended with special values for function and editing keys, and for > keys modified with Ctrl, Super, Hyper, and Shift where necessary (and > Meta is represented as an ESC prefix), but still it is a sequence of > characters without explicit ties to the keys. Even mouse clicks are > processed as a special kind of characters. Unless I misunderstand what you mean by "character", the above is simply not true. In Emacs, input is a stream of events. Several kinds of events are supported, see enum event_kind in termhooks.h. Only some of them are characters, most are not. The relevant variable in keyboard.c is frequently called 'c', so one could think it's a character, but in fact it is a Lisp object, and can be anything. In particular, a mouse click doesn't look at all like a character, it is actually a cons cell. > This is inevitable when running in a terminal emulator where the > underlying abstraction works this way, but in a GUI build this leads > to inability to distinguish, for example, the ‘.’ character as coming > from the bottom-row right ring finger in US English layout, or from > the bottom-row right pinky in Russian layout, or from the decimal > separator key on the keypad. That is a different issue, unrelated to what kind of input events are recognized and how they are represented. Emacs does support function keys on X and other GUI environments, so it could potentially support any abstraction for keys, if the underlying GUI APIs allow that on the X message level. We even install a low-level keyboard hook on Windows to salvage some of the keys that Windows insists on intercepting ahead of the application. IOW, I see no architectural limitations here, only implementation that might be missing or hard to come up with. > Another example was described in Daniel Colascione’s article/rant > “Buttery Smooth Emacs”. Daniel's blog is a good read for someone who is familiar with the internals, but I don't recommend to form your opinions about the Emacs internals and their problems based solely on that blog. For starters, some of what is written there is no longer true these days.