Need clarification on scope, goals, and procedures of the project

[alandmoore]

It's just a few days into this project, but I'm already seeing a danger of this project becoming a bikeshed-fest. I think some clarification about what we're doing here would help mitigate endless discussion and debate.

Target audience for emacs

In my mind, emacs is primarily an editor/IDE for code, and incidentally useful for other text-oriented tasks as well (organization, email, etc). But that's just my perspective, and not supported by any weight of data. Other people seem to want to target less-technical users and non-coding uses.

If the goal is to make the out-of-the-box experience "better", the unavoidable question is "better for whom?"

What use case?

If the goal is to make emacs better for programmers, it makes sense to look at software that programmers are using (Atom, Sublime, Visual Studio, etc) and follow their lead. If there are other groups that need to be taken into consideration, that should probably be expressed so that we don't run roughshod over their needs.

What level of technical proficiency?

We can alway imagine a more ignorant, inexperienced, or timid user for whom to demand (or exclude) any feature. We can also excuse any user-unfriendliness in emacs on behalf of the expected technical proficiency of its intended audience ("we're mostly coders, right?"). Where do we draw the line?

What kind of hardware?

Issues of performance or screen real-estate come up frequently. Where to draw the line on hardware? Should a feature be disabled by default to accomodate 10" screens or 15-year-old hardware?

Scope

Not sure if "scope" is the right word here, but my understanding is that this project is essentially curating a list of suggestions to present to emacs-devel for new defaults. That being the case:

• Is it necessary for us to select the best implementation of a feature, or to exclude features because the available implementations are not adequate? Or is it enough to say, "We would like to see a feature like this to be enabled by default.", and let emacs-devel work out the implementation details?

• What things are clearly beyond the scope of this project, and can we clarify that in the documentation? A lot of discussion about defaults can get derailed pretty quickly by pie-in-the-sky solutions and wanting to fix issues in the core. Maybe a set of realistic parameters to work within would be good.

Procedure

Commit rights seem to be readily available for anyone interested, but how to decide on a pull request or feature request when there is reasonable debate happening? I feel uncomfortable merging code without a consensus, but given that we're only creating a list of suggestions, maybe that's too cautious?

I'd appreciate some discussion along these lines. Thanks.

[phillord]

For myself, I am not so worried about the bike shed. Having issues open is no bad thing, not necessarily because they be acted on, but because they give us some idea about problems that might be solved. And, we have had some good suggestions.

From my perspective, I am not interested in this project as a starter-kit/prelude kind of option for Emacs, and I do not care at all about the code base per se -- rather I am interested in the code in so far as it is used to describe a problem and a potential solution to it. Once we know that, we can aim for fixing the code IN core.

The other thing that I would really like this project to do is to contribute to generating a protocol for working out when we should change things. If we can find two or three people willing to sit behind newish or less experienced Emacs users, get them to do a task, then write up the results as a case study, then we will have achieved a something valuable, and probably something more valuable than code base.

[angrybacon]

I'm commenting as I read (I legit copied your text).

In my mind, emacs is primarily an editor/IDE for code

Yes undeniably.

Other people seem to want to target less-technical users and non-coding uses.

That's because it would be opinionated no to.

If the goal is to make emacs better for programmers, it makes sense to look at software that programmers are using (Atom, Sublime, Visual Studio, etc) and follow their lead. If there are other groups that need to be taken into consideration, that should probably be expressed so that we don't run roughshod over their needs.

The thing is that the use cases are already compartmentalized with major modes. The way I see it, we can very well improve OOB experience for a person who will write code one time and write text the next minute.

What level of technical proficiency?

I wouldn't encourage replacing . and .. in dired-mode by current directory and parent directory. Obviously that's an extreme case but I only want to show that subjects can be as fundamental as this. Point is, I don't feel there need to be a line anywhere. Instead we should rely on common sense (more on that in the TL;DR.

Should a feature be disabled by default to accomodate 10" screens or 15-year-old hardware?

Those are only examples, I get it. But to answer the questions, yes and yes. Ideally our changes will end up in default Emacs. That means that with time it will also end up on remote servers where the users might not have a choice other than Emacs (because he doesn't like Vi and Emacs feels less painful than Nano).

This may be too limiting so correct me if you think I'm genuinely wrong when thinking that we should limit ourselves with the most demanding users across all different use cases. Meaning: Emacs shouldn't go against the way of the least experienced of all programmers, nor should it for the least experienced of all writers.

Or is it enough to say, "We would like to see a feature like this to be enabled by default.", and let emacs-devel work out the implementation details?

I'm guessing this would need more specifications than just "We would like line numbers to be displayed." because it lacks some things the code we might push provides such as: what modes should this be in, what side should the numbers be displayed on or even what color should they use. Those are silly examples for the most part.

Commit rights seem to be readily available for anyone interested, but how to decide on a pull request or feature request when there is reasonable debate happening?

(TL;DR) Something at least a little doubtful to the question "Is this at most as opinionated as what Emacs currently ships?" should at most end up in a pull request. If the answer was a clear "Yes" then a push/merge makes sense. If the answer was a clear "No" then the change should end up in an issue or a pull request if there's code to work with.

[jackrusher]

@alandmoore "In my mind, emacs is primarily an editor/IDE for code"

Many people compare emacs to [whichever editor/IDEs] because they view it primarily as a text editor for programmers. I would very much like to expand the common understanding of emacs from "editor" to "system for constructing workflows." That is, we should embrace the lisp machine heritage of this software, and I would hope that this deeper philosophy inform what we do here and what core does in the future.

[alandmoore]

@jackrusher So my point is that, if that's the case, we need that expressed somewhere (Readme or other docs), because I suspect the majority of contributors are/will be programmers using emacs primarily as an IDE and not seeing the point in other use cases or target audiences. Otherwise every non-mode-specific change will have people talking past one another, each imagining a very different target user with seemingly obvious needs.

[jackrusher]

@alandmoore I agree with you completely about making this clear. My goal for this project would be to make it easy for people to get into emacs as an editor, but also lead them in a direction that allows them to to really use to its fullest potential.

[josteink]

I think recent changes to Emacs (eglot, tree-sitter, etc) has helped make Emacs much more usable OOB. Considering repo-purpose obsolete.

Closing all issues and archiving repo. Thanks to all contributors!