[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Scripting support (PATCH)
From: |
Marco Gerards |
Subject: |
Re: Scripting support (PATCH) |
Date: |
Sun, 30 Oct 2005 17:05:01 +0100 |
User-agent: |
Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) |
Vladimir Serbinenko <address@hidden> writes:
> But the next questions are menu entries. I propose the following syntax:
> menu [arguments] name
> {
> Commands
> }
>
> arguments can be --default, --fallback perhaps some more in the future.
>
> But the main question is about realization. We need to store the
> source code to be able to edit it. Marco and me propose the following
> solution:
> lexer keeps the buffer of current parsed script/block and it stores
> begin and end of tokens in this buffer in yylloc's new fields: buf_beg
> and buf_end. Then when parser founds a menu entry it copies a part of
> buffer using position of command. E.g (schematically):
>
> "menu" string '{' commands '}'
I would even propose something like:
menuargs: /* Empty */
menuargs ARG
...
;
menuentry: "menu" menuargs '{' commands '}'
;
Or something like that. Arg is something the scanner can recognize or
so. I am not sure how that should work :)
> {
> char was = address@hidden;
> address@hidden = 0;
> create_menu_command ($2, grub_strdup (&address@hidden));
> }
I didn't know that bison had such buffer. I think it is cleaner to
use grub_strndup so you don't have to modify the buffer. You also
have to pass the result of `commands' ($4 in your example) to
create_menu_command.
> And menu is always stored unparsed and parsed only just before
> execution. Than editing is no problem.
I think you have to parse it immediately and both store parsed and the
unparsed code. After editing you do the same again.
> Other solution proposed by Marco was to rerun the script file or part
> of it.
This solution is required if you want to be able to edit the complete
script instead of just the separate menu entries. I think this is not
interesting, but if someone wants to know I can say more about this.
Thanks,
Marco
Re: Scripting support (PATCH), Yoshinori K. Okuji, 2005/10/31
Re: Scripting support (PATCH), Hollis Blanchard, 2005/10/30