From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: Tramp defaults (was: Changes for emacs 28) Date: Tue, 08 Sep 2020 19:08:28 +0800 Message-ID: <87o8mgjzkj.fsf@localhost> References: <20200906133719.cu6yaldvenxubcqq.ref@Ergus> <20200906133719.cu6yaldvenxubcqq@Ergus> <83lfhnnew7.fsf@gnu.org> <20200906163418.3p2wuygb4osm76wa@Ergus> <20200906203807.u237c3h22oxwtmba@Ergus> <87wo15adtj.fsf@rabkins.net> <87tuw8kirh.fsf@localhost> <87k0x4d3up.fsf_-_@gmx.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15829"; mail-complaints-to="usenet@ciao.gmane.io" Cc: spacibba@aol.com, rms@gnu.org, Yoni Rabkin , emacs-devel@gnu.org To: Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 08 13:10:13 2020 Return-path: Envelope-to: ged-emacs-devel@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 1kFbVt-00041P-1s for ged-emacs-devel@m.gmane-mx.org; Tue, 08 Sep 2020 13:10:13 +0200 Original-Received: from localhost ([::1]:35410 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kFbVs-0002EB-4G for ged-emacs-devel@m.gmane-mx.org; Tue, 08 Sep 2020 07:10:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42790) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kFbVH-0001eC-Ag for emacs-devel@gnu.org; Tue, 08 Sep 2020 07:09:35 -0400 Original-Received: from mail-pj1-x102e.google.com ([2607:f8b0:4864:20::102e]:52657) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kFbVF-00060W-8G; Tue, 08 Sep 2020 07:09:35 -0400 Original-Received: by mail-pj1-x102e.google.com with SMTP id o16so8125798pjr.2; Tue, 08 Sep 2020 04:09:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=BaDy0SqncPm1uDuutnjBNcPnbXWz7YXdav/6xdgyPRg=; b=tsORZ5Lkygb0pNTcFEieDqiSJ1g8veALDP7Y1USgi6nAzB20Yf/CM/Esy2zSQdGEKu 7cuydnoHrwQwIRdcp4b0fDqY67hhn4zfZrLMP7oHKPMB7lEr796vAVBBsF015+Lz1TJR m5PYlPxgK3pAWP3hXDs3nrKUJC21aagyHmQyxRx7oIxRMb55vxV5i5NtJEkL3HH7hfyD dyq+MDjPIf5/Pc3tUIylRWrGraocyvxFqxl2qnFxjzJfX5ckp/3zpnMaf4aWQV+K+3PN kWWcBXoRs1aPVpHRE9eehzUZvWDalo28bewbhQw5pjOn6cOrn8aAnvB7Mrx2IpO19Cc7 03sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=BaDy0SqncPm1uDuutnjBNcPnbXWz7YXdav/6xdgyPRg=; b=FxW7N73KK1Z9mCUGhpQRfTjmvIEKch/9iCfpzua+NRpD028EAOgAOOs12AgEKMJGXI gZ3AnlVNgjKeykHGwwtnfMyBmdwvYIjN1/vUtcT3WWqFEVkdMnZsUMbP667e6tUXqG2S sny4HG3cX6i0FyfpK1BteEek3KBKPYMbLO5T7P9id6rcDnMDFgyPqQO4SFQwSCYgi2Nf kzCjeNwm3OcW9UYnoHQkRi8x1W3+gD2IvKVOH6RHpaA1RWMfdm7T19xw/8xh16wfftTG l9/uMYQrC1oo6vcrSoy6b8ce3PwCy9rxrmn7pPWMJvk6r8H1GwRIFCAVGEkevyBNOnLJ 4adA== X-Gm-Message-State: AOAM532Gl76B7O2et1LIJWC2IyIXuNe5c3ygpNq2E7UlgtnLAVI5X0tM 9oMG5Ny6eV51Pq4eU79D1kc= X-Google-Smtp-Source: ABdhPJwIpaMUfhfpg/NBlh1SvMDpBjFXG3quhl/29R830oIotTva0YAhDT8105wfO3PJ9AGn470dFw== X-Received: by 2002:a17:90b:46d3:: with SMTP id jx19mr3349403pjb.165.1599563371358; Tue, 08 Sep 2020 04:09:31 -0700 (PDT) Original-Received: from localhost ([167.88.61.176]) by smtp.gmail.com with ESMTPSA id j1sm14742403pgp.93.2020.09.08.04.09.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Sep 2020 04:09:30 -0700 (PDT) In-Reply-To: <87k0x4d3up.fsf_-_@gmx.de> Received-SPF: pass client-ip=2607:f8b0:4864:20::102e; envelope-from=yantar92@gmail.com; helo=mail-pj1-x102e.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:254719 Archived-At: >> ... However, I believe that it would be a >> good option to have several sets of defaults, which would better fit >> some common use-cases, like programming, note-taking, tramp, git, etc. >> Then, the existing defaults will represent "Generic" use-case, but a new >> user (who may or may not have programming background) might easily >> select other set of defaults, which is more suitable for the user's >> background and expected use-cases. > It has been mentioned several times in the past that there shall be > better (or other) Tramp defaults. But I haven't seen proposals. Sorry. My writing was probably not clear enough. I am not proposing to decide on concrete "better defaults" at this point. Looking at multiple threads discussing the defaults, there will be no agreement on this. Instead, I propose to create a general framework allowing people to create such defaults (maybe multiples of defaults): 1. Change the welcome screen highlighting "User guide" for new users 2. Upgrade "User guide" to be more like "presentation" or "configuration wizard". Basically, I propose to make "User guide" interactive and splitted into multiple slides/pages: a. Introduction page describing how Emacs is different from mainstream editors. Something in like the following (not necessary literally, I am just describing the idea): --------- You are about to dive into one of the most powerful and the oldest text editing tools - GNU Emacs. Many of the commonly used concepts existing in modern (and younger) text editors were first introduced here. Many Emacs concepts are not used so commonly though. They can be powerful in experienced hands but require time (sometimes a lot of time) to master. In the following slides, we will go through some important concepts existing in Emacs, which are different from what you may be used to. We encourage you to use these Emacs concepts, but will also offer more familiar (but less powerful in long term) alternatives -------- Copy/Paste concepts Unlike other editors, Emacs does not use C-c/C-v bindings to copy/paste text. At the time C-c/C-v became a standard Emacs already had conflicting standards for these key-bindings. If you wish to use the C-c/C-v bindings anyway (and miss on some more advanced features), you can turn on "cua-mode" below [ ] You can always return to superior Emacs bindings from <...> b. Customisation page allowing user to select the intended functionality. Here, the user can chose "configuration bundles" optimised for specific use-cases --------- Emacs is very powerful piece of software where you can find pretty much any feature you may imagine (and many feature you never thought of). However, the large number of features is also a disadvantage: you will most likely be lost in all the possibilities you can choose from. As you are just getting started with Emacs, you may choose the types of workflows you are interested in. Unrelated features will be hidden from the interface to reduce possible confusion. If you wish to, you may still access the hidden features in "Other" menu items or "Other" sections of customisation interface. [ ] In the following slides we will go through specific common workflows, you may want to enable/disable. The options relevant to the chosen workflows will not be hidden. The next slides should go through the main sections of Emacs manual (maybe also including theme selection). Each section will be represented by the following (maybe in multiple slides): - short description of the section - this slide should have a button "do not plan to use", skipping all other relevant slides and hiding menu and cusomisation options. By hiding, I mean grouping the relevant menu options into "Other" sub-menu and moving the relevant customisation groups/options into "Other" group - slides showing common workflows for the section. For example, org-mode section may have "Agenda" and "Outlining" slides describing different things user may do in org-mode. In "agenda" user may be offered to check/uncheck tracking TODO changes (which is disabled by default) depending how they prefer to do planning (if they care about it): (1) Via journal notes; (2) Via agenda views. 3. Provide interface for "hiding" less common customisations/menu items from the user: - unimportant menu items can be moved to "Other" sub-menus - unimportant customisations/customisation groups can be moved under "Other" sub-group The "unimportant" customisation means the following: 1. Not frequently-used 2. But also not chosen as important within the "workflow" selected by user in the above slides. Of course, this feature is only enabled if the user actually went through the above slides and chose to hide "confusing options" The individual "better defaults" are better to be discussed when creating the relevant slides. This whole thing will go nowhere if we discuss those details right now. First, it would be better to have the framework creating the slides and hiding irrelevant options. Best, Ihor Michael Albinus writes: > Ihor Radchenko writes: > > Hi, > >> I do think that the existing Emacs defaults are a good starting point >> for a new user with unknown workflows. They are generic enough to tweak >> Emacs in any possible direction. However, I believe that it would be a >> good option to have several sets of defaults, which would better fit >> some common use-cases, like programming, note-taking, tramp, git, etc. >> Then, the existing defaults will represent "Generic" use-case, but a new >> user (who may or may not have programming background) might easily >> select other set of defaults, which is more suitable for the user's >> background and expected use-cases. > > It has been mentioned several times in the past that there shall be > better (or other) Tramp defaults. But I haven't seen proposals. > > For sure I'm biased, but I believe the current Tramp defaults are suited > for the majority of users. Could people pls tell me where I'm wrong with > this? What other Tramp defaults are better? > > And promised, I'm willing to accept proper changes. > >> 5. Similar guided tours may be created for most popular Emacs features: >> - working with source code >> - org-mode >> - version-control and collaboration >> - remote file access >> - mail >> Those tours might also offer some initial customisation, so that the >> user may disable/enable some features which are not relevant to >> his/her workflow. >> The guides should be easily accessible from menu. > > Hard to do. Remote file access is different for everybody, because > everybody uses another remote host. I'm lacking on ideas what such a > guided tour for remote access shall show (except the simple > recommendation "write /ssh:user@host:/path/to/file instead of /path/to/file"). > > Proposals welcome! > >> Best, >> Ihor > > Best regards, Michael.