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
Preview for text files in version 1.6.0 #122
Comments
I would rather issue a 1.6 with the current feature set and then make 1.7 the one with the file previews, if it's ok for you. Will still need to see what's missing from documentation, with regard to the latest changes, and make sure the translations are on sync. |
Hello! TODO: |
Also:
|
Previewing text files is an old issue. Features that were not even planned were added to this version. Why postpone the preview solution? |
Ok. Let’s improve the preview for text files for 1.6 and let binary formats for later. Special care must be put in choosing which files are binary or text, and proper treatment of any exceptions. Regarding branches, until now all versions were intended to be compatible backwards, so it made some sense to fix any bugs in the next update within the same branch. Our public releases are published on PyPI, not on GitHub’s development repo. When we decide to switch to v2.x, then yes, we must keep a separate v1.x branch for bug fixes. I believe I have added tags for all previous releases, could you please check again? I missed one release, so I added a new tag recently. Maybe that’s the one you were referring to? With regards to tests, I can test on macOS Catalina, iOS/Pythonista, Haiku R1/beta2 and maybe a few virtual machines. The last time I tested on macOS, I got one failing test. I believe it has something to do with the creation of a comparison file, and you have already explained that to me but I confess I can’t remember. I will submit an issue to see if you are able to help, ok? Finally, keeping documentation in sync across different languages can easily become a mess. I would like to find some sort of technical solution to help keep them synchronized, but not sure what the best solution is. I know there are some specialized web apps, like Pootle which I have used for Haiku, but that would require setting up a server and probably some costs. I have heard of GlobalSight and OmegaT, but I haven’t tried any of those yet. |
Hello! This version is proposed by me for discussion. This has its pros and cons. What do you think? Updated
|
I think we can preview some binaries using the Python standard library.
Determining which files are binary or text files is difficult.
Ok. It makes sense to me.
There were changes in the version documentation after these tags.
I have Windows and Linux.
Comparison files are generated automatically in the latest tests. It might be an old test file.
I suggest maintaining only English documentation (Read The Docs and README) after v1.6. |
Hi! I had a quick look over your new branch and it seems a nice improvement indeed. Thanks. As usual, documentation must be clear about availability issues and IMO it should also include some guidance on how to get it to work on Windows.
Actually, I believe we can also count with iOS/StaSh has no With regards to multilingual documentation, I didn't give up on it yet. The English version will be the master, but any changes should be properly identified so that the translators know where to look for. I intend to keep maintaining at least the Portuguese translation (it can be kept in that single markdown file). |
Currently, command availability checking is limited to specific operating systems (win, linux, darwin). The
A shorter version of the documentation in one markdown file for each language? |
This information may be useful, especially the https://stackoverflow.com/questions/11210104/check-if-a-program-exists-from-a-python-script
I am not sure if we can make it much shorter without leaving some features undocumented, but we may consider keeping it in a single file if it helps. At this time, we have that situation in Portuguese (a short Readme and a longer single-file documentation). The simplest workflow (not necessarily the best one though) would be going back to a single file per language, merging back readme and documentation. That would let us with a single documentation file for each language. Now, the most important IMHO bit is to establish a workflow. For instance, whenever the user interface changes, e.g. a new feature is added/removed or it gets a new behaviour, the developer could also add a new issue indicating the changes that need to be updated in the documentation. If possible, the English version should be updated together with the code pull request itself, so that at least the English documentation is always up to date. The issue tracker would let us keep track of any sections that need to have their translation updated. What do you think? |
I propose to completely solve the issue with previewing text files in this version.
And we can leave a preview for the binaries until the next version of the package.
Option 1
Option 2 with skipping some known binaries
For example, files with known signatures.
The text was updated successfully, but these errors were encountered: