Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move functions to inc/ and add more tests #196

Open
wants to merge 18 commits into
base: master
Choose a base branch
from
Open

Move functions to inc/ and add more tests #196

wants to merge 18 commits into from

Conversation

lucc
Copy link
Collaborator

@lucc lucc commented Jun 29, 2016

@rkitover can you also test this on non linux system please. Especially the "Unify ..." commits.

@lucc lucc mentioned this pull request Jun 29, 2016
@lucc lucc force-pushed the test2 branch 3 times, most recently from 7a15f49 to cfa817a Compare June 29, 2016 14:37
rkitover added a commit that referenced this pull request Jun 29, 2016
Use tr -d '\015' to remove CRs instead of sed 's/\r//', many versions of
sed do not understand \r.
rkitover added a commit that referenced this pull request Jun 29, 2016
Use tr -d '\015' to remove CRs instead of sed 's/\r//', many versions of
sed do not understand \r.
rkitover added a commit that referenced this pull request Jun 29, 2016
In quit() for both vimpager and vimcat, change `exit "$@"` to
`exit "${@:-0}"` so that the default is zero explictly.

For some reason on OpenBSD `quit` for vimpager was returning 1.
@rkitover
Copy link
Owner

@lucc I fixed a couple of minor issues and rebased, now it passes on OS X, Sol10, FreeBSD and OpenBSD.

I haven't read the changes yet, will do so soon.

Could we please default to 4 space indent in new work? Just because that's what we made the main files. If you really need the two space indent it's ok I don't really care that much, but just trying to be consistent as much as possible.

@lucc
Copy link
Collaborator Author

lucc commented Jun 29, 2016

Ok will do the 4 spaces thing.

Is there a reason you put the github issue number in the git commit message? I would remove that.

@@ -19,7 +19,7 @@ quit() {

rm -rf "$tmp" 2>/dev/null # rm -rf "" shows error on OpenBSD
) &
exit "$@"
exit "${@:-0}"
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will also change this to exit "${1:-0}" as e.g. exit 1 2 fails. Some interactive shells don't even exit if you give more than one argument to exit.

@rkitover
Copy link
Owner

@lucc good point, any idea why the travis build isn't running for this branch?

@lucc
Copy link
Collaborator Author

lucc commented Jun 29, 2016

yes: https://www.traviscistatus.com/

I canceled the old osx builds that were blocking the current linux build. osx might still take a while and we could cancel some of them to see the linux builds run.

@lucc lucc force-pushed the test2 branch 2 times, most recently from bef454f to dea3ae1 Compare June 29, 2016 22:13
@lucc
Copy link
Collaborator Author

lucc commented Jun 29, 2016

@rkitover are you manually restarting builds on travis? I canceled some but their status changed to "created" again (was "canceled" before).

@lucc lucc force-pushed the test2 branch 2 times, most recently from 126deaa to dea3ae1 Compare June 30, 2016 00:25
@rkitover
Copy link
Owner

@lucc nope...

@rkitover
Copy link
Owner

@lucc all of this looks great, let me know when you want it merged.

That said, I'd like to do some things a little bit differently. I'm fine with doing this later and merging this now or doing it before we merge, either way:

  • let's leave program specific functions in the program, and just set a variable to not call main() when we source it for the functions, e.g.
[ "${VIMPAGER_SOURCE:-0}" -ne 0 ] && main "$@"

in this way, the functions can be tested without invoking the program, or reused, or whatever.

The intent of this is to have at least the relevant code in the program itself for people to look at.

  • runtime shell code should go into sh/ while stuff that gets included should go into inc/. Neither of these dirs are used by vim so we don't break the plugin bundle functionality.
  • common functions should be called something like sh/lib.sh
  • sh/ should get installed sh/lib.sh should be sourced at runtime by the installed version and the git version

The intent of the sh/ directory is to share shell code, as well as perhaps to spin off some of our work into separate projects at a later time. Like I was thinking of creating a platform.sh for shell programmers at some point with some of this stuff. Certainly I want to spin off my uudecoding work, that stuff was a lot of work, and it could be useful for things that make portable shell archives (I forget right now what that project was called...)

That's all I have. Questions, comments, disagreements? Let's discuss.

I am going to be traveling the next few days, my main computer with all of my VMs will be packed up (it's a 2011 mac mini) but I will have my laptop to check on things on the road. We're driving from the east coast of the US to the west coast, from Philadelphia to Los Angeles, and then we'll be on a 3 day cruise (where I'll have some limited internet and my laptop too.)

So I will be checking in on the project but can't do OS testing for at least a few days.

@rkitover
Copy link
Owner

@lucc also, just a reminder, you were going to give me more details about the hang you get with dash on arch. As I told you I made an arch VM and was not able to reproduce the problem.

@lucc
Copy link
Collaborator Author

lucc commented Jun 30, 2016

sh/lib.sh could also be lib/functions.sh or lib/vimpager.sh or so. I would prefer lib/ over sh/ as it is closer to things like /usr/lib/ in name.

I think installing code into /usr/local/lib is good. But when installing these "source files" we need to give them a better name than lib.sh or functions.sh as these are way to generic for a system wide lib directory.

I would also be fine with just renaming inc/ to lib/ (moving all files from inc/ to lib/). That would make it more uniform. Obviously only the needed files should be installed by make install.

I am fine with keeping some functions in the main scripts. But I think introducing a new environment variable just to not run main is strange. I suggest to move all functions that we want and can test to the separate files in inc/ and lib/ . These files should be sourceable without side effects aside from function and variable definitions. main() and maybe a few other functions would stay in the main scripts to give readers an idea about the code.

Factoring out code into a separate project: don't care.

We can either rebase and edit this branch or add new commits to do it. We can also merge now or add these commits first, I don't care.

I also AFK from time to time, no worries. (for example this weekend)

PS: I am running irc://luc.now-ip.net/#chat on my raspberry

@lucc
Copy link
Collaborator Author

lucc commented Jul 6, 2016

I will put together a report about the nvim+dash+man problem. It is dependent on my vimrc file so it is probably only a problem for me. Currently I just install vimpager with POSIX_SHELL=/bin/bash to solve it.

After some thought: lets merge this now/soon and do any further changes in a new PR. That makes it easier to start new PRs as this one is a big change that would result in merge conflicts with any other work.

@lucc
Copy link
Collaborator Author

lucc commented Sep 2, 2016

Bump: rebased after recent changes in master.

@rkitover
Copy link
Owner

rkitover commented Sep 4, 2016

Hey @lucc,

sorry for the long absence, but I just moved to my mom's house on the other coast of the US (San Francisco from Philadelphia, passing through Los Angeles) for a few months, and ended up doing a clean install of my mac etc. so I didn't have all my stuff to work with.

Anyway, I got my VMs back up, still need to fix some issues with the mac like the unstable thunderbolt GPU, but I can get back into things slowly.

Will get back to you on this soon.

@lucc
Copy link
Collaborator Author

lucc commented Feb 10, 2017

The tests do not yet pass but I managed to rebase it. I think the test failure is due to a recent change in the vimrc searching code.

@lucc
Copy link
Collaborator Author

lucc commented Feb 11, 2017

The test for find_vimpagerrc_files fails because of the changes in 1e862d5. Do would you like me to remove the test or try to fix it (it looks like the function can no longer garante that it will set these variables so what could we test?)

@lucc
Copy link
Collaborator Author

lucc commented Feb 14, 2017

I removed the offending test for now. I still have it locally so I will try to add it later again, but I want to get this PR finished some day, so not here :)

@lucc
Copy link
Collaborator Author

lucc commented Feb 20, 2017

On travis only the osx tests fail because of some strange issue with script and the tty.

rkitover and others added 4 commits February 20, 2017 14:44
Use tr -d '\015' to remove CRs instead of sed 's/\r//', many versions of
sed do not understand \r.
In quit() for both vimpager and vimcat, change `exit "$@"` to
`exit "${1:-0}"` so that the default is zero explicitly and quit() doesn't
fail if called with more than one argument.

For some reason on OpenBSD `quit` for vimpager was returning 1.
@lucc
Copy link
Collaborator Author

lucc commented Feb 20, 2017

Same solution as above: Just don't build on osx for now (that was very slow to start as well). I still have the code locally so we can figure it out later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants