custom options parsing allows for per-sheet options.zM, which does row-wise expansion of iterables in a column (very useful with nested data).the "i" family of commands to add an increment column.more visibility for long values, with "v" to toggle multi-line rows and and z+hjkl to adjust cell offset.Here's curated list of highlights, the ones that seemed like people would be interested to know about: It may not seem like much now, but I predict that this becomes a sleeper hit. The fancy chooser (now the default for choosing aggregators or jointypes) uses this split window, and I have many other ideas for it as well. One panel contains the current/top sheet, the other panel contains the sheet "under" the top sheet. Press Shift+Z to split the terminal window into a top panel and bottom panel. Of course they all look the same in VisiData so I can go back and forth without any friction. json file and used that for a few months, and now I've been using it in an sqlite database. I've been using it to manage my mp3 collection and my personal contacts database, which was a tsv file until I wanted to add a multiline "notes" field, so I saved it as a. This means vd can work quite naturally as an interactive file manager, or as a sqlite database editor. These changes are colorized on the screen and can be saved as data (or not saved, in the case of deletes) with save-sheet (Ctrl+S), even if they haven't been committed back to the original source with commit-sheet. Deferred modificationsĬertain sheets which know how to incrementally update their source-notably, the DirSheet and SqliteSheet- defer changes made to them, requiring an explicit save/commit step with commit-sheet (z Ctrl+S). If you upgrade to 2.0 and learn nothing else about it, your life will be better for knowing Shift+U (undo) and Shift+R (redo). This is a "game changer" according to and redo, along with the new guard-sheet command, make it much easier to rely on VisiData for data cleaning and data entry. It still needs a bit more polish, but the meat and bones are there. Take a look at the actual API, at /docs/api. (We don't intend to strictly adhere to "semver", but it's still important to try to maintain backwards compatibility within a major version number.) So now, we have an API spec with over 200 functions, which will be of interest if you want to customize VisiData, or create a plugin for it, or just to know more about its internal components. I knew I wanted to go through every function and decide whether I wanted to include it in the 2.0 API to be supported for the rest of the 2.x lifecycle, which might be years. To be honest, this is what held off the 2.0 release for so long. The last released version of vdtui.py under MIT was 1.5.2 if anyone wants to use that. It's now just the visidata module as a whole, which I'm releasing under GP元. Approximately no one showed interest in that though, and it became unwieldy to maintain, so over the course of developing VisiData 2.0, the vdtui library was thoroughly dismantled. Previously, there was a core vdtui single-file library that I licensed as MIT, as I thought it might be a platform for a variety of apps like VisiData. And, most importantly, an API specification for plugins. It's got several major improvements, a bunch of new loaders, and tons of new features and quality of life improvements. After almost 2 years of development, version 2.0 of VisiData is finally released.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |