On Monday 17 March 2008 04:52 pm, Bert Wesarg wrote: > > * modified_hook--modify it to report what has changed in the textBuf > should this be fired before or after the change happen? so, should it > report what will happen, or what happened?
Well the (my) need for it is so I can make the same change in the "other" textBuf that comes into play with the back end design I proposed for folding. Thus, I'm pretty sure I want it to report what did change. (things like, "new text" added at pos nnnn) > > * modified_rangeset_hook--should report the change(s) (additions, > > deletions, locations) > > * cursor_moved event--should report the change (i.e., the new location) > because this is fired after the actual movement, you get the new > position easily with the $cursor variable. so it maybe has more value > if the old position is given, or this is fired before the movement > happen Hmm, you're right, it might have more value for some purposes, but I think that for the purpose I'm talking about, knowing the new location after the change is adequate. And maybe, since the $cursor variable is available, I would only need to know that the event occurred. (Unless things got so slow that events piled up before getting processed.) > > * selection_change hook--should report the new selections > > * scroll_change hook--should report the new scroll position (is that the > > top line (or the first character) in the display?) > > you see, there are more questions you must think of for each hook, not > just a oneliner Sure, but: * the oneliner is a start * those other questions are easier to identify when somebody asks them rather than when I try to anticipate them ;-) Thanks for asking them! As far as the question about "top line (or first character) in the display" that was more intended to show my lack of knowledge about how scroll position is currently reported (or is it reported?) (another one of those "my lack of knowledge" questions). > > I suspect I'll think of more. > sure, there are plenty of things happen in a editor ;-) > > > > > On the other hand, if we (someone) writes the backend changes necessary for > > folding in C, then, presumably, these won't be required. > why? how about a fold_hide/fold_unhide event? thats maybe of value too. Well, absolutely, depending on what you mean. The one I'm thinking of is an event occuring, for example, when there is a mouse click on the boxed + or - in the fold mark gutter, and is the event that triggers folding or unfolding. I sort of had those kin of events in another category in my head--a potential (GSoC) project to create the fold mark gutter, the marks in it, and handle related events, but, if you can roll them into the Macro Hook/Event Binding project, that would be great. > *trommelwirbel* ;-) Ahh, thank goodness for babelfish--a drumroll. ;-) I'll refresh that page again before sending this. Darn! The list is there, we're not on it. :-( Randy Kramer -- NEdit Develop mailing list - [email protected] http://www.nedit.org/mailman/listinfo/develop
