A modern editor with a backend written in Rust.

Last update: Jan 5, 2023

Related tags

Overview

Xi Editor

(pronounced "Zigh")

A modern editor with a backend written in Rust.

Maintenance status: The xi-editor project is not currently under active development. Although we will happily accept bug fixes, no new features are currently planned. We would like to revisit writing a text editor again at some point in the future, but for the time being our attention is elsewhere. — The Editors

Note: This repo contains only the editor core, which is not usable on its own. For editors based on it, check out the list in Frontends.

The xi-editor project is an attempt to build a high quality text editor, using modern software engineering techniques. It is initially built for macOS, using Cocoa for the user interface. There are also frontends for other operating systems available from third-party developers.

Goals include:

Incredibly high performance. All editing operations should commit and paint in under 16ms. The editor should never make you wait for anything.
Beauty. The editor should fit well on a modern desktop, and not look like a throwback from the ’80s or ’90s. Text drawing should be done with the best technology available (Core Text on Mac, DirectWrite on Windows, etc.), and support Unicode fully.
Reliability. Crashing, hanging, or losing work should never happen.
Developer friendliness. It should be easy to customize xi editor, whether by adding plug-ins or hacking on the core.

Learn more with the creator of Xi, Raph Levien, in this Recurse Center Localhost talk.

Screenshot:

Getting started

This repository is the core only. You'll also need a front-end, from the list below.

Building the core

Xi-editor targets 'recent stable Rust'. We recommend installing via rustup. The current minimum supported version is 1.40.

To build the xi-editor core from the root directory of this repo:

> cd rust
> cargo build

Frontends

Here are some front-ends in various stages of development:

xi-mac, the official macOS front-end.
xi-gtk, a GTK+ front-end.
xi-term, a text UI.
xi-electron, a cross-platform front-end based on web-technologies.
Tau, a GTK+ front-end written in Rust. Forked from https://github.com/bvinc/gxi, which was abandoned.
xi-win, an experimental Windows front-end written in Rust.
kod, a terminal frontend written in Golang.
xi-qt, a Qt front-end.
vixi, a Vim like front-end in Rust.

The following are currently inactive, based on earlier versions of the front-end protocol, but perhaps could be revitalized:

xi_glium, an experimental GL-based front-end in Rust.
XiEditorVS2015, C#.
xi-android, an Android frontend.

There are notes (I wouldn’t call it documentation at this point) on the protocol at frontend.md. If you're working on a front-end, feel free to send a PR to add it to the above list.

Design decisions

Here are some of the design decisions, and motivation why they should contribute to the above goals:

Separation into front-end and back-end modules. The front-end is responsible for presenting the user interface and drawing a screen full of text. The back-end (also known as “core”) holds the file buffers and is responsible for all potentially expensive editing operations.
Native UI. Cross-platform UI toolkits never look and feel quite right. The best technology for building a UI is the native framework of the platform. On Mac, that’s Cocoa.
Rust. The back-end needs to be extremely performant. In particular, it should use little more memory than the buffers being edited. That level of performance is possible in C++, but Rust offers a much more reliable, and in many ways, higher level programming platform.
A persistent rope data structure. Persistent ropes are efficient even for very large files. In addition, they present a simple interface to their clients - conceptually, they're a sequence of characters just like a string, and the client need not be aware of any internal structure.
Asynchronous operations. The editor should never, ever block and prevent the user from getting their work done. For example, autosave will spawn a thread with a snapshot of the current editor buffer (the persistent rope data structure is copy-on-write so this operation is nearly free), which can then proceed to write out to disk at its leisure, while the buffer is still fully editable.
Plug-ins over scripting. Most text editors have an associated scripting language for extending functionality. However, these languages are usually both more arcane and less powerful than “real” languages. The xi editor will communicate with plugins through pipes, letting them be written in any language, and making it easier to integrate with other systems such as version control, deeper static analyzers of code, etc.
JSON. The protocol for front-end / back-end communication, as well as between the back-end and plug-ins, is based on simple JSON messages. I considered binary formats, but the actual improvement in performance would be completely in the noise. Using JSON considerably lowers friction for developing plug-ins, as it’s available out of the box for most modern languages, and there are plenty of the libraries available for the other ones.

Current status

This is still a project in its early stages. The Mac build has basic editing functionality (it was used to write this README), but looks very spare and is still missing essentials such as auto-indent. At the moment, it’s expected that its main community will be developers interested in hacking on a text editor.

Authors

The xi-editor project was started by Raph Levien but has since received contributions from a number of other people. See the AUTHORS file for details.

License

This project is licensed under the Apache 2 license.

Contributions

We gladly accept contributions via GitHub pull requests. Please see CONTRIBUTING.md for more details.

If you are interested in contributing but not sure where to start, there is an active Zulip channel at #xi-editor on https://xi.zulipchat.com. There is also a #xi channel on irc.mozilla.org. Finally, there is a subreddit at /r/xi_editor.

Comments

Syntax highlighting via LPeg

One possible suggestion for the method of syntax highlighting is via LPeg. This is used by the Vis editor, which borrowed it from the Scintillua project as described in this README.

You can see all the languages supported in the Vis lexers directory.

If you wanted to embed this in xicore there seem to be multiple Rust Lua bindings, such as these two:

https://github.com/kballard/rust-lua https://github.com/jcmoyer/rust-lua53

Or maybe LPeg could be use from a Lua-based external tool using whatever future RPC mechanism you intend for "plugins". But this may make sense to be done inside the core.

opened by leavengood 44
Update notify 5.0
Closes #1158

This PR will change based on comments but gives a good idea of what's coming.

[x] I have responded to reviews and made changes where appropriate.

[x] I have tested the code with cargo test --all / ./rust/run_all_checks.

[x] I have updated comments / documentation related to the changes I made.

[x] I have rebased my PR branch onto xi-editor/master.
opened by sjoshid 23
Managing and persisting user preferences
Preferences and persistence

This is a brief sketch of how I've been thinking about the preferences / config system, how the various levels of preferences fit together, and some thoughts on how we might manage client settings.

Config levels

There are a number of configuration 'tiers', which override one another in a set order:

Defaults: the base level settings that ship with xi; these are included in assets/defaults.toml. These are always loaded first, and provide sane general-case defaults.

Platform specific: these are platform-specific overrides that ship with xi, in (for instance) assets/windows.toml. These override the default settings on a particular platform.

General user preferences (optional): these are persistent user preferences, which override defaults. When a user modifies preferences, they are modifying these.

Syntax specific (system): these are syntax-specific settings which are bundled with xi. These override even user preferences; if a user's preferences declare a desire for tabs over spaces, the yaml syntax (assets/yaml.toml) preferences (which want spaces over tabs) will be preferred.

Syntax specific (user) (optional): The user can optionally set their own syntax-specific settings, which will override all previous settings, and persist between application launches.

Session overrides (system): finally, on a per-buffer basis xi-core may override some settings, for instance if we have a preference for spaces over tabs but open a file that is indented with tabs, we might override the user preference for that given file.

Session overrides (user): through the RPC protocol, the client may override a given setting for the current buffer. These overrides are not persistent; they would be used to manually set a line-ending or encoding on a per-document, per-session basis.

Of these, only the third and fifth are user-defined and persistent; they're the focus of this discussion.

Getting and persisting user preferences

Two of these tiers (general and syntax-specific) require us to persist user preferences. There are a few possible approaches to this:

File based, core managed: the classic unix text editor approach: all preferences are saved in preference files; files are watched and preferences reloaded on change. This is the easiest approach, and has pedigree, but it can confuse and frustrate newer users, and doesn't really respect platform conventions.

RPC based, client managed The opposite pole: the client manages all user settings, sending them to core at launch and then keeping core up to date about changes. This would involve RPC calls to the effect of:

{ "method": "set_preferences", "params": { "user": { "font_size" 14 } "python": { "translate_tabs_to_spaces": true, "tab_size": 2 } } }

This approach gives the client total control over how preferences are managed, but also requires each client to implement a settings system.

File based, shared A compromise; preferences are file based, but instead of editing those files directly, the user has some platform idiomatic preferences interface, and the client writes the user's preferences to disk, where changes are picked up by core. This approach is flexible (only clients that want to do this have to) but it's also fairly inelegant.

File backed, RPC modified Another compromise; core stores all preferences, and sends them to the client at launch. The client can present an idiomatic UI to the user, and preference changes are sent to core via a set_preference RPC call. Core persists the changes. This lets core handle file modification in a way that preserves document structure (https://github.com/joelself/tomllib), and is also opt-in for the client (or the user): if either wants to just edit files directly, that's no problem. It is also reasonably cross platform (a user can export their settings and have it just work), but is a bit cumbersome.

Multimodal: Allow the client to select from 1. and 2., above. Configuration is file based by default, but the client can opt into managing preferences, (with a launch flag or some RPC call) in which case core defers. This adds complexity in exchange for improved client flexibility.

Conclusion

This is intended to sketch out some of my thoughts around persistence specifically. I would like to try and come up with some solution that accommodates various possible use cases, and I don't know what all of those are. If anything is missing or unclear, please help me clarify.
discussion
opened by cmyr 23
Implement workspaces
This is a medium-sized project for somebody, which will require a design document and discussion. I am happy to mentor somebody who is interested in taking this on.

Workspaces group a collection of open documents, and enable a variety of features:

auto-save and session restoration: workspaces will passively track state, including window properties (probably an opaque blob of data updated as needed by the frontend, that might include things like window position, size, and other state) and will also store unsaved changes, the undo stack, etc; a client should be able to pass a 'workspace id' to core on startup, and have be able to easily reopen all previously open documents.

directory tracking: a workspace should consist of one or more directories, and there should be api for adding and removing directories; these will be used for things like 'quick open'

(eventually) workspaces should have their own config domain, so that config options can be set on a per-workspace basis

(eventually) workspaces will provide a new hook into the config and plugin systems, for things like language server support

multiple workspaces should be possible, and there should be an initial implicit workspace

For an initial version of this, I think it's reasonable to focus on the persistence bits.
enhancement on hold needs design
opened by cmyr 22
Add Command Recording
As per the discussion in https://github.com/xi-editor/xi-editor/issues/806, there are some basic actions missing from xi that are comprised of already existing commands. Instead of implementing these manually, it'd be really convenient if we could just compose existing commands.

The implementation was a bit different than the one originally suggested by @cmyr; instead of having and RPC that holds events, we have an RPC that toggles a recording state and an RPC that plays the recorded state. I'm open to switching to the other model if it's preferred-- I was just getting a feel for the project with this first pass.

TODOs

[x] Record commands (duh)

[x] Add tests

[x] Undo / Redo entire replay in a single command

[x] Limit to only edit commands?

[ ] ~Handle requests alongside notifications?~

[x] Don't record Undo / Redos

[x] Clear recording

[x] Allow for multiple recordings?
opened by mbStavola 19
allow opening from command line as root

Wanted to edit my /etc/sudoers file with visudo.

I use xi as my $EDITOR for everything.

Unfortunately, sudo xi doesn't open a file as root, it'd be nice if it just worked.
enhancement discussion

opened by nhooyr 18
Add chrome tracing support
In xi-mac#103 we added support for tracing using the chrome trace format.

This should be rolled out to xi-core, and eventually plugins. I would defer on the plugin work initially, and implement this in xi-core.

So: we should be generating traces on an ongoing basis, and then in response to some new dump_trace RPC we should be either writing them to a directory passed as an argument, or else returning them as a response. (It's unclear to me which of these is better; it comes down to whether the tools for viewing traces want a single file or not, probably)

Some questions:

Do we want to have some global trace repository, or do we want to use some thread-local structure and synchronize only as needed?

Do we want to include traces in xi-rpc? If yes, this gets a bit more complicated; we'd need to add some mechanism for collecting these.

Do we write to a file or return a response?

enhancement performance
opened by cmyr 18
To anyone who installed Rust via homebrew
Apparently installing Rust via Homebrew installs the 1.3 version, which causes xcodebuild to return the following error.

Compiling xi-rope v0.0.0 (file:///Users/xyz/dev-lab/xi-editor/rust/rope) Compiling serde v0.7.0 Compiling winapi-build v0.1.1 Compiling num-integer v0.1.32 rope/src/tree.rs:445:1: 451:2 error: the associated type `<N as tree::NodeInfo>::L` may not live long enough [E0309] ...

The solution was to install Rust from the official website obviously.

It's definitely my mistake, but I never really installed/used Rust before ...

(I thought about submitting a PR to explicitly specify a minimum Rust version ... but again I don't know enough about Rust to know which version would be required)
opened by nsbraksa 17
update to notify 5.0

A vague tracking issue: a major update to the notify crate is in the works, and we should investigate what will be involved in migrating to use it. I haven't looked into this at all, but there are some docs here.
enhancement help wanted

opened by cmyr 16
WIP: Added logging support with Fern
First step towards #408

Work in progress.

Tasks

[x] : add logging library

[ ] : convert existing calls to stderr directly via eprintln macro to log calls.

[ ] : log all RPC calls.

@cmyr Please affirm if I am heading in right direction. Thanks 😄
opened by betterclever 15
Selection granularity for drag gestures

Like most text editors, Xi lets you select a word by double-clicking or a line by triple-clicking. However, if you then drag the cursor, it will extend the selection one character at a time. This PR assigns the appropriate granularity to drag gestures, depending on whether they started with a single, double, or triple click.

opened by ryanbloom 14
Bump nokogiri from 1.13.6 to 1.13.9 in /docs
Bumps nokogiri from 1.13.6 to 1.13.9.

Release notes

Sourced from nokogiri's releases.

1.13.9 / 2022-10-18

Security

[CRuby] Vendored libxml2 is updated to address CVE-2022-2309, CVE-2022-40304, and CVE-2022-40303. See GHSA-2qc6-mcvw-92cw for more information.

[CRuby] Vendored zlib is updated to address CVE-2022-37434. Nokogiri was not affected by this vulnerability, but this version of zlib was being flagged up by some vulnerability scanners, see #2626 for more information.

Dependencies

[CRuby] Vendored libxml2 is updated to v2.10.3 from v2.9.14.

[CRuby] Vendored libxslt is updated to v1.1.37 from v1.1.35.

[CRuby] Vendored zlib is updated from 1.2.12 to 1.2.13. (See LICENSE-DEPENDENCIES.md for details on which packages redistribute this library.)

Fixed

[CRuby] Nokogiri::XML::Namespace objects, when compacted, update their internal struct's reference to the Ruby object wrapper. Previously, with GC compaction enabled, a segmentation fault was possible after compaction was triggered. [#2658] (Thanks, @eightbitraptor and @peterzhu2118!)

[CRuby] Document#remove_namespaces! now defers freeing the underlying xmlNs struct until the Document is GCed. Previously, maintaining a reference to a Namespace object that was removed in this way could lead to a segfault. [#2658]

sha256 checksums:

9b69829561d30c4461ea803baeaf3460e8b145cff7a26ce397119577a4083a02 nokogiri-1.13.9-aarch64-linux.gem e76ebb4b7b2e02c72b2d1541289f8b0679fb5984867cf199d89b8ef485764956 nokogiri-1.13.9-arm64-darwin.gem 15bae7d08bddeaa898d8e3f558723300137c26a2dc2632a1f89c8574c4467165 nokogiri-1.13.9-java.gem f6a1dbc7229184357f3129503530af73cc59ceba4932c700a458a561edbe04b9 nokogiri-1.13.9-x64-mingw-ucrt.gem 36d935d799baa4dc488024f71881ff0bc8b172cecdfc54781169c40ec02cbdb3 nokogiri-1.13.9-x64-mingw32.gem ebaf82aa9a11b8fafb67873d19ee48efb565040f04c898cdce8ca0cd53ff1a12 nokogiri-1.13.9-x86-linux.gem 11789a2a11b28bc028ee111f23311461104d8c4468d5b901ab7536b282504154 nokogiri-1.13.9-x86-mingw32.gem 01830e1646803ff91c0fe94bc768ff40082c6de8cfa563dafd01b3f7d5f9d795 nokogiri-1.13.9-x86_64-darwin.gem 8e93b8adec22958013799c8690d81c2cdf8a90b6f6e8150ab22e11895844d781 nokogiri-1.13.9-x86_64-linux.gem 96f37c1baf0234d3ae54c2c89aef7220d4a8a1b03d2675ff7723565b0a095531 nokogiri-1.13.9.gem

1.13.8 / 2022-07-23

Deprecated

XML::Reader#attribute_nodes is deprecated due to incompatibility between libxml2's xmlReader memory semantics and Ruby's garbage collector. Although this method continues to exist for backwards compatibility, it is unsafe to call and may segfault. This method will be removed in a future version of Nokogiri, and callers should use #attribute_hash instead. [#2598]

Improvements

XML::Reader#attribute_hash is a new method to safely retrieve the attributes of a node from XML::Reader. [#2598, #2599]

Fixed

... (truncated)

Changelog

Sourced from nokogiri's changelog.

1.13.9 / 2022-10-18

Security

[CRuby] Vendored libxml2 is updated to address CVE-2022-2309, CVE-2022-40304, and CVE-2022-40303. See GHSA-2qc6-mcvw-92cw for more information.

[CRuby] Vendored zlib is updated to address CVE-2022-37434. Nokogiri was not affected by this vulnerability, but this version of zlib was being flagged up by some vulnerability scanners, see #2626 for more information.

Dependencies

[CRuby] Vendored libxml2 is updated to v2.10.3 from v2.9.14.

[CRuby] Vendored libxslt is updated to v1.1.37 from v1.1.35.

[CRuby] Vendored zlib is updated from 1.2.12 to 1.2.13. (See LICENSE-DEPENDENCIES.md for details on which packages redistribute this library.)

Fixed

[CRuby] Nokogiri::XML::Namespace objects, when compacted, update their internal struct's reference to the Ruby object wrapper. Previously, with GC compaction enabled, a segmentation fault was possible after compaction was triggered. [#2658] (Thanks, @eightbitraptor and @peterzhu2118!)

[CRuby] Document#remove_namespaces! now defers freeing the underlying xmlNs struct until the Document is GCed. Previously, maintaining a reference to a Namespace object that was removed in this way could lead to a segfault. [#2658]

1.13.8 / 2022-07-23

Deprecated

XML::Reader#attribute_nodes is deprecated due to incompatibility between libxml2's xmlReader memory semantics and Ruby's garbage collector. Although this method continues to exist for backwards compatibility, it is unsafe to call and may segfault. This method will be removed in a future version of Nokogiri, and callers should use #attribute_hash instead. [#2598]

Improvements

XML::Reader#attribute_hash is a new method to safely retrieve the attributes of a node from XML::Reader. [#2598, #2599]

Fixed

[CRuby] Calling XML::Reader#attributes is now safe to call. In Nokogiri <= 1.13.7 this method may segfault. [#2598, #2599]

1.13.7 / 2022-07-12

Fixed

XML::Node objects, when compacted, update their internal struct's reference to the Ruby object wrapper. Previously, with GC compaction enabled, a segmentation fault was possible after compaction was triggered. [#2578] (Thanks, @eightbitraptor!)

Commits

897759c version bump to v1.13.9

aeb1ac3 doc: update CHANGELOG

c663e49 Merge pull request #2671 from sparklemotion/flavorjones-update-zlib-1.2.13_v1...

212e07d ext: hack to cross-compile zlib v1.2.13 on darwin

76dbc8c dep: update zlib to v1.2.13

24e3a9c doc: update CHANGELOG

4db3b4d Merge pull request #2668 from sparklemotion/flavorjones-namespace-scopes-comp...

73d73d6 fix: Document#remove_namespaces! use-after-free bug

5f58b34 fix: namespace nodes behave properly when compacted

b08a858 test: repro namespace_scopes compaction issue

Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR

@dependabot recreate will recreate this PR, overwriting any edits that have been made to it

@dependabot merge will merge this PR after your CI passes on it

@dependabot squash and merge will squash and merge this PR after your CI passes on it

@dependabot cancel merge will cancel a previously requested merge and block automerging

@dependabot reopen will reopen this PR if it is closed

@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually

@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

@dependabot use these labels will set the current labels as the default for future PRs for this repo and language

@dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language

@dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language

@dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

dependencies ruby
opened by dependabot[bot] 0
Bump thread_local from 1.0.1 to 1.1.4 in /rust
Bumps thread_local from 1.0.1 to 1.1.4.

Commits

4a54e57 Bump version to 1.1.4

ebf8b45 Merge pull request #34 from ibraheemdev/patch-1

3d69afa Fix memory ordering in RawIter::next

c7d8dcd Bump version to 1.1.3

5e8bbf2 Merge pull request #30 from Marwes/fix_drop

a44b836 fix: Drop the value in the ThreadLocal on drop

322cf34 Bump version to 1.1.2

dca4007 Merge pull request #29 from Kestrer/raw-iter

33ad405 Add #[inline] to non-generic functions

810c043 Implement iterator logic in RawIter

Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR

@dependabot recreate will recreate this PR, overwriting any edits that have been made to it

@dependabot merge will merge this PR after your CI passes on it

@dependabot squash and merge will squash and merge this PR after your CI passes on it

@dependabot cancel merge will cancel a previously requested merge and block automerging

@dependabot reopen will reopen this PR if it is closed

@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually

@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

@dependabot use these labels will set the current labels as the default for future PRs for this repo and language

@dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language

@dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language

@dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

dependencies rust
opened by dependabot[bot] 0
Bump smallvec from 0.6.13 to 0.6.14 in /rust
Bumps smallvec from 0.6.13 to 0.6.14.

Release notes

Sourced from smallvec's releases.

v0.6.14

Fix a possible buffer overflow in insert_many (#252, #254).

Commits

5757ac5 Fix potential buffer overflow in insert_many

See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR

@dependabot recreate will recreate this PR, overwriting any edits that have been made to it

@dependabot merge will merge this PR after your CI passes on it

@dependabot squash and merge will squash and merge this PR after your CI passes on it

@dependabot cancel merge will cancel a previously requested merge and block automerging

@dependabot reopen will reopen this PR if it is closed

@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually

@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

@dependabot use these labels will set the current labels as the default for future PRs for this repo and language

@dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language

@dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language

@dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

dependencies rust
opened by dependabot[bot] 0
Bump crossbeam-channel from 0.3.9 to 0.4.4 in /rust
Bumps crossbeam-channel from 0.3.9 to 0.4.4.

Changelog

Sourced from crossbeam-channel's changelog.

Version 0.8.1

Support targets that do not have atomic CAS on stable Rust (#698)

Version 0.8.0

Bump the minimum supported Rust version to 1.36.

Bump crossbeam-channel to 0.5.

Bump crossbeam-deque to 0.8.

Bump crossbeam-epoch to 0.9.

Bump crossbeam-queue to 0.3.

Bump crossbeam-utils to 0.8.

Version 0.7.3

Fix breakage with nightly feature due to rust-lang/rust#65214.

Bump crossbeam-channel to 0.4.

Bump crossbeam-epoch to 0.8.

Bump crossbeam-queue to 0.2.

Bump crossbeam-utils to 0.7.

Version 0.7.2

Bump crossbeam-channel to 0.3.9.

Bump crossbeam-epoch to 0.7.2.

Bump crossbeam-utils to 0.6.6.

Version 0.7.1

Bump crossbeam-utils to 0.6.5.

Version 0.7.0

Remove ArcCell, MsQueue, and TreiberStack.

Change the interface of ShardedLock to match RwLock.

Add SegQueue::len().

Rename SegQueue::try_pop() to SegQueue::pop().

Change the return type of SegQueue::pop() to Result.

Introduce ArrayQueue.

Update dependencies.

Version 0.6.0

Update dependencies.

Version 0.5.0

Update crossbeam-channel to 0.3.

Update crossbeam-utils to 0.6.

Add AtomicCell, SharedLock, and WaitGroup.

... (truncated)

Commits

48b13dc Bump crossbeam-channel to v0.4.4

679dac8 Bump crossbeam-channel to v0.4.3

f652c6a Change crossbeam-channel's license to MIT OR Apache-2.0.

149a3c9 Release crossbeam-queue 0.2.3

18363b5 Merge #476

e32c891 Release new versions

6d6591a Merge #474

528c3ca Undo bump of rand as it bumps MSRV

78043c7 Bump crossbeam to 0.7.4

640cec2 Bump crossbeam-deque to 0.7.3

Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR

@dependabot recreate will recreate this PR, overwriting any edits that have been made to it

@dependabot merge will merge this PR after your CI passes on it

@dependabot squash and merge will squash and merge this PR after your CI passes on it

@dependabot cancel merge will cancel a previously requested merge and block automerging

@dependabot reopen will reopen this PR if it is closed

@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually

@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

@dependabot use these labels will set the current labels as the default for future PRs for this repo and language

@dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language

@dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language

@dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

dependencies rust
opened by dependabot[bot] 0
Add Lapce
Not affiliated with Lapce, the description should probably be approved by https://github.com/dzhou121

Summary

Add Lapce as one of the frontends to the README.

Review Checklist

[ ] I have responded to reviews and made changes where appropriate.
opened by ricklamers 1
`xi-unicode` allows linebreaks in emoji sequences
The xi_unicode::LineBreakIterator allows breaks inside of a lot of the longer emoji sequences. For example:

assert_eq!( vec![(10, false), (14, false)], LineBreakIterator::new("🏳️‍🌈").collect::<Vec<_>>() );

Not sure whether this is an actual bug in the code or whether the Unicode data is just outdated. In any case, since this library is used by quite a few projects, it might be worth investigating!
bug
opened by laurmaedje 0