[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Tramp defaults (was: Changes for emacs 28)
From: |
Ihor Radchenko |
Subject: |
Re: Tramp defaults (was: Changes for emacs 28) |
Date: |
Tue, 08 Sep 2020 19:08:28 +0800 |
>> ... 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
<prev> <next>
--------
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.
<talk about M-w/C-y>
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
[ ] <Interactive checkbox enabling cua-mode>
You can always return to superior Emacs bindings from <Options menu>
<prev> <next>
<...>
<Similar slides describing key differences of Emacs and allowing
changing defaults to more common settings>
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.
[ ] <Checkbox to be checked if you want to hide confusing elements
for now>
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.
<prev> <next>
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 <michael.albinus@gmx.de> writes:
> Ihor Radchenko <yantar92@gmail.com> 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.
- Re: Changes for emacs 28, (continued)
- Re: Changes for emacs 28, tomas, 2020/09/08
- RE: Changes for emacs 28, Drew Adams, 2020/09/08
- RE: Changes for emacs 28, Ihor Radchenko, 2020/09/09
- RE: Changes for emacs 28, Stefan Kangas, 2020/09/09
- Re: Changes for emacs 28, Eli Zaretskii, 2020/09/09
- Re: Changes for emacs 28, Stefan Kangas, 2020/09/09
- Re: Changes for emacs 28, Ihor Radchenko, 2020/09/09
- Re: Changes for emacs 28, Eric S Fraga, 2020/09/10
- Re: Changes for emacs 28, Ihor Radchenko, 2020/09/10
- Tramp defaults (was: Changes for emacs 28), Michael Albinus, 2020/09/08
- Re: Tramp defaults (was: Changes for emacs 28),
Ihor Radchenko <=
- Re: Tramp defaults, Michael Albinus, 2020/09/08
- Re: Changes for emacs 28, Richard Stallman, 2020/09/08
- Re: Changes for emacs 28, Ihor Radchenko, 2020/09/09
- Re: Changes for emacs 28, Richard Stallman, 2020/09/09
- Re: Changes for emacs 28, Lars Ingebrigtsen, 2020/09/08
- Re: Changes for emacs 28, Richard Stallman, 2020/09/08
- Re: Changes for emacs 28, João Távora, 2020/09/07
- Re: Changes for emacs 28, Richard Stallman, 2020/09/07
- Re: Changes for emacs 28, Stefan Monnier, 2020/09/07
- joke (was: Changes for emacs 28), andres . ramirez, 2020/09/07