From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Wayne Harris via Users list for the GNU Emacs text editor Newsgroups: gmane.emacs.help Subject: on interface and behavior (Was: Re: indentation) Date: Thu, 29 Apr 2021 18:38:08 -0300 Message-ID: <86h7jo4vr3.fsf_-_@protonmail.com> References: <20210427090348.67C9B5D0@centrum.cz> <20210427202932.DFDEF50D@centrum.cz> <20210428083227.FCFDA7C0@centrum.cz> <20210429091455.3C8C08A9@centrum.cz> <875z056uf6.fsf@zoho.eu> Reply-To: Wayne Harris Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13151"; mail-complaints-to="usenet@ciao.gmane.io" To: help-gnu-emacs@gnu.org Cancel-Lock: sha1:2whJ7XjBSuLprYxqFctU1k88l7I= Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Thu Apr 29 23:39:06 2021 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lcENG-0003Ie-Kj for geh-help-gnu-emacs@m.gmane-mx.org; Thu, 29 Apr 2021 23:39:06 +0200 Original-Received: from localhost ([::1]:35074 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lcENF-0004iI-Or for geh-help-gnu-emacs@m.gmane-mx.org; Thu, 29 Apr 2021 17:39:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60844) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lcEMa-0004h8-7K for help-gnu-emacs@gnu.org; Thu, 29 Apr 2021 17:38:25 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]:53514) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lcEMW-0008NO-MK for help-gnu-emacs@gnu.org; Thu, 29 Apr 2021 17:38:23 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1lcEMT-00029f-FO for help-gnu-emacs@gnu.org; Thu, 29 Apr 2021 23:38:17 +0200 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=geh-help-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:129195 Archived-At: Emanuel Berg via Users list for the GNU Emacs text editor writes: > Stefan Monnier wrote: > >> More seriously, this does not necessarily require "smarts": >> in some (many?) projects, the coding conventions says >> precisely how indentation should be done, so there is no >> "smartness" involved and if you don't like what the >> auto-indentation does, either it's because of a bug in the >> code, or it's because you disagree with the conventions (and >> overriding the conventions should be rare). > > That's exactly right, set up the technology to do the routine > stuff and only where it matters you apply your own creativity > and brilliance so it will be put into just the right place :) > > Some people say Emacs is all about automation, other say pro > programmers are so productive with Emacs it is amazing, yet > other say Emacs makes you so creative virtually nothing ever > gets done... > > But actually I think one should instead think of all that as > positive entities that work _together_, and not at > all orthogonally. Or at the very least it doesn't HAVE to be > like that! > > Like the Greek poets and drama writers of the ancient world, > they had tons of formal rules, methods, a whole scientific > approach to their craft and art, with terminology and > everything. But as it happens, knowing all that was not > a limitation, on the contrary it OPENED the doors of > inspiration and creativity. And made it more fun and > interesting while doing it, I'm sure! > > So greetings from Sweden to all Emacs hackers all around the > world, I'll do my best to return to Elisp myself as soon as > possible God willing. I'm for all that. However, I think in terms of user interface and software behavior we should consider the following conjecture. --8<---------------cut here---------------start------------->8--- Conjecture. Computer systems should pleasurable to use. In the work and programming context, a pleasure-to-use system is one where the users gets a sense of precise control. The user should be able to predict where a window will show up and what's gonna happen to the text once s/he presses RET, say. --8<---------------cut here---------------end--------------->8--- (*) The case of frames in Windows Speaking of which, FWIW, I have gone through extra lengths to try to get frames to show up more consistently on Windows. Windows has no reasonable window manager, so that's left for the applications themselves. Most windows programs save their window sizes and position before quitting and restore when they come back alive. The GNU Emacs does not. I was constantly moving my initial frame to the right and I often create new frames and they insist on showing up more towards the left side of the my screen, so I like the initial frame on the right. I'm happy now with command-line --geometry -0 -fh -fn my-favorite-font. However, I must still (add-to-list 'initial-frame-alist '(height . fullheight)) (add-to-list 'default-frame-alist '(height . 0.91)) or new frames are larger than the initial frame because of the font I choose. (Due to fonts, the problem doesn't seem trivial.) I would appreciate --- as a default behavior --- the GNU Emacs on Windows remembering the size and position of the window before shuting down. (*) The documentation of initial-frame-alist could mention --geometry Elsewhere I learned about the full syntax of --geometry. The documentation of initial-frame-alist misses an opportunity to mention --geometry: --8<---------------cut here---------------start------------->8--- initial-frame-alist is a variable defined in ‘frame.el’. [...] Documentation: Alist of parameters for the initial X window frame. You can set this in your init file; for example, (setq initial-frame-alist '((top . 1) (left . 1) (width . 80) (height . 55))) Parameters specified here supersede the values given in ‘default-frame-alist’. [...] You can specify geometry-related options for just the initial frame by setting this variable in your init file; however, they won’t take effect until Emacs reads your init file, which happens after creating the initial frame. If you want the initial frame to have the proper geometry as soon as it appears, you need to use this three-step process: * Specify X resources to give the geometry you want. * Set ‘default-frame-alist’ to override these options so that they don’t affect subsequent frames. * Set ‘initial-frame-alist’ in a way that matches the X resources, to override what you put in ‘default-frame-alist’. [back] --8<---------------cut here---------------end--------------->8--- One last bullet could mention the full syntax of --geometry. Maybe --help could as well: it doesn't. (*) A suggested approach for Windows I believe the problem could be solved for Windows specifically by restoring the size and position of the initial-frame in w32-win.el. Of course, the size and position should be saved before exit. --8<---------------cut here---------------start------------->8--- (cl-defmethod window-system-initialization (&context (window-system w32) &optional _display) "Initialize Emacs for W32 GUI frames." (cl-assert (not w32-initialized)) ;; Do the actual Windows setup here; the above code just defines ;; functions and variables that we use now. (setq command-line-args (x-handle-args command-line-args)) [...] (x-open-connection "w32" x-command-line-resources ;; Exit with a fatal error if this fails and we ;; are the initial display (eq initial-window-system 'w32)) [...] ;; Apply a geometry resource to the initial frame. Put it at the end ;; of the alist, so that anything specified on the command line takes ;; precedence. (let* ((res-geometry (x-get-resource "geometry" "Geometry")) parsed) (if res-geometry (progn (setq parsed (x-parse-geometry res-geometry)) ;; If the resource specifies a position, ;; call the position and size "user-specified". (if (or (assq 'top parsed) (assq 'left parsed)) (setq parsed (cons '(user-position . t) (cons '(user-size . t) parsed)))) ;; All geometry parms apply to the initial frame. (setq initial-frame-alist (append initial-frame-alist parsed)) ;; The size parms apply to all frames. (if (and (assq 'height parsed) (not (assq 'height default-frame-alist))) (setq default-frame-alist (cons (cons 'height (cdr (assq 'height parsed))) default-frame-alist)) (if (and (assq 'width parsed) (not (assq 'width default-frame-alist))) (setq default-frame-alist (cons (cons 'width (cdr (assq 'width parsed))) default-frame-alist))))))) --8<---------------cut here---------------end--------------->8---