0EB$ doesn't show buffer ring
Opened this issue · 10 comments
0EB$ doesn't show buffer ring
Instead, it is creating an unnamed buffer.
The buffer ring is shown when you type 0EB until you hit Escape. So to just query the buffer ring, you type 0EB and rub it out afterwards. The 0 additionally shows the buffer ring but otherwise does not alter the behaviour of EB, so you can show the buffer ring and immediately go on opening some other file.
All in all, I am not that happy with the current behaviour - inherited from Video TECO - but I am not sure how to do it better. Perhaps, there should simply be a special immediate editing command to autocomplete from the list of files in the buffer ring (if the string argument is still empty) instead of from the files in the current directory.
0EB lists as:
<absolut-path-1> <absoulte-path-2> <absolute-path-3>
I'd rather see:
1 <absolute-path-1>
2 <absolute-path-2>
3 <absolute-path-3>
Also, in the case of 0EB, I would make it require the trailing $.
The problem is that the EB command normally takes an argument (the file name). It doesn't normally react until the trailing $. It wouldn't be possible. For consistency sake, I think it would be better if 0EB required $.
Thanks!
I'd rather see:
1 2 3
That's a matter of taste. But it would definitely make sense to see the buffer id prepended to the path. I will add that to my TODO. Of course you can also select the absolute path by mouse and insert it back from the clipboard to open a particular file from the ring. So for instance, you type 0EB, see what file you want, select it, insert it (middle mouse button in Linux) and hit Escape.
For consistency sake, I think it would be better if 0EB required $.
That's definitely not going to happen since EB$ is already taken to open the unnamed buffer. It would be inconsistent to not do that when prepended with a 0 as long as it will open any file even in the presence of 0. But see above, it would probably be best to abolish 0EB altogether and allow to autocomplete from the buffer ring. Unfortunately, we cannot use Shift-Tab in Curses, so you would have to use something like Ctrl+G (enable immediate editing modifier), followed by Tab. Or some unrelated function key. Or some Ctrl+Letter combination would also be possible. This autocompletion would only make sense at the very beginning of filename parameters, so you don't loose much if you cannot easily insert some ASCII character smaller than 32 (and they could still be inserted using Caret+Letter combinations).
The reason I like them vertical rather than horizontal is becase they're easy to compare. If they're in different directories or if their spelling is slightly off, it's easty to see if they are displayed vertically. If they're displayed horizontally like they are now, it is very difficult to see their differences.
But ordinary file completion popups you would like to keep as they are?
I hadn't seen those yet.
Having file completion popups displayed horizontally is much less of an issue I would think becasue they're all in the same directory and (I presume) alphbetical.
IMO, having 0EB$ open an unnamed buffer makes sense and is consistent. However, I don't think having 0EB display the buffer list is good. EB is being inconsistently overloaded. I'd suggest using a differend command sequence to display the buffer list.
However, I don't think having
0EBdisplay the buffer list is good.
Agreed, especially since language-wise 0EB does nothing. A new command would also be a possibility. But often when you look at the buffer list, you actually want to open a file afterwards, so having it somehow integrated into EB does make some sense. Considering how SciTECO currently works, a special completion command like Ctrl+T or Ctrl+B or whatever would make most sense IMHO.
Agreed. How about this -
XX (XX=whatever) displays the buffer list. XXn$ switched to buffer number n?
This way you can display the buffer list and simply put in the buffer number and $ and you've got it! No need to back up!