On Fri, Jul 14, 2006 at 05:30:03PM -0500, fvwm-workers wrote: > CVSROOT: /home/cvs/fvwm > Module name: fvwm > Changes by: griph 06/07/14 17:30:03 > > Modified files: > . : ChangeLog NEWS > fvwm : expand.c fvwm.1.in > libs : Strings.c Strings.h > > Log message: > * add variable filters > * make backslash escape character within $[...] expressions
If you write such patches that are monitored by several developers
it would be nice to explain what you are doing and how. We have
to be very careful with big changes in the parsing code because it
has the potential to break everything. Personally I want to
proofread such changes.
The syntax I quoted that Mikhael suggested has not really been
thought about a lot. It's just an ad-hoc idea. Now that you
implemented it, I think it has several general issues:
* There is currently no way to quote a literal string, which is a
very important feature. It would allow users to write monsters
like this more easily:
+ I PipeRead 'cd $HOME/.fvwm/palettes; /bin/ls *.pal | sed -e
\"s:\\(.*\\)\\(\\.pal\\):+ \\\\&\\1 Function SetPalette \\1\\2:\"'
* The syntax is too verbose. The strings you have to write eat
up too much space. Also, the name "filters" is misleading.
I suggest to follow zsh's example:
$[(flags)name]
Where "name" is the parameter name itself and "flags" describes
the modifications to apply to the expansion process.
Flags:
q<style>[<n>] (quote)
Quote the string <n> times using the given <style>.
<style> can be one of
q quote normally for use as a token
mi quote for use as a menu item label
mt quote for use as a menu title
l (literal)
Quote a literal string, i.e. everything up to the closing
brace.
r0 (recursive expansion off, default)
r1 (recursive expansion on)
Enable or disable recursive expansion ($[$[X]])
Note: If the flags l and r1 are present, recursive
expansion takes place first, and the result is used as
literal input for further processing - it is *not*
interpreted as a variable name.
s[<n>] (split)
Split string into individual tokens (by removing <n> levels
of quotes and whitespace). <n> defaults to 1.
t (tokenize)
Treat the resulting string as a single token (Useful in
ranges).
Examples:
With X="foo `bar`", $0="0", $1="1", ... (without the
quotes):
$[(qq)X]
--> 'foo `bar`'
$[(s1qq)X]
--> 'foo' 'bar'
$[(lqq2)foo `bar`]
--> "'foo `bar`'"
$[(lr1)X]
--> foo `bar`
$[(qq)1-3]
--> '1' '2' '3'
$[(tqq)1-3]
--> '1 2 3'
Maybe flags should be separated by colons to allow more and
longer flag names like $[(literal:qq)foo bar]
Thinks that are not good in the current patch:
* I think we shouldn't have different styles of quoting filters.
Just quote: should be enough. This is because quoting is just
meant to be used *internally by fvwm*. And fvwm does not care
wether tokens are quoted by ", ', ` or \. Fvwm could just
choose the type of quotes that has the shortest result.
A string quoted this way can *not* be passed to a shell for
example.
* It should be possible to add multiple levels of quotes in a
single filter (usefull in above example).
* The menu: filter should be split into two. In menu titles, the
characters ^, @, % and * have to be quoted (by doubling them).
In menu item labels, %, & and * have to be quoted. In either
case, the TAB character has to be quoted too.
* The glob: filter seems to promise something it can not live up
to. It can *not* be used for shell command quoting. Other
than that I see no purpose in that specific filter. It should
be removed.
* The noquote: filter should be removed.
* In constructs like $[$[X]], if X is "quote:foo", the result
should be the contents of the variable "quote:foo", not the
quoted result of the variable "foo". (I did not check how the
code qorks now).
Please take this as a base for discussion, *not* as instructions
to change the code now!
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
