mirror of
https://github.com/SpartanJ/eepp.git
synced 2026-10-02 11:10:31 +03:00
ecode: Enable line-wrap by default on new installations.
Added Code of Conduct and Contributing documents. Added templates for bug reports and feature requests.
This commit is contained in:
Martín Lucas Golini
@@ -0,0 +1,117 @@
|
||||
name: Bug report
|
||||
description: Report a reproducible problem in a project or component
|
||||
title: "[Bug]: "
|
||||
body:
|
||||
- type: markdown
|
||||
attributes:
|
||||
value: |
|
||||
Thank you for taking the time to report a problem.
|
||||
|
||||
Use this form only for observable bugs. Questions, troubleshooting, and uncertain reports belong in [Discussions](https://github.com/SpartanJ/eepp/discussions). Please read the [contribution guidelines](../../CONTRIBUTING.md) before continuing.
|
||||
|
||||
- type: checkboxes
|
||||
id: preliminary-checks
|
||||
attributes:
|
||||
label: Preliminary checks
|
||||
options:
|
||||
- label: I searched existing Issues and Discussions and did not find a duplicate.
|
||||
required: true
|
||||
- label: This is an observable defect, not only a preference or support question.
|
||||
required: true
|
||||
- label: I have personally reviewed this report and verified that its contents are accurate.
|
||||
required: true
|
||||
|
||||
- type: input
|
||||
id: project
|
||||
attributes:
|
||||
label: Affected project or component
|
||||
description: Identify the application, library, tool, module, or component where the problem occurs.
|
||||
placeholder: e.g. ecode editor, UI module, network module
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: textarea
|
||||
id: observed-behavior
|
||||
attributes:
|
||||
label: Observed behavior
|
||||
description: Describe precisely what happened, including any visible error or incorrect result.
|
||||
placeholder: Describe the concrete behavior you observed.
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: textarea
|
||||
id: expected-behavior
|
||||
attributes:
|
||||
label: Expected behavior
|
||||
description: Explain what should have happened and why.
|
||||
placeholder: Describe the expected result.
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: textarea
|
||||
id: reproduction
|
||||
attributes:
|
||||
label: Steps to reproduce
|
||||
description: Provide exact, minimal steps that another person can follow. Include a minimal example when possible.
|
||||
placeholder: |
|
||||
1. Start with...
|
||||
2. Configure or open...
|
||||
3. Perform...
|
||||
4. Observe...
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: textarea
|
||||
id: environment
|
||||
attributes:
|
||||
label: Environment
|
||||
description: Provide all details relevant to reproducing the problem.
|
||||
value: |
|
||||
- Project version, commit, or build date:
|
||||
- Operating system and version:
|
||||
- Architecture:
|
||||
- Compiler and version, if relevant:
|
||||
- Graphics backend, if relevant:
|
||||
- Other relevant details:
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: dropdown
|
||||
id: reproducibility
|
||||
attributes:
|
||||
label: Reproducibility
|
||||
description: How consistently can you reproduce the problem?
|
||||
options:
|
||||
- Every time
|
||||
- Frequently
|
||||
- Occasionally
|
||||
- Only once
|
||||
- Unable to reproduce again
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: textarea
|
||||
id: evidence
|
||||
attributes:
|
||||
label: Evidence
|
||||
description: Provide relevant logs, complete error messages, crash stack traces, screenshots, or recordings. If evidence is unavailable, explain why. You can drag files into this field.
|
||||
placeholder: Paste evidence, attach files, or explain why it cannot be provided.
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: textarea
|
||||
id: additional-context
|
||||
attributes:
|
||||
label: Additional context
|
||||
description: Include previous working versions, possible causes, workarounds, related links, or anything else that may help.
|
||||
validations:
|
||||
required: false
|
||||
|
||||
- type: checkboxes
|
||||
id: terms
|
||||
attributes:
|
||||
label: Submission agreement
|
||||
options:
|
||||
- label: I will provide reasonably requested information and follow the [Code of Conduct](../../CODE_OF_CONDUCT.md).
|
||||
required: true
|
||||
|
||||
@@ -0,0 +1,84 @@
|
||||
name: Feature request
|
||||
description: Propose a specific, well-defined improvement
|
||||
title: "[FR]: "
|
||||
body:
|
||||
- type: markdown
|
||||
attributes:
|
||||
value: |
|
||||
Well-defined feature requests are welcome. Early-stage or broad ideas should be posted in the [Ideas discussion category](https://github.com/SpartanJ/eepp/discussions/categories/ideas) first. Starting a Discussion before a large or consequential request is encouraged.
|
||||
|
||||
Please read the [contribution guidelines](../../CONTRIBUTING.md) before continuing.
|
||||
|
||||
- type: checkboxes
|
||||
id: preliminary-checks
|
||||
attributes:
|
||||
label: Preliminary checks
|
||||
options:
|
||||
- label: I searched existing Issues and Discussions and did not find a duplicate.
|
||||
required: true
|
||||
- label: This request is sufficiently defined to be evaluated and acted upon.
|
||||
required: true
|
||||
- label: I have personally reviewed this request and verified that its contents are accurate.
|
||||
required: true
|
||||
|
||||
- type: input
|
||||
id: project
|
||||
attributes:
|
||||
label: Affected project or component
|
||||
description: Identify the application, library, tool, module, or component this request concerns.
|
||||
placeholder: e.g. ecode editor, UI module, network module
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: textarea
|
||||
id: problem
|
||||
attributes:
|
||||
label: Problem or use case
|
||||
description: Describe the concrete problem, limitation, or use case. Explain who benefits and under what conditions.
|
||||
placeholder: What problem needs to be solved, and for whom?
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: textarea
|
||||
id: proposed-behavior
|
||||
attributes:
|
||||
label: Proposed behavior
|
||||
description: Describe the desired outcome precisely. Include examples where useful.
|
||||
placeholder: What should the project do?
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: textarea
|
||||
id: constraints
|
||||
attributes:
|
||||
label: Constraints and alternatives
|
||||
description: Describe relevant technical constraints, tradeoffs, alternative solutions, and existing workarounds.
|
||||
placeholder: What alternatives have you considered?
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: input
|
||||
id: discussion
|
||||
attributes:
|
||||
label: Related Discussion
|
||||
description: If this proposal was discussed first, link the Discussion here.
|
||||
placeholder: https://github.com/SpartanJ/eepp/discussions/...
|
||||
validations:
|
||||
required: false
|
||||
|
||||
- type: textarea
|
||||
id: additional-context
|
||||
attributes:
|
||||
label: Additional context
|
||||
description: Add mockups, examples, references, or other information that helps evaluate the request.
|
||||
validations:
|
||||
required: false
|
||||
|
||||
- type: checkboxes
|
||||
id: terms
|
||||
attributes:
|
||||
label: Submission agreement
|
||||
options:
|
||||
- label: I understand that submitting a request does not commit maintainers to implementing it, and I agree to follow the [Code of Conduct](../../CODE_OF_CONDUCT.md).
|
||||
required: true
|
||||
|
||||
@@ -0,0 +1,8 @@
|
||||
blank_issues_enabled: false
|
||||
contact_links:
|
||||
- name: Questions and support
|
||||
url: https://github.com/SpartanJ/eepp/discussions
|
||||
about: Ask project-related questions and request troubleshooting help in Discussions.
|
||||
- name: Ideas and early proposals
|
||||
url: https://github.com/SpartanJ/eepp/discussions/categories/ideas
|
||||
about: Share ideas that are not yet specific enough to be actionable Issues.
|
||||
@@ -0,0 +1,74 @@
|
||||
# Code of Conduct
|
||||
|
||||
## Our expectations
|
||||
|
||||
Everyone is welcome to participate. We value good-faith questions, reports,
|
||||
ideas, and contributions from people of all backgrounds and experience levels.
|
||||
|
||||
This project is maintained in limited time. Participation must be respectful,
|
||||
constructive, and mindful of that time.
|
||||
|
||||
Acceptable behavior includes communicating respectfully, following the
|
||||
repository guidelines, providing requested technical information, making a
|
||||
good-faith effort to help investigate reported problems, and respecting
|
||||
maintainers' final decisions while remaining free to disagree constructively.
|
||||
|
||||
Unacceptable behavior includes:
|
||||
|
||||
* Insults, threats, harassment, discrimination, sexualized attention, or
|
||||
personal attacks.
|
||||
* Demanding work, repeatedly arguing after a decision has been made, or treating
|
||||
maintainers and contributors as a support service.
|
||||
* Spam, deliberate disruption, off-topic posts, or opening multiple low-quality
|
||||
reports or feature requests in a short period of time.
|
||||
* Repeatedly ignoring issue templates, contribution guidelines, moderator
|
||||
instructions, or requests for information.
|
||||
* Impersonation, coordinated abuse, or using alternate accounts to evade a
|
||||
warning, block, interaction limit, or other moderation action.
|
||||
* Publishing another person's private information without permission.
|
||||
|
||||
Criticism of the software and technical decisions is welcome. Hostility toward
|
||||
people is not.
|
||||
|
||||
## Scope
|
||||
|
||||
This Code of Conduct applies to all project spaces, including Issues, Pull
|
||||
Requests, Discussions, and other communication associated with the project. It
|
||||
also applies when someone publicly represents the project or its community.
|
||||
|
||||
Issue-tracker participation must also follow [CONTRIBUTING.md](CONTRIBUTING.md).
|
||||
Questions and early-stage ideas belong in GitHub Discussions, not Issues.
|
||||
|
||||
## Enforcement
|
||||
|
||||
Maintainers may edit, hide, lock, or remove content; close or limit
|
||||
interactions; and temporarily or permanently block participants when behavior
|
||||
is inappropriate, disruptive, or contrary to these rules.
|
||||
|
||||
When practical, maintainers will first explain the problem and give the
|
||||
participant an opportunity to correct it. A warning is not guaranteed for
|
||||
serious abuse, obvious spam, threats, harassment, impersonation, or moderation
|
||||
evasion.
|
||||
|
||||
Account age and history may be considered as anti-abuse signals when deciding
|
||||
whether additional verification or moderation is necessary. Rules are based on
|
||||
behavior, not on nationality, ethnicity, age, language, or any other personal
|
||||
identity. Creating or rotating accounts to evade controls may result in an
|
||||
immediate block of all associated accounts.
|
||||
|
||||
Possible responses include a correction request, a warning, a temporary
|
||||
restriction, or a permanent restriction. Maintainers may choose the response
|
||||
appropriate to the behavior and its history; these steps do not have to be
|
||||
applied in order.
|
||||
|
||||
## Reporting conduct problems
|
||||
|
||||
Report conduct problems privately to the maintainer using the contact details
|
||||
on the maintainer's GitHub profile. Include links, screenshots, or other
|
||||
relevant context when possible. Reports will be handled as confidentially as
|
||||
reasonably possible. Do not open a public Issue to report a Code of Conduct
|
||||
violation.
|
||||
|
||||
Maintainers are responsible for clarifying and enforcing these standards. They
|
||||
must apply them in good faith and may recuse themselves when they cannot review
|
||||
a matter impartially.
|
||||
+119
@@ -0,0 +1,119 @@
|
||||
# Contributing and Community Support
|
||||
|
||||
Contributions and pull requests are welcome. Before posting, search existing
|
||||
Issues and Discussions to avoid duplicates and choose the appropriate channel
|
||||
below.
|
||||
|
||||
Maintainer time is limited. Reports that do not follow these guidelines may be
|
||||
closed or moved without investigation.
|
||||
|
||||
## Where to post
|
||||
|
||||
### Issues: actionable bugs and defined feature requests
|
||||
|
||||
Use the repository's GitHub Issues for:
|
||||
|
||||
* **Actionable bugs**: observable behavior where the affected project or
|
||||
component does not behave as documented or intended, produces an error or
|
||||
crash, or behaves inconsistently under equivalent conditions. A difference in
|
||||
preference or desired behavior is not by itself a bug.
|
||||
* **Well-defined feature requests**: a specific problem, use case, and proposed
|
||||
outcome whose scope can be evaluated and acted upon.
|
||||
|
||||
A report may still be valid when the cause is uncertain. What matters is that
|
||||
the unexpected behavior is concrete and reproducible enough to investigate.
|
||||
|
||||
### Discussions: questions, support, and ideas
|
||||
|
||||
Use the repository's GitHub Discussions for:
|
||||
|
||||
* Questions about using or building the project.
|
||||
* Troubleshooting where a project defect has not been established.
|
||||
* Early-stage, exploratory, or broad ideas.
|
||||
* Proposals that need feedback before their scope or desired behavior is clear.
|
||||
|
||||
Starting even a defined feature request in the **Ideas** discussion category is
|
||||
encouraged, especially when the change is large, affects existing behavior, or
|
||||
has significant design tradeoffs. Once the proposal is concrete and a
|
||||
maintainer agrees it is suitable, it may be tracked as an Issue.
|
||||
|
||||
Issues are not a support forum. Repeatedly opening questions as Issues after
|
||||
being redirected may be treated as disruptive behavior under the
|
||||
[Code of Conduct](CODE_OF_CONDUCT.md).
|
||||
|
||||
## Bug report requirements
|
||||
|
||||
A bug report must contain enough information for another person to understand
|
||||
and investigate the problem. Include, as applicable:
|
||||
|
||||
* A concise description of the observed and expected behavior.
|
||||
* Exact reproduction steps and the smallest reproducible example.
|
||||
* Project version, commit, or build date.
|
||||
* Operating system, architecture, compiler, graphics backend, and other relevant
|
||||
environment details.
|
||||
* Complete logs, error messages, crash stack traces, or sanitizer reports as
|
||||
text when available.
|
||||
* Screenshots or a short recording for visual or interaction problems.
|
||||
* Whether the problem is reproducible and whether it previously worked.
|
||||
|
||||
Remove passwords, tokens, private files, and other sensitive information before
|
||||
posting. Do not replace essential evidence with vague summaries such as "it
|
||||
doesn't work" or "it crashes sometimes."
|
||||
|
||||
Maintainers may request additional information or ask the reporter to test a
|
||||
change. If requested information cannot be provided, explain why and share the
|
||||
best alternative evidence available. Reports may be closed when there is not
|
||||
enough information to investigate or when the reporter does not respond or
|
||||
provide requested information within a reasonable time, or does not cooperate
|
||||
in a meaningful way. They can be reconsidered when the missing information
|
||||
becomes available.
|
||||
|
||||
## Feature request requirements
|
||||
|
||||
A feature request should explain the concrete problem or use case, who benefits,
|
||||
the desired behavior, relevant constraints and alternatives, and which project
|
||||
or component it affects.
|
||||
|
||||
A request is not a commitment that the feature will be implemented. Maintainers
|
||||
may decline requests that do not fit the project's scope, priorities, design,
|
||||
or maintenance capacity.
|
||||
|
||||
## Pull requests
|
||||
|
||||
Pull requests for bug fixes, features, documentation, tests, and other project
|
||||
improvements are welcome. Keep each pull request focused, explain the problem
|
||||
and the chosen solution, follow the existing code style, and include relevant
|
||||
tests or clear verification steps when practical. For large or potentially
|
||||
breaking changes, start a Discussion before investing substantial work.
|
||||
|
||||
Opening a pull request does not guarantee acceptance. Changes must fit the
|
||||
project's scope and technical direction, and may require revision after review.
|
||||
|
||||
## Automated and AI-assisted submissions
|
||||
|
||||
Do not use automated systems to create Issues or Discussions without meaningful
|
||||
human review. Bulk-generated, unattended, or unverified submissions are not
|
||||
welcome and may be treated as spam. If AI tools help prepare a post, the person
|
||||
submitting it must verify its accuracy, ensure it follows these guidelines, and
|
||||
take responsibility for its content and any follow-up.
|
||||
|
||||
Automated or AI-assisted pull requests are welcome when they provide clear
|
||||
value and are reviewed by the submitter. They are evaluated by the same quality,
|
||||
verification, and responsiveness standards as any other contribution.
|
||||
|
||||
## Posting responsibly
|
||||
|
||||
Open one report per independent problem. Do not split one problem across
|
||||
several Issues, repost closed content, or open a rapid batch of reports before
|
||||
maintainers can triage them. If you have found many possible problems, start a
|
||||
Discussion or prioritize the clearest and best-supported reports first.
|
||||
|
||||
Repeated vague, duplicative, unsupported, or noncompliant reports may be closed,
|
||||
and continued behavior may lead to interaction limits or a block. These
|
||||
standards apply to everyone; contribution history may help maintainers assess
|
||||
good-faith participation but does not exempt anyone from the rules.
|
||||
|
||||
Do not use alternate accounts to evade moderation or posting controls. Account
|
||||
evasion may result in an immediate block without an additional warning.
|
||||
|
||||
All participation is subject to the [Code of Conduct](CODE_OF_CONDUCT.md).
|
||||
@@ -185,6 +185,10 @@ I'm putting my efforts on improving the documentation on the UI module since
|
||||
currently is the most important and complex module but lacks of proper
|
||||
documentation. If you have any question you can contact me anytime.
|
||||
|
||||
Contributions and pull requests are welcome. Before participating, please read
|
||||
the [contribution and community support guidelines](CONTRIBUTING.md) and the
|
||||
[Code of Conduct](CODE_OF_CONDUCT.md).
|
||||
|
||||
## Getting the code
|
||||
|
||||
The repository uses git submodules so you'll need to clone the repository and
|
||||
|
||||
@@ -212,7 +212,7 @@ void AppConfig::load( const std::string& confPath, std::string& keybindingsPath,
|
||||
editor.linesRelativePosition = ini.getValueB( "editor", "lines_relative_position", false );
|
||||
editor.autoReloadOnDiskChange = ini.getValueB( "editor", "auto_reload_on_disk_change", false );
|
||||
|
||||
editor.wrapMode = LineWrap::toLineWrapMode( ini.getValue( "editor", "wrap_mode", "nowrap" ) );
|
||||
editor.wrapMode = LineWrap::toLineWrapMode( ini.getValue( "editor", "wrap_mode", "word" ) );
|
||||
editor.wrapType = LineWrap::toLineWrapType( ini.getValue( "editor", "wrap_type", "viewport" ) );
|
||||
editor.wrapKeepIndentation = ini.getValueB( "editor", "wrap_keep_indentation", true );
|
||||
|
||||
|
||||
@@ -130,7 +130,7 @@ struct CodeEditorConfig {
|
||||
bool autoReloadOnDiskChange{ false };
|
||||
bool codeFoldingEnabled{ true };
|
||||
bool codeFoldingAlwaysVisible{ false };
|
||||
LineWrapMode wrapMode{ LineWrapMode::NoWrap };
|
||||
LineWrapMode wrapMode{ LineWrapMode::Word };
|
||||
LineWrapType wrapType{ LineWrapType::Viewport };
|
||||
bool wrapKeepIndentation{ true };
|
||||
std::string autoCloseBrackets{ "" };
|
||||
|
||||
Reference in New Issue
Block a user