Re: [dev] Experimental editor
On 6/25/11, Connor Lane Smith wrote: > Progress update. You can edit things, but we don't have the B-tree in > place yet, so I'm mostly working on the peripherals. I'll set up a > repo very soon, though aside from my UTF-8 and display abstraction > library I have little to show, yet. > > Here's a little screenshot of the aesthetic I'm going for. There's not > much to see -- that's a feature. > > cls I'm interested to see what you come up with, and hope there's something that I can test soon. Will there be some sort of command buffer like in Sam? Or did you have something else in mind? John
Re: [dev] Experimental editor
Progress update. You can edit things, but we don't have the B-tree in place yet, so I'm mostly working on the peripherals. I'll set up a repo very soon, though aside from my UTF-8 and display abstraction library I have little to show, yet. Here's a little screenshot of the aesthetic I'm going for. There's not much to see -- that's a feature. cls <>
Re: [dev] Experimental editor
On 18 June 2011 09:34, garbeam wrote: > The closest thing that came to my mind is this idea of seeing swk as a > curses replacement. With this, the clients that are written with it, > could also run perfectly fine in text mode, but if you have a > graphical environment at hand, the implementation could pack the UI > more efficiently into graphical use. The way my abstraction library is working at the moment, we can basically draw rectangles or text. The interface for this editor (I need to come up with a name...) will more-or-less be a lot of text with a scrollbar on the right. I don't see any need for much else. If you were to write a curses back-end I suppose you could snap to the nearest cell; but I'm leaving that as an exercise to that poor soul. On 18 June 2011 09:21, pancake wrote: > The plan for swk was to move all drawing stuff to draw.c at some point. I > will be happy to hear from what you are writing for. As we're trying to abstract the interface completely, and not just provide useful X utility functions, I'm not using draw.c, since its and libdpy's (as I'm calling it right now) interfaces don't quite map one-to-one. > I stopped writing it because i didnt wanted to reimplement a text editor > stuff.. That's the problem with widgets: you need to basically write a text editor. Just using drawing routines, on the other hand, means we can just implement a few functions and then write the text editor as an actual text editor. > Another thing is that its redrawing everything all the time. There's no use > of damaged areas or so. I'll be solving this with a poor man's approach, which should basically mean that everything is redrawn only when the window is resized, and otherwise the editor can redraw only what has changed or been damaged. There are even more sophisticated approaches than this, but I don't think we need to care. Thanks, cls
Re: [dev] Experimental editor
Swk is based on a monospaced drawing area.. You just have a simple layout foo plus the possibility to draw on sub buffers. Which limiations do you see in swk? I dont want a mainframe like ui. It will not be usable in touchscreen interfaces for example. One thing i mss in swk is the possibility to handle global keybindings.. So you can use the interface without having to move between the widgets. This can be done like in config.h at every application that uses swk. We just need to register that array. Those events should be handled after the widget event handling callback (text edit..) On 18/06/2011, at 11:01, garbeam wrote: > On 18 June 2011 09:44, Robert Ransom wrote: >> On Sat, 18 Jun 2011 09:34:42 +0100 >> garbeam wrote: >> >>> On 18 June 2011 09:21, pancake wrote: The plan for swk was to move all drawing stuff to draw.c at some point. I will be happy to hear from what you are writing for. I stopped writing it because i didnt wanted to reimplement a text editor stuff.. But i think that conceptually swk can fit well in different emvironments like desktops or phones.. But it really need a rebump to emhace layouts. Another thing is that its redrawing everything all the time. There's no use of damaged areas or so. I was waiting for anselm here. I would like to hear from your project. It looks interesting and it can be a swk2.. >>> >>> Well, my swk conclusion is, that its interface as of now is some yet >>> another GUI TK interface with limitations, but not really what I have >>> concluded it should be. >>> >>> I believe the most important aspect of a potential revised swk is, >>> that it should only be totally text based -- this limitation should be >>> good enough. Starting dealing with bitmaps etc. makes its purpose >>> blurry and might leat to the yet another GUI TK interface idea once >>> again. >>> >>> The closest thing that came to my mind is this idea of seeing swk as a >>> curses replacement. With this, the clients that are written with it, >>> could also run perfectly fine in text mode, but if you have a >>> graphical environment at hand, the implementation could pack the UI >>> more efficiently into graphical use. >>> >>> I really think, the inner workings of such a library should be cursor >>> based, in that regard it is a question of abstracting the cursor >>> movements into a drawing interface and to define higher level stuff >>> using this approach. So the basic thing is a monospaced matrix. This >>> could also be used for a terminal and of course editor... >> >> That library already exists -- it's called ‘pdcurses’. We don't need >> more curses. > > I did not intend to say it should be curses compliant as this would be > a nightmare. I was rather referring to the concept of being cursor and > matrix based in the core as this will make a very simple interface, > that can work across a range of devices. > > --garbeam >
Re: [dev] Experimental editor
On 18 June 2011 09:44, Robert Ransom wrote: > On Sat, 18 Jun 2011 09:34:42 +0100 > garbeam wrote: > >> On 18 June 2011 09:21, pancake wrote: >> > The plan for swk was to move all drawing stuff to draw.c at some point. I >> > will be happy to hear from what you are writing for. >> > I stopped writing it because i didnt wanted to reimplement a text editor >> > stuff.. >> > But i think that conceptually swk can fit well in different emvironments >> > like desktops or phones.. But it really need a rebump to emhace layouts. >> > Another thing is that its redrawing everything all the time. There's no use >> > of damaged areas or so. I was waiting for anselm here. >> > I would like to hear from your project. It looks interesting and it can be >> > a >> > swk2.. >> >> Well, my swk conclusion is, that its interface as of now is some yet >> another GUI TK interface with limitations, but not really what I have >> concluded it should be. >> >> I believe the most important aspect of a potential revised swk is, >> that it should only be totally text based -- this limitation should be >> good enough. Starting dealing with bitmaps etc. makes its purpose >> blurry and might leat to the yet another GUI TK interface idea once >> again. >> >> The closest thing that came to my mind is this idea of seeing swk as a >> curses replacement. With this, the clients that are written with it, >> could also run perfectly fine in text mode, but if you have a >> graphical environment at hand, the implementation could pack the UI >> more efficiently into graphical use. >> >> I really think, the inner workings of such a library should be cursor >> based, in that regard it is a question of abstracting the cursor >> movements into a drawing interface and to define higher level stuff >> using this approach. So the basic thing is a monospaced matrix. This >> could also be used for a terminal and of course editor... > > That library already exists -- it's called ‘pdcurses’. We don't need > more curses. I did not intend to say it should be curses compliant as this would be a nightmare. I was rather referring to the concept of being cursor and matrix based in the core as this will make a very simple interface, that can work across a range of devices. --garbeam
Re: [dev] Experimental editor
On Sat, 18 Jun 2011 09:34:42 +0100 garbeam wrote: > On 18 June 2011 09:21, pancake wrote: > > The plan for swk was to move all drawing stuff to draw.c at some point. I > > will be happy to hear from what you are writing for. > > I stopped writing it because i didnt wanted to reimplement a text editor > > stuff.. > > But i think that conceptually swk can fit well in different emvironments > > like desktops or phones.. But it really need a rebump to emhace layouts. > > Another thing is that its redrawing everything all the time. There's no use > > of damaged areas or so. I was waiting for anselm here. > > I would like to hear from your project. It looks interesting and it can be a > > swk2.. > > Well, my swk conclusion is, that its interface as of now is some yet > another GUI TK interface with limitations, but not really what I have > concluded it should be. > > I believe the most important aspect of a potential revised swk is, > that it should only be totally text based -- this limitation should be > good enough. Starting dealing with bitmaps etc. makes its purpose > blurry and might leat to the yet another GUI TK interface idea once > again. > > The closest thing that came to my mind is this idea of seeing swk as a > curses replacement. With this, the clients that are written with it, > could also run perfectly fine in text mode, but if you have a > graphical environment at hand, the implementation could pack the UI > more efficiently into graphical use. > > I really think, the inner workings of such a library should be cursor > based, in that regard it is a question of abstracting the cursor > movements into a drawing interface and to define higher level stuff > using this approach. So the basic thing is a monospaced matrix. This > could also be used for a terminal and of course editor... That library already exists -- it's called ‘pdcurses’. We don't need more curses. Robert Ransom
Re: [dev] Experimental editor
Hi pancake, On 18 June 2011 09:21, pancake wrote: > The plan for swk was to move all drawing stuff to draw.c at some point. I > will be happy to hear from what you are writing for. > I stopped writing it because i didnt wanted to reimplement a text editor > stuff.. > But i think that conceptually swk can fit well in different emvironments > like desktops or phones.. But it really need a rebump to emhace layouts. > Another thing is that its redrawing everything all the time. There's no use > of damaged areas or so. I was waiting for anselm here. > I would like to hear from your project. It looks interesting and it can be a > swk2.. Well, my swk conclusion is, that its interface as of now is some yet another GUI TK interface with limitations, but not really what I have concluded it should be. I believe the most important aspect of a potential revised swk is, that it should only be totally text based -- this limitation should be good enough. Starting dealing with bitmaps etc. makes its purpose blurry and might leat to the yet another GUI TK interface idea once again. The closest thing that came to my mind is this idea of seeing swk as a curses replacement. With this, the clients that are written with it, could also run perfectly fine in text mode, but if you have a graphical environment at hand, the implementation could pack the UI more efficiently into graphical use. I really think, the inner workings of such a library should be cursor based, in that regard it is a question of abstracting the cursor movements into a drawing interface and to define higher level stuff using this approach. So the basic thing is a monospaced matrix. This could also be used for a terminal and of course editor... Cheers, --garbeam
Re: [dev] Experimental editor
The plan for swk was to move all drawing stuff to draw.c at some point. I will be happy to hear from what you are writing for. I stopped writing it because i didnt wanted to reimplement a text editor stuff.. But i think that conceptually swk can fit well in different emvironments like desktops or phones.. But it really need a rebump to emhace layouts. Another thing is that its redrawing everything all the time. There's no use of damaged areas or so. I was waiting for anselm here. I would like to hear from your project. It looks interesting and it can be a swk2.. On 17/06/2011, at 16:16, Connor Lane Smith wrote: > > I'm writing a simple UI abstraction library, sort of like swk meets > draw.c, in that it's completely platform-agnostic (so we can port it > to other things than Xlib), but doesn't use widgets, you just draw > things. This has the benefit of encapsulating all the complicated > stuff you need to with Xlib into a single place, which means the > editor proper can remain nice and clean. This, as well as the UTF-8 > library, might be useful in other projects as well. I'll try to keep > them independent. >
Re: [dev] Experimental editor
[2011-06-17 16:24] Martin Kühl > > Consider ex > mode. How do you edit text in it? You don't have normal mode to help > you, it only operates on "real" buffers, and you certainly don't have > ex mode available. If "ex mode" were just a command buffer, you could > use every piece of functionality your editor provided, maybe even open > another command buffer operating on the current one. > Or simply, as Connor put it, "all we're doing is editing text." Thanks for the explanation. Now I understand this point, and I agree here. meillo
Re: [dev] Experimental editor
Quoth Rob: > On Fri, Jun 17, 2011 at 07:15:22AM -0800, Andrew Hills wrote: > > On Fri, Jun 17, 2011 at 6:29 AM, Nick wrote: > > > But if we're thinking about > > > breaking from the terminal, how would remote editing work? > > > Some sort of ssh piping from / to the file on the server? > > > I haven't thought this through, but it's certainly a usecase > > > which would be nice to cover. > > scp > > sshfs? That probably would fit nicely, actually. I haven't used it before, so hadn't considered it - thanks for reminding me, I'll give it a whirl soon. pgp8AvFgxGVf3.pgp Description: PGP signature
Re: [dev] Experimental editor
On 17 June 2011 15:24, Martin Kühl wrote: > If "ex mode" were just a command buffer, you could > use every piece of functionality your editor provided, maybe even open > another command buffer operating on the current one. I'd not even considered this possibility, but you're right, it would work as a direct result of the command buffer abstraction. You could even open a dozen windows, SSH into different machines, and interactively run the same commands on each of them (I think there's a program which does this), without my having even considered it. All you need is `X a'. On 17 June 2011 15:29, Nick wrote: > tying things to X is a nasty thing to do. I haven't used it, > so don't know it's level of suckiness, but might cairo work? I don't believe Cairo abstracts anything other than drawing (i.e. keyboard and mouse), so it would have to be Cairo + something. > But if we're thinking about > breaking from the terminal, how would remote editing work? A minimalist remote editing protocol is a todo. It'll basically be like the sam host, except all editing actually happens locally, only modifications to the buffer are transmitted, so you don't have any visible lag besides the initial read. It'll also be simpler, and the editor won't be dependent on it; so think closer to 9P (only with efficient in-file insert and so on). That's once we've got the basics down, though. On 17 June 2011 17:54, Michael Farnbach wrote: > I don't know that X or tmux have anything more than mark and copy to > clipboard. The rest is handled by the program in them. This is true. > Also the modeless second window isn't a bad idea, but I wonder if it is > modeless or not. The modality of windows is debatable. But since we have X I don't consider it our problem, so long as we don't *add* to the problem. Thanks, cls
Re: [dev] Experimental editor
Just a few points from random things in this thread... Someone said they want cut and paste to be put to tmux, X, etc... I don't know that X or tmux have anything more than mark and copy to clipboard. The rest is handled by the program in them. Also the modeless second window isn't a bad idea, but I wonder if it is modeless or not. A nice feature for such a window would be a key command to go back and forth from it. While a more easy way to distinguish which mode you are in, it is no different then what VI does. In fact, VI even gives you the new window to type the command. On Fri, Jun 17, 2011 at 9:50 AM, Andrew Hills wrote: > On Fri, Jun 17, 2011 at 7:39 AM, Rob wrote: > > sshfs? > > That's what I use, personally, but some people hate it, and it's not > always available. I prefer to see the network latency when I'm > actually reading or writing the file rather than seeing my editor > freeze, though, so I always use sshfs or scp. > > --Andrew Hills > >
Re: [dev] Experimental editor
On Fri, Jun 17, 2011 at 7:39 AM, Rob wrote: > sshfs? That's what I use, personally, but some people hate it, and it's not always available. I prefer to see the network latency when I'm actually reading or writing the file rather than seeing my editor freeze, though, so I always use sshfs or scp. --Andrew Hills
Re: [dev] Experimental editor
On Fri, Jun 17, 2011 at 07:15:22AM -0800, Andrew Hills wrote: > On Fri, Jun 17, 2011 at 6:29 AM, Nick wrote: > > But if we're thinking about > > breaking from the terminal, how would remote editing work? > > Some sort of ssh piping from / to the file on the server? > > I haven't thought this through, but it's certainly a usecase > > which would be nice to cover. > scp sshfs?
Re: [dev] Experimental editor
On Fri, Jun 17, 2011 at 07:15:22AM -0800, Andrew Hills wrote: > On Fri, Jun 17, 2011 at 6:29 AM, Nick wrote: > > But if we're thinking about > > breaking from the terminal, how would remote editing work? > > Some sort of ssh piping from / to the file on the server? > > I haven't thought this through, but it's certainly a usecase > > which would be nice to cover. > > scp sure. so when i try changing a variable in a config file, your suggested usage is scp myserver:/etc/myconfig /tmp/ \ && $EDITOR /tmp/myconfig \ && scp /tmp/myconfig myserver: \ && ssh myserver sudo mv myconfig /etc/ (ignoring the fact that i'd need sudo to not prompt for a password) I'll stick with sudo vim /etc/myconfig, in that case. And no, wrapping the above in a script is not sensible.
Re: [dev] Experimental editor
On Fri, Jun 17, 2011 at 6:29 AM, Nick wrote: > But if we're thinking about > breaking from the terminal, how would remote editing work? > Some sort of ssh piping from / to the file on the server? > I haven't thought this through, but it's certainly a usecase > which would be nice to cover. scp --Andrew Hills
Re: [dev] Experimental editor
On Fri, Jun 17, 2011 at 10:49:12AM -0400, Kurt H Maier wrote: > On Fri, Jun 17, 2011 at 10:29 AM, Nick wrote: > > I haven't used it, > > so don't know it's level of suckiness, but might cairo work? > > > No. Guessed that would be the case, just throwing it out there ;) Connor's stuff tends to be good, anyway. I trust he'll do right.
Re: [dev] Experimental editor
On Fri, Jun 17, 2011 at 10:49:12AM -0400, Kurt H Maier wrote: > On Fri, Jun 17, 2011 at 10:29 AM, Nick wrote: > > I haven't used it, > > so don't know it's level of suckiness, but might cairo work? > > > No. maybe check out animator: http://repo.hu/projects/animator/ disclaimers: - i'm the author - i advertised it in this ml before - it's not suckless, that wasn't even the intention - but maybe the approach can be interesting... (also we used it for many things and it seems to be great for hacking together UIs and visualizations) regards, Mate
Re: [dev] Experimental editor
On Fri, Jun 17, 2011 at 10:29 AM, Nick wrote: > I haven't used it, > so don't know it's level of suckiness, but might cairo work? No. -- # Kurt H Maier
Re: [dev] Experimental editor
On Fri, Jun 17, 2011 at 03:16:00PM +0100, Connor Lane Smith wrote: > I'm writing a simple UI abstraction library, sort of like swk meets > draw.c, in that it's completely platform-agnostic (so we can port it > to other things than Xlib), but doesn't use widgets, you just draw > things. This has the benefit of encapsulating all the complicated > stuff you need to with Xlib into a single place, which means the > editor proper can remain nice and clean. This, as well as the UTF-8 > library, might be useful in other projects as well. I'll try to keep > them independent. I'm very interested and curious to see what direction this editor takes. Glad you're writing a generic UI abstraction; tying things to X is a nasty thing to do. I haven't used it, so don't know it's level of suckiness, but might cairo work? However, I spend quite a lot of time in editors logged in to remote servers. I don't want X on them. So, how should an editor handle these things. Obviously SSH is great for the terminal, and I love vim in it. But if we're thinking about breaking from the terminal, how would remote editing work? Some sort of ssh piping from / to the file on the server? I haven't thought this through, but it's certainly a usecase which would be nice to cover. Nick
Re: [dev] Experimental editor
On Fri, Jun 17, 2011 at 11:07, markus schnalke wrote: > [2011-06-15 14:47] Connor Lane Smith >> On 15 June 2011 12:26, markus schnalke wrote: > In vi, you enter insert mode, which you consider a real mode, with `i' > and leave it with Escape. Likewise you enter ex mode (i.e. last-line > mode), which you consider a quasimode, with `:' and leave it with > Enter. It surely isn't a mode you stay long in, but there is no reason > why it shouldn't be seen as a real mode. You understand my point of > view? In fact, he shares it. You just think that he thinks that ex mode is a quasimode, which it isn't, and which he doesn't. >> This. I want keys to always mean the same thing. > > I'd say that the meaning of `f' isn't the same as the meaning of `f' > if you hold Ctrl at the same time. Where's the difference if you alter > the meaning of a key with a modifier key or with a mode? Okay, the > former modification drops as soon as you release the key. That's the difference that matters. You can never *not* know whether you are in a quasimode or not. Also, composition, or complexity of the underlying model. Consider ex mode. How do you edit text in it? You don't have normal mode to help you, it only operates on "real" buffers, and you certainly don't have ex mode available. If "ex mode" were just a command buffer, you could use every piece of functionality your editor provided, maybe even open another command buffer operating on the current one. Or simply, as Connor put it, "all we're doing is editing text." >> Too often they don't, >> and you end up not knowing what on Earth is happening. With this >> approach, all you need to keep in mind is where your cursor is. > > Maybe you haven't used vi as it was meant to be used: You're always in > normal mode (hence the name). Switching to other modes is only a > temporary thing. > > If you wanna know where you are: Hit Escape! So you got used to the workaround and don't require a solution to the underlying problem. Great, more power to you! That doesn't mean anyone else should, or should have to. That's what quasimodes provide: You don't have to get used to exiting them, because you can't forget to let go of the trigger. Martin
Re: [dev] Experimental editor
On 17 June 2011 10:07, markus schnalke wrote: > I disagree with this analogy. Shift is no quasimode. Yes it is. > Likewise you enter ex mode (i.e. last-line > mode), which you consider a quasimode No, you misunderstand completely: I don't consider ex mode `quasi'. What I said was that in my editor `command mode' is activated simply by switching to a different window, and typing into that, in exactly the same way as you were typing into the original window, except this is a *different* window. Understand? > If you wanna know where you are: Hit Escape! I use vi all the time, and it is useful, but I want to make something better. Telling me to constantly hit escape is not a good way to convince me that I shouldn't. So you like vi? That's lovely. I really hope this doesn't deteriorate into an argument about everyone's favourite editor, that would be terribly boring. Aside from the trolls, I'm writing a simple UI abstraction library, sort of like swk meets draw.c, in that it's completely platform-agnostic (so we can port it to other things than Xlib), but doesn't use widgets, you just draw things. This has the benefit of encapsulating all the complicated stuff you need to with Xlib into a single place, which means the editor proper can remain nice and clean. This, as well as the UTF-8 library, might be useful in other projects as well. I'll try to keep them independent. On 15 June 2011 14:01, David Tweed wrote: > I've got a long comment queued up (restricted internet situation at > work) I'm looking forward to this. Still. ;) cls
Re: [dev] Experimental editor
[2011-06-17 09:54] David Tweed
> On Fri, Jun 17, 2011 at 9:51 AM, David Tweed wrote:
> > On Fri, Jun 17, 2011 at 9:46 AM, Nicolai Waniek wrote:
> >> On 06/17/2011 10:37 AM, markus schnalke wrote:
> >>> For the same reason we want Unix's manifold toolchain and for the same
> >>> reason we want several programming languages: Because ``One fits all''
> >>> is an illusion.
> >>
> >>
> >> Then try to figure out some basic tools that you can glue together to
> >> form a fully functional editor.
> >>
> >> 'Reinventing' an editor for every purpose and most probably copying some
> >> things on source level from one editor to the next is ridiculous.
Isn't vi a good example for how not to reinvent everything? It wraps
around ex. (Some say ``Vi is actually one mode of editing within the
editor ex.'')
But actually, I think you misunderstood my words. I don't think one
should do the *same* again and again but rather put small specialized
parts together. If you used ed or ex you quickly notice that they are
great for editing on line basis but you'll suffer when editing within
a line. You likely tend to rewrite the whole line anew instead of
editing it. Vi (i.e. the normal mode) improves here. On line basis you
might still want to use ex ... although many don't.
> > Even more annoying is that the way that the lack of an OS-level editor
> > component means that there's a tendency for any application that wants
> > to provide a writing/editing capability to write their own, often
> > poor, editing code.
You point to a different problem: Application programmers don't honor
common practice in Unix.
> To clarify, I by "OS-level component" I mean at the "this is THE
> component applications use when the want editing", but which would be
> changeable by the user.
Actually there is such thing: ${VISUAL-${EDITOR-vi}}
> > I entirely agree with that "one interface fits all
> > users" is a problem, but I'd like a system where there was "one
> > interface for editing in all circumstances for this user".
>From application's view: See above.
Else: Ed is the standard text editor!
meillo
Re: [dev] Experimental editor
[2011-06-15 14:47] Connor Lane Smith > On 15 June 2011 12:26, markus schnalke wrote: >> What's the difference between a mode and a ``quasimode''? > > What's the difference between shift and caps lock? I disagree with this analogy. Shift is no quasimode. In vi, you enter insert mode, which you consider a real mode, with `i' and leave it with Escape. Likewise you enter ex mode (i.e. last-line mode), which you consider a quasimode, with `:' and leave it with Enter. It surely isn't a mode you stay long in, but there is no reason why it shouldn't be seen as a real mode. You understand my point of view? > I want there to be just a collection of buffers, and typing > into command buffer is what gives you `command mode', sam style. We > always use the same keys, because all we're doing is editing text, so > it becomes muscle memory. Now draw the analogy between selecting one or the other buffer with with mouse to hitting some mode switching key. For me that's the same. You do want modes ... you simply don't want to call them ``modes''. :-) > This. I want keys to always mean the same thing. I'd say that the meaning of `f' isn't the same as the meaning of `f' if you hold Ctrl at the same time. Where's the difference if you alter the meaning of a key with a modifier key or with a mode? Okay, the former modification drops as soon as you release the key. > Too often they don't, > and you end up not knowing what on Earth is happening. With this > approach, all you need to keep in mind is where your cursor is. Maybe you haven't used vi as it was meant to be used: You're always in normal mode (hence the name). Switching to other modes is only a temporary thing. If you wanna know where you are: Hit Escape! meillo
Re: [dev] Experimental editor
On Fri, Jun 17, 2011 at 9:51 AM, David Tweed wrote: > On Fri, Jun 17, 2011 at 9:46 AM, Nicolai Waniek wrote: >> On 06/17/2011 10:37 AM, markus schnalke wrote: >>> For the same reason we want Unix's manifold toolchain and for the same >>> reason we want several programming languages: Because ``One fits all'' >>> is an illusion. >> >> >> Then try to figure out some basic tools that you can glue together to >> form a fully functional editor. >> >> 'Reinventing' an editor for every purpose and most probably copying some >> things on source level from one editor to the next is ridiculous. > > Even more annoying is that the way that the lack of an OS-level editor > component means that there's a tendency for any application that wants > to provide a writing/editing capability to write their own, often > poor, editing code. I entirely agree with that "one interface fits all > users" is a problem, but I'd like a system where there was "one > interface for editing in all circumstances for this user". To clarify, I by "OS-level component" I mean at the "this is THE component applications use when the want editing", but which would be changeable by the user. (If you've seen things like the historical Oberon OS, that kind of thing.) > cheers, dave tweed > -- cheers, dave tweed__ computer vision reasearcher: david.tw...@gmail.com "while having code so boring anyone can maintain it, use Python." -- attempted insult seen on slashdot
Re: [dev] Experimental editor
On Fri, Jun 17, 2011 at 9:46 AM, Nicolai Waniek wrote: > On 06/17/2011 10:37 AM, markus schnalke wrote: >> For the same reason we want Unix's manifold toolchain and for the same >> reason we want several programming languages: Because ``One fits all'' >> is an illusion. > > > Then try to figure out some basic tools that you can glue together to > form a fully functional editor. > > 'Reinventing' an editor for every purpose and most probably copying some > things on source level from one editor to the next is ridiculous. Even more annoying is that the way that the lack of an OS-level editor component means that there's a tendency for any application that wants to provide a writing/editing capability to write their own, often poor, editing code. I entirely agree with that "one interface fits all users" is a problem, but I'd like a system where there was "one interface for editing in all circumstances for this user". cheers, dave tweed
Re: [dev] Experimental editor
On 06/17/2011 10:37 AM, markus schnalke wrote: > For the same reason we want Unix's manifold toolchain and for the same > reason we want several programming languages: Because ``One fits all'' > is an illusion. Then try to figure out some basic tools that you can glue together to form a fully functional editor. 'Reinventing' an editor for every purpose and most probably copying some things on source level from one editor to the next is ridiculous.
Re: [dev] Experimental editor
[2011-06-15 08:12] Peter John Hartman > > Why would you want several editors? For the same reason we want Unix's manifold toolchain and for the same reason we want several programming languages: Because ``One fits all'' is an illusion. > The problem with vi and mutt is that > they have all these keybindings; hence you can on occasion find yourself in > some crazy dark key combination that you didn't mean to be in. Hit Escape and you'll be at a defined place. :-) (btw: I talk about vi, not about mutt.) meillo
Re: [dev] Experimental editor
hi, > > Whether or not your keyboard has a page up/down key is a bit moot; > > the point is that an editor should have under 10 keybindings: up, > > down, left, right (C-hjkl), page up and down (C-uv), save and quite > > (and search and search-and-replace (if you are feeling luxurious)). > you are wrong and/or never learnt to properly use an editor in your > > > lool then notepad is for you -- Guilherme Lino
Re: [dev] Experimental editor
On Thu, Jun 16, 2011 at 02:18:01PM +0100, David Tweed wrote: > On Thu, Jun 16, 2011 at 1:49 PM, Kurt H Maier wrote: > > On Thu, Jun 16, 2011 at 4:15 AM, David Tweed wrote: > >> I'm going to assume that what you mean by "The editor doesn't need to > >> do this." is "the computer user doesn't benefit from having undo in > >> the editor rather than a version control"; > > > > invalid assumption. what he meant was 'the EDITOR doesn't need to do > > this; some other piece of software can do it FOR the editor' > > The various subtlties in what he could have meant was precisely what I > was trying to get a clarification of. (It seemed silly to wait for a > round trip delay before proceeding to the conversation.) It's not I might concede another keybinding for undo/redo, since that'd still keep us under 10 keybindings. But it still seems rather luxurious nor should the editor (the software) be tasked with *very much* having to do with revision control---certainly cut-and-paste and managing buffers should be offloaded to the surrounding environment (be it X or tmux). On a related note: one-file-per-editor-instance, period. I guess I'm arguing for an anti-emacs editor which is mode-less. Oh, wait, I'm arguing for joe. Go joe! Best, Peter -- sic dicit magister P PhD Candidate Collaborative Programme in Ancient and Medieval Philosophy University of Toronto http://individual.utoronto.ca/peterjh
Re: [dev] Experimental editor
On Thu, Jun 16, 2011 at 1:49 PM, Kurt H Maier wrote: > On Thu, Jun 16, 2011 at 4:15 AM, David Tweed wrote: >> I'm going to assume that what you mean by "The editor doesn't need to >> do this." is "the computer user doesn't benefit from having undo in >> the editor rather than a version control"; > > invalid assumption. what he meant was 'the EDITOR doesn't need to do > this; some other piece of software can do it FOR the editor' The various subtlties in what he could have meant was precisely what I was trying to get a clarification of. (It seemed silly to wait for a round trip delay before proceeding to the conversation.) It's not clear what "use software to handle revision control" is meant to suggest: is it that you could implement something at the resolution of a typical editor undo buffer (individual character insertion/deletions) or is it "you shouldn't need any finer resolution than you can acheive with a current revision control system?". Incidentally, to be clear I'm looking at things at the user experience level: I don't care virtually at all about the difference between an editor which has an accessible-within-the-editor built-in fine-grained change buffer and one that acheives an accessible-within-the-editor fine-grained change buffer provided by an external program. But for me there's a huge difference between "to undo something on the current buffer, repeatedly invoke the undo command in the editor" compared to "open a terminal window, bring up a graphical rev control diff viewer, find the revision id corresponding to the desired undo point, rewind and check out that revision, go back to the editor and reload the file". cheers, dave tweed
Re: [dev] Experimental editor
On Thu, Jun 16, 2011 at 4:15 AM, David Tweed wrote: > I'm going to assume that what you mean by "The editor doesn't need to > do this." is "the computer user doesn't benefit from having undo in > the editor rather than a version control"; invalid assumption. what he meant was 'the EDITOR doesn't need to do this; some other piece of software can do it FOR the editor' -- # Kurt H Maier
Re: [dev] Experimental editor
On Thu, Jun 16, 2011 at 09:27:38AM +0200, Mate Nagy wrote: > hi, > > Whether or not your keyboard has a page up/down key is a bit moot; > > the point is that an editor should have under 10 keybindings: up, > > down, left, right (C-hjkl), page up and down (C-uv), save and quite > > (and search and search-and-replace (if you are feeling luxurious)). > you are wrong and/or never learnt to properly use an editor in your > life. > > with friendship, > Mate I'm editing this messaging that I'm writing with vim, why is that a bad thing? whats a bad thing is that I'm replying to the wrong statement :/ Less, I was tought in computers in better... not added restritions (sorry for the mis direction). I want those dark lost 'I don't know where I am' keys, I need them too live... because their is a way to be unix, and there is a way to not be unix, in real life. No books, to read for the PhDs... just you should read them. Jon.
Re: [dev] Experimental editor
On Wed, Jun 15, 2011 at 8:53 PM, Peter John Hartman wrote: >> > A simple editor probably shouldn't have any more keybindings than, say, >> > surf; in fact one or two less: page up/down, up/right/left/down, and find. >> > One doesn't need modes for that. If you want to do something wacked out to >> > your file (like go to the third word on the 4th sentence and delete every >> > vowel), that should probably be done *outside* the editor. >> >> I've got a long comment queued up (restricted internet situation at >> work), but just to respond to the comment about moving stuff "outside >> the editor". One big disadvantage of doing everything "by hand" is >> that such stuff isn't in an undo history that you can execute. I tend >> to use undo a certain amount, mostly immediately (which could be >> simulated by just keeping one copy) but a reasonable amount undoing >> several sets of changes. > > I can't wait. As to revision control, just use software made to handle > revision control. The editor doesn't need to do this. I'm going to assume that what you mean by "The editor doesn't need to do this." is "the computer user doesn't benefit from having undo in the editor rather than a version control"; I'm much less interested in what _needs_ to be done rather than what is most _beneficial_ to do. (It's probably obvious from other posts that I don't subscribe to the common interpretation of the suckless philosophy. IMO, it's unfortunate that both GNOME/KDE/whatever and suckless developers seem more interested in doing stuff for reasons based on the underlying code -- it's cool to do that, it looks good in demos, it's minimal to do that, etc -- rather than from a consideration of what most benefical for the user.) I actually use relatively fine-grained version control as an additional workflow measure (as-i-develop bisection, etc), but there are some things for which firing up an existing VC and attempting to revert a minor change is overkill. The comment I'm talking about isn't specifically about your email but a general post on the thread; ironically the reason the post is queued up is because I chose to write it in an effective editor rather than this crummy gmail edit box, and I can't send arbitrary files through this work machine. cheers, dave tweed
Re: [dev] Experimental editor
hi, > Whether or not your keyboard has a page up/down key is a bit moot; > the point is that an editor should have under 10 keybindings: up, > down, left, right (C-hjkl), page up and down (C-uv), save and quite > (and search and search-and-replace (if you are feeling luxurious)). you are wrong and/or never learnt to properly use an editor in your life. with friendship, Mate
Re: [dev] Experimental editor
On Wed, Jun 15, 2011 at 1:40 PM, Piotr Zalewa wrote: > I use G2 as an emergency when I need to edit via SSH. > it works well with vi. I have a Motorola Droid on which I use vi over SSH on a regular basis. It is extremely painless. --Andrew Hills
Re: [dev] Experimental editor
On 06/15/11 21:24, Andrew Hills wrote: On Wed, Jun 15, 2011 at 4:02 PM, Szabolcs Nagy wrote: * Andrew Hills [2011-06-15 11:51:17 -0400]: On Wed, Jun 15, 2011 at 11:59 AM, Jon bradley wrote: I own a keyboard that has no pgup/pgdn, or arrow keys. Did you steal it from a museum? you don't have to go to a musem for that http://en.wikipedia.org/wiki/File:T-Mobile_G1_launch_event_2.jpg That keyboard also doesn't have Ctrl... and I'm guessing no one here will bother porting the editor to an Android app. --Andrew Hills I use G2 as an emergency when I need to edit via SSH. it works well with vi. zalun
Re: [dev] Experimental editor
plus mark, cut and paste. On Wed, Jun 15, 2011 at 2:11 PM, Peter John Hartman < peterjohnhart...@gmail.com> wrote: > On Wed, Jun 15, 2011 at 05:03:23PM -0400, Kurt H Maier wrote: > > On Wed, Jun 15, 2011 at 4:24 PM, Andrew Hills > wrote: > > > That keyboard also doesn't have Ctrl... and I'm guessing no one here > > > will bother porting the editor to an Android app. > > > > Nokia n900/n810 have no pgdn or pgup, but do have ctrl and arrows. > > Whether or not your keyboard has a page up/down key is a bit moot; > the point is that an editor should have under 10 keybindings: up, > down, left, right (C-hjkl), page up and down (C-uv), save and quite > (and search and search-and-replace (if you are feeling luxurious)). > > peter > > > -- > sic dicit magister P > PhD Candidate > Collaborative Programme in Ancient and Medieval Philosophy > University of Toronto > http://individual.utoronto.ca/peterjh > >
Re: [dev] Experimental editor
On Wed, Jun 15, 2011 at 05:03:23PM -0400, Kurt H Maier wrote: > On Wed, Jun 15, 2011 at 4:24 PM, Andrew Hills wrote: > > That keyboard also doesn't have Ctrl... and I'm guessing no one here > > will bother porting the editor to an Android app. > > Nokia n900/n810 have no pgdn or pgup, but do have ctrl and arrows. Whether or not your keyboard has a page up/down key is a bit moot; the point is that an editor should have under 10 keybindings: up, down, left, right (C-hjkl), page up and down (C-uv), save and quite (and search and search-and-replace (if you are feeling luxurious)). peter -- sic dicit magister P PhD Candidate Collaborative Programme in Ancient and Medieval Philosophy University of Toronto http://individual.utoronto.ca/peterjh
Re: [dev] Experimental editor
On Wed, Jun 15, 2011 at 4:24 PM, Andrew Hills wrote: > That keyboard also doesn't have Ctrl... and I'm guessing no one here > will bother porting the editor to an Android app. Nokia n900/n810 have no pgdn or pgup, but do have ctrl and arrows. -- # Kurt H Maier
Re: [dev] Experimental editor
On Wed, Jun 15, 2011 at 4:02 PM, Szabolcs Nagy wrote: > * Andrew Hills [2011-06-15 11:51:17 -0400]: >> On Wed, Jun 15, 2011 at 11:59 AM, Jon bradley wrote: >> > I own a keyboard that has no pgup/pgdn, or arrow keys. >> >> Did you steal it from a museum? > > you don't have to go to a musem for that > > http://en.wikipedia.org/wiki/File:T-Mobile_G1_launch_event_2.jpg That keyboard also doesn't have Ctrl... and I'm guessing no one here will bother porting the editor to an Android app. --Andrew Hills
Re: [dev] Experimental editor
* Andrew Hills [2011-06-15 11:51:17 -0400]: > On Wed, Jun 15, 2011 at 11:59 AM, Jon bradley wrote: > > I own a keyboard that has no pgup/pgdn, or arrow keys. > > Did you steal it from a museum? you don't have to go to a musem for that http://en.wikipedia.org/wiki/File:T-Mobile_G1_launch_event_2.jpg
Re: [dev] Experimental editor
> > A simple editor probably shouldn't have any more keybindings than, say, > > surf; in fact one or two less: page up/down, up/right/left/down, and find. > > One doesn't need modes for that. If you want to do something wacked out to > > your file (like go to the third word on the 4th sentence and delete every > > vowel), that should probably be done *outside* the editor. > > I've got a long comment queued up (restricted internet situation at > work), but just to respond to the comment about moving stuff "outside > the editor". One big disadvantage of doing everything "by hand" is > that such stuff isn't in an undo history that you can execute. I tend > to use undo a certain amount, mostly immediately (which could be > simulated by just keeping one copy) but a reasonable amount undoing > several sets of changes. I can't wait. As to revision control, just use software made to handle revision control. The editor doesn't need to do this. Peter -- sic dicit magister P PhD Candidate Collaborative Programme in Ancient and Medieval Philosophy University of Toronto http://individual.utoronto.ca/peterjh
Re: [dev] Experimental editor
On Wed, Jun 15, 2011 at 11:59 AM, Jon bradley wrote: > I own a keyboard that has no pgup/pgdn, or arrow keys. Did you steal it from a museum? --Andrew Hills
Re: [dev] Experimental editor
- Original message - > > Still I wonder why you try so much to stay modeless. Modes are a real > > advantage because each mode offers a separate editor. Take vi: You can > > edit in normal mode (= the actual vi mode) or in ex mode or in insert > > mode (e.g. with ^W, ^U). You have the choice which editor (mode) you > > use for some editing task. Ed has modes, too: Command and insert mode. > > > > Surely, the problems are knowing in which mode you're in and switching > > modes. But in return, each mode lets you re-use your keyboard keys > > (the optimum) and for each mode you can design a new editor that's > > best suited for the kind of editing this mode is intended to do. > > Why would you want several editors? The problem with vi and mutt is that > they have all these keybindings; hence you can on occasion find yourself > in some crazy dark key combination that you didn't mean to be in. > > A simple editor probably shouldn't have any more keybindings than, say, > surf; in fact one or two less: page up/down, up/right/left/down, and > find. One doesn't need modes for that. If you want to do something > wacked out to your file (like go to the third word on the 4th sentence > and delete every vowel), that should probably be done *outside* the > editor. > > Peter > > > -- > sic dicit magister P > PhD Candidate > Collaborative Programme in Ancient and Medieval Philosophy > University of Toronto > http://individual.utoronto.ca/peterjh I own a keyboard that has no pgup/pgdn, or arrow keys. My 2 cents. Jon.
Re: [dev] Experimental editor
On Wed, Jun 15, 2011 at 02:47:55PM +0100, Connor Lane Smith wrote: > My view of that kind of editing is, you select the third word in the > fourth sentence (either by leaping or with the mouse), hop over to the > command buffer (Ctrl-Tab?), and run `x/[aeiou]/d'. If you want > something weird like sorting a file, just use `|sort'. > > Thanks, > cls This makes sense. I love sam, but always wished there was a way to switch to the command window (~~sam~~) using the keyboard.
Re: [dev] Experimental editor
On 15 June 2011 12:26, markus schnalke wrote: > What's the difference between a mode and a ``quasimode''? What's the difference between shift and caps lock? > Surely, the problems are knowing in which mode you're in and switching > modes. But in return, each mode lets you re-use your keyboard keys > (the optimum) and for each mode you can design a new editor that's > best suited for the kind of editing this mode is intended to do. This is the sort of argument, imo, which led to the modal soup that is emacs. I want there to be just a collection of buffers, and typing into command buffer is what gives you `command mode', sam style. We always use the same keys, because all we're doing is editing text, so it becomes muscle memory. On 15 June 2011 13:12, Peter John Hartman wrote: > Why would you want several editors? The problem with vi and mutt is that > they have all these keybindings; hence you can on occasion find yourself in > some crazy dark key combination that you didn't mean to be in. This. I want keys to always mean the same thing. Too often they don't, and you end up not knowing what on Earth is happening. With this approach, all you need to keep in mind is where your cursor is. On 15 June 2011 14:01, David Tweed wrote: > One big disadvantage of doing everything "by hand" is > that such stuff isn't in an undo history that you can execute. Yeah, this is one of the benefits of having a command buffer: the shell is just a special case of text editing. You can run editor commands, like mass selections, replacements, etc, and you can also call Unix commands with `!'. (`!sh' basically gives you a shell in your editor for free.) My view of that kind of editing is, you select the third word in the fourth sentence (either by leaping or with the mouse), hop over to the command buffer (Ctrl-Tab?), and run `x/[aeiou]/d'. If you want something weird like sorting a file, just use `|sort'. Thanks, cls
Re: [dev] Experimental editor
On Wed, Jun 15, 2011 at 1:12 PM, Peter John Hartman wrote: > A simple editor probably shouldn't have any more keybindings than, say, > surf; in fact one or two less: page up/down, up/right/left/down, and find. > One doesn't need modes for that. If you want to do something wacked out to > your file (like go to the third word on the 4th sentence and delete every > vowel), that should probably be done *outside* the editor. I've got a long comment queued up (restricted internet situation at work), but just to respond to the comment about moving stuff "outside the editor". One big disadvantage of doing everything "by hand" is that such stuff isn't in an undo history that you can execute. I tend to use undo a certain amount, mostly immediately (which could be simulated by just keeping one copy) but a reasonable amount undoing several sets of changes. -- cheers, dave tweed__ computer vision researcher: david.tw...@gmail.com "while having code so boring anyone can maintain it, use Python." -- attempted insult seen on slashdot
Re: [dev] Experimental editor
> Still I wonder why you try so much to stay modeless. Modes are a real > advantage because each mode offers a separate editor. Take vi: You can > edit in normal mode (= the actual vi mode) or in ex mode or in insert > mode (e.g. with ^W, ^U). You have the choice which editor (mode) you > use for some editing task. Ed has modes, too: Command and insert mode. > > Surely, the problems are knowing in which mode you're in and switching > modes. But in return, each mode lets you re-use your keyboard keys > (the optimum) and for each mode you can design a new editor that's > best suited for the kind of editing this mode is intended to do. Why would you want several editors? The problem with vi and mutt is that they have all these keybindings; hence you can on occasion find yourself in some crazy dark key combination that you didn't mean to be in. A simple editor probably shouldn't have any more keybindings than, say, surf; in fact one or two less: page up/down, up/right/left/down, and find. One doesn't need modes for that. If you want to do something wacked out to your file (like go to the third word on the 4th sentence and delete every vowel), that should probably be done *outside* the editor. Peter -- sic dicit magister P PhD Candidate Collaborative Programme in Ancient and Medieval Philosophy University of Toronto http://individual.utoronto.ca/peterjh
Re: [dev] Experimental editor
[2011-06-12 18:55] Martin Kühl > > [...] command-quasimode [...] > [...] mostly modeless. [2011-06-12 22:38] Connor Lane Smith > > For substitution I'm tempted to just add a keybind to switch to and > from the command pane, which appears at the bottom of the view > (`Quake-like', as Paul says). That means we can do this just with a > raw command, like vi does with `:'. > > So that's pretty much modeless, then. What's the difference between a mode and a ``quasimode''? Almost none! It appears as if you just *want* modes. ;-) I have followed this editor discussion, only reading. Still I wonder why you try so much to stay modeless. Modes are a real advantage because each mode offers a separate editor. Take vi: You can edit in normal mode (= the actual vi mode) or in ex mode or in insert mode (e.g. with ^W, ^U). You have the choice which editor (mode) you use for some editing task. Ed has modes, too: Command and insert mode. Surely, the problems are knowing in which mode you're in and switching modes. But in return, each mode lets you re-use your keyboard keys (the optimum) and for each mode you can design a new editor that's best suited for the kind of editing this mode is intended to do. Am I missing some big disadvantages of modes? I simply don't understand your strong dislike. meillo
Re: [dev] Experimental editor
On 13 June 2011 03:25, Leon wrote: > x doesn't necessarily match lines; it chunks the file arbitrarily. The > chunks could potentially be huge. Of course; I just meant the matches and their addresses. > Also, another buffer seems unwieldy. > Still, perhaps a non-contiguous highlighted "dot" of sorts would be > possible, as the only context in which that would occur currently is > in the middle of an incomplete x/X/y/Y command. It's possible, though there seems something very powerful about having all the matches in one view, perhaps folded to a few lines if they are too big, etc -- especially if the matches span multiple files. Certainly, if you select some text and run `x' on it it ought to dot matches within that, not spawn a whole new view. I suppose the match view should only appear if, say, you are operating on multiple files. > I like the idea of a Sam in which the viewing window responds more > quickly to changes in the command window, such that it's practical to > navigate and edit entirely from the command window if one so chooses, > while still having the viewing window as the focus for one's eyes. This could be useful, though I suspect a mixture of the two would be the most efficient. I will probably spend most of my time interacting with the view, switching over to the command pane for structural regular expressions. > This would mean e.g. the dot "chasing" incomplete address regexps > (with a partial undo if the command remains incomplete); "a", "i", and > "c" causing the viewing window to dynamically update, etc. This sort of thing is secondary to the editor proper, but I would like this to be possible. I'm also keen to make substitutions similarly interactive: as you type the match component it highlights matches, with (pastel-)coloured submatches, and when you type the replacement it could demonstrate the changes, or so. As I say, these are closer to finishing touches, and we've barely got anything yet. ;) Still, it's useful to establish our direction now. > The main > difficulty would be maintaining the conceptual purity of Sam while > trying to reduce inefficient keypresses -- the vi-style "f" solution > (for example) seems pretty ugly. Yeah, this is why I've been hoping to stay modeless, and why I've opted for archy's `leaping'. Unfortunately, power and purity seem mutually exclusive in some cases, in which case it's a difficult decision. For example, the command composition quasimode I'm unsure about: it would be powerful, but also very `vi' (and quite unlike the sam command language, to which ours will be similar). > I'm only an absolute beginner with C, but might try implementing some > of these things over the uni break. You'd be welcome to help out with this, though these are very early days. Thanks, cls
Re: [dev] Experimental editor
> The editor uses interactive structural regular expressions, somewhat > like sam, only with more visual support. Say you run the command > `x/re/'; a special `match' buffer will open containing the matching > lines and line numbers (and in the case of X & Y, their file names > too), allowing you to jump to those locations. You can then edit and > run commands on these matches (including filtering) and the buffer(s) > will be updated accordingly. x doesn't necessarily match lines; it chunks the file arbitrarily. The chunks could potentially be huge. Also, another buffer seems unwieldy. Still, perhaps a non-contiguous highlighted "dot" of sorts would be possible, as the only context in which that would occur currently is in the middle of an incomplete x/X/y/Y command. I like the idea of a Sam in which the viewing window responds more quickly to changes in the command window, such that it's practical to navigate and edit entirely from the command window if one so chooses, while still having the viewing window as the focus for one's eyes. This would mean e.g. the dot "chasing" incomplete address regexps (with a partial undo if the command remains incomplete); "a", "i", and "c" causing the viewing window to dynamically update, etc. The main difficulty would be maintaining the conceptual purity of Sam while trying to reduce inefficient keypresses -- the vi-style "f" solution (for example) seems pretty ugly. I'm only an absolute beginner with C, but might try implementing some of these things over the uni break. Leon
Re: [dev] Experimental editor
On 12 June 2011 18:55, Martin Kühl wrote: > Have you considered a command-quasimode? That way you could keep > vi-style composeable commands and stay mostly modeless. Yes, this is possible -- I was wondering whether we could fit in command composition. A quasimode would work well for things like numeric composition (e.g., `Meta↓ # ↑ Ctrl↓ 6 r f ↑' or similar), but wouldn't work for complex functions like substitution. For substitution I'm tempted to just add a keybind to switch to and from the command pane, which appears at the bottom of the view (`Quake-like', as Paul says). That means we can do this just with a raw command, like vi does with `:'. So that's pretty much modeless, then. The only mode is switching pane, which is a necessary component of the X user's locus. Sounds good to me. > Nice, just please keep leaping backwards in mind as well. I seem to > recall later Archie prototypes spliting leap into two commands for > leaping forwards and backwards (Mod+> and Mod+< respectively), both > implemented as quasimodes. Yeah, leaping backward is an annoyance. I'd like to keep leaps in instant muscle memory, which imo rules out `Mod->'. Meta-Ctrl would use up too many digits -- I imagine binding Meta to CapsLock, in which case I naturally use fingers 4 and 5, leaving nothing to hit Shift -- we would need "foot pedals and a chin switch". So honestly I don't know, yet. I'm open to more ideas. Thanks, cls
Re: [dev] Experimental editor
On Fri, Jun 10, 2011 at 00:05, Connor Lane Smith wrote: > My plan, then, is to write an editor for X, which although > (almost-)modeless, is extremely fast to use. (I say `almost' because > search, for instance, is a mode, but is at the users' locus of > attention. I may also make `Escape' an optional command/insert mode > switch.) Let me be clear, this will not be a tiny minimalist editor; > that is already covered by ed. This will fill the same place as vi: it > may be a little larger, but damn is it fast. Have you considered a command-quasimode? That way you could keep vi-style composeable commands and stay mostly modeless. > The editor uses interactive structural regular expressions, somewhat > like sam, only with more visual support. Say you run the command > `x/re/'; a special `match' buffer will open containing the matching > lines and line numbers (and in the case of X & Y, their file names > too), allowing you to jump to those locations. You can then edit and > run commands on these matches (including filtering) and the buffer(s) > will be updated accordingly. I like this idea a lot. Incidentally, that's exactly how I imagine my ideal file manager should work, and it should work for managing windows just as well. > In Vi I use `f' and `F' a lot. That is, I jump within lines so I don't > have to bother crawling with the cursor or reaching for the mouse. > This is faster than using `/' because you don't have to press enter > (surprisingly this has a big difference). In a similar fashion, this > editor will (as well as normal search) have a `leap' quasimode (cf. > Jef Raskin) which lets you search just by holding Meta, and to exit > search mode you just release. This is faster to use, doesn't spam your > search history, and means we can stop matching at the first match, > whereas with full search we'd highlight all matches in the scrollbar. Nice, just please keep leaping backwards in mind as well. I seem to recall later Archie prototypes spliting leap into two commands for leaping forwards and backwards (Mod+> and Mod+< respectively), both implemented as quasimodes. Cheers, Martin
Re: [dev] Experimental editor
Connor Lane Smith lubutu.com> wrote: > > I've been working on a minimalist UTF-8 library for the editor, based > on Plan 9's libutf, except designed for native Unix, with support for > Unicode beyond the Basic Multilingual Plane, and without the > vulnerabilities on 64-bit systems. I'm not sure if I should release it > separately as well? > > Thanks, > cls > I'm not sure if it's related to your work. You could check this discussion[1], which is mdocml oriented[2]. If it has nothing to do with your work, sorry for bothering you. Otherwise you could mail BSD guys. [1] http://mdocml.bsd.lv/archives/tech/0364.html [2] http://mdocml.bsd.lv/ -- Paul Onyschuk
Re: [dev] Experimental editor
On 10 June 2011 14:42, Rob wrote: > It looks like it's been decided that X is the way to go, but before any > code is implemented, I thought I'd just stick my oar in - what if we > were to keep to the terminal and open a connection to an X server, if > available, and simply query the modifier key states when reading a key? Having thought about this, I don't think it would be a good idea. Terminals are restrictive for more reasons than their keyboard input, tbh. I've been working on a minimalist UTF-8 library for the editor, based on Plan 9's libutf, except designed for native Unix, with support for Unicode beyond the Basic Multilingual Plane, and without the vulnerabilities on 64-bit systems. I'm not sure if I should release it separately as well? Thanks, cls
Re: [dev] Experimental editor
On 10 June 2011 08:54, Rafa Garcia Gallego wrote: > The lack of Shift+Control modifier is a serious bummer indeed. It looks like it's been decided that X is the way to go, but before any code is implemented, I thought I'd just stick my oar in - what if we were to keep to the terminal and open a connection to an X server, if available, and simply query the modifier key states when reading a key? This way we can still have a console editor, but overcome the problem of modifier keys, and not have to bother with window handling. Good idea? Hackish idea? Finally-got-rid-of-curses-and-I'm-trying-to-drag-you-all-back idea? You decide.
Re: [dev] Experimental editor
Paul Onyschuk writes: > It has been discussed before[1]. With Sam regexps, own window manager > can be handy. Some quotes: > > Russ Cox swtch.com> wrote: > >> >> The die hard sam users would disagree vehemently with you. >> The nice thing about sam is that it's one window, not many, >> making it comfortable to edit a 30-file project without getting >> caught up in managing windows. That just means you need a better window manager. Whatever sam does, why can't a specialised program do that as well? -- \ Troels /\ Henriksen
Re: [dev] Experimental editor
On 10 June 2011 12:19, Paul Onyschuk wrote: > Is vertical side by side layout stupid idea? Maybe not. We've gone from > small screens to high resolution widescreen monitors. Moreover 2 or > 3-screens setup isn't fancy anymore. Using so much vertical space > effectively for text editing is a topic worth of consideration. I'm unsure about this. It would involve complicating the idea of a view, and I'm not sure text disappearing off the bottom and appearing at the top a little to the right is very appealing. Still, by using multiple views into the same buffer you could mimic this while remaining more dynamic. > Version control systems have evolved past few years. Still more > fine-grained history could be useful sometimes. Recdit introduced deep > diffs. Also this could be used as argument for avoiding syntax > highlighting (too much colors at once). Deep diffs look extremely ugly. There may be a way to make them nicer, of course, but I can't really see what problem they solve, at least wrt programming. > I love the text editor Sam. There is one problem with it - it's stack > based WM over stack based WM. How to resolve this issue? Just look at > so called distraction-free editors like FocusWriter[2] - using full > screen is a feature. Like I said earlier, we won't bother with window management, we'll just make windows. The beauty of this is you can do with them what you will. Embedded in tabbed and maximised? Sure. > Maybe those group of editors is silly, but at least they don't pretend > to be anything else than text editors. I think that they were created > as response to complex WYSIWYG editors and IDE's, which made religion > out of interface. I assure you that is unlikely to happen here. The current UI debate is, "do we display a modeline at the bottom, or have absolutely nothing but the text itself?" On 10 June 2011 13:51, Paul Onyschuk wrote: > It has been discussed before[1]. With Sam regexps, own window manager > can be handy. Have you ever used Rio? No wonder they want separate windowing: Plan 9's window system is legendarily bad. We have dwm; we don't spend any time at all managing windows. Coupled with the option of tabbed, we really don't need to worry about this. Thanks, cls
Re: [dev] Experimental editor
On 10 June 2011 08:54, Rafa Garcia Gallego wrote: > What do you mean by that? Is there an experimental way to view, > insert, change, delete text? I've read below about the multiple views > and all, is that one of the research-y ideas? Just curious. Well, you can't exactly go crazy, but there are some things I'd like to experiment with. The newest thing is probably adding interactivity to structural regular expressions. There are also a lot of things which do exist elsewhere but have never been brought together (we're basically blending vi, emacs, sam, and archy); I think if we do this well cool interactions will emerge. > I dislike spawning several windows per process (it's confusing, > specially if several processes run concurrently), but then again you > need them if you want those multiple views. Please, do not split, > tab,etc your windows internally; not managing them sounds healthy > enough, but try not to gimp the thing too much. I'd like window creation to be `fire and forget': we make it, that's it. If for whatever reason you want to run multiple instances you can always use tabbed, or just different tags, so you don't confuse them. Each window will be a view, that's all. > This is exactly what sandy does now, but sandy only has one windows, of > course. So it is! I suppose the only difference is we'll show where the mark is. I didn't realise sandy did this; emacs seems to just have the two. > I like the idea of structural regex, but I haven't used sam much. The > match buffer sounds a bit emacs-y for my taste. I doubt emacs has > something exactly like that; then again I am more of a vi(m) guy so > emacs is really a myth for me. And a scary one at it. Understandable. I'm happy with a match buffer on the basis that matches are inherent to structural regular expressions, and they're `first-class' in the editor. As such we won't have any accumulation of view types, because regular expressions don't do very much. It just seems strange, I suppose, that sam is built upon them, and yet if you want to use them you have to use the command line interface. It seems sensible that if you can run `x/re/' you can see them visually. The match view wouldn't even do anything particularly special, just instead of displaying a single buffer's 0,$ range it would display various buffers' matched ranges. (For that reason I think we should actually call it a match view, not a match buffer.) We could actually make the behaviour part of the nature of views, in the sense that views just display arbitrary ranges within buffers. I can't think of another use case yet, but the symmetry is nice. > Something like http://en.wikipedia.org/wiki/Rope_%28computer_science%29 I > guess? Similar, yes, though our approach will mean we can jump to an arbitrary line or rune, rather than just a certain byte, in logarithmic time. > Best of luck with your project. It sounds different enough from sandy, > and we surely can exchange ideas, code, etc. Sounds good to me. :) Thanks, cls
Re: [dev] Experimental editor
Yoshi Rokuko rokuko.net> wrote: > > if an application needs more windows these windows should be managed > by the window manager - usually starting multiple instances is > enough, so imho using something like :sp in vim from inside X is > stupid. > > fullscreen is for me not the point in [2] you can hit alt+m in dwm and > get a fullscreen vim or something - the padding is the point here, it > makes text much more readable. > > best regards, yoshi > It has been discussed before[1]. With Sam regexps, own window manager can be handy. Some quotes: Russ Cox swtch.com> wrote: > > The die hard sam users would disagree vehemently with you. > The nice thing about sam is that it's one window, not many, > making it comfortable to edit a 30-file project without getting > caught up in managing windows. > Erik Quanstrom quanstro.net> wrote: > > back when i was doing distributed search, i'd have sam running for > months with 200 files in the menu. > This can sound like fairy tale for many ;) [1] http://thread.gmane.org/gmane.os.plan9.general/26178/ -- Paul Onyschuk
Re: [dev] Experimental editor
+--- Paul Onyschuk ---+ > [...] > I love the text editor Sam. There is one problem with it - it's stack > based WM over stack based WM. How to resolve this issue? Just look at > so called distraction-free editors like FocusWriter[2] - using full > screen is a feature. > if an application needs more windows these windows should be managed by the window manager - usually starting multiple instances is enough, so imho using something like :sp in vim from inside X is stupid. fullscreen is for me not the point in [2] you can hit alt+m in dwm and get a fullscreen vim or something - the padding is the point here, it makes text much more readable. best regards, yoshi [...] > [1] http://www.thimbleby.net/truetext/ > [2] http://gottcode.org/focuswriter/ >
Re: [dev] Experimental editor
After seeing words "very experimental", I'm willing to share some ideas, maybe too controversial otherwise for suckless folk ;) First of all, check Recdit[1] editor. It's Mac OS X app, but nice paper and short video is available. It has some unique features. Is vertical side by side layout stupid idea? Maybe not. We've gone from small screens to high resolution widescreen monitors. Moreover 2 or 3-screens setup isn't fancy anymore. Using so much vertical space effectively for text editing is a topic worth of consideration. Version control systems have evolved past few years. Still more fine-grained history could be useful sometimes. Recdit introduced deep diffs. Also this could be used as argument for avoiding syntax highlighting (too much colors at once). I love the text editor Sam. There is one problem with it - it's stack based WM over stack based WM. How to resolve this issue? Just look at so called distraction-free editors like FocusWriter[2] - using full screen is a feature. Maybe those group of editors is silly, but at least they don't pretend to be anything else than text editors. I think that they were created as response to complex WYSIWYG editors and IDE's, which made religion out of interface. Sam power with more classical interface (tabs - just check how FocusWriter uses them) and Quake-like console (showing when needed) for regexps could be a quite useful combo. It looks like I presented idea for pretty much full blown text editor, now bring in some bashing ;) [1] http://www.thimbleby.net/truetext/ [2] http://gottcode.org/focuswriter/ -- Paul Onyschuk
Re: [dev] Experimental editor
On Fri, Jun 10, 2011 at 9:54 AM, Rafa Garcia Gallego wrote: > I like the idea of structural regex, but I haven't used sam much. The > match buffer sounds a bit emacs-y for my taste. I doubt emacs has > something exactly like that; then again I am more of a vi(m) guy so > emacs is really a myth for me. And a scary one at it. Good ol' M-x occur
Re: [dev] Experimental editor
Hi On Fri, Jun 10, 2011 at 12:05 AM, Connor Lane Smith wrote: > > Hey all, > > I'd like to include those of you who aren't in IRC in the discussion > we're having wrt writing a new text editor. We do already have Sandy > of course, and I think Rafa is doing a great job, but there are a > couple of reasons why I don't think it will for me replace Vi: Well, that's great. As soon as I have more free time I'll probably join the IRC channel, maybe contribute some code if I get around the code. > 1. Curses: it has its benefits, but for a modeless editor it is > extremely restrictive. The lack of Shift+Control modifier is a serious bummer indeed. > 2. Speed: maybe I've just not warmed up to it yet, but I don't feel > like I'll get as fast with Sandy as I am with Vi. You probably won't unless things change a bit. Sandy is not a "power-editor" right now. You could probably build a power editor using sandy's code as a base, but it is not right now; and I doubt you could build one while remaining mostly modeless. > 3. It's not experimental. In some ways that's a good thing. My project, > however, will be very experimental. Perhaps too much. It'll teach us > things. What do you mean by that? Is there an experimental way to view, insert, change, delete text? I've read below about the multiple views and all, is that one of the research-y ideas? Just curious. > My plan, then, is to write an editor for X, which although > (almost-)modeless, is extremely fast to use. (I say `almost' because > search, for instance, is a mode, but is at the users' locus of > attention. I may also make `Escape' an optional command/insert mode > switch.) Let me be clear, this will not be a tiny minimalist editor; > that is already covered by ed. This will fill the same place as vi: it > may be a little larger, but damn is it fast. I like some of these. X seems sadly necessary. > It's difficult with a project like this to know where to start, so > I'll just explain the idea and hope I don't leave out anything > important. Feel free to contribute ideas; not much code has been > written, yet (expect this to be a long-term project). > > So, we have a bunch of windows, each of which represents a buffer. > Multiple windows can display a single buffer, if you clone (or > `zerox') it, in which case you can edit in both windows > simultaneously, which is nice when you're dealing with big files like > `dwm.c'. Importantly, we just make windows, we don't manage them: you > can use dwm, or embed them in tabbed, or whatever; we don't care. I dislike spawning several windows per process (it's confusing, specially if several processes run concurrently), but then again you need them if you want those multiple views. Please, do not split, tab,etc your windows internally; not managing them sounds healthy enough, but try not to gimp the thing too much. > Each window maintains three marks within the buffer, `cursor', > `select', and `mark'. The `cursor' is your current position in the > buffer, `select' defines the extent of your current selection, and > `mark' is a separate subtle cursor-like point elsewhere in the buffer > which acts as a useful kind of pivot. For instance, when you > (incrementally) search it sets `mark' to your original location and > then hops through the buffer, so you can always return to where you > were in a keypress. This is exactly what sandy does now, but sandy only has one windows, of course. > The editor uses interactive structural regular expressions, somewhat > like sam, only with more visual support. Say you run the command > `x/re/'; a special `match' buffer will open containing the matching > lines and line numbers (and in the case of X & Y, their file names > too), allowing you to jump to those locations. You can then edit and > run commands on these matches (including filtering) and the buffer(s) > will be updated accordingly. I like the idea of structural regex, but I haven't used sam much. The match buffer sounds a bit emacs-y for my taste. I doubt emacs has something exactly like that; then again I am more of a vi(m) guy so emacs is really a myth for me. And a scary one at it. > In Vi I use `f' and `F' a lot. That is, I jump within lines so I don't > have to bother crawling with the cursor or reaching for the mouse. > This is faster than using `/' because you don't have to press enter > (surprisingly this has a big difference). In a similar fashion, this > editor will (as well as normal search) have a `leap' quasimode (cf. > Jef Raskin) which lets you search just by holding Meta, and to exit > search mode you just release. This is faster to use, doesn't spam your > search history, and means we can stop matching at the first match, > whereas with full search we'd highlight all matches in the scrollbar. I always disliked that vi's f/t/F/T commands did not wrap to the next line. > That's pretty much an overview of the core idea. If anyone has any > ideas I'd like to hear them. Right
[dev] Experimental editor
Hey all,
I'd like to include those of you who aren't in IRC in the discussion
we're having wrt writing a new text editor. We do already have Sandy
of course, and I think Rafa is doing a great job, but there are a
couple of reasons why I don't think it will for me replace Vi:
1. Curses: it has its benefits, but for a modeless editor it is
extremely restrictive.
2. Speed: maybe I've just not warmed up to it yet, but I don't feel
like I'll get as fast with Sandy as I am with Vi.
3. It's not experimental. In some ways that's a good thing. My project,
however, will be very experimental. Perhaps too much. It'll teach us
things.
My plan, then, is to write an editor for X, which although
(almost-)modeless, is extremely fast to use. (I say `almost' because
search, for instance, is a mode, but is at the users' locus of
attention. I may also make `Escape' an optional command/insert mode
switch.) Let me be clear, this will not be a tiny minimalist editor;
that is already covered by ed. This will fill the same place as vi: it
may be a little larger, but damn is it fast.
It's difficult with a project like this to know where to start, so
I'll just explain the idea and hope I don't leave out anything
important. Feel free to contribute ideas; not much code has been
written, yet (expect this to be a long-term project).
So, we have a bunch of windows, each of which represents a buffer.
Multiple windows can display a single buffer, if you clone (or
`zerox') it, in which case you can edit in both windows
simultaneously, which is nice when you're dealing with big files like
`dwm.c'. Importantly, we just make windows, we don't manage them: you
can use dwm, or embed them in tabbed, or whatever; we don't care.
Each window maintains three marks within the buffer, `cursor',
`select', and `mark'. The `cursor' is your current position in the
buffer, `select' defines the extent of your current selection, and
`mark' is a separate subtle cursor-like point elsewhere in the buffer
which acts as a useful kind of pivot. For instance, when you
(incrementally) search it sets `mark' to your original location and
then hops through the buffer, so you can always return to where you
were in a keypress.
The editor uses interactive structural regular expressions, somewhat
like sam, only with more visual support. Say you run the command
`x/re/'; a special `match' buffer will open containing the matching
lines and line numbers (and in the case of X & Y, their file names
too), allowing you to jump to those locations. You can then edit and
run commands on these matches (including filtering) and the buffer(s)
will be updated accordingly.
In Vi I use `f' and `F' a lot. That is, I jump within lines so I don't
have to bother crawling with the cursor or reaching for the mouse.
This is faster than using `/' because you don't have to press enter
(surprisingly this has a big difference). In a similar fashion, this
editor will (as well as normal search) have a `leap' quasimode (cf.
Jef Raskin) which lets you search just by holding Meta, and to exit
search mode you just release. This is faster to use, doesn't spam your
search history, and means we can stop matching at the first match,
whereas with full search we'd highlight all matches in the scrollbar.
That's pretty much an overview of the core idea. If anyone has any
ideas I'd like to hear them. Right now we're mostly brainstorming,
though rransom is writing a monoid which will let us use B-trees for
out internal buffer data structure. Simply put, it will make buffers
ridiculously fast: linear regexp matching, constant or logarithmic
everything else. So then I'll get to work on the editor proper.
("I think we're gonna confuse the ocean waves with all this typing.")
Thanks,
cls
