[Suggestion] Easier removal of features and adding

[BeyondMagic]

Yes, sorry for not using the issue template, but you know, we know, everyone knows that tuxi will get more and more features, and since some want to use it only for a few ones, like math operations, we should have a fast way to disable the other features.

Right now the way is to go the tuxi file and comment or remove the lines with other features, but it's a slow process both to do it and undo as well, maybe making aliases/functions for each one should probably make things easier.

[Bugswriter]

@Genghius are you going to work on functions ? for every feature? If anyone solve this please be careful. Lot of things will change in script.

[Bugswriter]

@officialcactar @owl4ce @colonvirus I think it's time to fix this issue. Creating functions properly for each scrape and making a proper doc with images too. After this with a proper mass testing we can merge this with main and further add more functionality by writing proper functions.

[Genghius]

@Genghius are you going to work on functions ? for every feature? If anyone solve this please be careful. Lot of things will change in script.

I actually am not, i went to sleep yesterday and i just woke up with 10 issues. so imma spend today making a new PR panacea 4 the return of the meme to fix as many issues as possibles.

[colonvirus]

How about we split each scraper into its own file, as a function, make a file called tuxi_include (or something else) that calls all the functions, and can be commented out, And then source tuxi_include in tuxi

[colonvirus]

I could do this while i'm documenting the div classes So you guys just try fixing the issues

[Bugswriter]

How about we split each scraper into its own file, as a function, make a file called tuxi_include (or something else) that calls all the functions, and can be commented out, And then source tuxi_include in tuxi

No. Not a good idea. We can KISS

[colonvirus]

It's not complex, and it makes maintaining easier

Also, we can stuff edge cases without making the main code look messy

[owl4ce]

I could do this while i'm documenting the div classes So you guys just try fixing the issues

Maybe, looks like a great idea. For example,

/usr/local/bin/tuxi

#!/usr/bin/env sh

[...]

# Featured Snippets ( eg: who is garfield )
source /etc/tuxi/featured_snippets

[...]

/etc/tuxi/featured_snippets

#!/usr/bin/env sh

feat="$(echo "$google_html" | pup 'span.hgKElc text{}' | tr -d '\n' | recode html..ISO-8859-1 | tr ' ' '\0' | xargs -0 -n10)"
[ -n "$feat" ] && output "$feat" && exit 0

[Bugswriter]

It's not complex, and it makes maintaining easier

Also, we can stuff edge cases without making the main code look messy

We can add a image link which will tell what part of google search result we are dealing with the script. And then we don't have to make document. We can just commend the ID/Class on top properly.

Scripts will become document. But guys. Then we can't use curl method of installing. Also managing multiple files will come with more issues like -

• How we are going to feed the google_html? scripts are not going to work independently.
• Script behavior are going to rely on priority so .. if a function is working correctly. Still we can have issue due to priority in our main script.

can't we just write functions properly and call those functions? I know we are getting lot of new feature but soon we will run out of ideas when we scrape almost everything which we get from google search results. And I think our file is not so long? Look at neofetch .. whole program is just one file. Bigger than our.

also fff file manager is just one script. ?? 500-600 lines long script is fine. we can make sure it doesn't break.

[Genghius]

This is reaching the snowflake point, we are approaching the moment when we will not be able to change anything without breaking everything else. PR panacea 3 explains this better.

[colonvirus]

I suggested tuxi_include so that the users may decide what snippets they want to include or not

Instead of each scraper having its own file, we could atleast move all the scrapers to one file

[owl4ce]

I suggested tuxi_include so that the users may decide what snippets they want to include or not

Instead of each scraper having its own file, we could atleast move all the scrapers to one file

ok.

[Bugswriter]

I suggested tuxi_include so that the users may decide what snippets they want to include or not

Instead of each scraper having its own file, we could atleast move all the scrapers to one file

Even suckless devs don't do it like this. They provide patches which patch in one file, not snippets (different files). Also IG everyone want every feature. ?

[colonvirus]

If we wanted to be suckless, we would've done this in C lol

[owl4ce]

Yeah, I think don't KISS too much. Because isn't it for all the questions to be answered?

Different in context with the compiled low-level language so that it affects efficiency and performance.

[colonvirus]

Yea, we need to address all the cases, so that'll be messy Suckless programs and other unix programs do just one thing, and they do it well We do one thing too, scrap google, but not well, unless we cover all cases, but that's gonna make the whole code complex

[Bugswriter]

Yeah, I think don't KISS too much. Because isn't it for all the questions to be answered?

Different in context with the compiled low-level language so that it affects efficiency and performance.

idk man it's just I am not having a good feeling about making snippet scripts .. ask @Genghius He know thing is getting so messy in develop branch. What is wrong with functions? Functions are also separating stuff? If we add snippets Soon we will add .config and don't forget this is shell program not .. C or python.

[Bugswriter]

The max max number of features we can add from google search results will be less than 20. IG. It means 20 functions in one script.

[colonvirus]

We didn't say functions are wrong, we need them. I meant moving those functions to another file, sorta like a header file.

Alright then, we won't do that

[Bugswriter]

We didn't say functions are wrong, we need them. I meant moving those functions to another file, sorta like a header file.

Alright then, we won't do that

Ok so we do need functions right? How about we put this discussion on hold .. and implement functions in dev2 branch turning our current main version into more proper version with functions. ? Then we test our script and merge it again to main. and Since turning function means not tweaking anything with functionality. We shouldn't get any new issues while doing this. (if we avoid stupid mistakes) This will make our script a little extensible and then we can continue by adding our new feature which we have in develop branch as a form of function carefully. We will only add features which are well tested and avoid features which are creating bugs.

Then we can continue this discussion after that. Since we only have to put those functions into different file in form of snippets?

[BeyondMagic]

tl;dr let's make a plan before we add future PRs to fix all the hell of code

1. Documentation is code, code is documentation (organization purposes)
2. Scrapping an element? Document it, how did you get it and give the query
3. Make priority list explainable and logic (this will help fixing/removing the dependecy of rich snippets)*
4. Let's not kill the develop branch just because it has problems right now, most of the problems are because of priority than selecting elements, which is easier to resolve.

It seems that we all agree, contributors and maintainer: the problem is, still is, will always be priority & snippet's organization.

---

After "rich" snippets were added, we had some conflicts because its scrap was too broad and could always get some top answers, even in simple queries like "define power", yes. I tried to simplify it and I know others tried as well, like put them in bottom or get a more specific element with class or ID for it, but doing that it broke for some queries that "rich" snippes should get, which makes things harder. Location is a problem, too. Different answers in different countries, sometimes scrapping, sometimes not.

A fast skip, for both, we had option "-a" for all, and "-l" for location, so they were added in the develop branch, with this, we could see the results of all snippets instead of stopping in one and exiting the program, and the location. After some tries with "-a" option and random queries, it's obvious how rich answers could scrap for things they shouldn't and returning "View more", or something bad like that. A hell.

The solution could be putting very specific types of queries first, for example, math operations give a very specific element that we can scrap easily. Same for weather or lyrics. But! This stills a hell because it's unmaintable for some locations, like mine, even though I can get the lyrics using tuxi, I can't get it when I search in my browser (Firefox btw), so I can't fix those when Google Search updates (change all classes and IDs we are scrapping), and we had to add more one class for some who lived in U.S. and couldn't get it.

So, this script needs to be changed to fit the user its using by the user itself, we can't simply fix for all countries and put many and many different classes or IDs in the script, this is unstable.

This is in part my fault, and I know some made some mistakes, too, but scrapping Google Search is hard! So, and even though the code currently have an easy way to add features, an easiest way should be added.

The line to verify if the snippet was called successfully is repeated many times, it can be simplified to one line (I believe Genghius did it), I tried in the develop branch just to call a function, but I believe it can be further simplified.

anyway, this is not a rant, but a call for hope for the devs working on the script right now and a little bit of explanation of how we got here.

[Maskedman99]

tuxi will get more and more features, and since some want to use it only for a few ones, like math operations, we should have a fast way to disable the other features.

@Bugswriter how is the end-user going to make the changes, a dotfile (in .config) or some other method ?

[BeyondMagic]

@Maskedman99

The changes should be made in the script itself, bash is not hard to understand and we can make it more readable friendly for those who don't know much about bash.

[Bugswriter]

tuxi will get more and more features, and since some want to use it only for a few ones, like math operations, we should have a fast way to disable the other features.

@Bugswriter how is the end-user going to make the changes, a dotfile (in .config) or some other method ?

He ll use flags thats it.

[BeyondMagic]

tuxi will get more and more features, and since some want to use it only for a few ones, like math operations, we should have a fast way to disable the other features.

@Bugswriter how is the end-user going to make the changes, a dotfile (in .config) or some other method ?

He ll use flags thats it.

A flag for every snippet? Doesn't seem a bad idea.

[Bugswriter]

7

tuxi will get more and more features, and since some want to use it only for a few ones, like math operations, we should have a fast way to disable the other features.

@Bugswriter how is the end-user going to make the changes, a dotfile (in .config) or some other method ?

He ll use flags thats it.

A flag for every snippet? Doesn't seem a bad idea.

Why can we just start with functions. I promise we ll do snippets. but .. I want to move the first step.

[BeyondMagic]

Snippet ≈ function, lol.

[Bugswriter]

Snippet ≈ function, lol.

Ok do it. But in different branch. Give me PR. If it work correctly I ll merge

[BeyondMagic]

No, bro, I mean, the snippet (the one we use to scrap something, like ‹rich answers › and ‹define› are snippets), and, like you said, a function for each one should help.

[colonvirus]

Yo, here's something to make everything a little bit easier https://github.com/colonvirus/tuxi-docs

It has all the SERPs we currently have in the develop branch, their html bits, and images

[Bugswriter]

I have to say. This looks better than I first thought. So. .What next?

[Bugswriter]

Should we create a new branch?

[colonvirus]

For...?

[Bugswriter]

For snippets !! :)

[Bugswriter]

I created a new snippets branch. @colonvirus You can work on this branch and make snippets for all the features we have currently in our main

Will you do it? This will shift tuxi into a new snippets format and I will close this issue because then we can easily add or remove features.

[colonvirus]

Functions and main code all in the same file yea?

[Bugswriter]

Functions and main code all in the same file yea?

No NO. I now understand .. the idea of snippets. I still believe ..making shell script modular is not a very good idea .. But looking at the situation you are right .. we should make script modular so if something is not working we can just remove that from main.sh and fix separately. Also location factor is a issue. Lets try snippets. You almost did everything with your https://github.com/colonvirus/tuxi-docs/tree/main/SERPs IG just need to make a main.sh ??

[colonvirus]

So we have three choices,

Tuxi main executable at /usr/bin/tuxi

1. Snippet functions at /usr/lib/tuxi/snippets/ with each snippet having its own file And then . "/usr/lib/tuxi/snippets/*" in tuxi main executable Call sourced functions in tuxi's main()

2. All snippets functions in a single file in /usr/lib/tuxi/snippets.sh And then . "/usr/lib/tuxi/snippets.sh" in tuxi main executable Call sourced functions in tuxi's main()

3. All snippets functions will be at the bottom of the script Call functions in main()

[Bugswriter]

I need time. Lets just hold this. Give me time .. I will respond.

[BeyondMagic]

Thanks @colonvirus , your repo should be explicitly visible in the README.