A new user perspective about "Changes for emacs 28"

A new user perspective about "Changes for emacs 28"

[Nicola Manca]

Dear Emacs Developers,

I'm probably one of the newest emacs users in thin ML, I started using 
it since about one year. I decided to write this email hoping that my 
opinion as a "new emacs user" could add something to the ongoing 
discussion about emacs defaults.

I started using debian at high school, 20 year ago, as my only
operative system. This mainly for political agreement with the free 
software movement. Since then I tried to start using emacs several 
times, but I always gave up, despite my motivation towards free software 
in general.

Today I'm not a programmer, I'm a scientist and I never understood why I 
should spend time learning to use a software that I could barely shuth 
down (typically with a "pkill -9 emacs"). Last year a friend of mine 
spent few hours convincing me that emacs worth another try. He explained 
me the logic of keybinding (Meta is Alt, really?!?) and then the 
org-mode was the game-changing feature. I then did the tutorial a couple 
of times, copied something from his .emacs and then moved to 
stackexchange or reddit to look for more. First, I installed 
org-superstar, to have nice bullets, and then
learned how to change the default theme to dark one with decent
contrast and colors (sanityinc-tomorrow-night). Yes, sorry, I have to 
tell you that these are the priority for a new user: feel comfortable, 
so that he/she is motivated to spend time in something...

Now I use emacs on a daily basis. My .emacs is about 500 lines,
similarly to my TODO.org. By spending a non-negligible amount of time I 
managed to have a python environment comparable to other graphical 
editors (Spyder) and latex nicely configured in a similar way to 
TexStudio.  I even manage to have two dictionaries working together 
thanks to a discussion in this ML, super cool!

However, how many people have the opportunity and the will to spend tens 
of ours to just do in emacs what they already did in texstudio or 
spyder? I don't know if cry or laugh when I read that switching to a 
dark theme is a "radical change". I would love to see much more radical 
changes. There are a lot of low-hanging fruit that could make emacs 
appealing for new users and provide the enthusiasm required to overcome 
its steep learning curve.

These are just the first examples that came up in my mind:
- undo-tree-mode
- which-key-mode
- beacon-mode
- ido-mode (everywhere)
- helm-M-x

I'm aware that there are probably copyright or technical problems to 
make these defaults (together with a nice shiny theme). However, this 
should be the main objective of the development activity. In particular 
packages as WK or helm-M-x are very good for learning keystrokes. Humans 
learn by trials and errors, not by reading the manual, and these 
packages are great for this.

I bealive that the final goal should alwasy be to attract new users, 
otherwise non-free software will always have a larger userbase. So far, 
I've not the technical skills to do this, maybe someone out there can 
and want. However, my feeling is that there is not much push in this 
direction (maybe in the opposite) and this may results in lack of 
enthusiasm.

I want to thank Ergus for trying, and all the developers for the great 
software. May it become even better!

best wishes
Nicola

Re: A new user perspective about "Changes for emacs 28"

[Ergus]

On Mon, Sep 07, 2020 at 06:45:59PM +0200, Nicola Manca wrote:

Hi Nicola:

I totally agree with you in all your points because when I started my
experience was exactly the same. Actually I stayed because I didn't have
internet in my country and I couldn't install anything else.. and vim
has modes ;p

Just some technical quotes/comments:

>These are just the first examples that came up in my mind:

>- undo-tree-mode
Undo tree had some problems in the past. But if you want the basic
undo/redo behavior there is something already in vanilla (as usual a bit
hidden):

(global-set-key [remap undo] 'undo-only)
(global-set-key (kbd "C-M-_") 'undo-redo)

which I discovered after asking here and fighting with undo tree for
almost a year.

>- which-key-mode

Yes, yes!! sadly it is not even in elpa. But I know that for a new user
this is 90% of his time the first days. "Learn where is everything".

Probably this is the only feature I really miss in elpa or even in
vanilla because when it is more needed is when the user doesn't know how
to install a package yet.

>- ido-mode (everywhere)

We have had some "issues" with ido support and integration with the
modern completion infrastructure. I am working in the default completion
infrastructure and icomplete/fido to improve them a bit (keeping things
simple) and make "fido more ido" when possible.

>- helm-M-x
This overlap some functionalities of ido right? Any way Helm will not
come to vanilla due to copyright issues... But we can improve icomplete
and completions (as we are doing, but it worth nothing if the users
doesn't find the differences).

I think that in the best case (being realistic) ivy is closer than helm
to come to vanilla as it is already in elpa and Oleh has already
contributed before.

>I've not the technical skills to do this, maybe someone out there 
>can and want.

You still can contribute in many ways:

- Documentation
- Testing
- Trying and reporting issues in newer features. (ej: trying fido-mode
and reporting the issues and differences with ido you find)
- Reporting bugs
- Replying to new users in the "help" list.
- Contacting melpa developers to add their features to elpa or vanilla
if you think they worth.

Software is not only code... if we had a graphical designer here half of
the discussion about the themes will be solved faster.

>
>best wishes
>Nicola
>

Re: about fido-mode

[Ergus]

On Mon, Sep 07, 2020 at 07:12:31PM +0000, andres.ramirez wrote:
>Hi. Ergus.
>
>This proposal about the defaults is a great starting point:
>--8<---------------cut here---------------start------------->8---
>https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg00159.html
>--8<---------------cut here---------------end--------------->8---
>
Yes when I have some time I will (try to) go for it. (I am not a
prominent lisper, so It will take me a lot of time... but I have at
least two years for that ;p )

>>>>>> "Ergus" == Ergus  <spacibba@aol.com> writes:
>
>
>[...]
>
>    >> - ido-mode (everywhere)
>
>    Ergus> We have had some "issues" with ido support and integration with the modern completion
>    Ergus> infrastructure. I am working in the default completion infrastructure and icomplete/fido
>    Ergus> to improve them a bit (keeping things simple) and make "fido more ido" when possible.
>
>I have had a problem with this ido based funct when testing eglot on a C source file:
>--8<---------------cut here---------------start------------->8---
>https://gist.githubusercontent.com/magnars/2360578/raw/822b60a5572ae208641f90b0e209fd93082f0153/gistfile1.el
>--8<---------------cut here---------------end--------------->8---
>
>Because of the issue above Joao told me "eglot works fine with fido-mode".
>I have tried it for a couple of hours (I have found below issues with fido):
>--8<---------------cut here---------------start------------->8---
>1. Y on dired-mode does not work. {Y runs the command
>dired-do-relsymlink}. I could not write the name of the symlink.
>2. I could not use my aliases {I have a bunch of them}

Please give me some more details to reproduce. These two are working
fine for me.

>3. fido vertical mode is not on pair with ido. Some vertical
>misalignment

Fido vertical is actually an external package. I am implementing an
internal alternative which is still in bared bones.

There is a branch features/icomplete-vertical that I shared with Joao to
try and improve (please don't try it yet it is WIP). 
>--8<---------------cut here---------------end--------------->8---
>
>Also I should mention the discussion on this bug about the completion
>mechanism (improvement of the documentation):
>--8<---------------cut here---------------start------------->8---
>http://debbugs.gnu.org/41423
>--8<---------------cut here---------------end--------------->8---
>
This seems to be related with the completion backend. The big guys are
already working on that... 

>>> - helm-M-x
>    Ergus> This overlap some functionalities of ido right? Any way Helm will not come to vanilla due
>    Ergus> to copyright issues...
>
>helm as ido (stated above) also does not let me use my aliases (below are a couple of
>examples)
>--8<---------------cut here---------------start------------->8---
>(defalias 'cc 'compile)
>(defalias 'rc 'recompile)
>--8<---------------cut here---------------end--------------->8---
>
>Best Regards

Re: about fido-mode

[andrés ramírez]

>>>>> "Ergus" == Ergus  <spacibba@aol.com> writes:


[...]

    Ergus> Yes when I have some time I will (try to) go for it. (I am not a prominent lisper, so It
    Ergus> will take me a lot of time... but I have at least two years for that ;p )

Perhaps as with the new elpa (without copyleft). There could be a couple of
defaults {stable, and experimental (with no backard compatibility to
previous versions)}.


    Ergus> Please give me some more details to reproduce. These two are working fine for me.
--8<---------------cut here---------------start------------->8---
1. Y on dired-mode does not work. {Y runs the command
dired-do-relsymlink}. I could not write the name of the symlink.
2. I could not use my aliases {I have a bunch of them}
--8<---------------cut here---------------end--------------->8---

About number One. it is simple. Just open the elpa directory and do Y on
any folder. Or if You try with my snippet below then M-x dired-do-relsymlink
You could pick 'which-key-XXXXXXXX.YYYY' and create a symlink to just
the shorter 'which-key'.

On my case when I write which-key it completes to something and does not
let me tell just 'which-key'. Let me know If You can replicate it.

About number two:
I have retried it a few seconds ago. And it is working fine. Sorry for
the noise.

    >> 3. fido vertical mode is not on pair with ido. Some vertical misalignment

    Ergus> Fido vertical is actually an external package. I am implementing an internal alternative
    Ergus> which is still in bared bones.

I am testing fido this way:
--8<---------------cut here---------------start------------->8---
emacs -Q -l /tmp/test-fido.el
--8<---------------cut here---------------end--------------->8---

This is the content of test-fido.el
--8<---------------cut here---------------start------------->8---
(when (fboundp 'fido-mode)
                       (fido-mode t)
                         (setq icomplete-separator "\n"
                                     max-mini-window-height 10
                                     resize-mini-windows 'grow-only
                                     truncate-lines t)

                         )

(defalias 'cc 'compile)
(defalias 'rc 'recompile)
--8<---------------cut here---------------end--------------->8---

Best Regards

Re: about fido-mode

[Ergus]

On Mon, Sep 07, 2020 at 08:44:45PM +0000, andr�s ram�rez wrote:
>>>>>> "Ergus" == Ergus  <spacibba@aol.com> writes:
>
>
>[...]
>
>    Ergus> Yes when I have some time I will (try to) go for it. (I am not a prominent lisper, so It
>    Ergus> will take me a lot of time... but I have at least two years for that ;p )
>
>Perhaps as with the new elpa (without copyleft). There could be a couple of
>defaults {stable, and experimental (with no backard compatibility to
>previous versions)}.
>
>
>    Ergus> Please give me some more details to reproduce. These two are working fine for me.
>--8<---------------cut here---------------start------------->8---
>1. Y on dired-mode does not work. {Y runs the command
>dired-do-relsymlink}. I could not write the name of the symlink.
>2. I could not use my aliases {I have a bunch of them}
>--8<---------------cut here---------------end--------------->8---
>
>About number One. it is simple. Just open the elpa directory and do Y on
>any folder. Or if You try with my snippet below then M-x dired-do-relsymlink
>You could pick 'which-key-XXXXXXXX.YYYY' and create a symlink to just
>the shorter 'which-key'.
>
>On my case when I write which-key it completes to something and does not
>let me tell just 'which-key'. Let me know If You can replicate it.
>
>About number two:
>I have retried it a few seconds ago. And it is working fine. Sorry for
>the noise.
>
>    >> 3. fido vertical mode is not on pair with ido. Some vertical misalignment
>
>    Ergus> Fido vertical is actually an external package. I am implementing an internal alternative
>    Ergus> which is still in bared bones.
>
>I am testing fido this way:
>--8<---------------cut here---------------start------------->8---
>emacs -Q -l /tmp/test-fido.el
>--8<---------------cut here---------------end--------------->8---
>
>This is the content of test-fido.el
>--8<---------------cut here---------------start------------->8---
>(when (fboundp 'fido-mode)
>                       (fido-mode t)
>                         (setq icomplete-separator "\n"
>                                     max-mini-window-height 10
>                                     resize-mini-windows 'grow-only
>                                     truncate-lines t)
>
>                         )
>
No, this doesn't work fine, that's why I am doing the branch I
mentioned. If you want vertical fido with the external package while the
internal is ready:

https://github.com/oantolin/icomplete-vertical

>(defalias 'cc 'compile)
>(defalias 'rc 'recompile)
>--8<---------------cut here---------------end--------------->8---
>
>Best Regards

Re: about fido-mode

[andrés ramírez]

Hi. Ergus.

>>>>> "Ergus" == Ergus  <spacibba@aol.com> writes:


[...]

    Ergus> No, this doesn't work fine, that's why I am doing the branch I mentioned. If you want
    Ergus> vertical fido with the external package while the internal is ready:

    Ergus> https://github.com/oantolin/icomplete-vertical

I hake just tried it indirectly. I the meantime I could wait for when
your changes arrive on master ;).

BR
ps: were You able of reproducing the problem with dired-do-relsymlink?

Re: about fido-mode

[Ergus]

On Mon, Sep 07, 2020 at 10:08:21PM +0000, andr�s ram�rez wrote:
>Hi. Ergus.
>
>    Ergus> Actually I am interested a bit on this specific one because so far the ido-imenu function
>    Ergus> you shared with me is an ido wrapper around imenu completion. But as icomplete/fido uses
>    Ergus> the internal infrastructure it shouldn't be needed this hack.
>
>Right.
>
>    Ergus> OTOH (from my absolute ignorance about ido-imenu), I tried imenu+fido and it works like a
>    Ergus> charm. Probably the only missing thing is the sorting part?
>
>It is not the same. ido-imenu shows just the functions, not de 'Class' or
>'Fields'. one less thing to pick. Just go directly to the
>functions. Actually I need to comment this imenu is so awesome. It is
>present on vanilla emacs. Probably others editors do not have it present
>by default, without needing a plugin or package.
>
If course it is not the same. Look at the code. Actually What it list
are the symbols not only the functions.

>    Ergus> In the code you shared I only see that you need to replace the ido-completing-read with
>    Ergus> something else.
>
>There was a issue when trying ido-imenu with eglot activated. The error was this
>one:. I have been trying to create a git-issue without success from within
>emacs. So I am going to report later the complete case:

I don't care at all about ido (as a radical I consider that ido should
be removed in favor of ivy, helm, and anything else better supported and
integrated with the actual infrastructure... that's why I support fido)

Any way, in general I think that this (untested) code could do the work
in fido-mode:

;; Same flet code in your function
(defun my-filter (symbol-list)
   (let (name position name-and-pos)
     (dolist (symbol symbol-list)
       (setq name nil
             position nil)
       (cond
        ((listp symbol)
         (if (imenu--subalist-p symbol)
             (addsymbols symbol)
           (setq name (car symbol))
           (setq position (cdr symbol))))

        ((stringp symbol)
         (setq name symbol)
         (setq position (get-text-property 1 'org-imenu-marker symbol))))

       (when (and position name)
         (add-to-list 'name-and-pos (cons name position))))
     name-and-pos))

;; Filter the aoutput of imenu--make-index-alist 
(advice-add 'imenu--make-index-alist :filter-return #'my-filter)

Basically the point is that imenu calls imenu--make-index-alist to
create the candidates list and it can have many symbols and nested
elements. But you want a simplified flatten list of symbol only
candidates.

With this advise you process the output imenu--make-index-alist to
return a flatten alist of symbols only. (it is exactly the same function
you had declared with flet, but simpler)

Then imenu could do what you want.

Re: about fido-mode

[andrés ramírez]

Hi. Ergus.

>>>>> "Ergus" == Ergus  <spacibba@aol.com> writes:


[...]


    Ergus> Any way, in general I think that this (untested) code could do the work in fido-mode:

addsymbols function needs to be defined:
--8<---------------cut here---------------start------------->8---
if: Symbol’s function definition is void: addsymbols
--8<---------------cut here---------------end--------------->8---


[...]

BR

Re: about fido-mode

[Ergus]

On Tue, Sep 08, 2020 at 09:06:45AM +0000, andrés ramírez wrote:
>Hi. Ergus.
>
>>>>>> "Ergus" == Ergus  <spacibba@aol.com> writes:
>
>
>[...]
>
>
>    Ergus> Any way, in general I think that this (untested) code could do the work in fido-mode:
>
>addsymbols function needs to be defined:
>--8<---------------cut here---------------start------------->8---
>if: Symbol’s function definition is void: addsymbols
>--8<---------------cut here---------------end--------------->8---
>
my-filter is the new name of addsymbol. Just change that; I wrote the
code by mind, didn't try it. It was just pseudo-code.

>
>[...]
>
>BR
>

Re: about fido-mode

[andrés ramírez]

Hi. Ergus.

>>>>> "Ergus" == Ergus  <spacibba@aol.com> writes:

    Ergus> my-filter is the new name of addsymbol. Just change that; I wrote the code by mind,
    Ergus> didn't try it. It was just pseudo-code.

Good news. It works.
Bad news. It fails with eglot enabled buffer.

BR

Re: about fido-mode

[Ergus]

On Tue, Sep 08, 2020 at 04:14:18PM +0000, andr�s ram�rez wrote:
>Hi. Ergus.
>
>>>>>> "Ergus" == Ergus  <spacibba@aol.com> writes:
>
>    Ergus> my-filter is the new name of addsymbol. Just change that; I wrote the code by mind,
>    Ergus> didn't try it. It was just pseudo-code.
>
>Good news. It works.
>Bad news. It fails with eglot enabled buffer.
>
I don't know eglot at all (I use LSP), so maybe Joao can help here as he
wrote eglot. Lets wait for him because I have no idea about eglot
internals and its integration with imenu.

Probably the problem is that eglot returns something else in the
alist. So maybe we need an extra condition in the filter.

Let's wait for him

Re: about fido-mode

[andrés ramírez]

Hi. Ergus.
>>>>> "Ergus" == Ergus  <spacibba@aol.com> writes:


[...]

    >> Good news. It works.  Bad news. It fails with eglot enabled buffer.
    >> 
    Ergus> I don't know eglot at all (I use LSP), so maybe Joao can help here as he wrote
    Ergus> eglot. Lets wait for him because I have no idea about eglot internals and its integration
    Ergus> with imenu.

I have tested the function with LSP. And the function works nicely.

[...]

BR

Re: A new user perspective about "Changes for emacs 28"

[Dmitry Gutov]

On 07.09.2020 21:08, Ergus wrote:

>> - undo-tree-mode
> Undo tree had some problems in the past. But if you want the basic
> undo/redo behavior there is something already in vanilla (as usual a bit
> hidden):
> 
> (global-set-key [remap undo] 'undo-only)
> (global-set-key (kbd "C-M-_") 'undo-redo)
> 
> which I discovered after asking here and fighting with undo tree for
> almost a year.

Good point.

undo-tree has been stable for me lately, but it might be overkill for a 
lot of users, and the default undo behavior is... exotic.

So I think ideally we'd switch to the above key mappings by default. But 
since this is going to be a hard sell, at least this option should be 
better documented/advertised, maybe even on the new splash screen people 
have imagined/mentioned.

RE: A new user perspective about "Changes for emacs 28"

[Drew Adams]

> > (global-set-key [remap undo] 'undo-only)
> > (global-set-key (kbd "C-M-_") 'undo-redo)
> >
> > which I discovered after asking here and fighting with undo tree for
> > almost a year.
> 
> the default undo behavior is... exotic.
> ... ideally we'd switch to the above key
> mappings by default.

Why on earth would we do that?  Emacs undo
is superior.

Why would we want to go back to what was
available before Emacs undo?  Back to 1968...

https://en.wikipedia.org/wiki/Undo#History

(Why?  Oh, I know.  It's because other apps
are limited that Emacs too should be crippled,
at least by default.)

Re: A new user perspective about "Changes for emacs 28"

[Dmitry Gutov]

On 07.09.2020 23:34, Drew Adams wrote:
> Why on earth would we do that?  Emacs undo
> is superior.

undo-tree is superior.

The default undo is mostly tedious. It's also more limited UI-wise.

RE: A new user perspective about "Changes for emacs 28"

[Drew Adams]

> > Why on earth would we do that?  Emacs undo
> > is superior.
> 
> undo-tree is superior.

So now you're proposing that as the default, instead
of the keybindings you proposed earlier today?

(What will you propose tomorrow for it?)

Re: A new user perspective about "Changes for emacs 28"

[Dmitry Gutov]

On 08.09.2020 00:11, Drew Adams wrote:
>>> Why on earth would we do that?  Emacs undo
>>> is superior.
>>
>> undo-tree is superior.
> 
> So now you're proposing that as the default, instead
> of the keybindings you proposed earlier today?

Nope. You're welcome to re-read the original message.

RE: A new user perspective about "Changes for emacs 28"

[Drew Adams]

> >>> Why on earth would we do that?  Emacs undo
> >>> is superior.
> >>
> >> undo-tree is superior.
> >
> > So now you're proposing that as the default, instead
> > of the keybindings you proposed earlier today?
> 
> Nope. You're welcome to re-read the original message.

No need to reread it.  But you're welcome to,
as many times as you like.

(Perhaps you're trying to pick a nit, in that you
supported that proposal but didn't initiate it.)
___

Do you think ordinary (non-Emacs) Undo plus
Redo is superior to Emacs undo, and for that
reason it should replace it as the default?

Or do you think it is inferior, but it should
replace Emacs undo as the default in spite of
being inferior?  Or perhaps _because_ of being
inferior?

Re: A new user perspective about "Changes for emacs 28"

[Dmitry Gutov]

On 08.09.2020 00:39, Drew Adams wrote:

>>> So now you're proposing that as the default, instead
>>> of the keybindings you proposed earlier today?
>>
>> Nope. You're welcome to re-read the original message.
> 
> No need to reread it.  But you're welcome to,
> as many times as you like.

I meant my message, the one you replied to.

> (Perhaps you're trying to pick a nit, in that you
> supported that proposal but didn't initiate it.)

Also no.

> Do you think ordinary (non-Emacs) Undo plus
> Redo is superior to Emacs undo, and for that
> reason it should replace it as the default?

It is better controllable. E.g., I can floor 'redo' (or undo-tree-redo) 
and have Emacs quickly reach a buffer state I expected, and go no further.

Being more familiar to new users doesn't hurt either.

The fact that the current Emacs undo is theoretically more powerful 
doesn't matter too much when said power is only accessible via an 
awkward interface.

Re: A new user perspective about "Changes for emacs 28"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

You are both being harsh in your tone.  Whatever your views, would
you please express them without attacking anyone?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: A new user perspective about "Changes for emacs 28"

[Dmitry Gutov]

On 08.09.2020 05:54, Richard Stallman wrote:
> You are both being harsh in your tone.  Whatever your views, would
> you please express them without attacking anyone?

Did I... insult somebody?

Re: A new user perspective about "Changes for emacs 28"

[Alfred M. Szmidt]

   > Why on earth would we do that?  Emacs undo
   > is superior.

   undo-tree is superior.

That would make Emacs unusable for the majority of Emacs users.

Re: A new user perspective about "Changes for emacs 28"

[Dmitry Gutov]

On 08.09.2020 09:18, Alfred M. Szmidt wrote:
>     > Why on earth would we do that?  Emacs undo
>     > is superior.
> 
>     undo-tree is superior.
> 
> That would make Emacs unusable for the majority of Emacs users.

"Unusable" is a strong word, but indeed it's a more complex UI than many 
users need, probably.

Hence my actual suggestion.

Re: A new user perspective about "Changes for emacs 28"

[Eli Zaretskii]

> From: ams@gnu.org (Alfred M. Szmidt)
> Date: Tue, 08 Sep 2020 02:18:24 -0400
> Cc: nicola.manca85@gmail.com, spacibba@aol.com, drew.adams@oracle.com,
>  emacs-devel@gnu.org
> 
>    > Why on earth would we do that?  Emacs undo
>    > is superior.
> 
>    undo-tree is superior.
> 
> That would make Emacs unusable for the majority of Emacs users.

I believe this is an exaggeration.  Exaggerations aren't useful in
discussion such as this one.

IME, both the Emacs undo and undo-tree are similarly seamless for
simple use cases, which cover 80% of their use.  Once more complex
situation arise, my opinion is that undo-tree is more complex and
harder to grasp than the Emacs undo, so I don't think undo-tree is
better suited to newbies than the default undo.

Re: A new user perspective about "Changes for emacs 28"

[Alfred M. Szmidt]

   >    undo-tree is superior.
   > 
   > That would make Emacs unusable for the majority of Emacs users.

   I believe this is an exaggeration.  Exaggerations aren't useful in
   discussion such as this one.

I would find it entierly unusable (I've tried it several times) and I
know several people who use Emacs would find the same, so I do not
find it at all an exaggeration.

Re: A new user perspective about "Changes for emacs 28"

[Amin Bandali]

[-- Attachment #1: Type: text/plain, Size: 650 bytes --]

Alfred M. Szmidt writes:

>    >    undo-tree is superior.
>    > 
>    > That would make Emacs unusable for the majority of Emacs users.
>
>    I believe this is an exaggeration.  Exaggerations aren't useful in
>    discussion such as this one.
>
> I would find it entierly unusable (I've tried it several times) and I
> know several people who use Emacs would find the same, so I do not
> find it at all an exaggeration.

Perhaps the point about 'exaggeration' was not about you finding it
completely unusable, but rather generalizing your (and the several other
people's you mentioned) experience to "the majority of Emacs users"?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 857 bytes --]

Re: A new user perspective about "Changes for emacs 28"

[Alfred M. Szmidt]

It seems that suggesting totally radical changes without any kind of
though is all the rage.  There are enough subtelities in how undo
works in emacs that, yes, the vast majority would find it annoying and
unusable if it was changed to something like undo-tree.

Re: A new user perspective about "Changes for emacs 28"

[Thibaut Verron]

[-- Attachment #1: Type: text/plain, Size: 595 bytes --]

If the only point is to be able to do undo and redo easily, I believe that
the
problem is already solved by undo-only and undo-only-redo. Would giving
undo-only-redo (if not done already) a default binding break anybody's
workflow?

Le mar. 8 sept. 2020 à 17:54, Alfred M. Szmidt <ams@gnu.org> a écrit :

> It seems that suggesting totally radical changes without any kind of
> though is all the rage.  There are enough subtelities in how undo
> works in emacs that, yes, the vast majority would find it annoying and
> unusable if it was changed to something like undo-tree.
>
>

[-- Attachment #2: Type: text/html, Size: 894 bytes --]

Re: A new user perspective about "Changes for emacs 28"

[Ergus]

On Tue, Sep 08, 2020 at 06:18:44PM +0200, Thibaut Verron wrote:
>If the only point is to be able to do undo and redo easily, I believe that
>the
>problem is already solved by undo-only and undo-only-redo. Would giving
>undo-only-redo (if not done already) a default binding break anybody's
>workflow?
>
The problem is a bit trickier (I think) because undo-only/undo-only-redo
comes in pair (please correct me if I am wrong) so we need bindings for
the two.

>Le mar. 8 sept. 2020 � 17:54, Alfred M. Szmidt <ams@gnu.org> a �crit :
>
>> It seems that suggesting totally radical changes without any kind of
>> though is all the rage.  There are enough subtelities in how undo
>> works in emacs that, yes, the vast majority would find it annoying and
>> unusable if it was changed to something like undo-tree.
>>
>>

Re: A new user perspective about "Changes for emacs 28"

[Óscar Fuentes]

ams@gnu.org (Alfred M. Szmidt) writes:

>    >    undo-tree is superior.
>    > 
>    > That would make Emacs unusable for the majority of Emacs users.
>
>    I believe this is an exaggeration.  Exaggerations aren't useful in
>    discussion such as this one.
>
> I would find it entierly unusable (I've tried it several times) and I
> know several people who use Emacs would find the same, so I do not
> find it at all an exaggeration.

Leaving aside the extra and unobtrusive features it brings, undo-tree
just changes the undo/redo cycle to explicit undo and redo. I can't
think how that makes Emacs unusable, as it is how most editing
applications works out there.

Or are you talking about the obnoxious bugs where undo-tree corrupts the
undo information? It seems that they were fixed some months ago.

Re: A new user perspective about "Changes for emacs 28"

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Tue, 08 Sep 2020 17:27:07 +0200
> 
> Or are you talking about the obnoxious bugs where undo-tree corrupts the
> undo information? It seems that they were fixed some months ago.

That's indeed another problem with undo-tree: an external package that
uses internal details of the undo system is bound to break when those
details change.  Newbies shouldn't have to deal with such issues.

I'm not entirely sure that the problems with saving undo-tree info to
a file and restoring it after restart were indeed all fixed.

Re: A new user perspective about "Changes for emacs 28"

[Eli Zaretskii]

> From: ams@gnu.org (Alfred M. Szmidt)
> CC: dgutov@yandex.ru, nicola.manca85@gmail.com, spacibba@aol.com,
> 	drew.adams@oracle.com, emacs-devel@gnu.org
> Date: Tue, 08 Sep 2020 10:54:48 -0400
> 
>    >    undo-tree is superior.
>    > 
>    > That would make Emacs unusable for the majority of Emacs users.
> 
>    I believe this is an exaggeration.  Exaggerations aren't useful in
>    discussion such as this one.
> 
> I would find it entierly unusable (I've tried it several times) and I
> know several people who use Emacs would find the same, so I do not
> find it at all an exaggeration.

I don't know what you tried, but as long as you just use undo and
don't redo (which is what most users do), I don't see how you can
distinguish between the default undo and undo-tree.

Re: A new user perspective about "Changes for emacs 28"

[Thibaut Verron]

[-- Attachment #1: Type: text/plain, Size: 366 bytes --]

Le mar. 8 sept. 2020 à 17:27, Eli Zaretskii <eliz@gnu.org> a écrit :

>
> I don't know what you tried, but as long as you just use undo and
> don't redo (which is what most users do), I don't see how you can
> distinguish between the default undo and undo-tree.
>

Do you have data backing the claim that most users do not use redo
(or space-undo-undo)?

[-- Attachment #2: Type: text/html, Size: 724 bytes --]

Re: A new user perspective about "Changes for emacs 28"

[Eli Zaretskii]

> From: Thibaut Verron <thibaut.verron@gmail.com>
> Date: Tue, 8 Sep 2020 18:13:10 +0200
> Cc: "Alfred M. Szmidt" <ams@gnu.org>, nicola.manca85@gmail.com, spacibba@aol.com, 
> 	emacs-devel <emacs-devel@gnu.org>, Drew Adams <drew.adams@oracle.com>, dgutov@yandex.ru
> 
>  I don't know what you tried, but as long as you just use undo and
>  don't redo (which is what most users do), I don't see how you can
>  distinguish between the default undo and undo-tree.
> 
> Do you have data backing the claim that most users do not use redo 
> (or space-undo-undo)? 

I have my own experience: I use undo about 10 times more frequently
than redo.

Re: A new user perspective about "Changes for emacs 28"

[Thibaut Verron]

[-- Attachment #1: Type: text/plain, Size: 271 bytes --]

Le mar. 8 sept. 2020 à 18:23, Eli Zaretskii <eliz@gnu.org> a écrit :

>
> I have my own experience: I use undo about 10 times more frequently
> than redo.
>

That more or less matches my own experience. And I consider "redo"
invaluable
for those occurrences.

[-- Attachment #2: Type: text/html, Size: 569 bytes --]

Re: A new user perspective about "Changes for emacs 28"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I would find it entierly unusable (I've tried it several times) and I
  > know several people who use Emacs would find the same, so I do not
  > find it at all an exaggeration.

Could you present some specific scenarios in which it works badly for
you?  That would enable us to go deeper than "I love it" / "I hate
it."


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: A new user perspective about "Changes for emacs 28"

[Alfred M. Szmidt]

     > I would find it entierly unusable (I've tried it several times) and I
     > know several people who use Emacs would find the same, so I do not
     > find it at all an exaggeration.

   Could you present some specific scenarios in which it works badly for
   you?  That would enable us to go deeper than "I love it" / "I hate
   it."

Sure, here is very simple example on how unintuitive the mode is from
the point of a Emacs user.  Installed undo-tree-mode, and enabled it.
In an empty buffer I write,

  foo bar baz

And issue C-x C-u -- the first thing it does is take over half the
screen and switches the buffer to a "undo tree visualizer" -- I just
want to undo whatever I did.

I try doing C-x C-u again -- that doesn't work, since the
undo-tree-visualizer mode doesn't support that binding.  Am I supposed
to move up and down to replace the text in this new buffer?  Seems so;
fair enough -- but that will make recording macros that change text
using undo very peculiar.  At this point, I disabled it out of
frustration.

Now how you would go about explainin this mode to a new Emacs user is
beyond me; since it involves several concepts that a beginner would
not have become used to to -- just the notion that doing undo will make
all kind of windows pop up is quite strange.

Re: A new user perspective about "Changes for emacs 28"

[Eli Zaretskii]

> From: ams@gnu.org (Alfred M. Szmidt)
> CC: eliz@gnu.org, nicola.manca85@gmail.com, spacibba@aol.com,
> 	emacs-devel@gnu.org, drew.adams@oracle.com, dgutov@yandex.ru
> Date: Wed, 09 Sep 2020 15:01:44 -0400
> 
> Now how you would go about explainin this mode to a new Emacs user is
> beyond me

We'd probably disable the visualizer by default.

Re: A new user perspective about "Changes for emacs 28"

[Dmitry Gutov]

On 09.09.2020 22:07, Eli Zaretskii wrote:
>> Now how you would go about explainin this mode to a new Emacs user is
>> beyond me
> We'd probably disable the visualizer by default.

undo-tree-undo doesn't show the visualizer either.

Only undo-tree-visualize does.

Re: A new user perspective about "Changes for emacs 28"

[Dmitry Gutov]

On 08.09.2020 17:20, Eli Zaretskii wrote:
> Once more complex
> situation arise, my opinion is that undo-tree is more complex and
> harder to grasp than the Emacs undo, so I don't think undo-tree is
> better suited to newbies than the default undo.

I'm pretty sure undo-tree is better for complex situations thanks to of 
its visualization interface.

But that's orthogonal to the question of suitability for newbies.

Re: A new user perspective about "Changes for emacs 28"

[Eli Zaretskii]

> Cc: nicola.manca85@gmail.com, spacibba@aol.com, drew.adams@oracle.com,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 8 Sep 2020 18:02:10 +0300
> 
> On 08.09.2020 17:20, Eli Zaretskii wrote:
> > Once more complex
> > situation arise, my opinion is that undo-tree is more complex and
> > harder to grasp than the Emacs undo, so I don't think undo-tree is
> > better suited to newbies than the default undo.
> 
> I'm pretty sure undo-tree is better for complex situations thanks to of 
> its visualization interface.

If visualization is the main advantage, we could have visualization
for the default undo as well.  That's not the complex part, and not
what differentiates between the 2 undo's.

Re: A new user perspective about "Changes for emacs 28"

[Dmitry Gutov]

On 08.09.2020 18:28, Eli Zaretskii wrote:

>> On 08.09.2020 17:20, Eli Zaretskii wrote:
>>> Once more complex
>>> situation arise, my opinion is that undo-tree is more complex and
>>> harder to grasp than the Emacs undo, so I don't think undo-tree is
>>> better suited to newbies than the default undo.
>>
>> I'm pretty sure undo-tree is better for complex situations thanks to of
>> its visualization interface.
> 
> If visualization is the main advantage, we could have visualization
> for the default undo as well.  That's not the complex part, and not
> what differentiates between the 2 undo's.

Having separate bindings shouldn't hurt either, especially in said 
complex situations.

And try to consider how the visualization would look. I think it would 
have to be like a tree (basically, like the one undo-tree paints). Then 
it would probably be logical to have at least two different commands 
which allow traversing the buffer states in both directions along the 
branches of that tree. And presto, we got undo-tree again.

Perhaps I'm lacking in imagination, though.

Re: A new user perspective about "Changes for emacs 28"

[Jack Kamm]

> And try to consider how the visualization would look. I think it would 
> have to be like a tree (basically, like the one undo-tree paints). Then 
> it would probably be logical to have at least two different commands 
> which allow traversing the buffer states in both directions along the 
> branches of that tree. And presto, we got undo-tree again.

undo-tree is great. I used to think it was superior to native undo, but
had to disable it due to the corruption bugs.

Recently, I started using selective undo (i.e. undo in region). In my
opinion, it's a killer feature of native undo, and even more useful than
the undo-tree -- in particular, I think it's usually quicker to find an
old edit with selective-undo, than it is with undo-tree.

undo-tree can use selective undo, but in the past it was considered
buggy, and the common recommendation was to disable it [1]. I'm not sure
if that's still the case, but if you think about it, selective undo
violates the tree structure of the undo history, so naturally seems a
poor fit with undo-tree.

Using selective-undo, revert-buffer, undo-only, and undo-redo-only, it
becomes a lot easier to navigate emacs' undo. But these features are not
immediately obvious; I had to read the Info page to learn about
them. Whereas, undo-tree is quickly grokked due to the nice
visualization.

[1] https://emacs.stackexchange.com/a/37399

Re: A new user perspective about "Changes for emacs 28"

[Howard Melman]

Jack Kamm <jackkamm@gmail.com> writes:

> Using selective-undo, revert-buffer, undo-only, and
> undo-redo-only, it becomes a lot easier to navigate emacs'
> undo. But these features are not immediately obvious; I
> had to read the Info page to learn about them. Whereas,
> undo-tree is quickly grokked due to the nice
> visualization.

I've seen in various posts people mention commands like
undo-redo, undo-redo-only, redo, redo-only, and I don't know
what they are referring to.  I understand how repeated uses
of undo works in emacs and what happens when you break a
chain of them, but it sounds like people are describing
something else.

I'm using Emacs 27.1 (the carbon port).  I have commands
`undo' and `undo-only' but no commands with redo in their
names other than `org-agenda-redo'.  In the emacs manual the
only index entry for redo refers to the Undo node which
doesn't describe any command named `redo' or `redo-only'.
I've tried undo-tree before but didn't care for it.  It has
a command called `undo-tree-redo' but nothing called
`redo-only'.

Could someone point me at some explanation of what they're
referring to when they say redo-only?  

-- 

Howard

Re: A new user perspective about "Changes for emacs 28"

[Jack Kamm]

> Could someone point me at some explanation of what they're
> referring to when they say redo-only?  

The command undo-redo (not undo-redo-only, my mistake) has been added to
simple.el for emacs 28. You'll have to build emacs from master to usue
it. It's basically the inverse of undo-only, it skips undo'ing anything
that isn't an undo.

Re: A new user perspective about "Changes for emacs 28"

[Vasilij Schneidermann]

[-- Attachment #1: Type: text/plain, Size: 332 bytes --]

> You'll have to build emacs from master to usue it.

This isn't true though.  I've backported it to 27.1 by copying the definitions
of `undo--last-change-was-undo-p` and `undo-redo` into my init file.  Works
great and might very well replace undo-tree for me (I've had random hangs with
it lately that make undoing text a gamble).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: A new user perspective about "Changes for emacs 28"

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: nicola.manca85@gmail.com, spacibba@aol.com, drew.adams@oracle.com,
>>  emacs-devel@gnu.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Tue, 8 Sep 2020 18:02:10 +0300
>> 
>> On 08.09.2020 17:20, Eli Zaretskii wrote:
>> > Once more complex
>> > situation arise, my opinion is that undo-tree is more complex and
>> > harder to grasp than the Emacs undo, so I don't think undo-tree is
>> > better suited to newbies than the default undo.
>> 
>> I'm pretty sure undo-tree is better for complex situations thanks to of 
>> its visualization interface.
>
> If visualization is the main advantage, we could have visualization
> for the default undo as well.  That's not the complex part, and not
> what differentiates between the 2 undo's.

I would like to connect this discussion back to some earlier discussions
about how to make Emacs more popular, and this recent what changes
people want to see.

As I see almost everyone agrees that Emacs has best undo-redo mechanism
that is out there, right?  I tend to agree with this. I think you should
"market" this much better then you do. First and foremost, I think you
should give it a bit more advanced term, something like:
"non-destructive text editing", rather then undo-redo. The new term
should not be a replacement but a completition to old undo-redo term.

Why such term?

1. It describes better how Emacs undo-redo works and also distincts
Emacs from other software which has simpler undo-redo facilitie.

2. It gives you opportunity to market a unique and distinctive Emacs
feature that actually gives more value to the user.

A popular photo-editing tool by a big software house is very proud to
market their non-destructive photo-editing tools and people are writing
blog posts and book chapters to point out the benefits and how to work
with it. Emacs should not be different in this regard.

Next, implement undo-tree visualisation (graph) as Eli suggests. No idea
if you can just adapt undo-tree code or have to write new. Personally I
don't use undo-tree nor have it installed longer; but I do think the
idea is very cool. Also, regardless if I personally see it just as a
gimmick, I think it is a distinctive feature of Emacs to have a
graphical and interactive visualisation of undo-redo history; I don't
know of any other text editor with such capability. It would be nice if
it used unicode characters to create more graph-like chart instead of
ascii chars.

I think the Emacs undo-redo and it's visualisation, can be one of so
called "selling points" when it comes to Emacs (one of many of course).

Another feature I would like to see is if it would be possible to
"freeze" (remove) undo-history in order to save memory. This operation
would remove old-undo information, like if the document was just
opened/created.

I would never thought that undo-redo in a piece of software can be such
a passionate discussion subject, but yet here we are ... :-)

Re: A new user perspective about "Changes for emacs 28"

[Ergus]

Hi Arthur:

The non technical part of the "popularity" problem is

1) the lack of interaction of core emacs developers with the communities
outside (github independent package developers, reddit, telegram groups)
It happens to me once that I knew about an error in a feature I
implemented because someone talk about it in a Telegram group about
emacs in Spanish. They didn't report the issue because they didn't know
how to do so (they were looking on github/issues as usual) but also
because they didn't know enough english.

2) "Publicity" I mean, we "haven't invested" / "don't know how" to sale
better what we have. It is like having a shop with amazing products no
advertisements, dark entrance but even if a client gets in; most of the
products are not exhibited but he has to ask for them sometimes in a
special code.



On Wed, Sep 09, 2020 at 07:03:09AM +0200, Arthur Miller wrote:
>Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Cc: nicola.manca85@gmail.com, spacibba@aol.com, drew.adams@oracle.com,
>>>  emacs-devel@gnu.org
>>> From: Dmitry Gutov <dgutov@yandex.ru>
>>> Date: Tue, 8 Sep 2020 18:02:10 +0300
>>>
>>> On 08.09.2020 17:20, Eli Zaretskii wrote:
>>> > Once more complex
>>> > situation arise, my opinion is that undo-tree is more complex and
>>> > harder to grasp than the Emacs undo, so I don't think undo-tree is
>>> > better suited to newbies than the default undo.
>>>
>>> I'm pretty sure undo-tree is better for complex situations thanks to of
>>> its visualization interface.
>>
>> If visualization is the main advantage, we could have visualization
>> for the default undo as well.  That's not the complex part, and not
>> what differentiates between the 2 undo's.
>
>I would like to connect this discussion back to some earlier discussions
>about how to make Emacs more popular, and this recent what changes
>people want to see.
>
>As I see almost everyone agrees that Emacs has best undo-redo mechanism
>that is out there, right?  I tend to agree with this. I think you should
>"market" this much better then you do. First and foremost, I think you
>should give it a bit more advanced term, something like:
>"non-destructive text editing", rather then undo-redo. The new term
>should not be a replacement but a completition to old undo-redo term.
>
>Why such term?
>
>1. It describes better how Emacs undo-redo works and also distincts
>Emacs from other software which has simpler undo-redo facilitie.
>
>2. It gives you opportunity to market a unique and distinctive Emacs
>feature that actually gives more value to the user.
>
>A popular photo-editing tool by a big software house is very proud to
>market their non-destructive photo-editing tools and people are writing
>blog posts and book chapters to point out the benefits and how to work
>with it. Emacs should not be different in this regard.
>
>Next, implement undo-tree visualisation (graph) as Eli suggests. No idea
>if you can just adapt undo-tree code or have to write new. Personally I
>don't use undo-tree nor have it installed longer; but I do think the
>idea is very cool. Also, regardless if I personally see it just as a
>gimmick, I think it is a distinctive feature of Emacs to have a
>graphical and interactive visualisation of undo-redo history; I don't
>know of any other text editor with such capability. It would be nice if
>it used unicode characters to create more graph-like chart instead of
>ascii chars.
>
>I think the Emacs undo-redo and it's visualisation, can be one of so
>called "selling points" when it comes to Emacs (one of many of course).
>
>Another feature I would like to see is if it would be possible to
>"freeze" (remove) undo-history in order to save memory. This operation
>would remove old-undo information, like if the document was just
>opened/created.
>
>I would never thought that undo-redo in a piece of software can be such
>a passionate discussion subject, but yet here we are ... :-)
>

Re: A new user perspective about "Changes for emacs 28"

[tomas]

[-- Attachment #1: Type: text/plain, Size: 384 bytes --]

On Wed, Sep 09, 2020 at 10:35:21AM +0200, Ergus wrote:
> Hi Arthur:
> 
> The non technical part of the "popularity" problem is
> 
> 1) the lack of interaction of core emacs developers with the communities
> outside (github independent package developers, reddit, telegram groups)

You depict it as if it were just in that one direction. This is
interesting.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: A new user perspective about "Changes for emacs 28"

[Ergus]

On Wed, Sep 09, 2020 at 10:41:16AM +0200, tomas@tuxteam.de wrote:
>On Wed, Sep 09, 2020 at 10:35:21AM +0200, Ergus wrote:
>> Hi Arthur:
>>
>> The non technical part of the "popularity" problem is
>>
>> 1) the lack of interaction of core emacs developers with the communities
>> outside (github independent package developers, reddit, telegram groups)
>
>You depict it as if it were just in that one direction. This is
>interesting.
>
>Cheers
> - t

I think that there is so much fragmentation in the user community
because we don't have anything "official" more dynamic and modern (or
familiar) than the mailing list.

I mean something equivalent to gitter/trello/github's issues/slack
channel. So the users create/find their own alternatives and this ends
in many sub communities.

The closest is the reddit channel where Eli interacts frequently. But of
course there is not any link to that in the emacs site, the readme or
anywhere.

Re: A new user perspective about "Changes for emacs 28"

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]

On Wed, Sep 09, 2020 at 12:00:19PM +0200, Ergus wrote:

[..]

> I think that there is so much fragmentation in the user community
> because we don't have anything "official" more dynamic and modern (or
> familiar) than the mailing list.

Yes, I see that. I try to ignore the little value judgement subliminally
packed in "modern" :-)

It'll be as difficult to "move" the mailing list people to...

> I mean something equivalent to gitter/trello/github's issues/slack
> channel. So the users create/find their own alternatives and this ends
> in many sub communities.

...gitter/trello/github (or reddit) as it'll be the other way around.
After all some stick to mail for good reasons (as some love github
for some other good reasons)...

> The closest is the reddit channel where Eli interacts frequently. But of
> course there is not any link to that in the emacs site, the readme or
> anywhere.

...so I think we'll have to live in a somewhat diverse landscape and
find ways around there.

"Multilingual" people (as you are, but also Eli) are an important part
of this, I think.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: A new user perspective about "Changes for emacs 28"

[Arthur Miller]

tomas@tuxteam.de writes:

> On Wed, Sep 09, 2020 at 12:00:19PM +0200, Ergus wrote:
>
> [..]
>
>> I think that there is so much fragmentation in the user community
>> because we don't have anything "official" more dynamic and modern (or
>> familiar) than the mailing list.
>
> Yes, I see that. I try to ignore the little value judgement subliminally
> packed in "modern" :-)
>
> It'll be as difficult to "move" the mailing list people to...
>
>> I mean something equivalent to gitter/trello/github's issues/slack
>> channel. So the users create/find their own alternatives and this ends
>> in many sub communities.
>
> ...gitter/trello/github (or reddit) as it'll be the other way around.
> After all some stick to mail for good reasons (as some love github
> for some other good reasons)...
>
>> The closest is the reddit channel where Eli interacts frequently. But of
>> course there is not any link to that in the emacs site, the readme or
>> anywhere.
>
> ...so I think we'll have to live in a somewhat diverse landscape and
> find ways around there.

I don't think that Emacs popularity has to do with how Emacs is developed.
Blender's popularity didn't rise in last few years because they switched
development to more "modern" platform, but because they changed the
application from using an obscure in-house interaction model to more
standard ("modern") interaction model as used in other applications.

> "Multilingual" people (as you are, but also Eli) are an important part
> of this, I think.

Emacs is not directly the most popular text editor/IDE amongst english
speaking programmers either, so I don't think it has anything to do with
the language per se, but it would certainly be a plus for Emacs if
manual was avialable in all worlds languages, as well as gui etc.

By the way, personally, I hate when I see error messages (or other) from
my OS or GCC in Swedish. In my opinion it was horrible idea to localize
GCC and stdlib error messages. If I get compile/error message I wish to
be able to copy it and search for it on SX/Google wherever. Having those
in local language (swedish in my case) is just useless; the community is
so small and hits are very few, unlike english speaking community. Same
goes for elisp and emacs, the "local" community is miniscule compared to
english speaking one.

I have LC_ALL=C in my .bashrc, so at least GCC spits compile errors in
english.

Re: A new user perspective about "Changes for emacs 28"

[Eli Zaretskii]

> Date: Wed, 9 Sep 2020 12:36:25 +0200
> From: tomas@tuxteam.de
> Cc: emacs-devel@gnu.org
> 
> "Multilingual" people (as you are, but also Eli) are an important part
> of this, I think.

I don't think I follow: what do you mean by "multilingual" in this
context, and how is that related to the issue at hand?

Re: A new user perspective about "Changes for emacs 28"

[tomas]

[-- Attachment #1: Type: text/plain, Size: 752 bytes --]

On Wed, Sep 09, 2020 at 05:36:32PM +0300, Eli Zaretskii wrote:
> > Date: Wed, 9 Sep 2020 12:36:25 +0200
> > From: tomas@tuxteam.de
> > Cc: emacs-devel@gnu.org
> > 
> > "Multilingual" people (as you are, but also Eli) are an important part
> > of this, I think.
> 
> I don't think I follow: what do you mean by "multilingual" in this
> context, and how is that related to the issue at hand?

Sorry. It was just a metaphor for people who communicate with several
communities -- as you do with reddit. Multi-medial, perhaps.

Some people are just too comfy in one environment (I'm one of those),
be it a mailing list, or some other discussion platform, and this is
definitely a factor towards fragmentation.

Cheers (and thanks!)
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: A new user perspective about "Changes for emacs 28"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

It is most unfortunate that any group of free software developers has
started using Slack for discussions.  Slack itself is nonfree
software, which means unjust software.  GNU packages must not
recommend the use of Slack.  To do so would be an own goal.

  > > The closest is the reddit channel where Eli interacts frequently. But of
  > > course there is not any link to that in the emacs site, the readme or
  > > anywhere.

Is it possible to communicate through that channel without running
any nonfree software?  (Including Javascript software?)

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: A new user perspective about "Changes for emacs 28"

[Robert Pluim]

>>>>> On Wed, 09 Sep 2020 22:38:28 -0400, Richard Stallman <rms@gnu.org> said:

    Richard> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
    Richard> [[[ whether defending the US Constitution against all enemies,     ]]]
    Richard> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    Richard> It is most unfortunate that any group of free software developers has
    Richard> started using Slack for discussions.  Slack itself is nonfree
    Richard> software, which means unjust software.  GNU packages must not
    Richard> recommend the use of Slack.  To do so would be an own goal.

    >> > The closest is the reddit channel where Eli interacts frequently. But of
    >> > course there is not any link to that in the emacs site, the readme or
    >> > anywhere.

    Richard> Is it possible to communicate through that channel without running
    Richard> any nonfree software?  (Including Javascript software?)

Thereʼs at least one emacs client for it, but it suffers from the same
issue as Gnus with the future changes to G-Suite: you need to log in
to reddit using a browser to generate the authentication
tokens. Logging in to www.reddit.com with LibreJS enabled fails for
me (although I get no warnings from LibreJS about nonfree Javascript).

Robert

Re: A new user perspective about "Changes for emacs 28"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  >     Richard> Is it possible to communicate through that channel without running
  >     Richard> any nonfree software?  (Including Javascript software?)

  > Thereʼs at least one emacs client for it, but it suffers from the same
  > issue as Gnus with the future changes to G-Suite: you need to log in
  > to reddit using a browser to generate the authentication
  > tokens. Logging in to www.reddit.com with LibreJS enabled fails for
  > me (although I get no warnings from LibreJS about nonfree Javascript).

Thanks for checking.

It follows that we cannot refer people to Reddit.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: A new user perspective about "Changes for emacs 28"

[Juri Linkov]

> I mean something equivalent to gitter/trello/github's issues/slack

Trello is a pale imitation of Org mode.

Re: A new user perspective about "Changes for emacs 28"

[Ricardo Wurmus]

Juri Linkov <juri@linkov.net> writes:

>> I mean something equivalent to gitter/trello/github's issues/slack
>
> Trello is a pale imitation of Org mode.

Yes, but it also provides something to its users that Org mode does not:
a visual concept of cards and stacks.  I know several people who are
overwhelmed by how “free” and associative Org mode is, and who enjoy the
rigidity of a simple enforced concept of cards and stacks.

Oh, it also makes working in *groups* much easier.  I have no idea how
to easily collaborate on one shared Org file with other people without
having to teach everyone version control first.

-- 
Ricardo

Re: A new user perspective about "Changes for emacs 28"

[Arthur Miller]

> On Wed, Sep 09, 2020 at 07:03:09AM +0200, Arthur Miller wrote:
>>Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> Cc: nicola.manca85@gmail.com, spacibba@aol.com, drew.adams@oracle.com,
>>>>  emacs-devel@gnu.org
>>>> From: Dmitry Gutov <dgutov@yandex.ru>
>>>> Date: Tue, 8 Sep 2020 18:02:10 +0300
>>>>
>>>> On 08.09.2020 17:20, Eli Zaretskii wrote:
>>>> > Once more complex
>>>> > situation arise, my opinion is that undo-tree is more complex and
>>>> > harder to grasp than the Emacs undo, so I don't think undo-tree is
>>>> > better suited to newbies than the default undo.
>>>>
>>>> I'm pretty sure undo-tree is better for complex situations thanks to of
>>>> its visualization interface.
>>>
>>> If visualization is the main advantage, we could have visualization
>>> for the default undo as well.  That's not the complex part, and not
>>> what differentiates between the 2 undo's.
>>
>>I would like to connect this discussion back to some earlier discussions
>>about how to make Emacs more popular, and this recent what changes
>>people want to see.
>>
>>As I see almost everyone agrees that Emacs has best undo-redo mechanism
>>that is out there, right?  I tend to agree with this. I think you should
>>"market" this much better then you do. First and foremost, I think you
>>should give it a bit more advanced term, something like:
>>"non-destructive text editing", rather then undo-redo. The new term
>>should not be a replacement but a completition to old undo-redo term.
>>
>>Why such term?
>>
>>1. It describes better how Emacs undo-redo works and also distincts
>>Emacs from other software which has simpler undo-redo facilitie.
>>
>>2. It gives you opportunity to market a unique and distinctive Emacs
>>feature that actually gives more value to the user.
>>
>>A popular photo-editing tool by a big software house is very proud to
>>market their non-destructive photo-editing tools and people are writing
>>blog posts and book chapters to point out the benefits and how to work
>>with it. Emacs should not be different in this regard.
>>
>>Next, implement undo-tree visualisation (graph) as Eli suggests. No idea
>>if you can just adapt undo-tree code or have to write new. Personally I
>>don't use undo-tree nor have it installed longer; but I do think the
>>idea is very cool. Also, regardless if I personally see it just as a
>>gimmick, I think it is a distinctive feature of Emacs to have a
>>graphical and interactive visualisation of undo-redo history; I don't
>>know of any other text editor with such capability. It would be nice if
>>it used unicode characters to create more graph-like chart instead of
>>ascii chars.
>>
>>I think the Emacs undo-redo and it's visualisation, can be one of so
>>called "selling points" when it comes to Emacs (one of many of course).
>>
>>Another feature I would like to see is if it would be possible to
>>"freeze" (remove) undo-history in order to save memory. This operation
>>would remove old-undo information, like if the document was just
>>opened/created.
>>
>>I would never thought that undo-redo in a piece of software can be such
>>a passionate discussion subject, but yet here we are ... :-)
>>
Ergus <spacibba@aol.com> writes:

> Hi Arthur:
>
> The non technical part of the "popularity" problem is
>
> 1) the lack of interaction of core emacs developers with the communities
> outside (github independent package developers, reddit, telegram groups)
> It happens to me once that I knew about an error in a feature I
> implemented because someone talk about it in a Telegram group about
> emacs in Spanish. They didn't report the issue because they didn't know
> how to do so (they were looking on github/issues as usual) but also
> because they didn't know enough english.
I agree that language and knowledge (being informed about Emacs)
barriers can be part of reasons why Emacs is not more popular.
I am guilty of it myself. Numerous times I didn't know Emacs can do
something I wished it could, because I didn't invest enough time in
RTFM. Part of reason is also that I have almost all gui features turned
off and I am probably not exploring it enough myself.

But that is problem to me as a person not the Emacs. How good language
translations are and if there exist depends on the community not the
core developers. Developers on their own can't ensure that Emacs and
manual are translated in all possible languages and locales, they can
only ensure infrastructure to make translations possible and leave it to
the community to realize those translations.

It would be, though, unrealistic to expect ccore developers to take part
in social media discussions just to "market" Emacs. Also I know that some
does that at least on Reddit in Emacs group. 

> 2) "Publicity" I mean, we "haven't invested" / "don't know how" to sale
> better what we have. It is like having a shop with amazing products no
> advertisements, dark entrance but even if a client gets in; most of the
> products are not exhibited but he has to ask for them sometimes in a
> special code.
>
>
Yes, you are definitely correct about Emacs not marketing some of it
awesomnes enough! :-)

Re: A new user perspective about "Changes for emacs 28"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > 1) the lack of interaction of core emacs developers with the communities
  > outside (github independent package developers, reddit, telegram groups)
  > It happens to me once that I knew about an error in a feature I
  > implemented because someone talk about it in a Telegram group about
  > emacs in Spanish. They didn't report the issue because they didn't know
  > how to do so (they were looking on github/issues as usual) but also
  > because they didn't know enough english.

If people are blocked by a language barrier, I doubt we could do
anything effective to help them, so we may as well not worry about it
much.

However, if there are people who could report it if only they knew
how, that is something we could help with.  We could write a short
invitation to report bugs, which gives briefly the info and points
at the Emacs Manual's explanation, and we could send that to every
forum where it would reach some interested people.  It could say
which methods of communication we don't use, and why.

As for Spanish speakers, there are probably some Emacs developers that
could read bug reports in Spanish.  Should we write, in Spanish, a
brief guide for sending bug reports to us in Spanish?




-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: A new user perspective about "Changes for emacs 28"

[Dmitry Gutov]

On 09.09.2020 08:03, Arthur Miller wrote:
> As I see almost everyone agrees that Emacs has best undo-redo mechanism
> that is out there, right?  I tend to agree with this.

Do you mean 'M-x undo'?

As you can see from the recent messages, a lot of users prefer undo-tree 
or even undo-only+undo-redo rather than the default undo.

Re: A new user perspective about "Changes for emacs 28"

[Arthur Miller]

Dmitry Gutov <dgutov@yandex.ru> writes:

> As you can see from the recent messages, a lot of users prefer undo-tree or even
> undo-only+undo-redo rather than the default undo.
Yes, but as I understand the situtaion a lot of users, usually those
that are new to Emacs does not get at the start how Emacs undo works,
and they resort to something simpler they are familiar with.

That is why I suggested to start talking about non-destructive text
editing to emphasize more on how undo feature in Emacs works. I see no
problems with having to different undo-mechanisms either, the original
one, and one simpler. Simpler could work as people are used from other
applications and could be default, and could be disabled by setting some
nil value for some variable so experienced user can use original undo.

Undo tree as a visualisation is very cool feature, and could be one of
unique Emacs features, if it could visualise any undo/redo history. I
don't use undo-tree myself, but I think that graphical representation of
undo history is a cool even if mostly gimmicky.

Re: A new user perspective about "Changes for emacs 28"

[Ergus]

One thing at the time. Having an alternative to traditional undo that
could be enabled with one of the profiles we were discussing before or
throw an option in the menubar is (in my opinion) a good first step.

If we decide in the future to improve that with visualization or any
other fancy option it is orthogonal to this change as that can be
customized with a simple option (maybe (setq undo-redo-visualize t) ;p)

On Fri, Sep 11, 2020 at 01:29:42PM +0200, Arthur Miller wrote:
>Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> As you can see from the recent messages, a lot of users prefer undo-tree or even
>> undo-only+undo-redo rather than the default undo.
>Yes, but as I understand the situtaion a lot of users, usually those
>that are new to Emacs does not get at the start how Emacs undo works,
>and they resort to something simpler they are familiar with.
>
>That is why I suggested to start talking about non-destructive text
>editing to emphasize more on how undo feature in Emacs works. I see no
>problems with having to different undo-mechanisms either, the original
>one, and one simpler. Simpler could work as people are used from other
>applications and could be default, and could be disabled by setting some
>nil value for some variable so experienced user can use original undo.
>
>Undo tree as a visualisation is very cool feature, and could be one of
>unique Emacs features, if it could visualise any undo/redo history. I
>don't use undo-tree myself, but I think that graphical representation of
>undo history is a cool even if mostly gimmicky.
>

Re: A new user perspective about "Changes for emacs 28"

[Jack Kamm]

Ergus <spacibba@aol.com> writes:

> One thing at the time. Having an alternative to traditional undo that
> could be enabled with one of the profiles we were discussing before or
> throw an option in the menubar is (in my opinion) a good first step.

I don't think this needs a profile -- just default keybindings for
undo-only and undo-redo. In my usage, they don't replace the standard
undo, rather they complement it.

Re: A new user perspective about "Changes for emacs 28"

[Ergus]

On Fri, Sep 11, 2020 at 07:53:38AM -0700, Jack Kamm wrote:
>Ergus <spacibba@aol.com> writes:
>
>> One thing at the time. Having an alternative to traditional undo that
>> could be enabled with one of the profiles we were discussing before or
>> throw an option in the menubar is (in my opinion) a good first step.
>
>I don't think this needs a profile -- just default keybindings for
>undo-only and undo-redo. In my usage, they don't replace the standard
>undo, rather they complement it.
>
We don't have too many short bindings available for this.

Also having two "undo" I think is gonna be even more confusing for the
users.

Re: A new user perspective about "Changes for emacs 28"

[Eli Zaretskii]

> Date: Fri, 11 Sep 2020 17:03:30 +0200
> From: Ergus <spacibba@aol.com>
> Cc: Arthur Miller <arthur.miller@live.com>, emacs-devel@gnu.org,
> 	nicola.manca85@gmail.com, ams@gnu.org,
> 	Dmitry Gutov <dgutov@yandex.ru>, Eli Zaretskii <eliz@gnu.org>,
> 	drew.adams@oracle.com
> 
> Also having two "undo" I think is gonna be even more confusing for the
> users.

Why would it be confusing?  We already have several buffer-switching
commands and several commands to show the list of all buffers, and I
didn't hear about any confusion due to that.

Re: A new user perspective about "Changes for emacs 28"

[Dmitry Gutov]

On 11.09.2020 18:16, Eli Zaretskii wrote:
>> Also having two "undo" I think is gonna be even more confusing for the
>> users.
> Why would it be confusing?  We already have several buffer-switching
> commands and several commands to show the list of all buffers, and I
> didn't hear about any confusion due to that.

The usage patterns of buffer switching commands and undo commands are 
going to be hella different.

And I'm pretty sure Jack is more of an exception (as a person using both 
kinds of undo commands) rather than the rule.

Re: A new user perspective about "Changes for emacs 28"

[Arthur Miller]

Ergus <spacibba@aol.com> writes:

> On Fri, Sep 11, 2020 at 07:53:38AM -0700, Jack Kamm wrote:
>>Ergus <spacibba@aol.com> writes:
>>
>>> One thing at the time. Having an alternative to traditional undo that
>>> could be enabled with one of the profiles we were discussing before or
>>> throw an option in the menubar is (in my opinion) a good first step.
>>
>>I don't think this needs a profile -- just default keybindings for
>>undo-only and undo-redo. In my usage, they don't replace the standard
>>undo, rather they complement it.
>>
> We don't have too many short bindings available for this.
>
> Also having two "undo" I think is gonna be even more confusing for the
> users.
With different key-bindings/menu entries and good documentation, it does
not need to be confusing. I would emphasize in documentation
non-destructive editing history and explain better how Emacs lets one go
back and effort between edits; how the editing history branches in a
tree-like structure and how it compares to "linear" edit history as
(usually) recorded in other applications as a simple stack. Here I would
tack on "undo-tree like" interactive graphical visualisation of
undo/redo history.

Re: A new user perspective about "Changes for emacs 28"

[Dmitry Gutov]

On 12.09.2020 16:02, Arthur Miller wrote:
> With different key-bindings/menu entries and good documentation, it does
> not need to be confusing. I would emphasize in documentation
> non-destructive editing history and explain better how Emacs lets one go
> back and effort between edits;

If the current 'undo' command was renamed to something longer (with a 
corresponding explanation), that could work.

Re: A new user perspective about "Changes for emacs 28"

[chad]

[-- Attachment #1: Type: text/plain, Size: 2378 bytes --]

Starting point for a concrete proposal:
* Rename undo in simple.el to something descriptive.
** Perhaps undo-sequence or undo-branching?
* Create an alias or dispatcher undo that calls the renamed simple.el
undo by default.
* Create a customize option (or similar) to allow the user to choose
between the current simple.el undo method, the "undo/redo-only" method
bindings, and perhaps undo-tree.
* Change the default action of C-z, at least in gui frames, to call the
above undo rather than suspend frame.
** Also add a binding for C-Z (aka C-S-z) to call redo-only. I'm unsure if
this should be bound to something else if the "simple.el undo" method is
chosen, or if an alternative binding for C-Z would be better there.
* Add a user option to revert this change for C-z. I'm unclear if this is
better implemented by changing the binding or by adding it as an option to
the dispatcher concept above, perhaps something like
"undo-or-suspend-frame".

Reasoning:
I believe that people using emacs in a gui context tend to have a
system-wide method for switching between active windows/applications, and
they don't use the C-z binding for it. This is certainly true of the
people I see today who don't use emacs, and was true of the new and
non-new, non-expert emacs users I used to see often. It was usually true of
expert emacs users that I knew personally that they rebound C-z.
This gets us an intuitive keybinding for gui computer users of various
types that doesn't hide their window (when I used to work in user support
way back when, we *frequently* found users surprised by "my emacs
disappeared"), and it connects a very common keybinding (muscle memory for
a vast body of users) to a familiar/powerful decision point for emacs.
The cost is the loss of suspend-frame on C-z, which seems most likely to be
an issue for either people who are very capable of reverting it, and for
people who are very used to the control-z behavior inside a tty. I have
personally spent a *lot* of time using emacs in tty-only environments with
C-z rebound, and preferred it that way. Anecdotally, people who spend a lot
of time in emacs inside screen or tmux prefer to rebind C-z away from
suspend, but of course tastes vary.

I'm sure there are issues with this, even setting aside the very strong
small-c-conservatism of long-time emacs users on this list; what are they?

Thanks,
~Chad

[-- Attachment #2: Type: text/html, Size: 2653 bytes --]

Re: A new user perspective about "Changes for emacs 28"

[Dmitry Gutov]

On 14.09.2020 01:13, chad wrote:
> ** Perhaps undo-sequence or undo-branching?

Maybe undo-persistent or persistent-undo.

Re: A new user perspective about "Changes for emacs 28"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > * Rename undo in simple.el to something descriptive.
  > ** Perhaps undo-sequence or undo-branching?

To rename the command would be an incompatible change that would break
programs.  To define an alias would not be a problem, but we would
need to think of a good one.  I don't see any resemblance between
undo-sequence or undo-branching and what undo does.

Perhaps undo-or-redo would be a meaningful name.

  > * Change the default action of C-z, at least in gui frames, to call the
  > above undo rather than suspend frame.

I don't like making the default bindings for important commands
vary for different types of frames.  On tty frames we NEED suspend-frame.

But we could have a mode to rebind keys which would rebind C-z.

  > ** Also add a binding for C-Z (aka C-S-z) to call redo-only. I'm unsure if
  > this should be bound to something else if the "simple.el undo" method is
  > chosen, or if an alternative binding for C-Z would be better there.

Having C-z be different is ok in a special mode to rebind keys, but
in the default bindings we should not start making shift significant
for control keys.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: A new user perspective about "Changes for emacs 28"

[Alfred M. Szmidt]

     > * Change the default action of C-z, at least in gui frames, to call the
     > above undo rather than suspend frame.

   I don't like making the default bindings for important commands
   vary for different types of frames.  On tty frames we NEED suspend-frame.

INCF.

   But we could have a mode to rebind keys which would rebind C-z.

Maybe it could be part of cua-mode; and then there could be a cua-mode
enable button or something like that in the splash screen.

Re: A new user perspective about "Changes for emacs 28"

[Dmitry Gutov]

On 11.09.2020 14:29, Arthur Miller wrote:
> Undo tree as a visualisation is very cool feature, and could be one of
> unique Emacs features, if it could visualise any undo/redo history. I
> don't use undo-tree myself, but I think that graphical representation of
> undo history is a cool even if mostly gimmicky.

It's not a gimmick. The buffer has its own set of commands with 
navigation along the branches of the tree.

And only when using them I really did, or several occasions, feel the 
benefit of Emacs's undo history data structure.

Going along the branches of the undo tree, switching them at will, and 
skipping over some branches in favor older changes really makes the 
process easier to understand and saves time significantly.

Re: A new user perspective about "Changes for emacs 28"

[Arthur Miller]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 11.09.2020 14:29, Arthur Miller wrote:
>> Undo tree as a visualisation is very cool feature, and could be one of
>> unique Emacs features, if it could visualise any undo/redo history. I
>> don't use undo-tree myself, but I think that graphical representation of
>> undo history is a cool even if mostly gimmicky.
>
> It's not a gimmick. The buffer has its own set of commands with navigation along
> the branches of the tree.
I am refering to the drawing itself. When it comes to using undo, I am
sure you could feed data into helm (or other completion system) and
have a list of branches with fuzzy completion instead of graphical image
which probably would be as usefull or even more useful that graphical
tree. But as I said, I think the graphical representation itself is cool
and as you describe, for some users more clear option. I just undo with
M-x undo, in my case it is bound to C-_ and works just fine for me.

> And only when using them I really did, or several occasions, feel the benefit of
> Emacs's undo history data structure.
>
> Going along the branches of the undo tree, switching them at will, and skipping
> over some branches in favor older changes really makes the process easier to
> understand and saves time significantly.
Sure, whatever works. I didn't yet have encountered such case for
myself; I tried undo-tree some years ago and uninstalled it since I
never used it. 

Re: A new user perspective about "Changes for emacs 28"

[Dmitry Gutov]

On 11.09.2020 18:08, Arthur Miller wrote:

>> It's not a gimmick. The buffer has its own set of commands with navigation along
>> the branches of the tree.
> I am refering to the drawing itself. When it comes to using undo, I am
> sure you could feed data into helm (or other completion system) and
> have a list of branches with fuzzy completion instead of graphical image
> which probably would be as usefull or even more useful that graphical
> tree.

It's hard for me to imagine how this can work at all, much less how it 
would work better than navigation in the said tree.

> But as I said, I think the graphical representation itself is cool
> and as you describe, for some users more clear option. I just undo with
> M-x undo, in my case it is bound to C-_ and works just fine for me.

And I most of the time use the undo-tree-undo and undo-tree-redo 
commands which are more or less analogous to undo-only and undo-redo.

Using its graphical UI is indeed a somewhat rare occurrence.

Re: A new user perspective about "Changes for emacs 28"

[Stefan Monnier]

>> As you can see from the recent messages, a lot of users prefer undo-tree or even
>> undo-only+undo-redo rather than the default undo.
> Yes, but as I understand the situtaion a lot of users, usually those
> that are new to Emacs does not get at the start how Emacs undo works,
> and they resort to something simpler they are familiar with.

That does likely match those users who prefer undo-only+undo-redo
(which provides the simple-and-restrictive form of undo that's most
common).

But not those who prefer undo-tree (which gives you just as much power
as Emacs's undo, with even more control).


        Stefan

Re: A new user perspective about "Changes for emacs 28"

[Stefan Monnier]

> But not those who prefer undo-tree (which gives you just as much power
> as Emacs's undo, with even more control).

BTW, I think using the `undo-equiv-table` we should be able to make our
undo system more beginner-friendly, e.g. by providing undo and redo
*and* telling the user when he's reaching a point in the undo history
(tree) where there's a choice to be made between undo-only and redoing
something that was undone earlier.


        Stefan

Re: A new user perspective about "Changes for emacs 28"

[Jack Kamm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> BTW, I think using the `undo-equiv-table` we should be able to make our
> undo system more beginner-friendly, e.g. by providing undo and redo
> *and* telling the user when he's reaching a point in the undo history
> (tree) where there's a choice to be made between undo-only and redoing
> something that was undone earlier.

This would be a really nice feature that would make navigating the undo
history easier, for both old and new users.

Re: A new user perspective about "Changes for emacs 28"

[Arthur Miller]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> But not those who prefer undo-tree (which gives you just as much power
>> as Emacs's undo, with even more control).
>
> BTW, I think using the `undo-equiv-table` we should be able to make our
> undo system more beginner-friendly, e.g. by providing undo and redo
> *and* telling the user when he's reaching a point in the undo history
> (tree) where there's a choice to be made between undo-only and redoing
> something that was undone earlier.
Yes, it sounds like a good thing. Just give a way to turn it off.

Re: A new user perspective about "Changes for emacs 28"

[Alfred M. Szmidt]

   > As I see almost everyone agrees that Emacs has best undo-redo mechanism
   > that is out there, right?  I tend to agree with this.

   Do you mean 'M-x undo'?

   As you can see from the recent messages, a lot of users prefer undo-tree 
   or even undo-only+undo-redo rather than the default undo.

One shouldn't take the very small amount of users that are on
emacs-devel as a metric, there are plenty of users who prefer the
default undo behaviour too.

Re: A new user perspective about "Changes for emacs 28"

[Dmitry Gutov]

On 11.09.2020 16:15, Alfred M. Szmidt wrote:
>     > As I see almost everyone agrees that Emacs has best undo-redo mechanism
>     > that is out there, right?  I tend to agree with this.
> 
>     Do you mean 'M-x undo'?
> 
>     As you can see from the recent messages, a lot of users prefer undo-tree
>     or even undo-only+undo-redo rather than the default undo.
> 
> One shouldn't take the very small amount of users that are on
> emacs-devel as a metric,

I don't. My observations usually come from outside of emacs mailing 
lists, but having such examples here is easier to refer to.

> there are plenty of users who prefer the
> default undo behaviour too.

I'm sure there are plenty of users who prefer either approach, as well 
as a significant fraction who got used to the current undo just because 
it's Emacs's default, and could have adapted to a different default just 
the same.

Only one of these approaches is familiar to non-Emacs users, however, 
and would make Emacs a bit more welcoming to beginners.

Custom Et Al: Build-Up The Underlying Platform was Re: A new user perspective about "Changes for emacs 28"

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 3331 bytes --]

The discussion around how to bring in new users etc is healthy as long
as it moves the ball forward.

Experience tells us that there are multiple directions in which we can
move,  some that will bear fruit, some that will wither and go away.

But independent of which of those branches/offshoots survive, making the
underlying platform, AKA Emacs' extension/configuration layer more
robust and flexible  is work that will stand us in good stead over the
long term.

From that perspective, I hope we can put some energy into making the
underlying M-x custom more robust --- see below for what I mean:

20+ years ago, M-x custom came to Emacs, initially disliked by all those
of us who prefered writing elisp in our init files. Over time though it
has definitely landed well and made Emacs easier to configure --- to the
extent that even  folks who are happy to write elisp by hand in their
setup use it to varying degrees.

that's the good half of Custom.

Custom however is also showing its age, here are some personal opinions
about its shortcomings:

A. It has the disadvantage of dumping all settings into a single file,
   feels like the Windows Registry and can be fragile.

   B. Tends to accumulate cruft, eg customizations for packages that
      dont exist linger in the customization file

      C. Custom scares you  away from touching its setup --- especially
         "the only one of these forms  can appear" bit that forces all
         settings into a single file.

         D. I think custom themes are a great idea but it feels like it
            was "started but never finished".

            E. A dual to custom is use-package that has the virtue of
               isolating package-specific setup to a package-specific
               form in your setup, so you stop using the package and
               there is no cruft left behind (except ... that custom can
               still grab some of those  settings  and dump it into your
               custom file).

               So while we debate the pros/cons of various features, it
               might be a good investment of  time to  rethink and
               evolve custom to become more robust along various axies,
               since any user-friendly layers of
               preferences/customizations we would add could all use the
               underlying infrastructure to advantage.
Dmitry Gutov <dgutov@yandex.ru> writes:

> On 07.09.2020 21:08, Ergus wrote:
>
>>> - undo-tree-mode
>> Undo tree had some problems in the past. But if you want the basic
>> undo/redo behavior there is something already in vanilla (as usual a bit
>> hidden):
>> (global-set-key [remap undo] 'undo-only)
>> (global-set-key (kbd "C-M-_") 'undo-redo)
>> which I discovered after asking here and fighting with undo tree for
>> almost a year.
>
> Good point.
>
> undo-tree has been stable for me lately, but it might be overkill for
> a lot of users, and the default undo behavior is... exotic.
>
> So I think ideally we'd switch to the above key mappings by
> default. But since this is going to be a hard sell, at least this
> option should be better documented/advertised, maybe even on the new
> splash screen people have imagined/mentioned.
>

-- 
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: Custom Et Al: Build-Up The Underlying Platform was Re: A new user perspective about "Changes for emacs 28"

[Daniel Martín]

"T.V Raman" <raman@google.com> writes:

>
> A. It has the disadvantage of dumping all settings into a single file,
>    feels like the Windows Registry and can be fragile.

For separating customizations into multiple files there is "initsplit"
(https://www.emacswiki.org/emacs/InitSplit). Maybe it's possible to
include its functionality as part of Custom.

--
Daniel Martín

Re: Custom Et Al: Build-Up The Underlying Platform was Re: A new user perspective about "Changes for emacs 28"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > For separating customizations into multiple files there is "initsplit"
  > (https://www.emacswiki.org/emacs/InitSplit). Maybe it's possible to
  > include its functionality as part of Custom.

I am sure we can implement the basic idea.  What I wonder about is,
how to split the settings up?  Based on what sort of plan or system?

If we have a clear answer for that, it should be a straightforward
matter of doing work.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Custom Et Al: Build-Up The Underlying Platform was Re: A new user perspective about "Changes for emacs 28"

[Tim Cross]

[-- Attachment #1: Type: text/plain, Size: 2918 bytes --]

I largely agree with Raman's points. In particular, the problem of stuff
building up in the custom file (or section). To make it worse, the format
can be fragile, especially if you want to try and edit it to clean it up
(not a big issue if your an experienced elisper, but if your not....). I
have also experienced additional items being added to the custom section
when I have used custom to set some values. At odd times I've seen values
added which are not values I have customized.

It might also be worth having some sort of tool which could check custom
definitions. I frequently see warnings about custom value mismatches. These
are often caused when something is defined as a customizable value, but the
code has changed and updating the custom definition has not been updated to
match the code changes. Some sort of tool which check custom definitions
for completeness and alerted developers to definition and initialisation
mismatches might be useful.

Given the growth in custom usage, perhaps a better approach, rather than
the 'custom section' or custom file would be to have custom write
individual files into a ~/.emacs.d/custom directory? This could be based on
the custom group or package name or perhaps add an additional field to the
custom definition which specifies the name of the file to use. Emacs could
then look in this directory at some pint in the startup process and consume
the files in the custom directory or perhaps the require function could be
modified so that libraries/modules look for a corresponding custom file
when they are loaded? A big advantage of the individual files is that it is
easy to remove a configuration and it wold likely be less fragile than the
existing custom section. The drawback is that having lots of small custom
files might adversely impact init time (unless you can do something like
add it to require or load etc so that it is only read when the associated
code is actually loaded).

On Wed, 9 Sep 2020 at 13:52, Richard Stallman <rms@gnu.org> wrote:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > For separating customizations into multiple files there is "initsplit"
>   > (https://www.emacswiki.org/emacs/InitSplit). Maybe it's possible to
>   > include its functionality as part of Custom.
>
> I am sure we can implement the basic idea.  What I wonder about is,
> how to split the settings up?  Based on what sort of plan or system?
>
> If we have a clear answer for that, it should be a straightforward
> matter of doing work.
>
>
> --
> Dr Richard Stallman
> Chief GNUisance of the GNU Project (https://gnu.org)
> Founder, Free Software Foundation (https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)
>
>
>
>

-- 
regards,

Tim

--
Tim Cross

[-- Attachment #2: Type: text/html, Size: 3841 bytes --]

RE: Custom Et Al: Build-Up The Underlying Platform was Re: A new user perspective about "Changes for emacs 28"

[Drew Adams]

> From: Tim Cross ...

Lots of interesting suggestions and observations.

In particular, this one:

  rather than the 'custom section' or custom file
  would be to have custom write individual files
  into a ~/.emacs.d/custom directory?

(I'd prefer that the dir location be the value of
a user option, with ~/.emacs.d/custom as default value.  But I think the idea is a good one.)
___


One thing I wouldn't mind having is some kind of timestamp on each `custom-set-variables' and `custom-set-faces' entry.  Or something equivalent.  Or optional sorting by recency of modification.  Or maybe such info in a separate log file.

Just a spur-of-the-moment thought, not carefully considered.  It comes from seeing an entry and wondering when the hell I added it (or why). ;-)

Re: Custom Et Al: Build-Up The Underlying Platform was Re: A new user perspective about "Changes for emacs 28"

[Ergus]

On Wed, Sep 09, 2020 at 08:53:14AM -0700, Drew Adams wrote:
>> From: Tim Cross ...
>
>Lots of interesting suggestions and observations.
>
>In particular, this one:
>
>  rather than the 'custom section' or custom file
>  would be to have custom write individual files
>  into a ~/.emacs.d/custom directory?
>
>(I'd prefer that the dir location be the value of
>a user option, with ~/.emacs.d/custom as default value.  But I think the idea is a good one.)
>___
>
>
>One thing I wouldn't mind having is some kind of timestamp on each `custom-set-variables' and `custom-set-faces' entry.  Or something equivalent.  Or optional sorting by recency of modification.  Or maybe such info in a separate log file.
>
>Just a spur-of-the-moment thought, not carefully considered.  It comes from seeing an entry and wondering when the hell I added it (or why). ;-)

In general having more and more files to read on startup is bad for
startup time and organization (not all of us have ssd).

Improving the current custom but sorting, grouping or anything is in my
opinion a better approach.

I would also prefer that the custom file will be separated by default to
prevent emacs changing the user's init file so it can be tracked with
git without needing:

```
(setq custom-file (expand-file-name "custom.el" user-emacs-directory))

(unless (file-exists-p custom-file)
   (write-region "" nil custom-file))

(load custom-file)
```

Re: Custom Et Al: Build-Up The Underlying Platform was Re: A new user perspective about "Changes for emacs 28"

[T.V Raman]

If loading multiple files is an optimization concern, that can be
dealt with in a manner similar to  package-quickstart --- 

Ergus writes:
 > On Wed, Sep 09, 2020 at 08:53:14AM -0700, Drew Adams wrote:
 > >> From: Tim Cross ...
 > >
 > >Lots of interesting suggestions and observations.
 > >
 > >In particular, this one:
 > >
 > >  rather than the 'custom section' or custom file
 > >  would be to have custom write individual files
 > >  into a ~/.emacs.d/custom directory?
 > >
 > >(I'd prefer that the dir location be the value of
 > >a user option, with ~/.emacs.d/custom as default value.  But I think the idea is a good one.)
 > >___
 > >
 > >
 > >One thing I wouldn't mind having is some kind of timestamp on each `custom-set-variables' and `custom-set-faces' entry.  Or something equivalent.  Or optional sorting by recency of modification.  Or maybe such info in a separate log file.
 > >
 > >Just a spur-of-the-moment thought, not carefully considered.  It comes from seeing an entry and wondering when the hell I added it (or why). ;-)
 > 
 > In general having more and more files to read on startup is bad for
 > startup time and organization (not all of us have ssd).
 > 
 > Improving the current custom but sorting, grouping or anything is in my
 > opinion a better approach.
 > 
 > I would also prefer that the custom file will be separated by default to
 > prevent emacs changing the user's init file so it can be tracked with
 > git without needing:
 > 
 > ```
 > (setq custom-file (expand-file-name "custom.el" user-emacs-directory))
 > 
 > (unless (file-exists-p custom-file)
 >    (write-region "" nil custom-file))
 > 
 > (load custom-file)
 > ```

-- 
♉Id: kg:/m/0285kf1  🦮♉

--
♉Id: kg:/m/0285kf1  🦮♉

Re: Custom Et Al: Build-Up The Underlying Platform was Re: A new user perspective about "Changes for emacs 28"

[Ergus]

>If loading multiple files is an optimization concern, that can be
>dealt with in a manner similar to  package-quickstart ---
>

It could, but it will add an extra complexity level for something that
is actually very simple, just needs some improvement in the current
format and maybe some comments here and there with quotations.

A custom-quick-start at the end will be a generated file similar to what
we have now right? So why split to merge latter?

The custom file at the end must be modified and managed by the custom
interface and the user direct interaction with that should be
minimal. So grouping and organizing that generated output a bit better
could be enough (I think)

Re: Custom Et Al: Build-Up The Underlying Platform was Re: A new user perspective about "Changes for emacs 28"

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1203 bytes --]

Richard Stallman <rms@gnu.org> writes:

My recommendation based on some of the present drawbacks I enumerated
might be to split the custom file into per-package customizations plus
an emacs-core piece. That might leave too many small files though which
is the other end of the pendulum's swing with respect to the
windows-registry single file failure, ie the UNIX world of a zillion
dot-files  --- but given the experience of both worlds, perhaps we can
find a good middle ground.> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > For separating customizations into multiple files there is "initsplit"
>   > (https://www.emacswiki.org/emacs/InitSplit). Maybe it's possible to
>   > include its functionality as part of Custom.
>
> I am sure we can implement the basic idea.  What I wonder about is,
> how to split the settings up?  Based on what sort of plan or system?
>
> If we have a clear answer for that, it should be a straightforward
> matter of doing work.

-- 
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: Custom Et Al: Build-Up The Underlying Platform was Re: A new user perspective about "Changes for emacs 28"

[Juri Linkov]

> My recommendation based on some of the present drawbacks I enumerated
> might be to split the custom file into per-package customizations plus
> an emacs-core piece. That might leave too many small files though which
> is the other end of the pendulum's swing with respect to the
> windows-registry single file failure, ie the UNIX world of a zillion
> dot-files  --- but given the experience of both worlds, perhaps we can
> find a good middle ground.

+1  To support multiple customization locations, Custom-save should
scan all loaded init files for custom-set-variables and update all places
where the saved variable was mentioned.

Re: Custom Et Al: Build-Up The Underlying Platform was Re: A new user perspective about "Changes for emacs 28"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > My recommendation based on some of the present drawbacks I enumerated
  > might be to split the custom file into per-package customizations plus
  > an emacs-core piece.

THat's an example of a fixed subdivision scheme, one that would be the
same for all users.

The other alternative I see would be for the user to choose how to
subdivide it.  I could not tell which one people had in mind.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: A new user perspective about "Changes for emacs 28"

[Ergus]

Errata:

Which-key IS in elpa. But an obsolete version.