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] dwm bug: mouse click not working on statusbar with Lithuanian keyboard layout
Any chance this fix makes into the official dwm release? 2011/6/15 Andreas Amann : > On Wed, 15 Jun 2011 11:46:36 +0300, Julius Meldaikis > wrote: >> Hello. I have been using dwm for about two years and undergone many >> version changes, but one bug always persisted. I am using the >> following section in my xorg.conf to switch between English and >> Lithuanian keyboard layouts: >> >> Section "InputClass" >> Identifier "Keyboard0" >> MatchIsKeyboard "yes" >> Option "XkbLayout" "us,lt" >> Option "XkbOptions" "grp:caps_toggle,grp_led:num" >> EndSection >> >> Whenever I am using the Lithuanian keyboard layout, mouse click on >> statusbar does nothing. That is, tags do not change as well as window >> layouts when I click on respective places in statusbar. Everything >> else in dwm and X works normally. That's also a bit surprising, since >> dwm uses number keys to switch tags, and in Lithuanian layout numbers >> are replaced by special Lithuanian letters. Even so, keyboard >> shortcuts DO work, while mouse click on statusbar does not. Thanks for >> help, > > > This is an old bug. For a fix see > > http://lists.suckless.org/dev/1010/6195.html > http://lists.suckless.org/dev/1005/4319.html > >
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
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.
[dev] Re: Experimental editor
Andrew Hills writes: > 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. Press the "ball" once for ctrl-, and twice for esc (=meta). One gets used to it. -- Christian Neukirchenhttp://chneukirchen.org
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 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 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] Re: sbase
On 16 June 2011 02:18, Connor Lane Smith wrote: > An update: I've done this, and added it to the Makefile. It's a little > simpler than doing it by concatenating all the sources, since we don't > need to worry about statics or anything. Currently sbase-box comes out > at 69K statically linked against musl, or 23K dynamically linked > against glibc. That looks much nicer than my script, actually, nicely done.
Re: [dev] [dwm] fullscreen apps losing focus
On 6/15/11, Bogdan Ionuț wrote: > 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!? > By default newly mapped windows become master and are focused. You could delay mapping new windows when a fullscreen window is focused, i.e. when the focused client's geometry equals the monitor's.
