RE: [External] : Re: Gitlab Migration

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

> ;; Convenient
> (setq scroll-preserve-screen-position t)
> (setq visual-order-cursor-movement t)
> (setq-default tab-width 4)
> (global-auto-revert-mode)
> (auto-save-visited-mode)
> (indent-tabs-mode -1)

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').

> ;; Compatibility with other editors
> (electric-indent-mode)
> (electric-pair-mode)
> (cua-mode)

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.

As for `cua-mode': That's more or less what
the whole question of `C-x' etc. is about, I
think.  I'm not in favor of turning it on by
default, but it's not a problem for me if
that happens - easy enough to turn it off
individually.

Even if `cua-mode' remains off by default,
however, I'm in favor of Emacs turning ON
`delete-selection-mode' by default.  And not
only for other-editor compatibility but also
for general convenience.

(I think that should have been done back
when we turned on `transient-mark-mode' by
default.)

> ;; Session
> (desktop-save-mode)

Not in favor of that, but OK; it's easy for
an individual to turn it off.

> ;; Visual
> (tool-bar-mode -1)
> (global-visual-line-mode)
> (show-paren-mode)

+1 for `show-paren-mode'.  But maybe not
globally - does it make a lot of sense, by
default, for non-programming modes?

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.

(I offer `tool-bar+.el', which lets you
hide the tool-bar and open it by clicking
a pseudo-menu in the menu-bar.  And it lets
you have tool-bars for only specific frames.

https://www.emacswiki.org/emacs/ToolBar#ToolBarPlus)

I turn on visual-line only when I'm in a
buffer with text that someone or something
else wrote, which has  l o n g  lines.
Maybe we should have a line-length option
that does this automatically (?).

> Some questions:
> 
> 1. Do we want to split the audience to writers and programmers because
>    it impacts the implementation and the messaging as well.

I don't think we do, but maybe the devil
is in the details.  Elaborate perhaps?

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).

> 2. Do we also install popular and relevant Elpa packages as part of the
>    profile setup or do we cross the line at variable setting? what
>    about keybindings?

A "profile" setting for an individual
could certainly specify installing or
loading whatever.  A stock profile (i.e.
a customizable template) could do that also.

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?

Wouldn't that be a good way to see whether
(and how) such a feature should (and could)
be added to Emacs?