Leo <[email protected]> writes: [snip]
> Anyway, the current way of implementation is not optimal. For example, > when you are at the top of the log buffer, then hit 'l' (or whatever > key), you have no cue of what happened. In fact I have the cut off > length increased to 1600 without knowing it. You will notice that Emacs freezes for a while :-) Showing a message on the modeline or the minibuffer saying something like "refreshing log with XXXX entries..." will be nice, though. >>> Emacs 23.2 actually got it right, they put two buttons at >>> the end of the log buffer so occasionally you can click on them if you >>> want to get more entries. >> >> I tend to avoid clicking on things. Keyboard shortcuts are much more >> convenient, IMO. > > 'click' was not the right word. I mean move the cursor to the button and > hit RETURN. In most cases, it is a combination of TAB + RETURN. I don't > see much of disadvantage here. Usually when you want to see more entries > is when you move towards to the end of log buffer. At first I liked the buttons on the VC log and actually tried to implement them on magit, but failed due to keymap issues. Now I think that using buttons is a bad idea. Suppose that the log is showing the last 100 entries of a large branch and you want to see some entry that you think is within the last 1000 revisions or so. With the buttons, you have to press TAB RETURN and wait for the refresh four times for showing at least 1000 revisions. This sucks. > Here is an example of how slime implements its function browser > (inspector); vc does something similar. I don't think that a function browser is a valid UI model for a log display. [snip]
