Kallithea issues archive

That is because w3m and elinks do not (or not fully) support Javascript. While making Kallithea work fine with Javascript disabled is an interesting and worthwhile goal, it would need some dedication from a suitably knowledgeable developer. Contributions are welcome.

Note that I do not agree with your classification of this issue being a 'major' bug. Trying to use such minimal browsers on today's web is not at all the general use case.

For the contributions I will try to works with another FS dev during coming days.

For the browsing, when I dev I works in Emacs-nox in Xterm in Ratpoison

If you get time to load : sudo iftop

and then compare what happen during w3m and Iceweasel (or other) you will understand my position.

Respectfully.

How do you dev?

@_aurelien_, it is extremely difficult to comprehend what you're writing. Could you please make some effort to improve your English, so it doesn't undermine our communication? :)

Thanks!

I do not want to use graphical web browser.

Do you write your code in your web browser?

Just to report this but I have to use iceweasel because from W3M here is what I got on login : CSRF verification failed. Request aborted.

My english is maybe not very good, but, could you please make some effort to improve your freedom way of think, so it doesn't undermine our way of life? :)

Thanks!

I develop using vim inside a tmux session inside a terminal window. Web browsing/testing is done with regular Firefox. It's true that this is much more resource-intensive than terminal-based browsing.

CSRF refers to Cross-Site Request Forgery. It is a mechanism where a unique key is added to forms, and checked when the form is submitted. When the key during form submission is different than the one used to generate the form from the server, the verification fails because it may be a malicious attempt. I didn't think there was JavaScript involved here, so I'm not sure why that would fail with w3m.

Anyway, with respect to this issue #143 and the librejs issue #140: both are things that may be important to some people, and contributions in this area are welcome. However, the current amount of active contributors is limited. Each of these active contributors probably has his own priority list of changes they find worthwhile to make. Like in any volunteer-based open-source project, it is not possible to impose tasks on contributors. Anyone that sees issues in a particular area is welcome to fix/improve things and contribute patches. This is the freedom that the GPL is written for.

Thanks. A friend from Free Software is coming home for some days, we will tried to works on that, because it represent a trouble for us and some more. How do you want us to proceed? (I think we will fork kallithea on https://bull.codes make it run as test on another part of the server and then, if we make it fine, you will be able to bring it back to merge it to kallithea) This option sounds ok to you?

The friend is an English from England ... that should simplify this topic.

There are some guidelines with respect to contributing at http://kallithea.readthedocs.org/en/latest/contributing.html

With respect to communication, here is my respectful advice:

• describe in full detail what you mean. Issues you have reported so far are most often max. 3 sentences but should be described in more detail. Clarify what you do exactly, what the results are (including logs, messages shown, URLs used, ...) and what you expect the behavior to be. Links to an online page that displays the problem can help too.
• when referring to other software or technologies, like librejs, elinks, w3m, ... do not assume that we know them. Clarify what it does, perhaps with a link to some relevant website, and clarify why/how you use this, and how this poses a problem for kallithea
• avoid shortening words unless they are common abbreviations. For example, 'how do you dev' was hard to understand.

With these tips in mind, I think we will have much more fruitful communication. I don't really care whether people write in 100% correct English, as long as I understand what they mean.

Thank you Thomas (I will noticed that) When I write programs I use Emacs-nox in screen in Xterm in Ratpoison on Parabola or Debian That looks like this Then, git add fs.py ... git commit -m "blabla" ... git push

Sometimes I need to scroll the website not as admin, but as user to works with other people on some part of source codes. (bull.codes is for free software, so no waste of time to know if I can or not, or if I waste my time with open source type of stuff) So for that is C-x b (switch buffer) to use direct w3m but I do not see any repo, for exemple my folder contain more than 5 repo, but they are invisible (but I just see one folder) if you goes to https://bull.codes/git/aurelien from a (graphical) webbrowser you will see them.

Graphical webbrowser are as great as they are disturbing.

This is also related to issue #106.

I think that there should be a user-accessible page that simply lists the repositories that the user can see. This page should probably share code with the existing such list in the Admin->Repositories section. When JavaScript is disabled, the 'Repositories' button should then simply link to that page. When JavaScript is enabled, the current behavior should remain, but in such a way that the user can still opt to go to the full list page, and fixing the issues mentioned in issue #106.