RE: [External] : Re: Gitlab Migration

[Drew Adams <drew.adams@oracle.com>]

> > I won't speak to those, apart from agreeing
> > about `indent-tabs-mode'.  But I have doubts
> > about `auto-save-visited-mode' (as opposed
> > to just `auto-save-mode').
> 
> These #file# are not what people expect as well as doing recovery. Auto
> save in the actual file is more consistent with others.

That may be true; I don't doubt it (or doubt you).

But Emacs intentionally and forthrightly has
buffers, as a separate thing and user concept
from files.  People don't expect buffers, but
they're important to Emacs and using Emacs,
even for newbies.

In Emacs, does it make sense to automatically
save all changes to a buffer periodically?
Out of the box?  I don't think so, a priori,
but let's see what others think about that.

There's a reason that Emacs auto-saves in a
separate file (and gives you ways to sync).
And that reason is...: BUFFERS are a thing.

> > I'm not in favor of turning on those electric
> > modes by default.  That behavior might be
> > compatible with some other editors, but it's
> > not compatible with the default behavior of
> > other other-editors.  And it's not compatible
> > with many other (non-editor) apps that allow
> > code and other-text editing.
> 
> Please expand; we're trying to be concrete here and gauge what's the
> most common behavior in the editors landscape w.r.t different features.

I was thinking of `electric-pair-mode' (not the
indenting), sorry.  Do most other editors
automatically insert closing delimiters etc.?
Even for non-code text?

I use doc-production tools all day long, for
software doc (code), and none of the tools I
and other writers use do that, even for code
examples.  (And I'm glad they don't.)

I can see Emacs turning on `electric-pair-mode'
automatically for this or that programming mode,
or even for all programming modes, using
`electric-pair-local-mode' on a mode hook.  But
turning it on globally?  Why would that be a
good thing?

(Again, I wouldn't have a problem with such a
change, for my own use - easy enough to turn
it off.)

> > Not in favor of the others, but OK (easy
> > to flip).  I don't use a tool bar, but it
> > might be helpful for newbies - at least
> > that was the idea.
> 
> In my knowledge, there is no other editor - code or not - that has a UI
> button for saving, copying or pasting. The design language has changed
> so unless it's redesigned, it's a bit confusing.

You won't get any argument from me about what
belongs in Emacs tool bars.  I don't use the
tool-bar, and I don't know what's best wrt it
for emacs -Q - either in terms of whether it
should be on or off or what buttons it should
contain.

> > Remember that the same person can be a
> > member of multiple audiences, depending
> > on the context.  That's kinda what major
> > modes are about (but I understand your
> > suggestion as being about more global
> > messaging).
> 
> It's  a great point, because we can set nice defaults that fit either
> prose writing or programming; can we do both?

How about finer-grained than just prose and
code?  We have major modes, and code modes
inherit from a common ancestor.

> > What, today, prevents someone from writing
> > a package (or a theme or any other code)
> > that, in effect, provides such a "profile"?
> >
> > If nothing, then why not just leave it to
> > those interested to create such packages,
> > themes, or whatever, and see how well they
> > get taken up?  People can add such things
> > to GNU ELPA or other repositories, right?
> 
> I don't understand; of course people can create any package they want
> and change Emacs behavior but we're looking for ways to make Emacs
> easier to use for new users by redefining defaults, changing keybinding
> to be comparable to other tools, and perhaps, adding some additional
> functionality from Elpa to round the experience.

And how to know what solution is good for that?
Why not encourage such experiments, and see how
actual users actually take up the results?

As you say, it's about possibly modifying Emacs.
How that's done, including just what's done, is
the question.  Let 100 flowers bloom, and then
see which are most fragrant (as smelled by users
and Emacs developers).  Compare actual Emacs
realizations of what you're aiming at.