Am Donnerstag, 4. Januar 2007 12:21 schrieb Abdelrazak Younes: > OK, I understand now but this looked weird (and still does). Maybe we > should think of adding an int argument() to the LFUN for internal > purpose. Wasn't that the purpose of the "any" branch that Lars was > talking about?
In this case that would not help. We don't keep "paste 0" for internal purposes only, this should also be callable by the user. What is wrong then to use "paste 0" also for internal purposes if it just does the right thing? > IIRC an empty argument means "paste most recent clipboard (internal or > external)", doesn't it? If yes, I agree that it should stay empty. Yes, it does mean that. > Here is what I think we should like to have: > > if argument is > 1) empty: "paste most recent clipboard (internal or external)" Yes. > 2) "n": paste n-th element from the theCuts clipboard stack (n == 0 is > the most recent element). Yes. > 3) "external clipboard line": paste external clipboard as lines That is a different lfun "clipboard-paste", not "paste". I don't see a need to change this. > 4) "external clipboard paragraph": paste external clipboard as paragraph. ditto: "clipboard-paste paragraph" > 5) "selection": paste selection (the internal/external detection should > be automatic here). We don't have an lfun for this, and should not. This should only be triggered by the middle mouse button. > 6) "selection line": paste selection as lines (the source will be > theSelection() independently from the internal or external state.) Again this is a different lfun: "primary-selection-paste". Again I don't see a need to change this. > 7) "selection paragraph": paste selection as paragraph (the source will > be theSelection() independently from the internal or external state.) ditto: "primary-selection-paste paragraph" > In the most common case (theClipboard().isInternal()), I reckon it won't > be very expensive. Yes. I don't want to investigate that further, I'll leave that for others to decide. Georg
