Allow PHPStorm Code Coverage integration by providing /opt/phpstorm-coverage in web container

Is there an existing issue for this?

[X] I have searched the existing issues

Is your feature request related to a problem? Please describe
PHPStorm provides you with the ability to run your PHP unit tests with coverage report directly from the GUI. After execution, you can see in your IDE which lines are covered and which are not.
Sadly this does fail currently in DDEV with the error message
Generating code coverage report in Clover XML format ... failed [00:00.345]
Directory "/opt/phpstorm-coverage" could not be created

The path is auto generated by PHPStorm, for example --coverage-clover<EMAIL_ADDRESS>and I didn't find an option to change the prefix of the generated path.
Describe the solution you'd like
You can manually create this directory and give it write permission for your user so PHPStorm can create the coverage reports in there but it would be great if this directory would already exist with appropriate permissions, so you can use this PHPStorm feature with zero configuration.
In this issue most of the people add this directory as a docker volume.
https://intellij-support.jetbrains.com/hc/en-us/community/posts/360006971460-Phpstorm-code-coverage-with-docker-container-
I am not aware of the advantges / disadvantages of mounting a docker volume instead of just providing the directory in the container for the coverage reports. I guess it would make the coverage reports persistent when restarting ddev? Your feedback is welcome.
So the solution I would like would be adding a docker volume mount or a directory at /opt/phpstorm-coverage with write permissions for the ddev user to the web container.
Describe alternatives you've considered
The alternative is adding a DDEV post-start hook executing:
mkdir -p "/opt/phpstorm-coverage" && chmod a+rw "/opt/phpstorm-coverage"

Additional context
In combination with https://github.com/drud/ddev/pull/3754 and the DDEV Integration Plugin solving this issue will allow the use of all test run features (Run, Debug, Run with Coverage) of PHPStorm with zero configuration.

You have 3 choices:

Bind-mount to something like .ddev/code-coverage or something (persists)
Docker volume (not available on the host side but persists)
Just create the directory in the image and it doesn't persist. (ddev restart throws it all away)

If it persistence doesn't matter the third option works.
You could probably put it in the ddev-global-cache (indexed by project name)
But... Isn't PhpStorm accessing this from the host side? If so, a docker volume isn't very useful, and only a bind mount would be useful. But where is the code coverage being created? Inside the container or on the host? Are you sure "Directory "/opt/phpstorm-coverage" could not be created" isn't complaining about something happening on the the host side?

But... Isn't PhpStorm accessing this from the host side? If so, a docker volume isn't very useful, and only a bind mount would be useful. But where is the code coverage being created? Inside the container or on the host? Are you sure "Directory "/opt/phpstorm-coverage" could not be created" isn't complaining about something happening on the the host side?

Yes, creating the directory inside the container fixes the issue. PHPStorm is generating and accessing the code coverage results inside the container.
After your explaination I would go with 2. Docker volume from the perspective of a PHPStorm user who likes to use this feature.
Is there much overhead when creating a docker volume? Guess not every ddev user is a PHPStorm users and only a few will use this feature.

The docker volume doesn't cost much, it's the fastest and most efficient way to have something in there. You could just link the directory it wants to /mnt/ddev-global-config/phpstorm//coverage, and you wouldn''t have to create or maintain a volume. The only issue then is that directory has to get created sometime (/mnt/ddev-global-config/...)

Thanks for your feedback!
I will try to create a pull request for that.

This was fixed in #3924


Python 3 Rewrite

Hi,
I did a python 3 rewrite. It's a bit shorter, only takes about 90 LOC, and has a cleaner API IMO. It supports arbitrary queries and I basically got rid of the IO and a lot of other stateful stuff: https://github.com/sils/twitterscraper/blob/sils/auth/scrape_from_author.py

PR is submitted #7

PR #7 is approved.


X11: use existing connection and window

It turns out we can use the window reference on X11 too to avoid creating a fake window for reading a clipboard. After integrating into KAS for testing, this part appears to work; this may however only be because of the blocking design and event processing normally happening in the expected order...
I copied the run logic from https://github.com/quininer/x11-clipboard but using this same connection and tested in KAS, and of course the run thread eats most of the main thread's events. There's a reason x11-clipboard uses two new connections, each with a fake window (though I don't know if the run part actually requires a window or just the connection).
It seems that the correct way to make a clipboard work under X11 (and I think Wayland) is to handle these events within the application's main event loop. Making this work correctly via a standalone lib requires at least one new event loop, perhaps with a channel to send read results from the background event-loop thread to the read function.
Obviously, this implies that the "correct" solution is to integrate clipboard functionality into winit, either directly or as a plug-in attached to a sub-set of events, and that a cross-platform API must be asynchronous (and I'm not sure that futures cut it).
(All this for a broken clipboard API — it obviously requires a hack somewhere to let selections persist beyond application closure.)
CC @vberger (Wayland, https://github.com/rust-windowing/winit/issues/872): do you have thoughts on what the clipboard API should look like? Also see #2.

Perhaps we shouldn't let X11/Wayland get in the way of good API design: APIs should be modular, with minimal inter-dependencies. In which case, we should be able to hack a solution here (though it probably means using the existing window connection to create a second connection to the same display/seat, then modifying the run thread to handle both reads and writes).

CC @vberger (Wayland, rust-windowing/winit#872): do you have thoughts on what the clipboard API should look like?

I don't have a lot of thoughts about that currently, as I don't have a lot of input about what apps expect from a good clipboard API. However,

I copied the run logic from https://github.com/quininer/x11-clipboard but using this same connection and tested in KAS, and of course the run thread eats most of the main thread's events.
[ ... ]
It seems that the correct way to make a clipboard work under X11 (and I think Wayland) is to handle these events within the application's main event loop.

It's possibly the case for X11, but that is a non-issue for Wayland. The Wayland client libraries has multiple event queues (while AFAIK X11 has only one). This allows multiple libraries to be able to share a single Wayland connection without eating each other's events. And this is basically what smithay-clipboard already does. While it still spawns its own thread, but I have in my plans to make it leaner.
Overall though, it seems to me that there is a common question: the clipboard handling library needs to be able to regularly check if it has new events to process. I see roughly 3 ways to do that:

spawn a thread and have it block/loop/epoll/... to process the clipboard events

more or less what is currently done in practice AFAIK ?

integrate the clipboard sockets into the main app event loop

this requires access to the main app event loop, winit currently does not expose it
this is not really applicable for Wayland, as the clipboard managing library must use the same Wayland socket as the main app, and this socket is already managed by the main loop

have the main app regularly call some function of the clipboard managing library, which checks if new messages are pending and processes them if any

this IMO would be the "correct" way to do that on Wayland, inducing the minimal overhead
cannot tell how relevant it could be for X11
for example when used in conjunction with winit, this function could be called whenever the MainEventsCleared event is received.

Thanks @vberger.

have the main app regularly call some function of the clipboard managing library, which checks if new messages are pending and processes them if any

This option sounds attractive, allowing a modular design and simple API without a background thread. (Hopefully it doesn't result in lots of "cross platform" apps with broken clipboards on Linux.)
A related question is how this should work with multi-window apps: window_clipboard::Clipboard should have one instance per window and is created from a RawWindowHandle. Ideally we don't want a separate event loop for each window; will everything work if we just instantiate a lazy_static with the first window's connection? And is that something to handle within smithay-clipboard or in an external wrapper?

Finally found a good write-up on how the X11 clipboard works:
https://www.uninformativ.de/blog/postings/2017-04-02/0/POSTING-en.html
It sounds like using an unmapped window to manage the clipboard is common practice.

A related question is how this should work with multi-window apps:

I don't know how it is for other platforms, but on Wayland you don't really need the window-specific part ofRawWindowHandle at all, so a single initialization for the whole app would work fine.

No, but from what I understand one does need the connection part. I believe the same applies to X11, so this seems to be fine.

I think my question is rather regarding this:

window_clipboard::Clipboard should have one instance per window

Why should there be one instance per window, rather than a single one for the whole app?

Well, maybe there shouldn't. But the current API suggests that a multi-window app should use the current window's handle. (This may just be a documentation issue.)

Anecdote: I accidentally discovered that a couple of KDE apps and Firefox block for several seconds when incorrectly setting the SELECTION. So apparently blocking APIs are common and not an issue.

I implemented enough to make this API work under my testing, so this might be ready for merging (or not, according to by CI).
This currently uses the background thread approach. I'm still not certain whether which should switch to the "update" method, and if so that should be another PR.

@hecrj the Ubuntu runner is failing with  = note: /usr/bin/ld: cannot find -lX11-xcb. I've not used GitHub workflows so not sure how to add a dependency here (it works on my local Fedora machine).

Wow, there's a lot to go through here!
I see you have implemented something similar to what the x11-clipboard already does. I wanted to try something different in this crate.
The main issue I see here is that we are spawning a thread sneakily in Clipboard::new. I believe this server idea should be an explicit concept in the public API. It should be something the user needs to deal with and keep alive (even when not dealing with X11). This is why I mentioned async in #2.
Ideally, I'd like to find a common denominator that unifies clipboard access to all platforms even if we have to complicate the API unnecessarily for some of them, while keeping things explicit. I believe this is the main challenge we face here.
We should probably think about different designs before writing any code.

@hecrj sorry to overwhelm you with a lot of discussion, but it seems you missed some of what happened. @vberger suggested adding an update or poll function to the clipboard which the user polls in MainEventsCleared; this would eliminate the need for a separate background thread and allow the two connections used here to be merged, but as I said, I think this should be a separate PR.
In the mean time, this PR adds clip-board write support (though I only tested on X11), and I don't think the addition of the background run thread is too bad (it uses connection.wait_for_event() for scheduling, and the complexity is all there for good reason).
So, if you fix the Ubuntu build dependency and merge this, I can go ahead and make a new PR adding Clipboard::update and some doc changes. Though I'm not completely convinced this is the right design: for non-Linux users the update function will do nothing and other functionality will work regardless, thus leading to potential portability issues. The nice thing about the current code is that it just works.

Note: on my system, libX11-xcb is provided by libX11-xcb-1.6.9-2.fc31.i686 which has many reverse-dependencies, so I'm surprised it's not included by the Ubuntu test instance. This dependency may be an issue in some cases however. If we don't want it, we would lose the ability to discover the X11 display name from an existing Xlib connection. In most cases this will resolve the same display name via environment variable anyway, but there may be some corner cases.

adding an update or poll function to the clipboard which the user polls in MainEventsCleared

How would this work when you use ControlFlow::Wait and another application triggers a clipboard read request? How will the main loop respond?

don't think the addition of the background run thread is too bad

I don't think spawning a thread in a constructor is an acceptable side-effect. conrod, for instance, creates a new x11-clipboard on every paste event, probably because they are unaware of the cost.

The nice thing about the current code is that it just works.

I understand, but I really believe code is the easy part. I don't see any value in copying exactly what other crates (like copypasta) are already doing. I'd like to explore type-safe, portable, hack-free, and explicit approaches here.

Async alone can't solve it.

I believe it could be part of the design we are looking for. We could have some kind of WindowManager type with an async connect method accepting a raw-window-handle. Then, the only way to obtain a Clipboard instance would be from a WindowManager itself.

ControlFlow::Wait

Good point.

unaware of the cost

IMO this is a documentation issue, as limited as documentation is. And presumably the only reason conrod gets away with constructing a new clipboard on each paste event is because the cost is actually not that important, relative to what an interactive app does anyway.
Before we go any further here, do we have any actual metrics on the cost of an extra background thread and display server connection?

WindowManager

So, you're talking about another type in this lib just to make construction more explicit? Or you're talking about making winit extensible by having it accept a future (or really just a closure) which it polls periodically?

IMO this is a documentation issue

Documentation is great, but it should not be used to patch or cover bad API design. The main issue here is that a constructor performing side-effects is not intuitive and not explicit in the API boundaries.

Before we go any further here, do we have any actual metrics on the cost of an extra background thread and display server connection?

The cost isn't really what worries me. It's the design.

So, you're talking about another type in this lib just to make construction more explicit?

Yes. I believe the first thing we need to do is find out which concepts need to exist in our cross-platform public API and how they relate to each other.

concepts

IMO we should aim for a simple API:

read String, blocking
write String, blocking or offloading

along with a more comprehensive API:

discover available formats of current entry
request current entry in some format, async
provide an entry in 1 or multiple formats, async

Blocking reads aren't really a problem.
Async reads could happen via polling a future or via somehow injecting messages into the event loop (probably this would require winit integration).
Writes could potentially happen in a few ways:

via a future the app is expected to poll frequently until completion (immediately on most platforms, once another app overwrites to the clipboard on X11 and Wayland); this relies on the app to handle this correctly and not e.g. drop the future or sleep too long
via a background thread, as here
integrated into winit

@hecrj keep's talking about needing to explore the options, but I did that (this PR was mostly a side-effect of that work). IMO we should not rely on the app too heavily, so this leaves us two options:

Use a background thread. We can rename Clipboard::new to Clipboard::spawn_runner if you like.
Integrate into winit. This IMO would be the neatest approach, but falls foul of the "divide-and-conquer" idiom (and it's clear winit is already struggling for developers).

Integrate into winit. This IMO would be the neatest approach, but falls foul of the "divide-and-conquer" idiom (and it's clear winit is already struggling for developers)

If you can write up a proposal to winit to include clipboard, I'm all for it, however we may keep both clipboard and dnd under a feature flag. implementing them in async way isn't really a problem, I'd assume + there's a glfw from where we can port a clipboard stuff.


python310Packages.flask: 2.2.2 -> 2.2.3, python310Packages.flask-expects-json: init at 1.7.0

Description of changes
Changelog: https://github.com/pallets/flask/blob/2.2.3/CHANGES.rst
Decorator for REST endpoints in flask: https://github.com/fischerfredl/flask-expects-json
flask-expects-json will be required for changedetection-io.

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Fixes for detected build failures:

#218027


denoising MGF

Can you add

[x] topx filter
[x] MGF export

Fixed by allowing the use of mzdata, which has support for writing raw files.


cksum: gets confused by base64 that happens to consist entirely of hexadecimal digits

The Base64 alphabet has, as the name suggests, 64 letters. 22 of these letters look like hexadecimal digits. That means that a random string of 8 Base64 letters (which encodes 6 bytes = 48 bits) has a chance of (22/64)^8 ~= 2^-12.3 to be a valid hexadecimal string. This means that generating a hash with an output length of 24 bits or a multiple thereof (e.g. SHA384 or Blake2b-48) might generate two different hexadecimal-looking hashes (of different lengths). This can cause all kinds of shenanigans with cksum, which has to detect/guess the encoding from the sums-file.
In particular, here is a case where it goes wrong:
$ echo -n esq > foo.dat # The bytestring b"esq" is very special
$ cksum --algo=blake2b --length=48 --base64 foo.dat | tee foo.sums # Because the base64 *looks* like it's hexadecimal!
BLAKE2b-48 (foo.dat) = fc1f97C4
$ cksum --check foo.sums # GNU cksum takes no issue with this.
foo.dat: OK
$ cargo run -q cksum --check foo.sums # But uutils gets confused by this.
foo.dat: FAILED
cksum: WARNING: 1 computed checksum did NOT match
[$? = 1]
$ cargo run -q hashsum --b2sum --bits 48 --check foo.sums # hashsum *also* gets confused by this.
foo.dat: FAILED
hashsum: WARNING: 1 computed checksum did NOT match
[$? = 1]

There are probably more bugs like this.
Note that this is not specific to blake2b: With SHA384, it would probably require around 2^99 attempts to find a file that hashes to a digest that triggers this bug. For reference, the Bitcoin mining community computes about 2^60 hashes per second according to some sketchy website, which is good enough for this thought experiment. So it would require about 17734 years to find that file. Okay, nevermind, this bug doesn't realistically affect SHA384. (But theoretically it does.)
Found while reading #6500 (probably unrelated though).
CC @sylvestre, because you seem to be interested in this kind of bugs.

Is this a GNU issue or just for our implementation?

I'm not entirely sure what you mean? The GNU behavior seems self-consistent, we differ from GNU behavior, and aren't self-consistent. So I'd say that this is a bug in uutils.

This ticket got closed by mistake due to #6822.


Mechanism to track build pipeline ownership

We need a way to track build pipeline ownership (in the yaml or otherwise) so that it makes it easier to determine who owns a pipeline if we need to do an exercise like migrating pipelines, in the future. The data required should be:

Alias of owner
Indicator of using Arcade or not

Things to consider:

Handling ownership changes
Deprecating old pipelines

Suggested solutions:

Metadata in the YAML (or custom labels that would attach to a build)

Concerns around staleness of data, how would we enforce this.
Arcade yaml could provide it's own tag on builds that would make it easier to identify builds that are using Arcade yaml templates.

Use Service Tree to track this (would need to create more Service Tree entries for this)

Concerns around how Service Tree has not been granular in the past for this type of work.

Release Note Category

[ ] Feature changes/additions
[ ] Bug fixes
[ ] Internal Infrastructure Improvements

Release Note Description

Service tree saved the day! Closing


Problem with wgctrl-sys under cross-compilation to armv7-unknown-linux-gnueabihf

Trying to cross-compile innernet on my M1 Macbook (because my Arm machines don't have enough ram to even install rust via rustup) and I'm blocked by a missing bindings.rs
$ cargo build --release --bin innernet --target armv7-unknown-linux-gnueabihf
[...]
error: couldn't read /Users/rjp/git/_others/innernet/target/armv7-unknown-linux-gnueabihf/release/build/wgctrl-sys-9a837bdbbe74630f/out/bindings.rs: No such file or directory (os error 2)
 --> wgctrl-sys/src/lib.rs:6:1
  |
6 | include!(concat!(env!("OUT_DIR"), "/bindings.rs"));
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

error: aborting due to previous error

error: could not compile `wgctrl-sys`

Works fine when native* compiling (x86_64-apple-darwin) or cross-compiling to M1 (aarch64-apple-darwin).

Huh, seems like bindgen didn't generate the bindings correctly, which is this error you're getting. Just to be clear, it builds fine on your M1 with the default target? I'm not 100% on how Rust handles building to different targets, but I'm guessing you tried a cargo clean before building a new target just to be sure there isn't some weirdness there?

Builds fine on the M1 with either apple-darwin target. cargo clean did nothing to alleviate the situation sadly. I've since run a whole bunch of experiments trying to see if there's any difference between the arm and darwin builds but there's nothing obvious I can see (e.g. cargo build --verbose doesn't mention bindings.rs for either of them.) Tried a whole bunch of "this is how to cross-compile to ARM from macOS" remedies without any success. I suspect this might just be one of those "you can't do that" situations...

Going to go ahead and close this since it seems to build fine on ARM targets, so this sounds like an issue with the cross-compilation toolchain.


Feature discussion: Azure Batch API

I noticed that the Azure Portal uses another API than the one used here for fetching metrics, which it might be interesting to use instead: https://management.azure.com/batch?api-version=2017-03-01
This apparently takes a list of urls and methods and returns a list of results. A single-request body looks like this:
{
    "requests": [
        {
            "relativeUrl": "/subscriptions/<subscription-id>/<resource-id>/providers/microsoft.Insights/metrics?...",
            "httpMethod": "GET"
        }
    ]
}

It would be interesting to see if this has some performance/quota benefits?

That sounds promising.

I've implemented a PoC for this and am running a parallel instance in one of our environments to see what the performance looks like. So far it looks like there are some decent gains at least.

To follow up, the average results look very good, around 50% better scrape times with four targets. However, there are outliers where it takes much longer time (hitting the scrape timeout). I'll continue to look into this.

@carlpett out of curiosity, where did you get with this?
We've noticed so far that (with maybe around 10 resources configured) we're having scrapes timeout around 5 times an hour. We've got a one minute scrape interval with a 30 second timeout for now, and we're doing some playing about with it, but your comments about the batch API sound pretty promising.

@adam-resdiary Unfortunately I was unable to get to the bottom of the strange behaviour I mentioned before wrapping up with the client where we were using this exporter.
I can see if I have the patch somewhere if you want to play around with it, but I no longer have access to an Azure environment I'm afraid.

Found it: https://github.com/carlpett/azure_metrics_exporter/commit/97917a34fd2535ce8d1101c860d8be432f1926d4
It doesn't apply cleanly any more (there's been a lot of other improvements since October), though.

Thanks @carlpett. I'll take a look at that if I can arrange some time.

I would like to piggyback on this idea and create an implementation.

Hi @brian-brazil , as @rolandvarga PR was merge, I think this issue can be closed!


Create PR to add metadata to Polkadot js

Blocked pending mainnet launch
Notes

https://github.com/polkadot-js/apps/tree/master/packages/apps-config

Rococo PR: https://github.com/polkadot-js/apps/pull/8076/files

[ ] Fill out details

Details

Use for Mainnet:
Replace Rococo png with svg ^

Completed.


Cake.Common.Tools.MSBuild cant resolve VS path on pre-release

What You Are Seeing?
Cake.Core.CakeException: MSBuild: Could not locate executable.
What is Expected?
Be able to set ToolVersion = MSBuildToolVersion.VS2019PreRelease
What version of Cake are you using?
0.34.1
Are you running on a 32 or 64 bit system?
64
What environment are you running on?  Windows? Linux? Mac?
Windows
Are you running on a CI Server?  If so, which one?
?

How Did You Get This To Happen? (Steps to Reproduce)

Output Log
An error occurred when executing task 'libs'.
Error: System.AggregateException: One or more errors occurred. ---> Cake.Core.CakeException: MSBuild: Could not locate executable.
   at Cake.Core.Tooling.Tool`1.RunProcess(TSettings settings, ProcessArgumentBuilder arguments, ProcessSettings processSettings)
   at Cake.Core.Tooling.Tool`1.Run(TSettings settings, ProcessArgumentBuilder arguments, ProcessSettings processSettings, Action`1 postAction)
   at Cake.Common.Tools.MSBuild.MSBuildAliases.MSBuild(ICakeContext context, FilePath solution, MSBuildSettings settings)
   at Submission#0.MSBuild(FilePath solution, Action`1 configurator)
   at Submission#0.<<Initialize>>b__0_2()
   at Cake.Core.CakeTaskBuilderExtensions.<>c__DisplayClass24_0.<Does>b__0(ICakeContext x)
   at Cake.Core.CakeTask.<Execute>d__43.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Cake.Core.DefaultExecutionStrategy.<ExecuteAsync>d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Cake.Core.CakeEngine.<ExecuteTaskAsync>d__31.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Cake.Core.CakeEngine.<RunTask>d__28.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Cake.Core.CakeEngine.<RunTargetAsync>d__27.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Cake.Scripting.BuildScriptHost.<RunTargetAsync>d__3.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Cake.Core.Scripting.ScriptHost.RunTarget(String target)
   at Submission#0.<<Initialize>>d__0.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.CodeAnalysis.Scripting.ScriptExecutionState.<RunSubmissionsAsync>d__9`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.CodeAnalysis.Scripting.Script`1.<RunSubmissionsAsync>d__21.MoveNext()
   --- End of inner exception stack trace ---
   at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
   at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
   at Cake.Scripting.Roslyn.RoslynScriptSession.Execute(Script script)
   at Cake.Core.Scripting.ScriptRunner.Run(IScriptHost host, FilePath scriptPath, IDictionary`2 arguments)
   at Cake.Commands.BuildCommand.Execute(CakeOptions options)
   at Cake.CakeApplication.Run(CakeOptions options)
   at Cake.Program.Main()
---> (Inner Exception #0) Cake.Core.CakeException: MSBuild: Could not locate executable.
   at Cake.Core.Tooling.Tool`1.RunProcess(TSettings settings, ProcessArgumentBuilder arguments, ProcessSettings processSettings)
   at Cake.Core.Tooling.Tool`1.Run(TSettings settings, ProcessArgumentBuilder arguments, ProcessSettings processSettings, Action`1 postAction)
   at Cake.Common.Tools.MSBuild.MSBuildAliases.MSBuild(ICakeContext context, FilePath solution, MSBuildSettings settings)
   at Submission#0.MSBuild(FilePath solution, Action`1 configurator)
   at Submission#0.<<Initialize>>b__0_2()
   at Cake.Core.CakeTaskBuilderExtensions.<>c__DisplayClass24_0.<Does>b__0(ICakeContext x)
   at Cake.Core.CakeTask.<Execute>d__43.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Cake.Core.DefaultExecutionStrategy.<ExecuteAsync>d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Cake.Core.CakeEngine.<ExecuteTaskAsync>d__31.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Cake.Core.CakeEngine.<RunTask>d__28.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Cake.Core.CakeEngine.<RunTargetAsync>d__27.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Cake.Scripting.BuildScriptHost.<RunTargetAsync>d__3.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Cake.Core.Scripting.ScriptHost.RunTarget(String target)
   at Submission#0.<<Initialize>>d__0.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.CodeAnalysis.Scripting.ScriptExecutionState.<RunSubmissionsAsync>d__9`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.CodeAnalysis.Scripting.Script`1.<RunSubmissionsAsync>d__21.MoveNext()<---

GIST LINK - Please create a gist and link to that gist here
OR
PLACE LOG CONTENT HERE

Current possible workaround is set settings
ToolPath = "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Preview\\MSBuild\\Current\\Bin\\MSBuild.exe";

Code in the following method should be using Visual Studio setup APIs to find the install path rather than making an educated guess:
https://github.com/cake-build/cake/blob/a1893a2bba26f49e089d66beeb78421cedf6126d/src/Cake.Common/Tools/MSBuild/MSBuildResolver.cs#L160

I think there is a VSWhere addin already, so that should really be the official way and then fall back to the smart guess.

VSWhere support is already built into Cake
https://cakebuild.net/api/Cake.Common.Tools.VSWhere/VSWhereAliases/
Was added 2017 in Cake 0.18.0.
https://cakebuild.net/blog/2017/03/vswhere-and-visual-studio-2017-support


post_processing example does not work

Bevy version
caa16c5
Relevant system information
Windows 11
AdapterInfo { name: "Radeon RX 590 Series", vendor: 4098, device: 26591, device_type: DiscreteGpu, backend: Vulkan }

What you did
cargo run --example post_processing --release

What went wrong
Something should appear in the window, but the window is blank.

Do the other shader examples work for you?

duplicate of #5019, fixed by #5020


Add commit hook for contribution quality check

Add Git Commit Hooks to check for duplicate names, Badly formatted ones etc.

Rather prefer to steer away from it since it requires npm dependencies that need maintenance


chore(avo): restore avo main to owa

Description
Music year: 2009

List of changes

pointing owa back at the avo main branch as have now merged it on avo
Issue(s)
Fixes #
How to test

Go to https://deploy-preview-2948--oak-web-application.netlify.thenational.academy
Click on ______
You should see ______

Screenshots
How it used to look (delete if n/a):
{screenshots}
How it should now look:
{screenshots}
Checklist

[ ] Added or updated tests where appropriate
[ ] Manually tested across browsers / devices
[ ] Considered impact on accessibility
[ ] Design sign-off
[ ] Approved by product owner
[ ] Does this PR update a package with a breaking change

:tada: This PR is included in version 1.612.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Apple Watch, iOS9. Light power state does not update

Power switches work fine, even when iPhone is turned off. When other HomeKit app changes the light power state it is not updated on the Watch and I have to switch it twice to make an action. I have no idea if the error is watchOS2 related or it's a bug in the app itself. It's updated correctly on the iPhone.

I'll see if it's fixed on the new HMWatch repo ;)


Docs lie about when a resource can contain some strings

This part is a lie:

The following words can't be used at the start of a resource name, but can be used later in the name:
LOGIN
XBOX

I just got denied making a server because my completely random ID had the audacity to include the letters xbox in a row.
The domain name label y5cg3b375rghxboxrchgey22uu is invalid. The name itself or part of the name is a reserved word such as a trademark. Please use a different name. (AzureSdk::BadRequest)

The banned letters are in the middle and not at the start.

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 5f956cd8-7704-2618-ff70-f4e133aa9ae3
Version Independent ID: 8acc7802-9005-3ea9-0549-11066418385a
Content: Reserved resource name errors - Azure Resource Manager
Content Source: articles/azure-resource-manager/troubleshooting/error-reserved-resource-name.md
Service: azure-resource-manager
Sub-service: troubleshooting
GitHub Login: @davidsmatlak
Microsoft Alias: davidsmatlak

#assign:davidsmatlak

@will thanks for the feedback. I'll update the article.

I submitted the fix for this issue and after the pull request is merged, this issue will automatically close. After the merge, the updated document will be online within 24 hours.

Thanks @davidsmatlak!


fix: assignment entry to nil map

Description:

Testing done:

Affected area:

Functional Area

New Functionality
[ ]

CI System
[ ]

CLI Tool
[ ]

Certificate Management
[ ]

Control Plane
[ ]

Demo
[ ]

Documentation
[ ]

Egress
[ ]

Ingress
[ ]

Install
[ ]

Networking
[ ]

Observability
[ ]

Performance
[ ]

SMI Policy
[ ]

Security
[ ]

Sidecar Injection
[ ]

Tests
[ ]

Upgrade
[ ]

Other
[ ]

Please answer the following questions with yes/no.

Does this change contain code from or inspired by another project?

Did you notify the maintainers and provide attribution?

Is this a breaking change?

Has documentation corresponding to this change been updated in the fsm-docs repo (if applicable)?

Codecov Report
Attention: 3 lines in your changes are missing coverage. Please review.

Comparison is base (045a590) 46.81% compared to head (d9e2dd5) 46.80%.

Files
Patch %
Lines

cmd/fsm-bootstrap/fsm-bootstrap.go
0.00%
3 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@               Coverage Diff                @@
##           release/v1.2     #174      +/-   ##
================================================
- Coverage         46.81%   46.80%   -0.01%
================================================
  Files               199      199
  Lines             15229    15232       +3
================================================
  Hits               7130     7130
- Misses             8053     8056       +3
  Partials             46       46

Flag
Coverage Δ

unittests
46.80% <0.00%> (-0.01%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


RPi4 build with SATA-USB expansion board and 5V fan

In connection with the metal case (https://diynodes.com/product/zkds-metal-case-for-the-raspiblitz/) I have been experimenting with this SATA-USB expansion board and found it very stable.
Sources:
Amazon:
https://www.amazon.co.uk/Geekworm-Raspberry-Expansion-USB3-0-Shield/dp/B07VXF2HJG/
DIYnodes.com (bitcoin only): https://diynodes.com/product/sata-usb-expansion-board-and-usb-bridge/
It has 2 pairs of 5V power pins too, so there are more options to attach a fan.
This one seems to be good quality, silent and efficient (keeps the temp at 58-62 degrees max with repeated stresstest runs ./config.scripts/blitz.stresstest.sh):
https://www.ebay.co.uk/itm/Fan-Square-Cooling-Fan-with-Heatsink-Cooler-Kit-For-Raspberry-Pi-4-3-V-df/372980446235
It sits on a heatsink which has a sticky layer on the bottom.
there can be plenty of similar fans be found on amazon/ebay/aliexpress.
Search for Square Fan Rasperry Pi

I am also using some 22mm x M2.5 screws (with M2.5 locking nuts) to support the screen from below. This keeps it very stable when pressed.

More for the Maximal package. BIg SSd-s seem to draw siginificantly more power than the smaller ones.
500GB SSD-s are taking 1-1.2 Amperes.
1TB I have seen are 1.6-1.7 (and 1.7 was causing problems)
I have tested 3 types of 1 TB SSD-s with this setup so far:
GOOD:
SanDisk SSD PLUS 1 TB Sata III 2.5 Inch Internal SSD, Up to 535 MB/s: https://www.amazon.co.uk/SanDisk-SDSSDA-1T00-G26-Internal-Speed-Write/dp/B07D998212
power req: 1.6 A - no issues so far
WD Blue 3D NAND Internal SSD 2.5 Inch SATA - 1 TB
https://www.amazon.co.uk/gp/product/B073SBQMCX/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8&psc=1
power req: 1.6 A - no issues so far

BAD:
Crucial MX500 CT1000MX500SSD1 1 TB (3D NAND, SATA, 2.5 Inch, Internal SSD)
https://www.amazon.co.uk/Crucial-MX500-CT1000MX500SSD1-NAND-Internal/dp/B078211KBB
power req: 1.7 A - on high load of the node (electrs + txindex indexing at the same time)  had read errors and froze (probably due to the power spike)

The power was a single 3A Pimoroni PSU from the shopping list for all. The X825 board can be powered separately too with a 5V barrel connector in case that would be needed in the future. Already very useful when cloning the disks.

Link to a build with the X825 board, heatsink-case and 22mm * M2.5 screws working together well:
https://twitter.com/DIYnodes/status/1248587471983607808
Fits the metal case too.

note from TG regarding the Geekworm Raspberry Pi 4 X872 M.2 NVMe SSD Expansion Board https://www.amazon.co.uk/Geekworm-Raspberry-Expansion-Compatible-Support/dp/B0855DMH6C
https://t.me/raspiblitz/40612

i had a similar issue with fan power inputs being used by the tft screen - in the end i stripped an old usb cable to power the internal fan i have a second external fan fixed in place temp never exceeds 47*


invalid css?

https://github.com/littlebits/react-popover/blob/v0.4.4/examples/jsx/main.css#L1
None of my build tools, nor my browser, are able to parse this line.
Sass gives me:
      @import directive requires a url or quoted path

css gives me:
Unexpected format../base

We use webpack to build the the examples (https://github.com/littlebits/react-popover/blob/v0.4.4/webpack.config.babel.js).


ICE compiling icu_locid_transform

rustc-ice-2023-10-31T19_27_33-11089.txt
With current nightly:

rustc 1.75.0-nightly (31bc7e2c4 2023-10-30)

Reproducer:
# cargo new foo; cd foo
cargo add icu_locid_transform
CARGO_PROFILE_DEV_CODEGEN_BACKEND=cranelift RUSTC_BACKTRACE=1 CARGO_INCREMENTAL=0 \
cargo +nightly build -p icu_locid_transform

It happens without cranelift!  Sorry, I'll reopen elsewhere; I had jumped on nightly due to the new component release.


Add possibility of excluding items from directory

Some users may want to upload/download an entire folder but exclude individual files within it.

Moving to Jira.


Add config option for MRU tabs

Prerequisites

[x] Can you reproduce the problem in safe mode?
[x] Are you running the latest version of Atom?
[x] Did you check the debugging guide?
[x] Did you check the FAQs on Discuss?
[x] Are you reporting to the correct repository?
[x] Did you perform a cursory search to see if your bug or enhancement is already reported?

Description
#10737 made ctrl+tabbing MRU-based, but did not offer a config option to revert to the existing left->right behavior.  Given that this is a very significant change to default behavior, we should keep the old sequential behavior as the default switching technique and expose MRU tabbing through its own setting.
/cc @natalieogle, @benogle
Versions
You can get this information from executing atom --version and apm --version at the command line.
Atom    : 1.7.0-dev-6beed1d
Electron: 0.36.8
Chrome  : 47.0.2526.110
Node    : 5.1.1

I really think we should make MRU ordering the default. Many other editors ship with it as the default, many people want it out of the box, and there are already 3 other pairs of commands (cmd-{|}, cmd-alt-left|right, ctrl-pageup|pagedown) that move left / right through the tabs.
If MRU switching is going to be the default, there will need to be a behavior change at some point. Why not now? I suppose the reason for why not now is if we're worried that it is buggy. But that's sort of what beta is for. If people are super worried about bugginess, maybe it wouldn't be the default for a release or so, then we'd need to do the behavior change.
But even then, I think it will be interesting to see if there are complaints or confusion when this hits beta.
People can revert via a keymap change, which we can advertise in the release notes or the blog post:
'body':
  'ctrl-tab': 'pane:show-next-item'
  'ctrl-tab ^ctrl': 'abort!'
  'ctrl-shift-tab': 'pane:show-previous-item'
  'ctrl-shift-tab ^ctrl': 'abort!'

:+1:

What this ^ctrl and abort! really do and why simple rebinding 'ctrl-tab': 'pane:show-next-item' is not enought? I think this syntax is not intuitive for many people. I thought long and hard what that might mean and why we need write ^ctrl second time if we already wrote ctrl-tab and still I have no idea what this means. And I saw other people post similar feelings.
I think the problem for people who want back left-to-right behaviour not with defalut, but with this cryptographic settings. :)

abort! is the same thing as abortKeyBinding() documented in the Flight Manual. The ^ctrl is a new ability for the atom-keymap package that was added specifically for MRU tab switching, it means that the command isn't activated until Ctrl is released.

Thanks for the answer. Now I read the docs and especially useful information in PR. It's really magic... :sparkles:
Now I understand what each of this construction do separately, but I still doesn't understand what they do in this concrete binding:
'ctrl-tab': 'pane:show-next-item'
'ctrl-tab ^ctrl': 'abort!'

My attempt to understand:
If user presses Ctrl+TAB, then do command switch to next tab in left-to-right order. If user then releases Ctrl, then abort this key binding (what keybinding? releasing Ctrl key? Or pressing Ctrl+TAB?) and continue searching for another matching binding. But why we need this? Maybe MRU switching in new release uses exactly this binding 'ctrl-tab ^ctrl' and we just want to unbind it? But why we don't use unset! then? I'm totally confused now.

Maybe MRU switching in new release uses exactly this binding 'ctrl-tab ^ctrl' and we just want to unbind it?

:point_up: This is the reason. There's really very little difference between abort! and unset! in this instance. You can use either.

I think it'd still be useful to have a config setting for us international users - which either can't type properly, or apply a patch to disable keyup functionality in keymaps.

I'd say to keep the old behavior by default and add a config option for MRU tab switching.
Such changes to the defaults are very disruptive for users and, IMHO, this is a huge downgrade—sequential tab switching by default is one of the few things that Atom had got better than Sublime.
At least for me, MRU is very hard to work with once you are working with more than two tabs—I don't have enough spare cognitive load to remember and update the order of the tabs I've used recently, I'm spending it with things that actually matter such as code logic and flow. And in case I'm working with just a few tabs of a larger set, it is easy to reorder them to be next to each other and sequentially switch between them forwards/backwards, thus only a single tabs order needs to be remembered and you can always take a quick look at the tabs bar to refresh your memory. Therefore, sequential switching is superior in every single aspect and MRU is completely useless to me.
Okay, sorry for the small rant.
In any case though, I know I have no say here and you guys can do whatever you want, but please, please make sure to document a way to disable MRU when you announce v1.7.0 stable in the blog post announcement (and perhaps somewhere in the official documentation?) if it ships with MRU by default.

For anyone else annoyed by this change: according to my (limited) testing, abort! doesn't work with the config changes posted above. Use unset! instead :smile:

So the fix is to insert this into the keymap, correct?
'body':
  'ctrl-tab': 'pane:show-next-item'
  'ctrl-tab ^ctrl': 'unset!'
  'ctrl-shift-tab': 'pane:show-previous-item'
  'ctrl-shift-tab ^ctrl': 'unset!'

Yep, unset! appears to do the trick. Using abort! makes things even weirder. :|
In all honesty, this level of customisation shouldn't be necessary for something as fundamental as window navigation...

I agree that it wasn't perhaps so wise to let this slip into a "minor" release (1.6 -> 1.7) without a UI to disable it. (I think I already had an MRU package in place, since I found the old behavior completely wrong for me, so I think the feature is nice, it's just the way that we delivered it to be a bit obtrusive.)

Why not just make MRU the default for new installs, while keeping the old behavior for existing installs? Most users currently using Atom have either gotten used to the current tab switching behavior, or (like me) installed a package to switch to MRU tab switching a long time ago. Then for new installs make MRU the default with an option to disable it.

@Ajedi32 idk, IMHO I think it'd be fine if it's made very clear in the release notes that there's a toggle (and where it is)

How many people actually read the release nodes? Most users just want to have a stable development environment, only few actually have the time to actively manage it.

I read the release notes, but I fully agree. Most casual Atom users will see an upgrade, install it habitually in an age of evergreen browsers, and not think twice about what it added until they notice a new feature... or bug.

This is not at all intuitive — I have been looking over the course of days in Atom Discuss and these issues to find this exact issue. I use Xcode, Sublime, and Atom, and now Atom is the odd one out on tab behaviour — I have never touched an IDE with MRU tab ordering.
If Atom is going to implement a very opinionated change like this, there at least needs to be a Settings switch for it.
Even if the prevailing opinion is that MRU is superior, the large group of more novice users who prefer the old tab behaviour have no switch, either in General Settings or the tabs package, to tweak this. I am not a beta tester, yet for the editor behaviour to change so radically and not provide me with an "out" makes me feel like one.

By the way, you guys say MRU was a "heavily requested feature", but I've read the relevant thread and I can see that most of Atom's core contributors opposed changing the default tabbing behavior to MRU. Also, you have to consider that people who were looking for MRU tabs switching in Atom are likely to reach that thread and +1 it, meanwhile casual Atom users who were happy with the sequential tab switching behavior and don't follow this repository (e.g. me) are very unlikely to reach such a thread. Therefore, your metrics were completely unfair and skewed!
The next time you consider such a drastic fundamental change to defaults, at the very least please perform a poll in an unbiased way for the community to decide (something simple like a Twitter poll may be enough, I think).

MRU is only intuitive if you can see the items ordered while switching.
Like cmd-tab on OSX or alt-tab on windows.
Please switch back to the old behavior or provide a config option for that! The workaround doesn't work for me ...

@UltCombo Agreed. I think the same effect is also happening here. With the exception of one or two people, everyone in this thread got here by noticing the change, not liking it, then searching Google to find out what happened and how to fix it.
A poll of some kind would be a good idea here. Ideally we'd just have Atom ask users which option they prefer when they update, then use that selection to determine which option the editor users for them and which option becomes the default for new installs.

It baffled me that the order that I cycle through tabs seemed to be random, and to add insult to injury, it would then change throughout the session. The logic of the ordering was entirely lost on me. I've always expected the tab behavior to be consistent with Chrome and had been very happy when I first tried Atom and found that it was. I typed up a bug report that tab order was completely broken by 1.7 and was about to report it before I found this thread.

I'd also like to add that the proposed fix doesn't work (on 1.8.0-beta1, Arch Linux x86_64)

I just want to give my voice for MRU.
And yes, I read this thread only because I posted in it early. Other people who prefer MRU just never see this thread. Therefore discussions like this never be constructive. There will be always many people who don't like the subject and almost none who likes because they just don't ask google for it. They just say "Ok. I like this new feature." and that's it.
For existing users something like asking user when updating: "There is new MRU tab switching feature you can use. [Enable MRU tab switching] [Use current behaviour]" would be ideal. Of course only if current CTRL-TAB binding is default and not overriden.
For new installations... I don't know. But all (literally all!) editors which I used before were using MRU. And not only editors. Windows ALT-TAB always used it and I just got used to it since the days of Windows 95. I never used MacOS. Maybe MacOS uses left-to-right behaviour? I don't know. The only exception to this that I use is Google Chrome and me always enraged his left-to-right behavior. Especially when 20 tabs are opened and I only want to switch between two, but know that the other 18 will need soon, therefore not close them.
But the important thing with Windows and all other editors with MRU: If you do not release the modifier key after pressing TAB, then they show overlay window with current items placed in MRU order. And therefore you know the order.
MRU is very convinient when you need continuously switch between two items (tabs). But it can became very inconvinient if you really need to switch to other tab. And in this cases this overlay window with list of items is very important. Without it I can understand @AgentME feelings about randomness. :) I like how it's done in tab-history extension. Used it before (when atom does not have this functionality) and it worked like a charm.

I think it's fine if there's no modal dialogue for users who upgraded. I just think it's sad that this wasn't mentioned in the release notes and that such a huge change to the default keybindings was made without keeping (simple) configurability in mind.

@xak2000 of course you're right about this issue unfairly representing the no-MRU camp, but, as was mentioned earlier by @UltCombo, the original thread that was apparently the basis for the feature's inclusion in Atom was the exact same but the other way around - all the MRU people posted there so the Atom core devs thought there was a lot of call for it and very few people against it. So yeah, creating a decision by asking the community will never be fair unless there's some way to ask every last user their preference.
That said, I say don't bother with the modal - it's too intrusive and more than a little odd to do. As has been said, most other editors use MRU by default, so it probably makes sense for Atom to follow anyway.
Also, FWIW @jneubrand it was mentioned in the release notes - v1.7.0-beta0 and 1.7.0 stable both mention it. They don't go into any more detail but they do say that MRU is in.

+1 for the option checkbox or the rollback. I've spent quite some time to at least figure out WTF, and how to fix this.
Right now both pane:show-previous-item and pane:show-previous-recently-used-item work absolutely the same, which is pure nonsense!

It's totally insane that I opened my editor up after updating and my tab behavior was completely changed. This should absolutely have an option to disable it for the sanity of developers everywhere.

@benogle

3 other pairs of commands (cmd-{|}, cmd-alt-left|right, ctrl-pageup|pagedown) that move left / right through the tabs.

FYI: None of these work on Windows for me with the CTRL equivalents except the page up/down, which is clunky on desktop and impossible on laptop. Furthermore, most users don't know this shortcut. There aren't viable alternatives for Windows users.
The keybinding did work, but it took me 15 minutes longer than it should've to find it (thanks to those who wrote it!).

Boo, Atom. Boo. 😿

The suggested workaround keybinding does not work for me... tabs are still switching in some unknown and weird order. Please reconsider disabling MRU by default!
I'm on Ubuntu 16.06 x64 with:
> atom --version
Atom    : 1.7.2
Electron: 0.36.8
Chrome  : 47.0.2526.110
Node    : 5.1.1

I've been looking for a suitable, modern replacement as I've been using Notepad++ for longer than I'd care to admit, and I thought I'd finally found it. I was loving every feature of Atom for a good part of the day, but I was only working on two files. As soon as I added more files to the pane, my workflow fell apart as I kept alt-tabbing to the wrong file. This is seriously frustrating!
So, another +1 for the MRU switch option.

I'd also like to point out that Notepad++ has a MRU checkbox sitting in the very visible location of the first settings pane the user sees when they flip the options open.
Not having this behaviour controlled by a core preference is in every sense counter-intuitive.

Honestly spent the last week or two thinking this was a bug. Not a fan of this change at all.

Whether MRU  is default or not is really not the issue - the issue is that if a user wishes to change the behaviour back the process is convoluted and unintuitive.
I don't mind if MRU is made the default but there really should be a preferences toggle to revert to tab order if the user wishes it without having to dig through search results wondering why their keymap override is not having the desired effect only to discover 'ctrl-tab ^ctrl': 'unset!' is needed as well.
Honestly what does this string even mean?   '^ctrl' ?  'unset!' ?  I assume that exclamation mark has some critical relevance to this command which is not immediately clear but the caret+ctrl is even more confusing.  I could go digging through documentation or source code to discover this but I really shouldn't have to.  a) The UI claims keymaps.cson is an OVERRIDE which I believe means that needing the unset in the first place is nothing short of a regression/bug, and b) Can people really be expected to know that this specific cryptic string in your custom DSL is required without spending time examining the API involved??
</my_2_cents>

@anomaly256
I am 100% not defending this MRU thing as I agree with the general sentiment of this issue, but to vaguely address your questions/points, this keymap stuff is an unfortunate grey area:
The caret syntax was introduced specifically (as far as I can tell, at least) for this MRU feature, in a way that means that the MRU stuff doesn't have to use core hacks - Atom is supposed to be modular after all, and bits of code that get special treatment in the core is not ideal. It means "when this key is lifted, do the following command, but not until it is lifted". As such, 1. it is necessary in order to ensure that the "last tab you were on" is only remembered when you actually stop on it (imagine pressing and holding down ctrl and pressing tab a few times, you don't want each of those intermediate tabs to go into MRU list) and 2. your keymaps.cson still is actually an override - the problem is that you can override the ctrl+tab behaviour, and presumably you are, but the caret control keymap is a completely separate keymap command that needs overriding. Hence why you need to unset it - you are overriding it with an unset.
But yes, it's all very infuriating (and somewhat counterintuitive).

I agree with @anomaly256. It's simply not user friendly to release a change to default behaviour without (a) making it painfully obvious to those users that the change was made, and (b) explaining how to reverse it.
In this particular case, we should have gotten a simple popup after upgrading, similar to how Gmail, Twitter, etc display informational popups to explain new features they've added.
In addition, the path for reverting this change should've been more thoroughly tested. There's a bug where copying the new key binding from the key bindings table in the settings doesn't include the ^ctrl part. Similarly, the key binding resolver also doesn't show the ^ctrl part. Due to this, it's all but impossible to learn about the new ^ctrl syntax and override the new keybinding, even for someone who knows and understands Atom's key binding system well. The fact that this bug exists means this change was made without really testing out the user experience of reverting it, which is a great way to frustrate a lot of people.

@alexrussell thanks for the explanation, and I can see how it's a bit of a pickle since there are actually 2 key bindings to override but only 1 is apparent/visible to the user.  I guess the 'copy' link on the keymapping page should account for releases as well and copy both actions that a key combination can result in.  I do think a preference pane addition to handle this 1 specific case is warranted though and easier on users.
@courthead I agree, the copying should include both press and lift actions a key combination can result in, then when a user sees them when they paste they can remove the ones they don't want to override.  Or at a minimum lift actions should be visible on the keymapping page directly underneath their press counterparts

The keybinding override doesn't work for me. While this issue is being sorted out, I've downgraded to Atom 1.6.2, before the breaking change. I just wanted to include this option in the thread in case it can help other people in the meantime:

Install atom 1.6.2 https://github.com/atom/atom/releases/tag/v1.6.2
Uncheck "Automatically Update" under core settings

(It seems that the "next tab" concept has MRU baked into it too? I'm not sure what's going on, but I don't want to spend time on this right now)

Same here @caseywatts, I'm unable to work with the current tab switching configuration. I could work out my mind to grasp which file I would go to when I ctrl+tab once, maybe twice, but how am I supposed to know on which file I'll end up if I press ctrl+tab four times ? How can I know how much time I have to ctrl+tab to reach that file over there ? I usually don't update often so I only noticed it recently. I'm very happy that I found this thread because I was going mad about this issue. Reverting back to Atom 1.6.2 it is then, yeah !

Was this argument already been raised?
Interface between human and computer should be as seamless as possible. Both human and computer should have the same information available / know the same things / talk about the same thing.
Left-to-right = predictable: A programmer can visually see how many taps on the keyboard's tab key is needed to navigate to a certain tab; tap = tab.
Metaphor/Analog: A model-M keyboard where keys stay in place enables you to type blindly.
MRU = unpredictable: A programmer might remember the last tab used (if accustomed to it) but other than that, most of us do not remember/follow the tab order past 2 or 3 tabs. Tabbing requires unreasonable effort (beyond 2/3 tabs) because the human does not know what the computer knows.
Metaphor/Analog: A model-M keyboard where keys constantly change places in order of word prediction to "help" the human type faster.
@xak2000: Windows Alt + Tab does not have MRU behavior (like Atom). Windows switches left-to-right but places the window previously used as the first next window, then continuing the other windows left-to-right. This is the most of "MRU" (variant) I have seen within other Windows programs that I use or have used (if I encountered such a program).
From Mozilla (Firefox) to Adobe (Reader/Photoshop) to Google (Chrome) to Microsoft (Visual Studio) to Corel (Paintshop) to Postman to WinSCP to ConTEXT.. they all use plain left-to-right.. (with Shift modifier to switch back)
Support for MRU, no matter its unpredictable nature, sure, I'll vote all for it! Everyone should feel comfortable and be able to customize his editor.
But lets make predictable tab-order (seamlessness between human and machine) the standard.
Alternatively, predictable can also be: left-to-right with "previous first next" like Windows, although Windows (Alt + Tab) is kind of a loner in its use.
On a different note: I have been using ConTEXT for years, trying out Sublime and the sorts, throwing them all away because they did not behave as expected (or actually because I could not find the right settings fast enough.. or at all..) Atom is the first editor that just did what it suppose to do out-of-the-box.. MRU by default might impact first impression more than you'd think..
You guys do what you want to do.. ultimately I care more about just having an on/off switch than how Atom is received by people about to make the switch to Atom for the first time.

aha! I accidentally investigated more :)
cmd+. shows the keybinding resolver, it shows how the keybinding is done. In my case, I'd brew installed atom, and it comes with its own darwin keybinding. Somehow both its keybinding and my personal override one (that was recommended in this thread) were both being triggered.

I tried removing the 4 offending lines from the bundled keymap (by clicking on its filename in the bottom pane), but that didn't work (and it also doesn't seem to be the best way to fix this).
I'm trying this now, using a more specific css selector to add the command back, as sorta recommended here:
'body':
  'ctrl-tab': 'unset!'
  'ctrl-tab ^ctrl': 'unset!'
  'ctrl-shift-tab': 'unset!'
  'ctrl-shift-tab ^ctrl': 'unset!'

'.platform-darwin':
  'ctrl-tab': 'pane:show-next-item'
  'ctrl-shift-tab': 'pane:show-previous-item'

@apboon Just to clarify: Windows Alt + Tab definitely have MRU behaviour.
Just now I have 5 windows open. Current active window (Chrome) is second on taskbar. I press Alt + Tab once, not releasing Alt. What I see in popup:
2(current) 1 4 5 3 (the index of window from taskbar). So it's a MRU, not just previous used inserted before others in left-to-right.
Not sure about "Visual Studio", not used it 10+ years. But "Visual Studio Code", which I use day-to-day uses MRU by default. But of course with popup window! So I must say it is popup window that missing. If it was present, most people would not even notice that Atom now uses MRU.
And you should understand that all this feelings about atom in comparison to other software that you used is yours personal feelings. For me, on the contrary, the lack of MRU was not good first impression. All editors that I used before were MRU. So it is just personal. So I aggree that it should be switch in config (and also popup window, because without it I better will use left-to-right than MRU).

maybe also some of my randomness was from this?

@xak2000 While having such popup would help grasp the order in which the tabs are with respect to the ctrl+tab, I have always frowned upon them because why have another list of tabs in another order than the one you already have in the editor ? If the order of the tabs you have in the editor don't suit you, then reorder them. Or maybe make atom reorder the actual tabs instead? So MRU and left-to-right would actually do the same. It might look pretty strange however...
To be honest, I think the discussion for or against MRU is not really productive. I'm not sure I could convince any MRU user to user left-to-right nor would I be convinced by any argument to use MRU. I think the only possible exit is an easy option in Settings. I don't really care which one is the default behavior, you can't please everyone anyway, I just want an easy checkbox to choose the one I like.

@xak2000, this made me giggle as we are both kind of right; it gets more complicated even. You are right about MRU order of window/program placement in the Alt + Tab list. Tabbing through the list itself (while holding Alt + Tab) goes left-to-right though. This is kind of what I was getting at. You can predict that each time when you press Tab, you will jump to the next thumbnail (representing a window).
I compare the tabs in the top in the Atom editor with the Alt + Tab list you see during switching.
So.. yes, Windows does MRU by placing its "tabs" in MRU order into an overview/list, and then going through it left-to-right. You can see where you are navigating to; the fifth window is actually the fifth tab.
Atom places tabs in some initial order or the developer reorders them to get a better oversight, then Atom jumps through the tabs in seemingly random order.
If Atom would forcefully reorder its tabs by MRU order, and go through it left-to-right, the user would know exactly where he would end up. But I think forcefully reorder would not be a very good solution :p
I just now noticed the commonalities and difference between Windows and Atom. Windows also have "tabs", which is the taskbar. But Windows does not use the taskbar to highlight which window (in MRU order) it has currently selected (like Atom does now); because it would be confusing to go through a non-MRU list (taskbar/tabs) in MRU-order (or presenting any order and then going about it in another order).
Looking at Windows, in order to do MRU right and predictable, Atom needs a MRU ordered list to pop-up while Ctrl + Tab-bing.
MRU support yes. But needs an MRU ordered (pop-up) list to make sense. "Blind MRU" does not work in my opinion.

@dmo-odoo
The discussion should indeed not be about MRU yes or no. Let everyone have the editor they love.
The discussion should be centered about these three flavors:

Tab order (sequential)
MRU order (pop-up; sequential)
"Blind MRU" (unknown order)

Blind MRU being the current implementation.

Looking at Windows, in order to do MRU right and predictable, Atom needs a MRU ordered list to pop-up while Ctrl + Tab-bing.

@apboon  Exactly! This is what I'm talking about in almost every my post about atom MRU implementation (I usually call it "popup window").
And yes, of course selecting items in this popup window goes left-to-right (or rather, up-to-down). How else? :) The whole purpose to show this popup window is to let user know the current MRU order instead of remember or predict it. It is exactly how MRU works in Eclipse, Sublime, Intellij Idea, Webstorm, Phpstorm, Visual Studio Code etc.
About reordering tabs instead of show popup window.. I think this is too intrusive. Maybe it is just my habit. I never used any editor which reorder tabs in MRU order. Maybe it will be convinient. Maybe not. I think rather no than Yes. If almost all other editors that use MRU show popup instead of reordering tabs, I think there is a reason. I'm just a user. But I'm sure, when something big like Intellij IDEA developed, there are experts of UI design and usability that take into account all possibilities and choose the "least evil" of all.

Another problem I see with this implementation (as stated in #11699) is that adding to the keybindings:
'body':
  'ctrl-tab': 'pane:show-next-item'
  'ctrl-shift-tab': 'pane:show-previous-item'

It should work as expected, without the 'ctrl-tab ^ctrl': 'unset!' needed.
The method called when ctrl is released (ctrl-tab ^ctrl) should not affect the shown tab, it should just change the internal stack of tabs; which shouldn't make a difference if we don't use MRU switching. The method linked seems to not change the pane to show, making it very weird that it does change behaviour.

Well, is anyone against the following points ?

keep the MRU feature but add a popup so you know which tab will come the next time you ctrl+tab
add an option to choose whether you want to use MRU with the popup or classic left-to-right tabbing

If not, then the only discussion left is which one should be set as the default. And to be honest, I don't really care, I just want both above points... ;-)

MRU should be disabled by default, with classic left-to-right the default.
Any user who wants MRU is likely to be an advanced user, who won't have any problems finding it in the settings to enable. Users who don't like MRU, or more importantly don't understand how it works, are more likely to give up and use something else - thinking it's a bug rather than a "feature".

Keep the MRU feature but add a popup so you know which tab will come the next time you ctrl+tab
Add an option to choose whether you want to use MRU with the popup or classic left-to-right tabbing
MRU should be disabled by default, with classic left-to-right the default.

I second that!

@valorin Atom's primary use case is as a development tool. Presumably the vast majority of it's users are "advanced users".
Anyway, as I pointed out earlier, it would be wrong to assume that the prevailing opinion in this thread is a representative sample of all Atom's users. We can't really know what the default should be without doing a poll of a representative sample of Atom's users.
Also all of the points being discussed in these last few comments have been made many times already:

"Display a pop-up of the MRU ordering" is covered by #11535
"Make it optional" was the whole point of this very issue
"Make left/right tab switching the default", has no dedicated issue, and so far nobody's really made a strong case for what the default behavior should be one way or the other. (And by a strong case I mean one backed up with actual data, not just "I like this way better".)

To assume that the average user is "advanced" is a very misguided approach to designing a widely accessible application. The left-right tab behaviour being the default is not an attempt to win a battle of opinion, but in fact undo the damage of the MRU switch, which itself was purely based on the preference of a few people.

On May 12, 2016, at 08:30, Andrew Meyer<EMAIL_ADDRESS>wrote:
@valorin Atom's primary use case is as a development tool. Presumably the vast majority of it's users are "advanced users".
Anyway, as I pointed out earlier, it would be wrong to assume that the prevailing opinion in this thread is a representative sample of all Atom's users. We can't really know what the default should be without doing a poll of a representative sample of Atom's users.
Also all of the points being discussed in these last few comments have been made many times already:
"Display a pop-up of the MRU ordering" is covered by #11535
"Make it optional" was the whole point of this very issue
"Make left/right tab switching the default", has no dedicated issue, and so far nobody's really made a strong case for what the default behavior should be one way or the other. (And by a strong case I mean one backed up with actual data, not just "I like this way better".)
―
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

Indeed, it seems to me the switch to MRU was done based on the opinions of a much smaller group of people than those who are against it.
Most importantly, MRU by default seems buggy to those who've never used it (I've been developing for 20 years and have never seen Atom's style of MRU), whereas left-right is intuitive to all people, even MRU users. Exactly zero issues were posted here mistaking left-right tabbing for a bug when it was the default. It's far more common in applications that support tabbing, e.g. every browser ever, the terminal, most IDEs, etc. Seems obvious to me what the default should be...

The left-right tab behaviour being the default is not an attempt to win a battle of opinion, but in fact undo the damage of the MRU switch

If the change was reverted days or hours after it was made perhaps, but I think that changing the default behavior again at this point, months after the original change was made, would just create more confusion, if anything.

Indeed, it seems to me the switch to MRU was done based on the opinions of a much smaller group of people than those who are against it.

That's certainly possible, but again, we don't know that without actually measuring it.

Most importantly, MRU by default seems buggy to those who've never used it

I think that's more of a side effect of the current implementation not displaying a pop up of the MRU stack (like literally every other MRU switching implementation I've used) than an inherent aspect of MRU.

If the change was reverted days or hours after it was made perhaps, but I think that changing the default behavior again at this point, months after the original change was made, would just create more confusion, if anything.

The users who don't like MRU would see it as an overdue bugfix, and those who do... well... that's what release notes are for! (Yes, that's the same miss-guided argument used for the switch to default... not such a good idea now, hey?)

If the change was reverted days or hours after it was made perhaps, but I think that changing the default behavior again at this point, months after the original change was made, would just create more confusion, if anything.

I disagree. The confusion is primarily caused by the poor user experience of the MRU feature itself, less so by changing between systems to the next. For people (like me) who endured MRU for weeks thinking it was a bug before finding this thread, this would be seen as a bug fix. And for people who like MRU, it would seem like a reversion to a tabbing system with a non-broken UX, since the current MRU UX is basically unusable.
Even after the MRU UX is fixed (via a popup), I still think there's a stronger case to make left-right tabbing the default, and make MRU opt-in. It's just a less common tabbing system in general, and although we may never be able to take an actual vote on what people want, the limited evidence we do have to go on suggests that people like left-right tabbing...

@courthead We don't have any evidence because, as @Ajedi32 said several times, this thread is almost exclusively filled with people who don't like MRU. Those who like it just don't google it.
Also we must take into account that it's not MRU is bad. It's implementation without popup is bad.

It's just a less common tabbing system in general

Completely disagree. Among programmers, MRU is more common tabbing system. Don't know which code editors you used before, but Chrome is not code editor.
But I'm not in any way not saying you are wrong and I am right. I'm just saying that everyone has their own opinion and their own experience. You should not take your own experience for the fact (so am I).
I'm just can't confortably switch between tabs without MRU. As much as you can't do without left-to-right. How many atom users are like me and like you? We don't know because this thread can't be taken as measure.
Anyway, many times it was suggested that there should be just 2 options and switch. Which option would be default? I don't care, really. I think MRU should be default (good MRU, with popup), because it is default in others cool code editors. But it just me. If left-to-right would be default, it's ok.
So let's close the discussion about which is better. There is no better. There is better for one group of people and better for others.
I think there is so many posts in this thread, that the developers of Atom is unlikely to be able to grasp the essence:

Current MRU implementation is broken (should be popup).
Current enable/disable of MRU is hard (should be simple switch).

I completely agree with @xak2000. And, I definitely was bugged by the previous defaults, and find the current MRU UX not "unusable", instead it works quite well for me, expecting MRU and finding anything else weird...
Could someone just add an option for disabling MRU and file a PR about it?  Those who like it just don't google it.

There are other threads, too. It seems to me the number of people complaining about MRU now that it's the default is much higher than the number of people who complained about LTR while it was the default.
But I digress. I think we mostly all agree on the important issues: MRU will be much more usable with a popup, and there should be a simple config option to switch between the two systems.

It's like if I upgraded and you changed my font to something completely different.

 PLEASE.

None of the ludicrously complex workarounds have solved this bug for me (OS X; Atom 1.7.3).

What, specifically, is being done to fix this and what is the recommended workaround?

There is currently no work being done to "fix" this.  As @lee-dohm described in https://github.com/atom/atom/issues/5344#issuecomment-215899975, the best way to approach this would be to move discussion to Discuss (heh) until a concrete proposal materializes.  The recommended workaround is to follow the instructions in this comment if you want to revert to left->right tabbing.

@50Wliu What do we need to do to make a concrete proposal materialize? At the very least, it looks like adding a simple config option for reverting the MRU change is universally supported.

Core team manager here. We hear you and definitely want to fix this. We will eventually if the community doesn't beat us to it. It seems the consensus is that we need:

An option to enable/disable MRU that modifies the keybindings.
A UI showing the traversal order when moving through tabs in MRU order, e.g. like tab-switcher.

We'd readily accept a PR to the effect.

@iolsen why not just extract the MRU feature along with UI to a separate core package? Those who like it, will keep it. Those who don't will just disable the package.

Don't you think it's overkill to have two tab-specific core packages?

 There are now about ~80 core packages. And I, for example, have disabled 30 of them.
And it's good.
Otherwise Atom will turn into Yet-Another-Monstrous-IDE-That-Can-Brew-You-A-Coffee. So, the more disable-able features, the better.

I'd kill to have Atom brew me a coffee, actually.
Would complement its CoffeeScript-based API nicely.

@Alhadis then write a package for that! :) Just make sure your coffee machine have an API ;) </offtopic>

Still open... huh. Why not assign it to @natalieogle ? ;)

I used to use Ctrl Tab and Ctrl Shift Tab all the time, but since this update the shortcut has been rendered entirely unusable because of its nonstraightforward and unpredictable behavior. It is, in my opinion, counter to human-centric design and should not be the default. Major ubiquitous applications like Chrome and Firefox go left right, and this MRU behavior differs from that common standard. Perhaps some other IDEs do the same, but they are less common than web browsers and they can't be assumed to use the better behavior. Please make left/right tabbing the default and add an option to set it to MRU. Or at the very least, at least add the option to tab left/right so I can even use the keyboard shortcuts again.

With tab-switcher, MRU is pretty much usable but otherwise would be very difficult since I can't predict which tab is going to be selected next. Sometimes, I'd have to riddle through many tabs just to get to the tab very next to the currently active one. Hope we get an option to switch the behavior pretty soon.

@Keavon There are instructions in the Atom FAQ on how to restore in-order tab traversal:
https://discuss.atom.io/t/i-want-ctrl-tab-to-work-like-it-used-to-how-do-i-do-that/28639/1
This Issue is only for adding a checkbox that does what the FAQ does :point_up:

@lee-dohm Fantastic, thanks so much for those instructions! It still should be the default and there still should be a checkbox, but at least I can work productively in the meantime.

http://www.webupd8.org/2016/08/atom-190-released-with-drag-and-drop.html
1.9 has been released and, as far as I know, there is still no option to disable MRU tab switching.

Related: atom/tabs#314, atom/tabs#361

I whipped up a simple package to disable MRU tabbing (using @BlaM's keymap suggestion).
Search for disable-mru-tabbing in settings > packages to install it.
https://github.com/entozoon/atom-disable-mru-tabbing

Noting some work in progress on this:

An option to enable/disable MRU that modifies the keybindings.

Still TODO.

A UI showing the traversal order when moving through tabs in MRU order, e.g. like tab-switcher.

[ ] Catch keyups more effectively: https://github.com/atom/atom-keymap/pull/156
[ ] New pane switch events to enable MRU List UI: https://github.com/atom/atom/pull/13008
[ ] MRU List UI: https://github.com/atom/tabs/pull/388

It boggles me as to why when it became apparent making MRU the default method of tab switching without a UI to show the MRU list and without a UI option to disable it was a bad idea that someone didn't revert that.
I just did a fresh Atom install 5 months after I first had this issue and the fact that I still had to search Google to copy-paste some lines into my keybindings.json just to have my tabs behave predictably is absurd.
Based on the current state of this ( @iolsen says the MRU List UI is still TODO ) MRU should not be the default, it should disabled by default and with an opt-in checkbox on the Core settings page.
I understand it was decided to use MRU as the default to appeal more to ST users since Atom is more or less an open-source ST built with Electron, but when the issue was raised that UI-less MRU behaviour is confusing and unintuitive the change to make it default really should have been reverted.

Indeed, imagine if Chrome suddenly switched its tab behavior to MRU. People would freak out and there would probably be a mass exodus from the browser because a logical feature was suddenly given illogical, unexpected behavior.

Definitely some mistakes were made pushing this out too fast. 😞

@iolsen it's not really a huge deal, I was just surprised to find the situation with this hadn't changed in 5 months given how rapidly Atom had been moving in other areas. I guess that's the thing with OSS though, often only the fun sexy parts get attention, so thanks and good on you for being the one to finally step up on this issue 👍

Tabbing behavior... changed... in my latest... Atom update...

It hasn't has it?

Looks like this bug was mistakenly closed by atom/atom-keymap#156. GitHub apparently isn't smart enough to realize that

and is a prerequisite for adding the MRU list UI (atom/tabs#388) that fixes atom/atom#11035.

isn't the same thing as

fixes atom/atom#11035

:stuck_out_tongue_winking_eye:

Is this still a current fix? With Atom 1.12.2 on OSX, the above code snippet does not revert the frustrating MRU default :/
'body':
  'ctrl-tab': 'pane:show-next-item'
  'ctrl-tab ^ctrl': 'unset!'
  'ctrl-shift-tab': 'pane:show-previous-item'
  'ctrl-shift-tab ^ctrl': 'unset!'

Is this still a current fix?

Yes it's still current in 1.12.x: I just confirmed it in 1.12.6. You might be able to use the keybinding resolver (cmd-.) to determine what's happening in your install.

@pehrlich looks right, the plugin:
https://github.com/entozoon/atom-disable-mru-tabbing
Still works for me, on Atom and Atom Beta.

Fixed in https://github.com/atom/tabs/pull/388. Set to ship in 1.14.

Thank you!

Thank you so much !

@iolsen, a god amongst men.

@entozoon Thank you!

Finding that option was really easy too! It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard'.
Jokes aside, here is the built-in option: https://discuss.atom.io/t/i-want-ctrl-tab-to-work-like-it-used-to-how-do-i-do-that/28639

😆 that's fair. We've been meaning to add setting search for a long time.

Is there any actual tick-box to enable or disable MRU, or is the official solution to edit the keymap.cson file ?

@dkurzaj there is a setting in the tabs package see https://discuss.atom.io/t/i-want-ctrl-tab-to-work-like-it-used-to-how-do-i-do-that/28639


Is it possible to fully hide a class?

Is there a way completely hide all unoccupied tag buttons for river/tags? What I want to do is basically the same thing that the hide vacant tags dwm patch does.
I have tried setting these properties:
font-size: 0;
min-width: 0;
min-height: 0;
margin: 0;
padding: 0;
border: 0;
opacity: 0;
background-color: transparent;

But they do not fully hide the tags. I still see blank space where the tags should be, and I'm still able to click on the unoccupied tags to focus them. I also tried display: none; and visibility: hidden;, but they were not valid properties.

same problem ,I want to hide some tags(no window),but visibility: hidden did't work.

A workaround can be found here: https://github.com/Alexays/Waybar/issues/2721


186 remove contract upload

closes #186

Pull Request Test Coverage Report for Build<PHONE_NUMBER>1
Details

7 of 8 (87.5%)  changed or added relevant lines in 4 files are covered.
5 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.4%) to 85.988%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

app/utils/tables.py
0
1
0.0%

Files with Coverage Reduction
New Missed Lines
%

app/routers/guest/applications.py
5
82.22%

Totals

Change from base Build<PHONE_NUMBER>3:
-0.4%

Covered Lines:
1749

Relevant Lines:
2034

💛  - Coveralls


HOCS-3577 Merge hocs-workflow main branch into epic/foi-mvp

HOCS-3577 Merge hocs-workflow main branch into epic/foi-mvp

Generally looks okay to go... there are a few possibly should do type changes but otherwise ok


Fix password flow

fix #3137

:x: There is undocummented changes. Run chronus add to add a changeset or click here.
The following packages have changes but are not documented.

:x:@typespec/http

Show changes


.NET Core 3.0 Preview 7 Migration

The first project to eat crab!

Successful running in production! .NET Core Rocks!


[Bug] SQL function: datediff, return error

Search before asking

[X] I had searched in the issues and found no similar issues.

Version
v1.1.1
What's Wrong?
when run query below:
select datediff('2023-03-27', '2023-03-26');
return 0
What You Expected?
return 1, '2023-03-27' - '2023-03-26' supposed to be 1
How to Reproduce?
No response
Anything Else?
select datediff('2023-12-31', '2023-01-01');
return 364, correct, so I don't now what's wrong with select datediff('2023-03-27', '2023-03-26');
Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

upgrade can solve


[Starter Bug] [SR-1608] NSStream

What's in this pull request?

NSStream "is-a" implementation with tests
Input/Output streams "has-a" implementation with tests

Resolved bug number: 1608 (https://bugs.swift.org/browse/SR-1608)
I have some questions i have outlined in the PR.
Specifically bout testing and using _MutablePairBoxing and _SwiftNativeFoundationType

closing and splitting in to smaller pulls


Inventory Manager - relative or cardinal directions don't seem to work

Describe
pastebin of code: https://pastebin.com/yrMbyY2Y
I'm having issues with the directions, the documentation says I can use relative or  cardinal directions, however when I use UP it says not a valid side.
When I use TOP, it doesn't seem to move the items. This script was originally written for 1.18 and I was trying to get it working in 1.19.2 again. Oddly enough, I had fixed this issue with a previous version of AP for 1.19.2 https://github.com/SirEndii/AdvancedPeripherals/issues/428 but I'm not sure if I'm missing something obvious...
I have also tried using WEST or LEFT, which has the same results as TOP or UP.
I made a 50 second video to demonstrate my problem, https://youtu.be/ostdsq1V6NQ
Steps to reproduce
See pastebin, plus 50 second video
Multiplayer?
Yes
Version
1.19.2-0.7.27r (Latest 1.19.2)
Minecraft, Forge and maybe other related mods versions
43.2.10 and 1.19.2
Screenshots or Videos
https://youtu.be/ostdsq1V6NQ
Crashlog/log
No response

Hi, this issue got fixed(#444) in 1.19.2-0.7.28r

Oh, I should have looked at the newer versions for posting. I'm sure it's fixed, just playing a modpack using an older  version. Sorry about that,

Np!