On Mon, Jan 13, 2014 at 05:11:13AM +0100, Jason A. Donenfeld wrote:
[snip]
+static int html_lua_filter(lua_State *lua_state)
+{
+ size_t len;
+ const char *str;
+
+ str = lua_tostring(lua_state, 1);
+ if (!str)
+ return 0;
+ len = strlen(str);
+
On 13.01.2014 05:11, Jason A. Donenfeld wrote:
Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com
---
cgit.h | 2 +-
cgit.mk | 13 ++-
filter.c | 284
---
All those *_lua_filter functions look rather self contained, maybe
- Switched back to python2 according to a problem in pygments with python3.
With the next release of pygments this problem should be fixed.
Issue see here:
https://bitbucket.org/birkenfeld/pygments-main/issue/901/problems-with-python3
- Just read the stdin, decode it to utf-8 and ignore
From: John Keeping j...@keeping.me.uk
This stops the code in cgit.c::print_repo needing to inspect the
cgit_filter structure, meaning that we can abstract out different filter
types that will have different fields that need to be printed.
Signed-off-by: John Keeping j...@keeping.me.uk
---
In this second installment I've squashed things down and cleanly separated
the framework commits from the lua commits. It should be much easier to
comprehend.
The weakest part is still the Makefile changes, which might not be very
portable and could probably be more configurable somehow. If
At some point, we're going to want to do lazy deallocation of filters.
For example, if we implement lua, we'll want to load the lua runtime
once for each filter, even if that filter is called many times.
Similarly, for persistent exec filters, we'll want to load it once,
despite many open_filter
The lua one is hugely faster than the python one, but both are included
for comparison.
Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com
---
filters/email-gravatar.lua | 25 +
filters/email-gravatar.py | 33 +
2 files changed, 58
From: John Keeping j...@keeping.me.uk
Change the existing cgit_{open,close,fprintf}_filter functions to
delegate to filter-specific implementations accessed via function
pointers on the cgit_filter object.
We treat the exec filter type slightly specially here by putting its
structure definition
Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com
---
cgit.c | 6 ++
cgit.h | 4 +++-
cgitrc.5.txt | 18 ++
filter.c | 3 +++
shared.c | 1 +
ui-commit.c | 4
ui-log.c | 2 ++
ui-refs.c| 9 -
ui-tag.c | 2 ++
9 files
So that we don't have to include the if(filter) open_filter(filter)
block everywhere, we introduce the guard in the function itself. This
should simplify quite a bit of code.
Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com
---
filter.c | 4
ui-commit.c | 18 ++
Signed-off-by: Jason A. Donenfeld ja...@zx2c4.com
---
cgit.mk | 22 ++-
cgitrc.5.txt | 29 ++
filter.c | 186 +++
3 files changed, 234 insertions(+), 3 deletions(-)
diff --git a/cgit.mk b/cgit.mk
index
Jason A. Donenfeld ja...@zx2c4.com on Thu, 2014/01/09 16:19:
On Thu, Jan 9, 2014 at 10:18 AM, Christian Hesse l...@eworm.de wrote:
You modified the code to make the icon match the font size, which is 10pt
by default. This is hard coded to the css file. Please note the URL
includes a size
Thanks for all your hard work on this. Sorry for the extended back and
forth. More comments, alas alas, below.
On Mon, Jan 13, 2014 at 12:02 PM, Stefan Tatschner ste...@sevenbyte.org wrote:
- Using inline CSS instead of this sys.stdout.print() hack.
Please don't do this. Inline CSS makes for
Am 13.01.2014 15:21, schrieb Jason A. Donenfeld:
On Mon, Jan 13, 2014 at 12:02 PM, Stefan Tatschner ste...@sevenbyte.org
wrote:
- Using inline CSS instead of this sys.stdout.print() hack.
Please don't do this. Inline CSS makes for much bigger files, and
there's nothing in the HTML5 spec
Am 13.01.2014 15:50, schrieb Jason A. Donenfeld:
On Mon, Jan 13, 2014 at 3:47 PM, Stefan Tatschner ste...@sevenbyte.org
wrote:
No, that's not the issue. By default 'pygments' adds a pre
style=line-height: 125% tag so I had to change the line-height of the
other column as well.
Strange. It
Hi,
What reasons do we have for supporting lua at all? Why not just go
with luajit? It's faster and just as widely supported. The motivation
for not supporting vanilla lua is this luajit library:
http://luajit.org/ext_ffi.html . This would be a nice way of being
able to ship scripts without a big
Using trac theme for pygments. It is very clean and not as
intrusive as the default or pastie theme. Especially I do
not like the the 'pastie' theme very much because of the
very strange illustration of multiline strings (the red
background thing).
Signed-off-by: Stefan Tatschner
- Switched back to python2 according to a problem in pygments with python3.
With the next release of pygments this problem should be fixed.
Issue see here:
https://bitbucket.org/birkenfeld/pygments-main/issue/901/problems-with-python3
- Just read the stdin, decode it to utf-8 and ignore
Perfect! Applied. Thanks for going through all the revisions.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Am 13.01.2014 22:50, schrieb Jason A. Donenfeld:
Perfect! Applied. Thanks for going through all the revisions.
thanks as well. :)
I have one simple question (just out of curiosity; I do not want to bash
anybody).
Why did you apply my patch with tabs instead of spaces? I was wondering
because I
On Mon, Jan 13, 2014 at 11:13 PM, Stefan Tatschner ste...@sevenbyte.org wrote:
Why did you apply my patch with tabs instead of spaces? I was wondering
because I adjusted the python script according to pep8 [1] and I'm sure
the patchfile was with spaces. Maybe you have an automatic convert
Am 13.01.2014 23:16, schrieb Jason A. Donenfeld:
On Mon, Jan 13, 2014 at 11:13 PM, Stefan Tatschner ste...@sevenbyte.org
wrote:
Why did you apply my patch with tabs instead of spaces? I was wondering
because I adjusted the python script according to pep8 [1] and I'm sure
the patchfile was
Personally, I think the trac colors are a bit ugly. I like pastie
best. But this is just preference.
Here's a comparison site:
http://blog.favrik.com/2011/02/22/preview-all-pygments-styles-for-your-code-highlighting-needs/
If folks want to take some kind of vote, I'll go with majority opinion.
On Tue, Jan 14, 2014 at 3:12 AM, Tim Hill drtimh...@gmail.com wrote:
LuaJIT is currently compatible with Lua 5.1, not 5.2 or the upcoming 5.3, and
my understanding is the LuaJIT project has now forked from mainstream Lua and
will not be staying in sync with anything past 5.1, so I would
On Monday, January 13, 2014, Jason A. Donenfeld wrote:
On Tue, Jan 14, 2014 at 3:12 AM, Tim Hill drtimh...@gmail.comjavascript:;
wrote:
LuaJIT is currently compatible with Lua 5.1, not 5.2 or the upcoming
5.3, and my understanding is the LuaJIT project has now forked from
mainstream Lua and
On Tue, Jan 14, 2014 at 3:37 AM, Andrew Starks andrew.sta...@trms.com wrote:
I don't have LuaJit installed and would not install it (and migrate
everything I do over to it) just to use a library. By way of example, your
library may as well have been written for Python, for as much good as it
On Monday, January 13, 2014, Jason A. Donenfeld wrote:
On Tue, Jan 14, 2014 at 3:37 AM, Andrew Starks
andrew.sta...@trms.comjavascript:;
wrote:
I don't have LuaJit installed and would not install it (and migrate
everything I do over to it) just to use a library. By way of example,
your
On Monday, January 13, 2014, Jason A. Donenfeld wrote:
On Tue, Jan 14, 2014 at 3:37 AM, Andrew Starks
andrew.sta...@trms.comjavascript:;
wrote:
I don't have LuaJit installed and would not install it (and migrate
everything I do over to it) just to use a library. By way of example,
your
28 matches
Mail list logo
