guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [screen-devel] GSoC 2015 and GNU Screen


From: Artur Skonecki
Subject: Re: [screen-devel] GSoC 2015 and GNU Screen
Date: Sat, 27 Sep 2014 17:30:58 +0200

Hi Mike,
Guile platform is interesting. I need to check how much of the
currently existing code which formed the basis of Python and Lua
support is integrable with Guile.
Extending Screen further with scripting support may seem like a waste
of time. After all, Screen commands are reachable from scripts. I
think that scripting language support would be mostly useful for the
rare breed of users who 'live' in Screen. Or lazy C developers :P.
During the development of screen-session I was missing the scripting
language support.
Keeping GNU Screen lean has a lot of advantages. Stability is very
important for the majority of users.
But it would nice to get some new major features. Screen is old.. 27
years is heck a lot of time. What about the next 27 years? ;)
I will be defending my master thesis in autumn 2015. Probably the last
call for me to apply for GSoC.
I am keen to learn Amadeusz opinion.

Cheers,
Artur

On 21 September 2014 16:28, Mike Gerwitz <address@hidden> wrote:
> On Sun, Sep 21, 2014 at 01:49:38PM +0200, Artur Skonecki wrote:
>> I always fanced scripting for GNU Screen. In GSoC 2009 there was work done
>> on scripting for GNU Screen which included Python and Lua. However it
>> didn't got upstream.
>> https://www.google-melange.com/gsoc/project/details/google/gsoc2009/firemeteor/5668600916475904
>> http://git.savannah.gnu.org/cgit/screen.git/log/?h=scripting
>>
>> Improving GNU Screen scripting was later mentioned as an GSoC idea at GNU:
>> http://www.gnu.org/software/soc-projects/ideas-2010.html
>>
>> Improving GNU Screen scripting is the problem I would preferably work on. I
>> would like to make more capabilities available through scripting and
>> stabilize it so it could be merged upstream.
>> I am also open to other ideas.
>
> I would like to see Guile integrated with screen. Not only is it GNU's
> extension language platform,[0] but work is underway for providing Lua
> support[1], which seems to be desired here. (Current language support
> includes Scheme, Elisp, Brainfuck, and ECMAScript). Guile is language
> agnostic;[2] I've seen discussions expressing interest for languages
> like Python in the past as well.
>
> The problem with introducing specific engines to handle Lua, Python, or
> any other language is that we have separately maintained systems that
> likely would require both separate bindings and runtimes for screen.
> When I talked with Amadeusz last last year / early this year, he decided
> to purge scripting support because it was (largely) unused and he was
> the only personal actively working on any large-scale maintenance of
> screen---so even if those languages were integrated, they still run the
> risk of being dropped in the future. If development is picking up again,
> then maybe it's a discussion that can be had again.
>
> For example, I had begun rewriting the winmsg parser for
> caption/hardstatus lines in C,[3] but I would much prefer to see
> something like that implemented in Guile Scheme.[4]
>
> [0]: 
> http://www.gnu.org/software/guile/manual/html_node/Guile-and-the-GNU-Project.html
>
> [1]: That said, the `lua' branch seems to have stalled for ~1yr, so
>      perhaps you or others may be interested in killing two birds with
>      one stone (forgive the morbid idiom) by improving Guile's Lua
>      support, thereby introducing Lua to any software using Guile.
>
> [2]: 
> http://www.gnu.org/software/guile/manual/html_node/Supporting-Multiple-Languages.html
>
> [3]: Can be found on Amadeusz' pre-maintainership dev repository
>      here: https://github.com/amade/screen/commits/winmsg
>
> [4]: 
> http://www.gnu.org/software/guile/manual/html_node/Interactive-Programming.html
>
> --
> Mike Gerwitz
> Free Software Hacker | GNU Maintainer
> http://mikegerwitz.com
> FSF Member #5804 | GPG Key ID: 0x8EE30EAB



reply via email to

[Prev in Thread] Current Thread [Next in Thread]