From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: hw Newsgroups: gmane.emacs.devel Subject: Re: Some developement questions Date: Sat, 25 Aug 2018 03:31:18 +0200 Organization: my virtual residence Message-ID: <871sanb71j.fsf@himinbjorg.adminart.net> References: <444779489.8504194.1534538988289.ref@mail.yahoo.com> <444779489.8504194.1534538988289@mail.yahoo.com> <83sh3cfb3t.fsf@gnu.org> <87sh36inql.fsf@himinbjorg.adminart.net> <8336v6cvem.fsf@gnu.org> <8736v6icgt.fsf@himinbjorg.adminart.net> <83tvnmb958.fsf@gnu.org> <877ekigiiw.fsf@himinbjorg.adminart.net> <837ekhb2me.fsf@gnu.org> <87zhxcbmtr.fsf@himinbjorg.adminart.net> <83in409lub.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1535160769 11866 195.159.176.226 (25 Aug 2018 01:32:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 25 Aug 2018 01:32:49 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cc: spacibba@aol.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 25 03:32:45 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 1ftNRS-0002wM-J1 for ged-emacs-devel@m.gmane.org; Sat, 25 Aug 2018 03:32:42 +0200 Original-Received: from localhost ([::1]:44233 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ftNTY-00079v-Ke for ged-emacs-devel@m.gmane.org; Fri, 24 Aug 2018 21:34:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44628) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ftNSt-00079l-3I for emacs-devel@gnu.org; Fri, 24 Aug 2018 21:34:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ftNSr-0005Nt-Oz for emacs-devel@gnu.org; Fri, 24 Aug 2018 21:34:11 -0400 Original-Received: from mo6-p00-ob.smtp.rzone.de ([2a01:238:20a:202:5300::3]:29825) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ftNSp-0005KJ-EX; Fri, 24 Aug 2018 21:34:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1535160844; s=strato-dkim-0002; d=adminart.net; h=Sender:References:Message-ID:Date:In-Reply-To:Subject:Cc:To:From: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=Ex7Bv30hvUsx5Xz7pOlbMlqpr98usd52bsNpNCNly5w=; b=qoEyyAI9pbrx5ZwZUrVFBmVPbthUP99pql/rJg0bjUhWyfS+8n/wbJ+XfCXjSI4plm xcTSqa5JzKlCjRfuLniyrPDL7iNvvZFQ0AH0rdSI2tzjz+9jmd/FVeC28n1hfaydSvGw CSM9j5eiLKAtMFv9dUNQZW6/DP97e14q9zopwIpMIpLlmnekR8Qv7RfB6+apv5Mm7GX1 rZ6iqFtzwnywz0JG3NM1eFYrFTn6RcQWOk0XxADfe2BYxq9I4h+dWVdcRSISA9p5+uWa HA8Y3SckvUfVruDovKxF2iNsDDAMDbGPtj/g+HfoWYbcOY6V6JQGy4M6jhLYzoSLLXFj w1jg== X-RZG-AUTH: ":O2kGeEG7b/pS1FS4THaxjVF9w0vVgfQ9xGcjwO5WMRo5c+h5ceMqQWZ3yrBp+AVdIIwXjneEe9k=" X-RZG-CLASS-ID: mo00 Original-Received: from lee by himinbjorg.adminart.net with local (Exim 4.90_1) (envelope-from ) id 1ftNSi-0000rw-A3; Sat, 25 Aug 2018 03:34:00 +0200 In-Reply-To: <83in409lub.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 24 Aug 2018 12:04:44 +0300") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a01:238:20a:202:5300::3 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:228885 Archived-At: Eli Zaretskii writes: >> From: hw >> Cc: spacibba@aol.com, emacs-devel@gnu.org >> Date: Fri, 24 Aug 2018 03:00:32 +0200 >>=20 >> How do we make such proposals? Should we post some or all of our >> settings here, including self-written functions we call with non-default >> key bindings? What are the users we should have in mind? > > My idea is to start with identifying particular classes of users, in > terms of stuff they mostly do in Emacs, perhaps with a second > gradation into 2 or 3 proficiency levels. Then making a list of > settings each class/level generally wants to change from the built-in > defaults. When we have that, we could step back and see what to do > with the data we collected. For some, we might decide we want to > change the defaults, end of story. For others, we should discuss in > what form(s) to expose the relevant options to each such group of > users. > > That is just one idea, of course; other ideas for making progress are > welcome. It=C2=B4s a good idea, though I think it shouldn't be limited to settings. >> (add-to-list 'auto-mode-alist '("\\.org\\'" . org-mode)) > > This is already in the defaults. I probably read it on the emacs wiki, 15 years ago maybe. Maybe Emacs should give us warnings when it discovers outdated, deprecated or useless settings in ~/.emacs. >> (setq scroll-margin 0) > > This is the default. I=C2=B4ve had it at 2 for many years and only tried 0 the other day. If I remove it, I won't remember how it's called, so I'd have to comment it out. >> (setq Man-width 75) > > Emacs nowadays calculates the width dynamically, depending on the > dimensions of the window. Why not make Emacs dynamically size it's windows to the width of the display first? ;~O Yes, Emacs can do that since a while, and has made it an extremely annoying default. Who wants to read manual pages or other text when it has been formatted to be about 140--300 characters per line wide (and way more than that if my eyes were what they used to be)? Lines that wide are great for programming and suck for manuals. Even the about 140 characters per line I have with defaulting to two windows side by side are a bit much for programming, and fortunately most lines are a lot shorter. If they are too long, I reformat them to a reasonable length. About 140 is a good compromise, yet still too wide for manuals. (For more than two windows side by side, I'd need a larger display (or glasses maybe).) And who wants to need to somehow re-format manual pages to a reasonable width when they make the window smaller? Re-formatting them isn't even possible --- at least it wasn't when I made this setting. If it now is, are the manual pages reformatted automatically when you change the size of the window? If they are, who would want to change the size of a window to be able to read a manual page? This is a good example for a default that really should be changed. Text is easiest to read at about 70--80 characters per line. Not having this setting at a reasonable default allows Emacs to show off with being able to reformat manual pages to ridiculous line lengths, thus making them unreadable, which is not useful for the users. How about changing the effect of Man-width, or an additional setting: Emacs could usefully format manual pages to fit the window when the window is narrower than the default width of manual pages (unless the window is ridiculously narrow, in which case it could fall back to the default width for manual pages) and format them no wider than the default width of manual pages for windows that are wider. It could also, depending on a(nother) setting(s), dynamically re-format the manual pages to min( (width_of_window <=3D ridiculously_narrow) ? max_width_of_manual_pages : width_of_window, max_width_of_manual_pages ) when the window is resized and had been less wide than the maximal width for manual pages before. I'd consider that as much more useful than ending up with ridiculously wide manual pages that are unreadable when they are as wide as the window and even more unreadable when you make the window less wide in an attempt to get the pages more readable: awww, too late .... This would be the solution for this particular setting: a good default. > >> (load "~/emacs/my-mark-line") > > This is not really a setting ;-) That's why I think packaging configurations targeted at qualified classes of users shouldn't be limited to settings like Man-width. Think of what Ergus pointed out in his last post[1] about the difficulties users and Emacs are experiencing: + find out about Emacs + install Emacs + find out about package manager of Emacs + configure package manager, add repos + somehow get an idea of what packages to install + get into dependency hell and alternatives hell + get into documentation hell because it's hard to tell which documentation is up to date + get nothing to work > So even if the new user had time, patience and abilities to configure > and open the package manager, add melpa, install jedi, but not > configure it or use autocomplete, nothing will work for him. This is > very error prone. I had auto-complete working (until I disabled it because it got into my way by trying to automatically complete everything when I used Emacs for something I didn't install auto-complete for), installed from a git repo somewhere on github. I don't know about melpa and jedi, and I remember that there was something that required something that had to do with either auto-complete or snippets (I had yasnippets also working but then couldn't be bothered to create all the snippets I would have needed for it to make sense, but it's cool), and that there were several things that would either provide automatic completion or snippets, and it was not too clear which one I should use. My clone of the auto-complete repo is from 2014, so I don=C2=B4t remember everything exactly. It wasn't too difficult, though, but I didn't do it for python. So I agree with Ergus here. This is why I was asking about the package manager handling dependencies (and alternatives). Users kinda need to be able to create a package from their running and working (and perhaps even non-working) configuration, including /everything/ that is needed for this configuration. Other users need to be able to back up their configuration --- hence be able to create configuration packages --- and to conveniently install packages created by other users, or by themselves. They do not need to have to try to figure out dependencies or alternatives when installing packages. Otherwise they would have some sort of Gentoo experience which can get so horrible it could make them switch to Windows, or even to a Mac.[2] Now when Ergus gets everything which is great for programming in python to work, he would create a configuration package, send it to me, and I could install it and start learning python. Emacs kinda needs to be able to be boring for users to become excited about it and wanting to learn. And that includes displaying manual pages by default in a boringly wonderful readable way. Often times, the greatest power arises from simplicity --- perhaps all the more so, the more complicated everything becomes. [1]: Message-ID: <20180823163325.cebnxjwu37efy45k@Ergus> [2]: For those who haven't tried: Gentoo is virtually great, i. e. great until the at-least-weekly update fails and forces you yet again to make wild guesses about how you could fix the dependencies because the package management doesn't do that because you're the one who is supposed to do it. If you can't fix them in time, or if you try to avoid the dreadful updates, or if you don't have several hours per machine each week for updates, the machine may quickly become impossible to update at all. Not only that, the machine may be useless because it can not provide the services it is supposed to provide before you fixed the dependencies, which may not be possible until some packages have been updated by the package managers. I can understand how I unexpectedly become the one to fix the dependencies, and I can not afford to depend on package managers who mess things up so badly that updates become impossible. This is one of the many paths leading to the appreciation of Centos and the realisation that sometimes there is nothing better than boring.