From: Jean-Marc Lasgouttes [lasgout...@lyx.org] Sent: Sunday, July 15, 2012 9:41 AM
Le 15/07/12 09:10, Scott Kostyshak a écrit : >>> I think theargument flag is not flexible enough to be useful. >> >> Why not? The attached patch checks whether the LFUN being called in >> GuiView.cpp has the Argument flag and is trying to use an empty >> argument. If so, the command is disabled (from getStatus). I think it >> is similar to checking NoBuffer. Why should checking for whether >> there's no argument be treated differently from checking whether >> there's no open buffer? Shouldn't both be done in getStatus and not >> by each individual LFUN? >> >> The patch adds the Argument property to a few LFUNs and removes some >> now unnecessary case-specific checks. These are just for examples >> though and the patch is not meant to be complete. >What I mean is that checking for "no argument" situation is only a small >part. We need at least to be able to say how many required and optional >arguments are needed. Moreover, some arguments just use the remainder of >the line. Also, to be useful, one needs to tell what the syntax is. >We could just be able to parse what we have in LyXAction.cpp, like: > space-insert <NAME> [<LEN>] >telling that there is on required argument and one optional one. >NoBuffer is different, since it only describes the context in which the >command can be used, which is much easier than its syntax. Ah, I see what you mean. Do you have an idea for the best way to parse LyXAction.cpp? Would any of the following strategies work well? (1) Parse LyXAction.cpp when building and store a map in lib and then load that map on runtime Is parsing LFUNs.lyx a bad idea? This would allow (2) Parse LFUNs.lyx during configure and store a map in lib (3) Parse LFUNs.lyx on run-time If this is a conversation best left for another time, let me know. Thanks, Scott
