Repository navigation
Fasta syntax #14
Description
I'm curious, what is the reasoning behind the chosen fasta syntax ?
IMHO this syntax would be great for a diff tool but not so much for browsing large collections of nucleotides sequences.
Please don't get me wrong, I really liked this project!
Activity
ababaian commentedon Jan 4, 2018
The fasta format is what actually started this project. I was doing manual contig assembly over a very difficult to assemble sequence (ribosomal DNA) and this meant having to align and edit sequences by eye. It was a nightmare until I could add syntax highlighting and read/write the sequence much more efficiently.
It's obviously not applicable for every use-case, but what I have subsequently found is that I still can infer patterns in large fasta sequences when scrolling through them. With the bioSyntax coloring scheme GC high and GC low regions are warm and cool respectively and you can approximate the kind of DNA you're in by looking at it. Also I can pick out low complexity regions visually which is useful when navigating a large sequence. That kind of inspired the whole project, there's tons of patterns in the data we're simply not seeing because it's a garble, check out the Preprint and there's a few more examples there.
Your idea with diff is good, that's a bit more applicable to multiple sequence alignments, which I would say CLUSTAL / .aln is better for.
nzachow commentedon Jan 4, 2018
That is really clever, I never thought that someone could actually make sense of these large sequences.
For my workflow something like a 'fasta-lite' syntax would be more helpful.
What I have in mind is a colour scheme where the sequence identifier is clearly visible but the actual sequence only have a minimal highlight with alternating colours every 3 bases.
What do you think about this idea ?
I can create a small PoC with this behaviour for Vim.
ababaian commentedon Jan 4, 2018
I'd say draft it up and share some screenshots. Let's see how creative you can get. A large part of this project has been exploring different and new ways of parsing the same information. If you think it's useful then other people may find it useful too!
I think since FA files are all organized into columns, adding a very slight accent or highlight to every 3rd or every 9th nucleotide and keep everything else standard may be even better. This will make a visual 'block'. Another feature is that some programs such as 'sublime' have a Ruler which can be set. You can essentially add a background grid of 3-char length to a certain file-type. This might be useful too.
The bar to keep in mind and compare yourself to is that almost anything is better then nothing and nothing is the standard 🤣
nzachow commentedon Jan 5, 2018
My first idea was to use alternating colours every 3 chars but it wasn't much helpful.
After that I went with your idea and highlighted every 10th char.
This second approach was also tested with 3, 6 and 9-char spacing, however I felt the result was more noise than actual information.
The good thing about the 10-char spacing is that it allow me to quickly count and compare sequences lengths.
I've also tweaked the code to use the colours defined by my theme. This allow the highlight to blend nicely with my environment.
ababaian commentedon Jan 5, 2018
That looks pretty snazzy; while every 10th does sort of make sense for our decimal system I think every 9th is more biological as it breaks down each chunk of sequence into a triplet of codons. i.e. columns 1,10,19,28,37,46,55.
This discussion raises what is probably the more important point: it would be best if you can change a single variable in the theme file and let the user decide which number columns they want to use
One note though, don't hard-code the colors into the theme file. Use links to refer to a class of text you would like the highlighting to work with. This way the colors are taken from the
./vim/colors/<theme>.vimfile.If it's alright with you I would like to add this as a user syntax. There will be lots of choices and use-cases for different people, I'll set-up the repository and website in such a way to include and share these. Might need a couple of days though ;)
Edit: Setting that up was easier then expected! When you're happy with the syntax definitions see Adding Alt-Definitions.
Or if that's too much work, just upload the files here and I can add it.
nzachow commentedon Jan 8, 2018
Nice !
I definitly agree with your point about user choice.
One thing I'm not sure about is where to put the documentation.
For example, in this syntax we probably will have a boolean for biological or decimal
highliting and I feel we should have a standard place to put detailed description for every
option and how they all(if it's the case) interact. Maybe even some use cases.
I could embeed this information in the file itself but I don't think it's the best solution. Maybe a
better approach would be creating a
<File_type>-<ID>_<Program>.mdfile containing thedescription.
You should expect a pull request, hopefully, before the end of this week.
ababaian commentedon Jan 8, 2018
I think the idea is to include all this usage information in the main
alt-syntax/README.mdas the 'description'. That way it's displayed on github when that README is opened and I can use the same markdown file as a web-page on the site once there's a collection of user definitions.ababaian commentedon Jan 18, 2018
Hows it going @nzachow? Anything we can help with?
I came up with my own little alternative syntax. I've been doing a bunch of CDS analysis for my project and I came up with a syntax to find an open reading frame, it highlights the ATG in green, colors each codon in alternating numeric colors (blue/purple) and the stop codon in red. Actually ended up pretty cool. I'll add it to the Alt Syntax folder as an example.