Re: [Bug-zile] Google Summer of Code 2014

[Gary V. Vaughan]

Hi Garnaik, Reuben,

On Mar 7, 2014, at 9:25 AM, Reuben Thomas <address@hidden> wrote:
> On 6 March 2014 20:21, Garnaik Sumeet <address@hidden> wrote:
>> Hello Sir,
>>              I am delighted to hear back from you.
>> Since my knowledge regarding text editors is limited to designing and 
>> implementing the basic buffer management,basic screen management using 
>> ncurses library and the ability to support only ascii,I would love to work 
>> on the following few things:
>> 
>> 1)adding unicode support,since this would help me gain knowledge regarding 
>> managing unicode in editors.
>> 
> This is certainly something we'd like for Zile, and might well be the right 
> amount of work for a GSoC project.

There have recently been some unicode support libraries for Lua added to
luarocks, and since Lua is already almost entirely 8-bit clean, adding
unicode support to Zile is now a much smaller task than we originally
anticipated when adding the task to the list.  I think this is a great
choice for a warm up exercise, since it mostly involves installing all
the infrastructure to build and run Zile, and getting to grips with the
build system.

And then the simple matter of choosing and integrating one of the new
unicode support libraries already available in luarocks.

Bonus points for run-time detection of the unicode library, and only
enabling Zile unicode support if available... gracefully degrading to
the current non-unicode code if not.  This is how ansicolors support is
handled, and quite easy to copy.
>  
>> 2)I am keen to learn the basics behind the concepts of syntax 
>> highlighting,so recreating a parser would be a great start.
>> 
>> Gary Vaughan is better placed to comment on this one.

This is quite a big task I think, and requires a fairly good understanding
of parsing and lexing.  The version I built originally uses Reuben's
lrex-oniguruma regular expression library for compatibility with the large
existing library of syntax highlighting modes for the TextMate editor.

Unlike a traditional one pass parser, any single key press can affect the
syntax highlighting of all following characters, and we don't want to
reparse an entire file every time a character is added to the beginning of
its text.  The strategies I used to mitigate this include, only running
the parser and highlighter when idling (handling screen updates, and user
key presses in the input buffer takes priority -- the highlighter plays
catch up each time the screen is up to date and the input buffer is empty),
and giving priority to (re)highlighting the currently visible portion of
the file.

The last of those is particularly tricky because it requires that the parser
be restartable at any point, so when editing in the middle of a large file,
the parsers only needs to restart from the state that it had just before the
earliest unhighlighted edit, and continue through to the end of the text
displayed by any buffer visiting the file.  Remembering that Zile may have
serviced several small changes if the user is a fast typist and kept the
input buffer from emptying for a short while since the last parse and highlight.

None-the-less, all of this code was working (albeit only just fast enough
to be useable) in an old version of the code before the tree was split up 
to support multiple editors in the same source tree.  I recommend porting
this code forward (one patch at a time) into current master to gain some
familiarity with how it works, and to have the opportunity to get concrete
answers to questions before moving on to a faster LPeg parser, which I'll
explain later :)

Take a look at the changesets towards the end of the topic/syntax-highlight
branch, which you may very well be able to get working separately by using
some older luarocks modules, once you're comfortable with the build system
and support infrastructure.

>> 3)I would love to implement a few new buffer implementations and allow 
>> myself to go out my comfort zone by implementing a few I am not acquainted 
>> with.
>> 
>> That's an interesting idea; I'm not sure whether it fits into any of the 
>> projects we have in mind. Gary?

It does.  One of the tasks I added from my TODO list is a splay-ropes
based buffer data structure as an alternative to the buffer-gap implementation
Reuben wrote.

Plenty of hints on the data structure at http://lua-users.org/wiki/SplayRopes


>> 4)Would love to add new editors to the framework.
>> 
> Reintegration of the experimental editor Zee is the obvious candidate here.
>  
>> All the things above will help me gain what I am seeking.Sir to be honest I 
>> am not familiar with zile code base and I am not familiar with lua,but know 
>> a few scripting languages,I have moderate knowledge regarding bash and have 
>> written a few small programs in it.
>> 
> I think Zile should not be too difficult to get to grips with, it's fairly 
> small and well-structured.

Easier than a lot of other Lua projects in fact, because most of Zile still
follows a very C-like structure and uses C-like idioms.

A big part of re-integrating Zee will be finding the right place to put
shared interfaces so that the existing editors continue to work properly,
while at the same time giving Zee the interfaces it needs.  This is quite a
sizeable task in itself, because the process of making modules in Zile self-
contained and accessible  only through a defined interface has only just
begun... the majority of the files in Zile communicate with each other through
the global namespace :(

> As well as learning some Lua, you should also familiarise yourself with the 
> process of building Zile, starting with LuaRocks (www.luarocks.org) to 
> install the dependencies. Following the instructions provided would be a good 
> test of those instructions, too!

Agreed!

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

signature.asc
Description: Message signed with OpenPGP using GPGMail