Georg Baum wrote:
Abdelrazak Younes wrote:
Georg Baum wrote:
Yes, I mean argument and data_. Maybe nothing is stored for that
particular lfun in argument anymore, but others do still use argument.
You did not change getArg(), and you also forgot to adjust operator==.
I did not forgot anything. I created data_ as an evolutionary member. I
did not touch at all the other uses of argument. The LFUN_SELF_INSERT
insert doesn't use getArg() it uses data(). As for operator==, it was
not useful for this particular patch. I have been told one patch, one
change...
That is right, but do you fully understand where the lfun travels and are
you sure that operator== is never used for LFUN_SELF_INSERT?
Yes, I've been debugging the lfun step by step to ensure that I don't
miss something. The number of operation involved in a simple keypress is
awfully impressive!!!
I don't, and
even if I did I would change operator== too, because it prevents future
mistakes. IMO if you change the data structure then the operator== change
belongs logically to the same feature.
OK, you're right on that point but it didn't invalidate the patch.
Adhoc
changes like that are calling for bugs.
It appears that we are only two working on this so I don't think so.
But your patch seems to do the full monty...
This is IMO less work finally than introducing data_ and change lfun
semantics.
I am not sure. I think there is a need to distinguish between argument
and data. I even think that argument could stay ascii and should be
limited to functional arguments (ex: passing the name of a dialog to
open). The advantage of my approach is that one could audit every use of
argument() and change that to data() only if it make sense in this
particular context. With your change, every little string is ucs4 even
when that's not needed.
But you did the work so no need to change direction now.
Abdel.
