Fix some style issues with lung nodule README and updated metadata.json

Fixes # .
Description
Fix some style issues with lung nodule README and updated metadata.json
Status
Ready/Work in progress/Hold
Please ensure all the checkboxes:

[x] Codeformat tests passed locally by running ./runtests.sh --codeformat.
[ ] In-line docstrings updated.
[X] Update version and changelog in metadata.json if changing an existing bundle.
[ ] Please ensure the naming rules in config files meet our requirements (please refer to: CONTRIBUTING.md).
[ ] Ensure versions of packages such as monai, pytorch and numpy are correct in metadata.json.
[ ] Descriptions should be consistent with the content, such as eval_metrics of the provided weights and TorchScript modules.
[ ] Files larger than 25MB are excluded and replaced by providing download links in large_file.yml.
[ ] Avoid using path that contains personal information within config files (such as use /home/your_name/ for "bundle_root").

Hi @zephyrie , there are two issues:

flake8 issue, which may due to their new release today (https://github.com/PyCQA/flake8/commit/b9a7794c4f425ef8419081e6993f99419cc667ea), it also impacts MONAI and I just created a ticket about it: https://github.com/Project-MONAI/MONAI/issues/5578
Th download large file issue, it also happens in https://github.com/Project-MONAI/model-zoo/pull/246  so far I'm not sure how to resolve it, I will try to figure out the root cause.

The flake8 issue is solved in the commit I pushed, but the download issue is blocked and may need to change the code in gdown side. I submit a PR in: https://github.com/wkentaro/gdown/pull/224 but not sure if it can be resolved soon.
To prevent block other PRs that only have flake8 issue, I will submit a separate PR to fix it first.
Hi @drbeh , the issue also happens in your PR. Hi @Nic-Ma and @wyli , do you have any suggestions here? Thanks!


XLC series thermocouple dataloggers

Hi Luke,
I am using one of your dataloggers, which I am very happy with by the way. I would like to know if you have any documentation for sending configuration to the device (TC type etc.) as a string using serial. I am reading data fine using python and would like to send the configuration using python, as I don't have any knowledge of C. It looks like TLOGA/B are formats for sending strings, is this correct?
Thanks,
Ben

Hi Ben, I am glad to hear that you're happy with the device. I don't have documentation for the configuration strings but I can put together a document over the next days.
You are correct that TLOGA/B are different formats for sending the data. Moreover, all the fields in GUI configure the device using strings over the serial port.
Is there a way I can reach you over email to pass on the document?
Thanks,
Luke


fix(version): update fabric8-runtime-console to 0.11.1

There were the following issues with your Pull Request

Commit: 9d1c5f446e638d85b2cf7fa2878fc51660756ad9
Your subject line is longer than 50 characters

Guidelines are available at https://github.com/fabric8io/fabric8-ui

This message was auto-generated by https://gitcop.com

There were the following issues with your Pull Request

Commit: 9d1c5f446e638d85b2cf7fa2878fc51660756ad9
Your subject line is longer than 50 characters

Guidelines are available at https://github.com/fabric8io/fabric8-ui

This message was auto-generated by https://gitcop.com


add sendPayloadChecksums config option and implement Bugsnag-Integrity header

Goal
Add Bugsnag-Integrity request header (where required APIs are available) and implement the sendPayloadChecksums core config option to allow opting out of this behavior.
Bugsnag-Integrity headers are set by default unless the endpoints configuration option is set, in which case they are disabled. This behavior can be overriden with the new sendPayloadChecksums config option.
Design

Bugsnag-Integrity headers are set where the environment supports it (requires native promises, subtle crypto, and a secure context)
The behaviour of sendPayloadChecksums was chosen to avoid possible CORS issues where custom endpoints are being used and they are not configured to accept the new Bugsnag-Integrity in requests.

Changeset

Add sendPayloadChecksums core config option
Set Bugsnag-Integrity in delivery-fetch, which is used in @bugsnag/web-worker.
Set Bugsnag-Integrity in delivery-xml-http-request, which is used in @bugsnag/browser.

Testing

unit tests on delivery-fetch and delivery-xml-http-request
manually tested using the web-worker example: event appears when integrity header is correct, event does not appear in the dashboard when the integrity header is wrong
integration tests for browser and web worker
e2e tests for browser and web worker

Do we also need to set this in the delivery-x-domain-request package? I suppose IE8 and 9 won't support an integrity header?

No, XDomainRequest is only available on ie8 and ie9 neither which support the necessary APIs for calculating and setting the integrity header. even ie11 is excluded because it doesn't have full native promise support, hence the typeof Promise !== 'undefined' && Promise.toString().indexOf('[native code]') !== -1 check.


Proposal: Adding C++ utilities to ign-cmake

Original report (archived issue) by Michael Grey (Bitbucket: mxgrey, GitHub: mxgrey).

Apologies in advance for the wall-of-text.
The original motivation for creating ign-cmake was to systematically ensure consistent build behavior across all the ignition projects, in a way that is maintainable and scalable.
Even though the ign-cmake package is still in development, it's had some very tangible benefits: we now have four projects (ign-math, ign-common, ign-msgs, and ign-transport) with robust build systems across all of our supported platforms and consistent package behavior across all of the projects. If we ever decide to change our packaging behavior or if we ever need to fix a build system bug, we can take care of it in ign-cmake, and all the ignition projects will benefit the next time they configure. Future and upcoming projects will experience these benefits as well.
However, we want to have consistency across all the ignition projects in more ways than just their build system and packaging. The most obvious example is the PIMPL pattern, which is a design pattern that we aim to use across all the ignition projects to achieve maximum flexibility in our development cycles without needing to be concerned about breaking ABI.
The forcing function that prompted me to make this proposal was in a recent ign-transport pull request, we found ourselves repeatedly writing boilerplate move and copy constructors, plus move and copy assignment operators for just about every darn interface class (here's a sampling from that one pull request: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19).
The worst part is, even with all that effort in manually creating all those constructors and assignment operators, some of the classes in that pull request still don't have proper copy and move semantics, simply because we have not yet noticed that their copy/move constructors/operators are missing.
That's when I remembered some design utilities promoted by Scott Meyers which makes the PIMPL pattern so very much more bearable. Here's a tl;dr of that article:
Instead of using a plain std::unique_ptr<Implementation> to contain the implementation object, you can have a impl_ptr<Implementation> which takes care of creating the copy and move constructors for your interface class. To make that more concrete, your class definition would look like this:
class MyClass
{
  public: /* Interface functions go here */

  private: class Implementation;
  private: ImplPtr<Implementation> dataPtr;
};

Then in the source file, your constructor would look like this:
MyClass::MyClass( /* constructor args */ )
  : dataPtr(MakeImpl<Implementation>(/* constructor args */))
{
  // Do nothing
}

This will allow MyClass to automatically create a copy constructor, move constructor, copy operator, and move operator, and all you have to do is replace std::unique_ptr with ImplPtr and new Implementation with MakeImpl<Implementation>. Note that we can also have a UniqueImplPtr which will allow moving but not copying, for classes that are not copyable. The catch, of course, is you need to have access to the header that defines ImplPtr and MakeImpl.
Since it's a single header file, the brute force approach would be to write the header and then drop it into each project. That's a viable solution if we're confident that we'll never ever have to make any changes to the implementation, but that's a very risky assumption to make.
Ideally, we would want the ImplPtr to be available in every project from a single source. We already have a project which is a required dependency of every ignition project: ign-cmake. If we were to consider the goal of ign-cmake to be achieving consistent, maintainable, scalable development (not just build+packaging behavior) across all the ignition projects, then it would make sense to have it provide a small set of C++ utilities that could be used across all projects to keep behavior and development consistent between them.
I can think of three utilities which would make sense to share across all projects right away: (1) the pimpl class mentioned here, (2) the warning suppression system which is currently in ign-common, and (3) the Console utility currently in ign-common. These are things that all project would benefit from:

Anything that can make PIMPL easier to stomach is a good thing.

We're repeatedly dealing with the same compiler warnings across every project. This would give us a clean way to handle those consistently everywhere.

Having the Console class and its error/warning macros as base utilities would allow us to have consistent status, warning, and error messaging behavior across all the libraries, instead of having some print proper messages while others print plain, unformatted messages.

We could also consider the Filesystem from ign-common, but I don't think that's as basic of a utility (and it will probably be replaced by the C++17 filesystem soon anyway).
Why not just use ign-common?
Right now, ign-common would be more aptly named ign-miscellaneous. Most of its content is not common to all projects, and it would be unreasonable to have all projects depend on it, even after it's been split into components.
ign-cmake is already a required dependency. Putting these utilities into ign-cmake will make them accessible to all projects right away, without introducing any new dependencies.
Then could we really call this project ign-cmake anymore?
Maybe not.
I would propose that we add these utilities to ign-cmake as a library called ignition-utilities (or maybe ignition-utils, or some variation on that). When each project calls find_package(ignition-cmake1) it will import a target for the ignition-utilities library, and ign-cmake can automatically link each project library against the utilities target. Consumer projects wouldn't have to change anything in their build scripts.
Then, when we're approaching the hypothetical release of ignition-cmake1, we can decide whether we want to keep using the name ignition-cmake. Maybe by then, ign-common will be rid of its miscellaneous components, and we can have ign-cmake take over the name ign-common. Otherwise, we could consider renaming ign-cmake to something like ign-utilities, ign-utils, ign-root, ign-base, or any other suggestions that people have. Or we could just keep the name as ign-cmake and accept the slight misnomer of the project.

A few months after this issue was ticketed, the utilities component was added to ign-cmake with the suppression warnings.
3 years later, on Ignition Edifice, we added the ign-utils package to serve this purpose, so we don't stretch the responsibility of ign-cmake and it can remain focused on build utilities. The ign-utils package is already used by libraries that don't directly depend on ign-cmake, like libSDFormat.
The PIMPL pointer helper is already on ign-utils, as well as the suppression macros. See #171 about deprecating the utilities in this repository.
I'm closing this issue in favor of putting new C++ utilities into ign-utils.


Odd behavior of training process in almost-machine-precision function fitting.

https://gist.github.com/AlessandroFlati/a4f5d23864bca30f2b96c1052efdc140

Please note that this is just an experiment - of course I know this is not the optimal way of training xy function.

Memorandum: never trust symbolic_formula without simplify = True, because it just trims down floating digits of the coefficient, while the result is actually correct (even if not "natural"). There was actually no problem with the trained model.
That said, is utterly strange that the "minimal" model won't learn this function even if we fix everything.
https://gist.github.com/AlessandroFlati/1934c6ba922388220f0a92acdc6cadfa

Maybe the most update-to-date version  0.2.0 solves this (at least partially). symbolic_formula() no longer does rounding, instead the user needs to specify how to do the rounding.
Example for multiplication:
https://github.com/KindXiaoming/pykan/blob/master/tutorials/Interp_1_Hello%2C MultKAN.ipynb


Require gulp-wp-pot

My first pull request - hope I'm doing this right!

Thanks @richtabor Don't know how I missed that. It was working at my end. Guess it was picking up the local CLI.

@richtabor This led to Version 1.0.3 with two fixes and one improvement.

Good to hear!


⚠ Bofrost.es has degraded performance

In 53d11d3, Bofrost.es (https://www.bofrost.es) experienced degraded performance:

HTTP code: 200
Response time: 1589 ms

Resolved: Bofrost.es performance has improved in 3395a47 after 32 minutes.


Upload only 3lap 1

Changed mk64.py to upload only the fastest 3-lap record instead of any top 5 record.

LGTM 👍


Disable an range of dates

Hello everyone, everything good?
I have a slight doubt, I want to insert a range of disabled dates in the calendar, but reading and rereading the structure I still haven't been able to find a way to insert an array of dates and make them "obfuscated", for example, if I'm using this framework for an agenda, I'd like to limit a few days and leave them "disabled", I didn't want to open this issue because I thought it would be easier to find a way to do this but I couldn't find it, I saw that there are two others issues How to disable future date in calendar? and Block Out Dates on DayRangeSelection with doubts similar to mine but although similar, but the solution given to one of the cases doesn't help me much because it doesn't allow me to enter more than one date.
I don't even know if it's possible to do this in the current state of the lib, if it's something too fancy please let me know so I can think of how to adapt this for it, I'm asking for help because I actually couldn't think of any solution with the code existing.
I thank and congratulate you for the development of this lib

Hey @Max8868 , happy to help! When you say "disabled range of dates," what is it exactly that you want? Do you want:

To prevent certain days from being tapped / interacted with?
To change the appearance of certain days so that they look disabled (crossed out? faded / greyed out? something else?)

Check out the Airbnb app - we use HorizonCalendar for all of our calendars. If you view a listing and select dates, you'll see that we prevent certain ranges of dates from being selected based on a host's availability.

Let me know how I can help!

Hello @bryankeller
would be basically that, my point is that I couldn't implement it here on my side 😅

@Max8868 you need to implement something like this:

private func viewDidLoad() {
  calendarView.daySelectionHandler = { [unowned self] day in
    guard !self.isDayDisabled(day) else { return }
    self.selectedDay = day
  }
}

private func makeContent() -> CalendarViewContent {
  return CalendarViewContent(...)
    ...
    .withDayItemModelProvider { [unowned self] day in
      if day == self.selectedDay {
        return CalendarItemModel<SelectedStyleDayView>(...)
      } else if self.isDayDisabled(day) {
        return CalendarItemModel<DisabledStyleDayView>(...)
      } else {
        return CalendarItemModel<NormalStyleDayView>(...)
      }
    }
}

private func isDayDisabled(_ day: Day) -> Bool {
  let date = calendar.date(from: day) // convert Day to Date
  // determine if date should be disabled or enabled, and return either true or false
}

You can create separate UIView subclasses for SelectedStyleDayView, DisabledStyleDayView, and NormalStyleDayView. Or, you can create one DayView type (or use the build in DayView type) and adjust its appearance using InvariantViewProperties. Either approach works.
Hope this helps!

wow, thank you very much, I was trying to do this for some time


📝 Documentation(All-in-Africa): Add Cap.so to the showcase page

Bug Report Checklist

[X] I have pulled the latest main branch of the repository.
[X] I have searched for related issues and found none that matched my issue.

Overview
It would be nice to have Cap.so be on the Showcase page of Million as well as Cap recently added Million to their setup

Additional Info
To find the file needed for the showcase, go to: https://github.com/aidenybai/million/blob/main/website/pages/showcase.mdx

Hey, could you kindly assign this to me?

Hey, could you kindly assign this to me?

Sure thing!


Add missing word

All other wildcard examples have the description "finds.....etc".

@Achilles1515 : Thanks for your contribution! The author(s) have been notified to review your proposed change.


[release-4.15] When updating status, do a live GET after conflict & Move diff before update to klog v2

Backporting in order to backport https://github.com/openshift/console-operator/pull/837
/assign @stlaz

/lgtm

/approve


Cyclic relationship in RXNO_0000580

Hi,
There looks to be a cyclic relationship in RXNO_0000580, where RXNO_0000580 is a subClass of itself:
<!-- http://purl.obolibrary.org/obo/RXNO_0000580 -->

    <owl:Class rdf:about="http://purl.obolibrary.org/obo/RXNO_0000580">
        <rdfs:subClassOf rdf:resource="http://purl.obolibrary.org/obo/RXNO_0000140"/>
        <rdfs:subClassOf rdf:resource="http://purl.obolibrary.org/obo/RXNO_0000580"/>

Please could you take a look?
Many thanks,
Rebecca

@rebecca-foulger thanls alot for finding this!
@colinbatchelor fixed in #50

Thanks for fixing this so quickly!


crash at the door leading to the bridge

Version
3.0.9
Seed
R730-WHKE-XNAA50QZ9W120LJMWK21XTACF857MXZZCXY
Scenario
RE 3 (Jill)
Player Character
Ada RE2
What happened?
When about to leave the park, that door that leads to the factory. it crashed. Also a request, could we get an option to turn off the custom "biorand" audio in the beginning? I'd rather not hear streamers saying it. Gonna attach a save file right before that door it crashes at.
17_2023-07-19 02^09.25.zip

Unfortunately I am not able to reproduce this crash, and neither were you on your second attempt. You teleported to the same room that the door connected to, so had it been a genuine issue you would have got a crash a second time. I think this might just be one of those occausional crashes that you can't do much about.


Command '['conda', 'info', '--json']' returned non-zero exit status 255

Working with the instructions to setup with Anaconda, jupyter notebook exists with an error
subprocess.CalledProcessError: Command '['conda', 'info', '--json']' returned non-zero exit status 255
Running conda info --json in the shell returns a status 0

This error happens when Anaconda is not in your PATH variable. Please check this.

Thanks @ittayd for your question, and thanks @cuent for answering. :)
@ittayd, did this solve your issue?

Closing the issue.  @ittayd , please reopen if the problem persists after following the instructions by @cuent .


Can't drag parents

I'm trying to do the same example as the in the demo page (the 'multi' example, with images)
http://jsbin.com/bequva/2/edit?html,css,js,output
I don't understand why on my example, I can't sort the parents in red

I've made it work http://jsbin.com/bequva/4/edit?html,css,js,output
but it's often hard to drag elements in the third tile


feat: Improve Spoon element to Sonar violation position matching

Fix #383
WIP implementation of the spec in #383

Currently, the only processor that fails tests when removing canRepairInternal is MathOnFloatProcessor. But that's not because the wrong element is provided to it, it's because its repairInternal implementation is not correct (it's easy to break it).

I want to setup a benchmark before merging this, so we can judge if it's at least as good as before.

#404 merged.

#404 merged.

Thanks! I ran the benchmark again, and we can see some improvements across the board. The ratios improved as follows:
Old total_repair_ratio: 0.8226181254841208
New total_repair_ratio: 0.8641141141141141
total_repair_ratio is unchanged or improved

Old attempted_repair_ratio: 0.9178910976663786
New attempted_repair_ratio: 0.9282258064516129
attempted_repair_ratio is unchanged or improved

For the precise updates, see 614d35d.
I'm happy with this PR now, ready for merge in my opinion!

@slarse thanks.


Issues with text sizes

Over the past few days I've been having some issues with text rendering in my project, so I thought it was best to ask about it. Not sure if it's a imgui-bundle (python) or regular imgui issue, but came here anyway.
In my project I need to be able to render text:

Using custom fonts (have the TTFs for them). They are purely glyphs, no icons and whatnots.
Using custom sizes: basically I would have a area (rect) in the screen where to draw the text, and the drawn text should fit/fill that area. So need something like scaling the text or calculating the proper font-size for the wanted area.

For custom fonts I've been using hello_imgui.load_font with FontLoadingParams(merge_to_last_font=False, inside_assets=False). And have a cache system to allow loading the same font over and over with different font-sizes
For rendering the text I've been using ImDrawList's add_text, passing the custom ImFont with the font-size to match the desired text area.
For the custom sizes part, initially I tried scaling the font_size arg to add_text, but that led to blurry/ugly scaled text.
So I made the font-caching system I mentioned earlier, using things like imgui.calc_text_size and so to calculate text sizes (from a "default" fixed font-size), and thus calculate the desired font-size for the area in which I wanted to draw the text.
Loading the same font with different font-sizes probably isn't very efficient but it solved the blurry text issue. However, now I have a issue that the size of the text isn't what I expected, mostly its height. It's kinda like the text, as imgui renders it (and checks in calc_text_size), has padding at the top/bottom of the glyphs. The following image shows this:

the blue horizontal lines is where I wanted the text height
the green lines is the size returned from calc_text_size
in this example, I had to offset the Y pos, and scale the text area height by 1.45 so the text height matches the desired area height.
the "bottom padding" seems to be to account for the "tails" or "bottom parts" of glyphs like q / g / p and so on (not sure the name of this), but the "top padding" has no discernible reason.

I appreciate any help solving this.
Frankly I'm not sure if the things I did are correct. I find imgui's documentation in general kinda confusing.
So what should/can I do to properly render quality text at any size, in any position, with custom TTF files?
Or how could I calculate that "top/bottom padding" of the font in order to take it into account and fix the calculation of text size/areas?

Hello,
ImGui Bundle uses Dear ImGui's font rendering. Only the loading may differ, since it provides helpers that will eventually call ImGui font loading functions.
For information, Dear ImGui can use either stb for the font rendering, or freetype. When using ImGui Bundle, the rendering is done via FreeType.

For the custom sizes part, initially I tried scaling the font_size arg to add_text, but that led to blurry/ugly scaled text.

For performance reasons, Dear ImGui will preload all the font glyphs at the desired size into a texture. This way, text rendering is then handled by pasting part of this texture onto the screen. This is the reason why it might lead to blurry text when rendering at sizes different from those that were loaded.
Please note that loading many fonts at many different sizes might overload your GPU memory.

the blue horizontal lines is where I wanted the text height.    the green lines is the size returned from calc_text_size
in this example, I had to offset the Y pos, and scale the text area height by 1.45 so the text height matches the desired area height.    the "bottom padding" seems to be to account for the "tails" or "bottom parts" of glyphs like q / g / p and so on (not sure the name of this), but the "top padding" has no discernible reason.

I think you might need to have a further look into font rendering, and may be at freetype documentation.
The terms you're referring to are "Ascent" and "Descent." Here is what a conversation with ChatGPT gave me; you might find interesting info there (expecially at the end)
https://chatgpt.com/share/f1cc254a-0a31-403e-8f63-64085d6be3b9

Sorry for the delay, been busy and only now managed to come back to this.
Good to know imgui-bundle already uses freetype. Don't recall seeing that in the docs/manual.
As for the performance aspect, I had that in mind already. In my project, for now, don't really mind that - the benefits of custom sizes will be better for UX than the performance costs. Also it's kind of a personal project, for now I don't think much people will use it for that to matter. I probably could change the text rendering to better suit my needs but that would require fiddling around with the native (C++) side of dear-imgui/imgui-bundle. This project is so far python-only (well, in what I code) and I like to keep it that way for simplicity.
However, I did have two ideas that might mitigate the performance issue:

Deleting/freeing memory from ImFonts I loaded that haven't been used in a while.
Only loading the glyphs I'm currently using, instead of the default load of all glyphs.

Any pointers/hints on how I can do those?
It's been some days since I've worked on this so I might've missed something but I don't recall seeing anything about unloading a font... And as for the partial glyph loading, I remember seeing stuff in the API about that using some predefined glyph-ranges but dunno at the moment how to create my own glyph-range for loading. Maybe would also need to merge the loading font into another? Remember I tried that initially when loading my custom TTFs and it had caused an error 🤔
As for the proper text size calculation, gonna check that and test using the font's ascent/descent for calculation, thanks!
When I have any results I'll get back here to let you and anyone else reading know.

Deleting/freeing memory from ImFonts I loaded that haven't been used in a while.

I don't think it's possible to clear only one font. But you can:
imgui.get_io().fonts.clear()

Only loading the glyphs I'm currently using, instead of the default load of all glyphs.

See https://github.com/pthom/imgui_bundle/blob/7d8fd2159b62389f8c8d2a9eecaa16482a957e29/bindings/imgui_bundle/hello_imgui.pyi#L881-L888
and
https://github.com/pthom/imgui_bundle/blob/main/bindings/imgui_bundle/demos_python/demos_immapp/demo_font_common_glyph_range.py

Thanks. I'll test those eventually.
As for the size calculation, I got it working with the font.descent value.
After some trial & error, I figured 2 (out of 3) fonts I use have a 2 * descent space at the top, and the expected descent space at the bottom. The other font was only a single descent space at the top and bottom.
Not the prettiest solution but it works fine. And since I most likely won't change the fonts I use or add new ones in the foreseeable future, it'll do.
I also had to put a max font size limit in place, since depending on context the code could try to use a font with size 230 (or larger) and that would crash imgui since the fixed buffer to load glyphs couldn't handle such large images.

I'm closing this issue please reopen it if you have more related questions


Adds feature to only save current window.

Issue ticket: https://github.com/Zeeker/sublime-SessionManager/issues/3

Looks good, thanks for the contribution!


proxy: Bump Istio dependency to v1.1.0 for Cilium 1.5

[ ] Bump Envoy dependency to the same SHA Istio is using
[ ] Update Istio dependency to v1.1.0
[ ] Update Istio GSG to match the new version

This was done via https://github.com/cilium/cilium/pull/7712


Not working with Nuxtjs

Hi,
Nuxt Version: v2.13.0
I can't figure out how to get this working with Nuxt JS.
I've imported the module as stated in the docs.
modules: [
'vue-scrollto/nuxt',
]
My markup in my component is as follows:

As a result, I get the following error and the scroll doesn't work at all.
vue.runtime.esm.js?2b0e:619 [Vue warn]: Failed to resolve directive: scroll-to
Am I missing a step? I am trying to apply the module to a list of LI's, should that cause issues? I think it's a pretty standard use case.
Thanks in advance

Same here

Hello,
I use that with Nuxt.js and work for me.
  modules: [     "vue-scrollto/nuxt",   ],

           {{ nav.name }}

nav.anchor return String for an example for me nav.anchor return "#services".
And my container is that :
`

      ...

`

Hello,
I use that with Nuxt.js and work for me.
 modules: [ "vue-scrollto/nuxt", ],

 {{ nav.name }}

nav.anchor return String for an example for me nav.anchor return "#services".
And add your ID anchor on your container you want to scroll to.

This worked well for me. Thanks, @RemiTiab!


Add data for coming soon breweries

Sidhe Brewing Company
990 Payne Ave
St. Paul, MN
http://www.sidhebrewing.com/
Expected: March 2015
Bad Weather Brewing
414 W. 7th. St.
St. Paul, MN
http://badweatherbrewery.com/
Expected: Summer 2015
Angry Inch Brewing Company
20730 Holyoak Ave, Suite 160, Lakeville, MN
http://www.angryinchbrewing.com
Expected: Spring/Summer 2015
Lake Monster Brewing
550 Vandalia St.
St. Paul, MN
http://lakemonsterbrewing.com/
Expected: Summer 2015
Amity Brewing
1075 St. Clair Ave.
St. Paul, MN 55105
http://www.amitybrewing.com/
Expected: Mid to Late 2015
56 Brewing
3134 California St. NE
Minneapolis, MN 55418
http://56brewing.com/
Expected: Mid 2015

All added with the exception of Amity.  The address for Amity points to what is pretty clearly a residential property.  Without a good location for a potential, pending taproom, there is no point in adding it.


SubFolder Setting when Using Imager with Imgix

For using Imager with Imgix.
Is it possible to add a setting for a sub folder in the imgix config profile for web folder setup?
I'm using one source / website in IMGIX and would like to have different imgix-config-profile / asset volume in Craft.
now I'm using the domains setting like:
'domains' => ['domain.imgix.net/assets/local'],
but would be better for validation if this would work:
'domains' => ['domain.imgix.net'],
'subFolder' => ['/assets/local'],

This was solved with release v2.1.8, which adds the addPath setting for Imgix configs (check the example in the docs).


Zipkin UI AWS ElasticSearch Encrypted data

Hi @adriancole
This is more a new feature, we have an elasticsearch as aws service and a zipkin docker as kinesis collector, for security concerns we need all data encrypted in elasticsearch, is possible zipkin UI Decrypt the data with a public key kms aws? I think this is a possible new feature
https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/encryption-at-rest.html

When Amazon says something is encrypted at rest that means that the APIs you use to interact with those things do not have to worry about decrypting the data. In this case it means the ElasticSearch instances the AWS hosts for you write their files to disk encrypted.

HIi @devinsba
Ok, but exists something for decrypt data with zipkin UI if maybe the zipkin collectors encrypt the data  (new feature)? it's only a discussion.  the store storage will be Elasticsearch (Forget the url) think in aws kms  module some integration..

If the collectors encrypted the data, then the UI could not query the data in any reasonable fashion. Please take any other requests or discussion about this to the zipkin repo: https://github.com/openzipkin/zipkin


Revert QAB when the action fails

Details

We want to revert the QAB when the action fails.
Fixed Issues

$ https://github.com/Expensify/App/issues/50311
PROPOSAL: https://github.com/Expensify/App/issues/50311#issuecomment-2396069442
Tests

Same as QA Steps

[x] Verify that no errors appear in the JS console

Offline tests

Same as QA Steps
QA Steps

Submit a money request to an invalid user (+1<PHONE_NUMBER>). It will give an error.
Press the FAB
Verify the QAB is not the money request done in step 1

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

https://github.com/user-attachments/assets/f9ca7d7b-45d8-48e9-bacc-d9b2c16cdc4d

Android: mWeb Chrome

https://github.com/user-attachments/assets/3b1b105f-6b53-4672-9c28-7ad87f6f04e1

iOS: Native

https://github.com/user-attachments/assets/247f474b-3aac-471b-808d-c323662868a9

iOS: mWeb Safari

https://github.com/user-attachments/assets/0669fa19-6257-4a8b-bb57-48b07232d9e3

MacOS: Chrome / Safari

https://github.com/user-attachments/assets/286a2086-a2e0-4280-b4e4-3c02fd40effb

MacOS: Desktop

https://github.com/user-attachments/assets/32b3a53a-b831-4b92-810d-b9c48dadc406

Reviewer Checklist

[x] I have verified the author checklist is complete (all boxes are checked off).
[x] I verified the correct issue is linked in the ### Fixed Issues section above
[x] I verified testing steps are clear and they cover the changes made in this PR

[x] I verified the steps for local testing are in the Tests section
[x] I verified the steps for Staging and/or Production testing are in the QA steps section
[x] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[x] I checked that screenshots or videos are included for tests on all platforms
[x] I included screenshots or videos for tests on all platforms
[x] I verified tests pass on all platforms & I tested again on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[x] I verified proper code patterns were followed (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I verified that this PR follows the guidelines as stated in the Review Guidelines
[x] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native
https://github.com/user-attachments/assets/905ce251-6028-44f0-b1d2-aad5c30e8fb7

Android: mWeb Chrome
https://github.com/user-attachments/assets/a74170db-7ee2-41b4-97f3-1c4121963933

iOS: Native
https://github.com/user-attachments/assets/1f4743db-8acf-4f14-b9bd-3b031f25c9b6

iOS: mWeb Safari
https://github.com/user-attachments/assets/ced14286-c062-4a05-ad11-1822fc9271a7

MacOS: Chrome / Safari
https://github.com/user-attachments/assets/24bfb09c-75ba-46aa-96b4-dfb7ee0ece34

MacOS: Desktop
https://github.com/user-attachments/assets/b463ffcd-642e-4940-acee-89cb69bb9610

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.


identifying issues in the current frontend code

[x] Using .css stylesheet instead of the inline styling
[ ] going through the code manually
[ ] fixing the file structure
[ ] every page needs to have its own file (separate from the components)
[ ] removing redundant code
[ ] create components for the code that appears more than once in any of the files
[ ] checking if a good LINTER for React exists (?)

MUI components are styled using sx prop, so as a halfway solution I moved most sx objects to a separate sxStyles file.


GO:0044291 cell-cell contact zone problematic for Dicty

I have papers, one of them PMID: 26801966 where for example a myosin I localizes to cell-cell contacts when they make contact in culture or in chemotaxis.
However, GO:0044291 cell-cell contact zone is a child of GO:0005911 cell-cell junction with the def: A cell junction that forms a connection between two or more cells in a multicellular organism; excludes direct cytoplasmic intercellular bridges, such as ring canals in insects.
It's true that Dicty doesn't have classical cell-cell junctions but they still make good contacts through surface molecules such as glycoproteins.
I would like to have a valid CC term to describe cell-cell contacts in Dicty. Is that possible? Thanks!

Hi @pfey03
Would GO:0098609  cell-cell adhesion work?

This term 'GO:0044291 cell-cell contact zone' is a bit weird - it's a NIF term, I only find 7 mentions in PubMed, and it's used to annotate papers that talk about cell junctions anyway, ie there are other terms that these proteins could be annotated to.

The parent 'GO:0005911 cell-cell junction' mentions multicellular organisms, but cites papers that describe adherens junctions. Maybe we can just make that term more general by fixing the definition?
What do you think?
@mah11 @RLovering you have your initials associated with this term; any opinion on this one?

I think GO:0005911 is meant to be generic enough to group terms for any & all junctions between cells. My involvement was literally 20 years ago, so no, I don't think I have anything more specific to contribute now.

thanks @mah11

@pgaudet, in Dicty users talk about cell-cell contacts but making cell-cell junction more general should work, maybe move cell-cell-contact (zone) as related synonym?

WRT cell-cell contact zone - does anyone know why we need a grouping term for
'intercalated disc' and 'peg and socket contact'?
@ukemi @vanaukenk @cmungall

Hi @pfey03
I fixed the def of cell-cell junction to
A cell junction that forms a connection between two or more cells of an organism; excludes direct cytoplasmic intercellular bridges, such as ring canals in insects." [GOC:aruk, GOC:bc, GOC:dgh, GOC:hb, GOC:mah, PMID:21422226, PMID:28096264]
and added synonyms:
+synonym: "cell-cell contact region" BROAD []
+synonym: "cell-cell contact zone" BROAD []

Thanks @Pascale, we have 15 annotations to cell-cell contact zone so I re-annotate those then to cell cell junction


Add Nirmara to adopters list

Explanation
Thank you for this awesome project! Adding Nirmata to Adopters list.

Awesome, thank you @anusha94 !


Can't use the library

While writing the dependencies I get this Issue called Bad Gateway and sync build failed due to this Error what to do ???
Could not resolve com.sothree.slidinguppanel:library:3.4.0.
Required by:
project :app

Could not resolve com.sothree.slidinguppanel:library:3.4.0.
Could not get resource 'https://jcenter.bintray.com/com/sothree/slidinguppanel/library/3.4.0/library-3.4.0.pom'.
Could not HEAD 'https://jcenter.bintray.com/com/sothree/slidinguppanel/library/3.4.0/library-3.4.0.pom'. Received status code 502 from server: Bad Gateway

can u provide more details on your problems?


registry is down

related to related to https://github.com/gulpjs/plugins/issues/168

No need for duplicate issues, just look at the one you linked

yeah I know, I found it afterwards, sorry


Defaulting mouse=a in a terminal is incorrect (new as of 7.4.2111)

Defaulting on the terminal mouse via defaults.vim breaks many expected behaviors, and should not be on by default, even when there is no .vimrc present.
In addition, this setting should lose to other settings in /etc if they express an alternate value that conflicts with the one in defaults.vim
Vim has a very long history of being conservative and reliable.  I have generally trusted vim.  This setting is far too aggressive.  Today it has caused significant lost productivity, and there is no clear path towards resolving this for the future across the many environments where I will encounter vim.  I cannot readily automate installing sanity on every image, vm, os, docker image, etc where I might expect vim to execute in the future.
I will  not be surprised if this is a dupe, but I made a good faith effort to search for past issues, open or closed, before creating it.   I feel it is a real and serious regression in vim behavior.

I do not see any explanation of what problem is caused by setting 'mouse' to "a".

I think this is a duplicate of #2042

#1188 and #1326 are also related.
I don't have strong opinion, but I saw several people complained about this setting.

As a random data point, I installed three new systems with Debian in
the last weeks; the first time I installed new systems for years. As
those systems were not intended for personal use, I didn't copy my
personal configs which have carried anti-mouse boilerplate for roughly
a decade.
I was bitten by mouse being enabled on every one of those systems;
especially when setting up, it's quite common to copy & paste text,
data, and config over. For configs, I usually use Vim. Not being able
to paste by pressing middle button and having my cursor jump all over
the place was surprising at best.
On the other hand, I do get that new users might have an expectation
of the mouse working. But I would argue that those could use gVim if
they wanted a more mouse-centric UI.
Richard

Using the shift key should work to get the terminal copy/paste behavior.  If it doesn't then probably there is something wrong in your setup.
Note that if we would remove setting 'mouse' to "a" then we have a lot of other users complaining that the mouse doesn't work in Vim.  It's impossible to guess what the user wants, thus we need to go for the majority, and it is unavoidable a few users will be unhappy.

Vim is a real outlier here.  Most terminal programs do not take over the mouse, so this newish behavior is failing principle of least surprise.
Then there are various problems.

the mouse setting docs are not clear on how to turn off terminal mouse, "not a".  Reading the docs leaves me without a clear idea how to turn it off.  I think most people would want mouse support in gtk-vim or mac vim, but not terminal vim and it's unclear from the mouse settings if turning it to some other value would break gui vim support for the mouse
The documentation states explicitly that "" is the default.  Users who are not expert in what defaults.vim is will likely not understand that it defaults to something else, really.
Checking the operating system defaults does not clarify the problem.
Decades of time went by for people to get used to set mouse=a being an option to switch on, and the downsides of mouse=a have not changed in that time.  For users to unpack how this came to be could take days of effort. (it did for me.)
Editing the operating system default config to change the mouse setting doesn't work, which is highly mystifying.  (I understand why now, but this was part of my journey to fix my vim install.)
My operating system (debian) basically wants to give me the mouse experience that I want, which is no mouse=a, but they can't because the customization layering does not provide for this.

Most terminal programs use only line editing.  Vim is a full screen editor, where using the mouse is expected to work.  I get quite annoyed when I run into a setup where it doesn't work.
I really don't see how users can use Visual mode, resize windows and many other things without the mouse.  And I see no reason to make disabling the mouse a better default.  Just get used to using the shift key if you want to dumb and low level terminal copy/paste (which doesn't support block mode, doesn't fill a register and has many other disadvantages).
The help clearly states that 'mouse' is set to "a" in defaults.vim, with a link to more detailed help.

You don't seem to be addressing any of the real problems.  This looks like you're pushing your own preferences on the world.
FYI, in my environment tried shift, and it didn't work.
I used to consider nearly all software to be unreliable, but vim was one of the reliable ones.

It's his project after all :)
I am failing to understand why you can't do :set mouse= and be done with it. After all, you most likely have probably already configured your vim, right?

Since you asked, I already pointed out this means that every time I ssh into a system, jump into a container, etc, selecting text with the mouse doesn't work.    You're suggesting that i put a config file into the world.  Happy to drop it at this point, but willing to answer any questions.

I don't have strong opinions about the default setting of "mouse", but I want to address this comment:

I really don't see how users can use Visual mode [...] without the mouse.

I use terminal Vim exclusively without mouse support enabled, and I use visual mode practically every day. I typically use "/" or "?" to move to the beginning of the text I want to select, use another search command to move the cursor to the end of the text I want to select then use something like V'' if I want to select a series of lines or v`` if I want a more granular selection.

this means that every time I ssh into a system, jump into a container, etc, selecting text with the mouse doesn't work.

How about changing the setting of your terminal? E.g.:

Disable mouse tracking
Set $TERM=vt100
Use a terminal which doesn't support mouse tracking

No need to set every system.

I really don't see how users can use Visual mode [...] without the mouse.

With the keyboard (mostly motions and text-objects).  I thought that was the whole point of visual mode---to be able to make selections while keeping your hands on the keyboard.

When I upgraded my servers to Stretch I ran into this. I agree this is a horrible default when running Vim over an SSH session and the change really should be reverted.
A typical use case for me is to double-click a word to highlight it, hold down shift and single click another word, which would also highlight the complete second word and everything in between. This works everywhere except (as of this commit) in Vim. @brammool The option to hold down shift no longer works for this use case at all, so as far as I am concerned Vim is now shipping a broken default and no longer covers my simple use case. Unfortunately this made it into Stretch and likely won't be fixed until all servers are upgraded to Buster, meaning this problem will persist for many years to come even if patched today.
For everyone else who just wants a good, tiny text editor with working mouse support and syntax highlighting to quickly edit a file on any random server they might need to access (ie. without a custom user configuration), JOE and Nano continue to work just fine and are also actively maintained and available seemingly everywhere.

Just got bitten by this working over SSH.

Most terminal programs use only line editing. Vim is a full screen editor, where using the mouse is expected to work.

This doesn't seem accurate to me, at all. The utility of vim is 99% in its use over SSH, where I DO expect it to act the same way as every other terminal program.

You don't seem to be addressing any of the real problems. This looks like you're pushing your own preferences on the world.

This seems to be the case here. Another +1 for running into this problem on a fresh install.
Right-Click to paste had always worked, until now. Knowing to hold SHIFT while you're in the middle of setting up large configs in a brand new environment is not something you would expect to know after years of never having to do it before.
I have read through the multiple issues on this project relating to configs and their defaults. There's a lot. And on each and every one of them, @brammool dismisses and promptly closes them all with essentially an "I don't care" attitude. Shame.
Again, I couldn't agree more with the following statement:

You don't seem to be addressing any of the real problems. This looks like you're pushing your own preferences on the world.

But, granted:

It's his project after all :)

However, this begs the question... How much noise has been generated by this new default? Is it worth the headache?
I'm confident if the "old" default behavior is brought back, the noise would go away.

Unfortunately Vim cannot possibly guess what the user wants.
If the default is to not enable the mouse, then all users that expect it to work will complain.  Or they might not even know the mouse could work if they enabled it. Or they don't even know how to enable it, since otherwise it always just works.
If the default is to enable the mouse then users who expect a different behavior will complain.  But they have an easy way to do ":set mouse=" and the problem is gone.  Thus it's a minor inconvenience.
Now some may argue that the current behavior gives rise to complaints.  Sure.  But if the default is the other way around then another group of users will complain (or think Vim is broken, if they don't know the mouse would actually work if they enable it).  It is my opinion that there are more users who want to use the mouse then users that don't want to use the mouse.  On top of that, since the fix is easy, defaulting to enabling the mouse is the right choice.

If the default is to enable the mouse then users who expect a different behavior will complain. But they have an easy way to do ":set mouse=" and the problem is gone. Thus it's a minor inconvenience.

The problem is for users who regularly SSH into many machines and need a text editor on them, for which this change cannot work. Unless they are all set up through configuration management under your control, in advance of connecting, every new machine will be using the defaults, so it might be impractical to set a configuration for every machine.
Worse still, some machine will use old versions of Vim, and some will use newer versions of them. The user experience is no longer consistent.
People who want the mouse to work are most likely to be people running Vim locally. They are more likely to only have one computer to configure, so it is far easier for those people to manually change the mouse behaviour if they so desire. That is why the default is now wrong.
FWIW, I'm actually an Emacs user primarily. I have the version on my local computer heavily customised to work exactly the way I like it (as I imagine most Vim users would). When I find myself SSHed into another machine (I wasn't initially using TRAMP from my local host) but also notice emacs installed on that destination host, I generally use Vim instead - because the defaults have always made more sense. For example, Vim doesn't create a file~ backup in the local directory automatically which can cause problems if editing some configuration files in specific directories. Vim by default shows you the row count without needing to run a command to show it. etc. Vim was the last good editor for this use case, but that is the case no longer.

I don't have strong opinion about this, but it seems that Bram doesn't want to change this setting anymore.

The problem is for users who regularly SSH into many machines

As I wrote above, you don't need to change the setting in every machine. You just need to disable mouse tracking in your terminal emulator.

As I wrote above, you don't need to change the setting in every machine. You just need to disable mouse tracking in your terminal emulator.

Emulating vt100 doesn't help -  it just makes things worse! For example, that breaks syntax highlighting. I think most people would agree that not having syntax highlighting is even worse than the mouse not working correctly.
However if there is some option in terminator that does what you mean, please let me know. I couldn't find anything that sounds like what you are describing and I've been using this terminal emulator for many years, so assuming such a feature doesn't exist.
Perhaps it would make more sense for Vim to have the default mouse setting changed only when Vim developers have upstreamed patches for all terminal emulators people are currently using to run it?
Alternatively, Vim might only have the mouse activated when in GUI mode (so it doesn't impact people running it in terminal emulators)? Aside from some edge cases such as elinks or dpkg-reconfigure menus that are primarily applications full of buttons/links, I question if people using a terminal emulator ever normally expect an application to alter mouse behaviour by default? I would be surprised if they did.

Unfortunately Vim cannot possibly guess what the user wants.

Again, there is no guess work required. Read this thread. We don't want mouse=a as a default. Put it back the way it was, please.

an easy way to do ":set mouse=" and the problem is gone. Thus it's a minor inconvenience.

Not a minor inconvenience when SSHing into many servers. It's a major inconvenience.

It is my opinion that there are more users who want to use the mouse then users that don't want to use the mouse.

*facepalm*
Why are you forcing you opinion onto the rest of the world? How did you come about this opinion? Do you have any data to support your opinion??
Opinions are like sphincters. Everyone has one!

since the fix is easy, defaulting to enabling the mouse is the right choice.

So you are admitting that we need to fix the new default. You may be shocked to hear that we never needed to fix the default config before.
It's not the right choice. It's your biased opinion. The right choice is to listen to your user base.
@brammool, Since you are a developer, it makes sense that you like to have the mouse enabled. I get it. You work on a local machine rarely needing to ssh and use vim on a remote machine. For those of us in the System Administration world, we use vim over ssh on a daily basis.
Since your fix is quite simple by running :set mouse=a on your laptop, could you please turn it off for the rest of the planet who doesn't use it?
If the rest of the world do actually use it, and  we are the minority, please provide factual data.
Opinions don't count.
I want to continue liking vim. I want to keep showing new linux sysadmins how good vim is. Please don't make me look for a different product... Please.
Hear Us.

Disable mouse tracking

I actually like this idea, as I want don't want my mouse to do weird stuff. I want my clipboard to work as it always have been. But I don't know how and a Google search got me nowhere. I might search later. I found some difficult solutions.
After stating the above, I feel compelled to question the reasoning for changing the behavior, as it is biased in two ways:

Note that if we would remove setting 'mouse' to "a" then we have a lot of other users complaining that the mouse doesn't work in Vim. It's impossible to guess what the user wants, thus we need to go for the majority, and it is unavoidable a few users will be unhappy.

How did you conclude that this is the majority? The point is: you won't get complaints from people for which Vim works well before you break things. Thus, your perception will be that the majority wanted mouse, which might as well not be the case.
By the same logic, your mouse-happy users will start to fade away because they will stop being vocal enough (because now it works how they want); now, we, who want the previous behavior back, are now the more vocal group and are now the majority. This implies you will bring back the old default. Your defaults will start to oscillate under this way of reasoning.
The problem is that mouse-unhappy users were never going to be vocal on time because we never knew a change like this was going to occur. We don't monitor each and every project to understand its commits and future. So it's unfair to the existing user base to think like this.

If the default is to enable the mouse then users who expect a different behavior will complain. But they have an easy way to do ":set mouse=" and the problem is gone. Thus it's a minor inconvenience.

This is the second bias: The minor inconvenience is exactly the same for people who wanted the mouse function. So, I propose a counterargument of mine: people who want the mouse have an easy way to do ":set mouse=a" and the problem is gone. Thus it's a minor inconvenience. Now your argument and mine are exactly the same.
I will just start looking for workarounds. This does not diminishes how much I appreciate Vim. Think of my comment as just a minor inconvenience. :-)

So, this is a case of a dev going all Gnome on it's user base. Gotcha.
The "easy fix" would be something like
echo "set mouse-=a" >~/.vimrc
use '>>' instead of '>' if you already have a customized vimrc

If you already have a personal vimrc, than it is no problem.

The utility of vim is 99% in its use over SSH, […]

Again, there is no guess work required. Read this thread. We don't want mouse=a as a default.

Since you are a developer, it makes sense that you like to have the mouse enabled. I get it. You work on a local machine rarely needing to ssh and use vim on a remote machine. For those of us in the System Administration world, we use vim over ssh on a daily basis.

Well, I'm neither a developer nor a sysadmin but a plain user, I never use SSH, and I want my mouse clicks to go to Vim and not to some dumb terminal, if at all possible, when I'm running Vim in a console terminal, so I get the same experience, or as close as possible, when using vim or gvim. So I'm giving the lie to all the quotes above, and yet I don't think I'm the only one of my kind, far from it. But I've had a vimrc since shortly after I started using Vim, which was long before defaults.vim came into being. Why don't you? No two people have exactly the same preferences: we're humans, not Panurge's muttons, after all (BTW, those particular muttons were sheep, actually, but at a time when the English upper class read Rabelais in the French original, hence the phrase "let's go back to our muttons"), thank $DEITY, and that's what the vimrc is for: You don't like the defaults? No problem, write your own settings into a vimrc, and voilà! Problem solved.

@tonymec If you don't use SSH, you probably have very few boxes you use Vim on. If you did use SSH to access remote servers from a pool of tens or perhaps hundreds of boxes possibly running different distributions with different versions of Vim, you would know that you no longer get a consistent experience.
The only option is to use configuration management to change the defaults for your user account on all these machines (which in some workplaces might be difficult where unnecessary customisation is frowned upon), or to remember to run :set mouse= every single time you launch the editor.

If I did, I would upload my vimrc somewhere on the Net, and download that into my user's home directory when changed (which isn't often). Yeah, version management is one option but not the only one. And if some admin wanted my home directory to be unwritable by me, he'd get my resignation slip fast.

I never said home directories are unwritable, but you're not going to just upload configuration files "somewhere on the Net" and expect to be able to access them in a production environment. There will be firewall rules, security policies, etc - just as there should be! You're not going to use a "USB chip" if you never have access to the physical hardware.
So yeah, if there actually were some practical solution other than those frustrating ones I've already listed, I'd love to hear it. I'm all ears.

alias vim=vim -c set mouse=

alias vim=vim -c set mouse=

This should be alias vim='vim -c "set mouse="'
Or, set the environment variable VIMINIT as follows.
$ export VIMINIT="set mouse="

Unfortunately I don't think the alias option is helpful over SSH, unless it's typed each time one connects to a remote box or is already deployed on each box (in which case, it would be no different from deploying a vimrc file).
The environment variable approach is more interesting. This would be great if the sshd_config setting PermitUserEnvironment was enabled by default or if it were added to AcceptEnv by default, but unfortunately it's not.
It's perhaps more reasonable to have this added to the AcceptEnv list on the servers we manage via configuration management (so we don't need to have per-user configuration preferences deployed everywhere). I guess that's as good as we can expect while the change to the mouse default exists, but it's far from perfect since each host still needs to be configured in advance.
At least the servers don't need per-user configuration changes, but individual users can still set VIMINIT locally as they wish (however they'll all have to update their ~/.ssh/config file also).

As Bram said, no matter what defaults Vim picks, it would annoy some users. Every default option is ultimately an opinion that the developer forces upon its users. Someone has to make a choice. You could always fork it.
There are already a lot of suggestions on how to alleviate this issue, but I'm kind of curious why people need to SSH into dozens of machines just to use vanilla Vim without any vimrc on them? I would assume you should mostly be deploying files to production servers, not to SSH into each one just to edit individual config files. Vim also supports editing files over scp, so you could be on a machine and edit files remotely, with all your customized vimrc on the local computer. A lot of terminals also do support shift-mouse-drag to select text (which I actually find really useful for using tmux with mouse mode on actually). Or you could always alias ssh to automatically map the vim command to start with clearing the mouse flag too if you so wish.

As Bram said, no matter what defaults Vim picks, it would annoy some users.

@ychin Except the users with some use cases are inconvenienced significantly more than others. Sure, it's not my project and I don't have any right to demand vim not mess with my mouse by default, but that doesn't prevent me from expressing my opinion or concerns.

I would assume you should mostly be deploying files to production servers

It is unfortunate so many assumptions have been made.
A recent example would be the issues over the last few months with the Linux kernel when running Xen paravirutal guests, and needing to run experiments with different boot arguments to get things working again. There have been issues in the past with the Debian Asterisk packages breaking some use cases where the server is using specific hardware and package pinning files needed to be adjusted.
When you have a significant number of servers to support that all run different software, things are going to go wrong and you're going to have to shell in and fix issues - which usually involves editing files with elevated privileges.
You may also have a bunch of machines that run non-critical services (such as an internal wiki, bug tracking software, inventory management software, etc.) that we don't have test infrastructure for, so in such cases configuration changes (Apache, PHP, etc.) need to be made and tested on the actual server before having changes migrated to configuration management.

Vim also supports editing files over scp, so you could be on a machine and edit files remotely

If you're already needing to be on the remote machine to run sudo update-grub, restart services, check logs, etc. it makes sense to use the editor already on the remote host as you already have a shell open there. Besides, none of our machines allow users to connect via SSH directly as root as per security policies, but editing such configuration files require root privileges.
Now if I wanted to do this, I could already do it with Emacs using TRAMP (and I do on occasion) - which even supports privilege escalation via sudo - but again I don't want to do that. It can be frustratingly slow when connecting to hosts on the other side of the world (where most of the hosts I manage are) and again - I already have a shell on the host I want to edit the file on.

A lot of terminals also do support shift-mouse-drag to select text

More error prone but nowhere near as efficient as double clicking anywhere within the first word, holding shift, and double clicking anywhere within the last word in a block (which I've been able to do without issue for as far back as I can remember in GNU/Linux) - especially when using a small font to maximise screen real estate. Doing that may now open visual mode and prevents Ctrl+Shift+C from even copying anything! Much of this issue is the inconsistent behaviour between machines we now face when performing simple mouse actions.

Or you could always alias ssh to automatically map the vim command to start with clearing the mouse flag too if you so wish.

I don't want the vim command to automatically start when I SSH into a remote host, if that's what you mean. I want to troubleshoot an issue, and edit files in a small vim installation (that most likely require privilege elevation via sudo) when I need to, and be able to copy and paste text between other shells and applications in a working and consistent manner. That's the use case.
For now I have AcceptEnv LANG LC_* VIMINIT in /etc/ssh/sshd_config which is deployed via configuration management, and I have SendEnv VIMINIT for all hosts in my ~/.ssh/config file, and I have export VIMINIT='set mouse=' loaded from my ~/.profile. This turned out to be an acceptable work-around for me for now. Much thanks to @chrisbra and @h-east for the tip.

I see, glad you got it solved for you.

As a user in a shell, I'm potentially jumping into and out of vim sessions quite a lot.

Try Ctrl-z and fg instead.  (I've also mapped Ctrl-z in my shell to do fg automatically / not spam the history, but fg is really short enough ;)).
Also of course there is :! if you do not want to leave/quit Vim (although you do not have the full shell there obviously).

Good point. Ctrl-z and fg would work for me in most cases. Something I have to get used to. :smile: Thanks.

This setting makes it extremely difficult to copy and paste between vim in a terminal emulator and other desktop apps. It makes absolutely no sense to force users to change a setting for this crucial feature. Make it an option, but have it off by default and make it show a dialog asking if you are absolutely sure you want to break copy and paste before enabling it.

External copy and paste is far more important that mouse support in a command-line editor. The whole reason anyone uses the command line is to avoid the mouse.

Everybody can have their opinion.  In the mean time the default has become "nvi". This means you can type a colon, copy the text, and Esc to go back.  It's the best compromise, I use it regularly in the Mac terminal.  I would not want to do without the mouse, e.g. for resizing a window.

OK, thanks! I'll remember that.
On Wed, Dec 11, 2019 at 1:47 PM Bram Moolenaar<EMAIL_ADDRESS>wrote:

Everybody can have their opinion. In the mean time the default has become
"nvi". This means you can type a colon, copy the text, and Esc to go back.
It's the best compromise, I use it regularly in the Mac terminal. I would
not want to do without the mouse, e.g. for resizing a window.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/vim/vim/issues/2841?email_source=notifications&email_token=AN54XP5I4YWO2ZGKYCGYMPLQYFNYVA5CNFSM4E4JFZG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGUV6RQ#issuecomment-564748102,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AN54XP74WHUHEVIIIGO5Q3DQYFNYVANCNFSM4E4JFZGQ
.

When you want this mouse then you edit the vimrc and enable it on your machine.
When you a system administrator you don't want mouse in vim and you've got boxes with the default vim. So the default must be mouse disabled.
Is this that hard to understand?

I am leaving vim because of this change of behavior! I was forced to search on the internet which led me here. What a waste of time for so many loyal users just for this tiny yet huge change! Sad!

Just joining the choir of people hating the new mouse mode default.
I log into tens of Linux machines daily, and copy and paste data between them. Having to :mouse= each and every time I open vim drains so much of my damn day.
The big issue with mouse mode is I expect pastes to go where my cursor is.. not where the mouse is. vim is a terminal application.  xvim can do whatever it wants.
Honestly, this change has been the single worst thing for my productivity in decades. I spend a lot of time in vim on a hugw number of systems. I'm having to spray vimrc files everywhere to keep from accidentally distroying sensitive bind zone records with paste data.

Hold shift?

@puremourning Please read the above posts. There are many situations where that doesn't help.

Honestly, this change has been the single worst thing for my productivity in decades. I spend a lot of time in vim on a huge number of systems.

I feel exactly the same way.

I just starting installing neovim (neovim.io) on every system I can find.  It disables mouse integration by default and offers some compelling features.

The default "mouse=a" is only used for xterm, where you can use the shift key to select text directly.
Otherwise "mouse=nvi" is used, in which case you can press ":" to go to the command line and then select text.

The default "mouse=a" is only used for xterm,

Most terminals report xterm.. so this is pretty irrelevant.
Here's gnome term under wayland for example:
gnome-terminal for example:
$ echo $TERM
xterm-256color

then simply set $TERM=foobar in your bash_profile

then simply set $TERM=foobar in your bash_profile

I repeat:
When you are a developer and want a fancy mouse then you set it up in your custom profiles.
If you a system administrator then you don't want mouse in vim and you've got boxes with a default vim. So the default must be mouse disabled.

If your $TERM says "xterm" then it should behave like an xterm.  How else can Vim know how your terminal behaves?

The whole point of this is the default to mouse=a means the following:

If you're a developer, and mouse mode is important within a terminal application, you have to :mouse=a one one system.
If you're a sysadmin managing hundreds of systems, and mouse mode drives you utterly bonkers breaking text pasting as reported pretty much everywhere (just google vim mouse sucks), you have to type :set mouse=-a in every document you edit on every system you work on, or put a vimrc in place across every system you manage in every user account you use (non-root, root, etc).

So the convince of a few desktop users outweigh the sanity of anyone using vim on 100's of systems and containers.

@ChipmunkV wrote:

If you a system administrator then you don't want mouse in vim and you've got boxes with a default vim. So the default must be mouse disabled.

The same could be said for system administrators who prefer the mouse enabled by default.  Having it by default allows them to resize windows etc. So I don't think it's a valid argument.  In fact, since you can use shift to prevent vim handling the mouse, it's more versatile if it enabled by default.
Every default setting is debatable, but if a default makes 90% if users happier, it seems like a win.
Now for sys admins that need to login to many boxes without ~/.vimrc on each box and who don't want the mouse, I don't really know how to set up their preference.  Maybe they should just start vim like this vim +'set mouse=.

If you're a sysadmin managing hundreds of systems, and mouse mode drives you utterly bonkers breaking text pasting as reported pretty much everywhere (just google vim mouse sucks), you have to type :set mouse=-a in every document you edit on every system you work on, or put a vimrc in place across every system you manage in every user account you use (non-root, root, etc).

I was about to write a cynical comment, but I figured it may be much more helpful to actually be constructive here :)
So would the following help:

Only :set mouse=a if a real xterm is used (by parsing the v:termresponse value and setting this value only for xterms > 266 which was released around 2010
Leave the mouse setting alone if an environment variable $VIM_DO_NOT_TOUCH_THE_MOUSE exists

This way you could set in your environment export VIM_DO_NOT_TOUCH_THE_MOUSE=1 and vim will no set the mouse option at all. Not sure if this helps, you would still have to configure your environment to add that variable there of course.
Something like this in a patch:
diff --git a/runtime/defaults.vim b/runtime/defaults.vim
index f1d5cd1ed..577d54602 100644
--- a/runtime/defaults.vim
+++ b/runtime/defaults.vim
@@ -78,12 +78,9 @@ inoremap <C-U> <C-G>u<C-U>
 " can position the cursor, Visually select and scroll with the mouse.
 " Only xterm can grab the mouse events when using the shift key, for other
 " terminals use ":", select text and press Esc.
-if has('mouse')
-  if &term =~ 'xterm'
-    set mouse=a
-  else
-    set mouse=nvi
-  endif
+if has('mouse') && exists("$VIM_DO_NOT_TOUCH_THE_MOUSE")
+    set mouse=
+  " Rest will be handled in <sid>SetMouse()
 endif

 " Only do this part when Vim was compiled with the +eval feature.
@@ -124,6 +121,27 @@ if 1
          \ echohl None
   augroup END

+  augroup VimTermResponse
+    au!
+    autocmd TermResponse * call <sid>SetMouse()
+  augroup END
+
+  function! <sid>SetMouse()
+    if exists("$VIM_DO_NOT_TOUCH_THE_MOUSE")
+      return
+    elseif has("mouse") && &term =~ 'xterm'
+      " Try to match xterms specific Terminal Identifier and only set the
+      " mouse=a if we are sure, that this is an actual xterm (version > 266)
+      let termresponse = matchlist(v:termresponse, '\(' .. "\e" .. '[>\d\+\);\(\d\+\);\(\dc\)')
+      if len(termresponse) > 2 && (termresponse[2]+0) > 266
+        set mouse=a
+      else
+        set mouse=nvi
+      endif
+    else
+      set mouse=nvi
+    endif
+  endfu
 endif

 " Switch syntax highlighting on when the terminal has colors or when using the

This obviously would need some documentation and perhaps the setmouse function can be made even more bulletproof.
Or perhaps I am just over-engineering this whole thing 🤷♂

@kallisti5  wrote:

It's kind of frustrating from all sides. Do a quick search for "vim disable mouse paste" and you get a million results of people trying to figure out how to turn this off
https://www.google.com/search?q=vim+disable+mouse+paste

It seems exaggerated:

people who don't like the new mouse setting will post, but people who like it stay silent. So it's biased.
many (or most) of the Google results are unrelated to the default mouse setting.  Google has become so bad that it annoyingly ignores some of the words in the query.

I'm really not sure that most users prefer the mouse disabled rather than enabled.  I suspect most prefer the mouse enabled, especially when it's easy to use shift to have the behavior you want.
In any case, you can't satisfy everybody here, so I don't see a way to resolve it.

IMHO, there's no point in trying to revert the change now (nor continue arguing). It had been 4-ish years since the issue surfaced with the new batch of distros releases and at that point it made sense to argue, the change was somewhat recent and the old users, who found the change disruptive, were far more than the new ones, who find it normal behaviour.
Nowadays, at least in my case, it has become part of my setup new server routine to enter vim and ':set mouse =', with the occasional curse towards vim devs in general for the (not the actual word I use) stupid setting when I forget to issue the command.
Besides that, the issue was closed and no revert ever happened

I agree, kill the beast, we dont want this feature.

IMHO, there's no point in trying to revert the change now (nor continue arguing). It had been 4-ish years since the issue surfaced with the new batch of distros releases and at that point it made sense to argue, the change was somewhat recent and the old users, who found the change disruptive, were far more than the new ones, who find it normal behaviour.

I disagree on this.  You're starting to find frustrated sysadmins who manage hundreds of systems as the default of mouse=a sneaks onto "stable" distros that have a long gap between upstream changes and os releases.    It's not  reasonable to expect us to disable the mouse  across hundreds of systems.
It's also not reasonable to ask anyone working in containers to disable vim mouse mode across every container they need to exec into.   vim mouse mode doesn't not work properly in kubectl exec -it and most other container stdio environments.  It's a constant struggle disabling the broken mouse + clipboard interactions everywhere
Stop catering to the loudest users instead of catering to the seasoned professionals.

I want to apologize for my comments from 2019 in this thread. I should have either left this as a settled issue or politely explained my opinions, not exaggerated the "problems" caused.

Stop catering to the loudest users instead of catering to the seasoned professionals who get paid to keep the internet and servers everywhere running.

But we (who complains about this change) are the loudest users, you barely see any supoorter of this setting on here. My point was they didin't revert it at the moment, they won't do it now that YEARS have passed.
If you use ansible, you can set up vim with the rest of the server and get rid of the awful mouse handling from the very begining

The "new" default is completely useless for anyone because users won't notice any  change other than that copy&paste is horribly broken unless they read manuals or changelog. Changes that can have catastrophic consequences without any warning should not be default.
 Even most pure GUI apps still support copy&paste with mouse middle button because for many users it is  more convenient than reading man pages.
I have started using vim in the 90ties when it was a sane alternative to all the vendor specific flavors that often weren't even capable of using those funky arrow keys on newish terminals. Well today there are enough other vi clones that work for everything I need. Good bye vim.

Vim continues to evolve and move forward.
What if something like this also becomes the default for Vim?
set clipboard^=unnamed,unnamedplus
Wouldn't this solve more problems for most users?
I'm assuming that this would restore the expected functionality for what the new default mouse setting has removed from users - at least it would work in a number of scenarios that I can think of.
Since changing the long-standing default of vim to set mouse=a, was a step toward vim fitting in with current expectations,  then wouldn't it also make sense if vim also changed the default setting of the unnamed register to use the system clipboard (if available) as well?
I imagine that the sorts of users who care about a change to the default of the unnamed register, might typically be capable of reverting the clipboard configuration quite easily.   More easily than it is for the sorts of users who are impacted by what the change of the default mouse setting.

@zewpo that doesn't solve anything for me.

Open vim document with default mouse mode

set clipboard^=unnamed,unnamedplus

Scroll wheel click to paste selection buffer

Newline pasted, no text added.
p  , no data pasted
right click, cursor moves

Still frustrating, unable to paste lol.

@kallisti5
I wonder if it is related to how your system clipboard is configured in your session.
Also, is your vim running on the same system, or you ssh or tmux or somewhere in there?
Admittedly I don't have a middle button to click.
Just checking.  It works for me in xterm, kitty, xfce4-terminal, terminator, windows console command prompt, and the new windows terminal.

copy some text from web browser

open a terminal, eg xterm and run;
vim --clean -U NONE +"set mouse=a clipboard^=unnamed,unnamedplus"

just type p
p

see what happens
For me, I see that it correctly pastes all the text that I previously copied from my browser.

In vim, with mouse, select some text that was just pasted,

copy (yank) that text
y

open another terminal, say xfce4-terminator

open vim in the second terminal
vim --clean -U NONE +"set mouse=a clipboard^=unnamed,unnamedplus"

paste what you copied from the first terminal
p

see it pastes correctly what I copied from the other instance of vim.

open up some random text,  eg open help
h:

select some random text from the middle of the help text.

copy (yank) that text

open gedit

paste into gedit, (eg ctrl-v)

see that it pastes exactly what I yanked from vim.

I wonder if it is related to how your system clipboard is configured in your session.

Default configuration.

Also, is your vim running on the same system, or you ssh or tmux or somewhere in there?

Same system, or other system via ssh. Same behaviour

Done
Done
Done
4.a  Highlight clipboard.    Highlight text.   p to paste in vim.    E353:  Nothing in register ''
4.b  I copy text in Opera (by actually clicking copy).  Highlight and do a full copy..   press p in vim  E353: Nothing in register ''
I never do this.  Just yy, y1l, y1w, etc.
etc

As I mentioned, using the selection clipboard.  You don't have to copy and paste in Linux, just highlighting text puts it into your "selection clipboard" which you paste via clicking the middle mouse wheel.

@kallisti5
I know what you mean about the linux clipboard, and text goes into the clipboard on selection.   I like that when I am on linux.
At the moment, my clipboard is integrated with the MS-windows clipboard, so it may be just lucky that it works for me that way.
I'm opening up a separate linux desktop session to try out what happens when windows clipboard is not in the middle.

@kallisti5
OK, yes, I see now.   E353
I had to disable the windows clipboard sharing in my Xrdp connection.
Thanks for showing me.
I wondered if I was missing something, you know when something seems too easy... it probably is...
So, now, I'm gonna play around with that for a while.  Not giving up yet. lol.

When selecting the text using the mouse, can you try pressing the Shift key?
No difference.

Is anyone working on vim mouse mode and making it the default actually using Linux as a desktop? :laughing:

I use Vim on a Linux desktop with mouse enabled now. I used to strongly dislike it, but now that I tried it, it's a lot easier. At least on GNOME Terminal, holding shift restores regular mouse behavior temporary.

@kallisti5
I think it depends on the terminal
Testing in an xfce4 desktop session...
Shift does make it work for me in gnome-terminal, kitty, xterm.  And, I checked it works regardless of settings mouse  'a' or none.
In xfce4-terminal, the middle click just works in vim to put the selected text from opera.  And it works regardless of the mouse setting 'a' or none.  This was a nice surprise :)  Shift was not needed, but it also worked anyway.

@zewpo wrote:

Shift does make it work for me in gnome-terminal, kitty, xterm. And, I checked it works regardless of settings mouse 'a' or none.

Shift has always worked for me in any terminal I tried (xfce4-terminal, gnome-terminal, xterm, alacritty...) on Linux or macOS. It also works in tmux and when running Vim inside a Vim terminal.
You have to hold Shift as you click or select text in the terminal. Maybe you're doing it differently?

@dpelle
[Shift does make it work] ⊆ [Shift has always worked ]
then [you're doing it differently] is false
maybe you meant to ask @kallisti5 if he is doing it differently?

Shift makes no difference for me.  Can you provide documentation on what shift is supposed to do?
I can reference the FreeDesktop clipboard specification which doesn't mention anything about required modifiers:
https://specifications.freedesktop.org/clipboards-spec/clipboards-0.1.txt

I read in some comments above that  "people" expect the mouse to "just work".  I did absolutely not notice that it would "work" in any way - other than breaking cut&paste.
If it did anything on my Debian system (xterm) it was totally non-obvius.. would anyone enlighten me what it was actually supposed to do?

Ok...  I finally figured out the behavior.

Middle click in vim without holding shift pastes the VIM clipboard buffer

Middle click while hosting shift in VIM pastes the "PRIMARY" from the OS or the "CLIPBAORD" buffer from the OS. (it seems to be whichever was populated last?)

Essentially, vim is mixing up the clipboards in a weird way which directly is against the freedesktop clipboard specification above.
As such, I recommend vim disabling mouse mode everywhere, or reversing the weird non-standard logic.
(Holding shift plates the vim clipboard instead of pasting the OS clipboard)

For any future lurkers, this sums up why mouse mode is default now:

brammool commented [on Jun 11, 2018]
Most terminal programs use only line editing. Vim is a full screen editor, where using the mouse is expected to work. I get quite annoyed when I run into a setup where it doesn't work.
I really don't see how users can use Visual mode, resize windows and many other things without the mouse.

tldr; the vim dictator doesn't understand how to use visual block mode without a mouse.
Don't expect any movement here.  I give up.


Pinch to zoom on mobile, dragging with two fingers

Pinch to zoom on mobile, dragging with two fingers

Awesome project!
I was wondering if you are still considering adding Pinch to zoom on mobile, dragging with two fingers.
It would be super useful!


Get and set the primary colGeometry

In practice there usually is a primary colGeometry, and we can reorder the colGeometries so the first one is the primary one, like cell segmentation in MERFISH and Visium spots (or you can change it to the centroids). Maybe we can have a convenience function to do such reordering since many functions default to the first one.

Assigned to @mingqizh

Inspect internals:
library(SingleCellExperiment)
devtools::load_all()
# Inspect the internals
int_colData(sfe)

You should see that int_colData(sfe) is a DataFrame (S4 data frame), with columns that include reducedDims, spatialCoords, and colGeometries. The columns themselves can be DataFrames. Next run int_colData(sfe)$colGeometries to see the internals of colGeometries. It should be a DataFrame whose columns are sf data frames. Then simply reorder the columns of int_colData(sfe)$colGeometries so the first column is the primary colGeometry.


fix: handle wagmi connection rejection in example web app

Add handling for errors that are thrown by the useConnect hook from wagmi in the example web app.

related to #691