Re: [dev] Experimental editor
[2011-06-12 18:55] Martin Kühl martin.ku...@gmail.com [...] command-quasimode [...] [...] mostly modeless. [2011-06-12 22:38] Connor Lane Smith c...@lubutu.com 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
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
On Wed, Jun 15, 2011 at 1:12 PM, Peter John Hartman peterjohnhart...@gmail.com 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
On 15 June 2011 12:26, markus schnalke mei...@marmaro.de 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 peterjohnhart...@gmail.com 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 david.tw...@gmail.com 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 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.
[dev] Re: Experimental editor
Josh Rickmar joshua_rick...@eumx.net writes: This makes sense. I love sam, but always wished there was a way to switch to the command window (~~sam~~) using the keyboard. I think sam together with the common discussed keybindings (which are partly implemented in p9p already), up/down-cursor keys for line movement(!) and shift-cursor selection would be a very usable and powerful editor already. Next step would be to drop its windowing system and use X11 windows. I'd also kill for a console samterm. ;) -- Christian Neukirchen chneukirc...@gmail.com http://chneukirchen.org
[dev] [dwm] fullscreen apps losing focus
it's kinda annoying to lose focus in a fullscreen app if a new one is started in the background, eg: fullscreen mplayer running in `chat` tag. it's a bug or a feature!?
Re: [dev] Re: Experimental editor
On Wed, Jun 15, 2011 at 04:42:27PM +0200, Christian Neukirchen wrote: Josh Rickmar joshua_rick...@eumx.net writes: This makes sense. I love sam, but always wished there was a way to switch to the command window (~~sam~~) using the keyboard. I think sam together with the common discussed keybindings (which are partly implemented in p9p already), up/down-cursor keys for line movement(!) and shift-cursor selection would be a very usable and powerful editor already. Next step would be to drop its windowing system and use X11 windows. I'd also kill for a console samterm. ;) Why not just keep the underlying sam the same (sam -d) but write a different samterm for it which does one window per buffer? This would also make it easy to switch to any buffer you wanted since it would just be part of the window manger.
[dev] Re: Experimental editor
Josh Rickmar joshua_rick...@eumx.net writes: Why not just keep the underlying sam the same (sam -d) but write a different samterm for it which does one window per buffer? This would also make it easy to switch to any buffer you wanted since it would just be part of the window manger. That's how I'd do it if I had the time, but note that samterm contains some nontrivial logic itself, too. -- Christian Neukirchen chneukirc...@gmail.com http://chneukirchen.org
Re: [dev] Re: Experimental editor
On 15 June 2011 15:54, Josh Rickmar joshua_rick...@eumx.net wrote: Why not just keep the underlying sam the same (sam -d) but write a different samterm for it which does one window per buffer? That question is where my editor started. The answer to why not is, sam is ugly. A common misconception is that samterm just speaks the same language as sam -d. It doesn't, it uses a custom binary protocol and contains a lot of caching logic and so on. The protocol wasn't designed before implementation, I think, and it was not designed with writing an alternative samterm in mind. It's just a de facto protocol, and imo it is quite broken. After starting a few samterms over the past year I decided the protocol is just too obscure, and we can make it a lot simpler just by writing something from scratch. That way we can also take advantage of the new back-end, allowing us to use interactive structural regular expressions and so on. It's easier to write a new sam-inspired editor than restrict ourselves to the samterm protocol. And that's what I'm going to do, rolling in a few ideas from other editors as I go. cls
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 11:59 AM, Jon bradley weat...@gmail.com 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
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
* Andrew Hills hills...@gmail.com [2011-06-15 11:51:17 -0400]: On Wed, Jun 15, 2011 at 11:59 AM, Jon bradley weat...@gmail.com 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
On Wed, Jun 15, 2011 at 4:02 PM, Szabolcs Nagy n...@port70.net wrote: * Andrew Hills hills...@gmail.com [2011-06-15 11:51:17 -0400]: On Wed, Jun 15, 2011 at 11:59 AM, Jon bradley weat...@gmail.com 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
On Wed, Jun 15, 2011 at 4:24 PM, Andrew Hills hills...@gmail.com 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 05:03:23PM -0400, Kurt H Maier wrote: On Wed, Jun 15, 2011 at 4:24 PM, Andrew Hills hills...@gmail.com 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
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 hills...@gmail.com 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 06/15/11 21:24, Andrew Hills wrote: On Wed, Jun 15, 2011 at 4:02 PM, Szabolcs Nagyn...@port70.net wrote: * Andrew Hillshills...@gmail.com [2011-06-15 11:51:17 -0400]: On Wed, Jun 15, 2011 at 11:59 AM, Jon bradleyweat...@gmail.com 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
On Wed, Jun 15, 2011 at 1:40 PM, Piotr Zalewa zal...@gmail.com 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
