Meet the Gang   1   2   3   4   5   6   7   8   9

#### By Jim Dennis, Ben Okopnik, Dan Wilder, Breen, Chris, and the Gang, the Editors of Linux Gazette... and You! Send questions (or interesting answers) to tag@lists.linuxgazette.net

There is no guarantee that your questions here will ever be answered. Readers at confidential sites must provide permission to publish. However, you can be published anonymously - just let us know!

### Control-Left = go left one word doesn't work in X

From Jay Christnach

Answered By Ben Okopnik, Dan Wilder, John Karns, Mike Orr, Karl-Heinz Herrman

I already spent hours trying to fix this annoying problem:

I don't even know if this normally works, but pressing the control and left-arrow keys simultaneosly should move the cursor one word back.

[Ben]
Nope, this doesn't normally work - because there's no such thing as "normally". The kind of functionality you're talking about is specific to a given piece of software, or, in several window managers, might even be a sequence that is caught and handled by the WM itself.
[John K] In the case of many versions of fvwm2, ctrl-arrow key combos move the mouse cursor. However, it seems that it no longer holds true as of fvwm2 ver 2.3.31 or so (or maybe it was changed by SuSE).
[Ben] When you ask this kind of a question, you always need to specify which application you're using. In Unix, one of the guiding principles is "don't set policy; provide mechanisms." Unlike other OS's GUIs, there's no single common interface (unless the window manager - KDE and Gnome are good examples - enforces one.)

Is this a problem in the xkb symbols? Is this a functionality that has to be provided by the applications and they simply don't have this shortcut? I don't know anymore where to look to fix this. Thanks for your help.

[Dan] This is functionality that has to be provided by the application.

Thanks for answering and trying to help

Well I asked a friend if this keyboard shortcut would work on his Linux box (Mandrake KDE) and he tried several applications and found that even xvi provides this kb shortcut.

[Ben] Err... Jay? Did you read our answers? Like, the content, not just the envelope? I'll repeat it again, just in case Dan's one-line statement and my longer explanation weren't clear:

#### It's application specific.

There's no magic file, or download, or anything else that you can install that will make that combination work in every editor. Whatever the author of that piece of software decided to put in as the "jump-word" key combo, that's what you get.
To correct your misconception, above: it's not "even xvi provides". The correct version reads "xvi is at least one editor that provides". What "xvi" provides bears no relation to what an author of another editor might use.

I asked him to send me a copy of his /usr/lib/X11/xkb directory. I suspected there were a missing Keyboard Symbol in my xkb config (I hacked it for being able to use dead-circumflexes and diaeresis for my sf keyboard, those were missing in the files which came with my debian distro) I use the Gnome Desktop (ximian) and sawfish window manager. I'm pretty shure that Abi-Word usually is able to handle the CTRL-Cursor thing. (It is nearly a copy of MS Word).

[Ben] Huh? That makes no sense. It's written for a different OS... with a different programming interface... everything, except the types of files that it can open is different from MS Word... and you expect the keystrokes to be the same? They might be - it's not an unusual key combo for the job - but expecting it is just plain silly.

Also in most text-widgets I am able to select the entire line with shift-Home or Shift-End which is consistent to ctrl-Shift-Cursor for selecting words and I think this is an accepted standard or at least should be.

[Ben] Ah, there's the problem: "accepted standard or at least should be." I knew there had to be a root cause of all this somewhere, and I'm glad we discovered it so early - it could get really bad if left to grow and spread unchecked. Here, let me excise that for you...
"Accepted standard" begs the question of "accepted by whom?" "By me" is not a valid answer; neither is "by MS Windows users." "Should be" according to you is obviously not a "should be" according to software authors. Since you're not one (that's a guess, but a fairly informed one), you don't get to decide what "should be". If the editors that exist don't suit you, you're always welcome to write one of your own - including whatever keystrokes you decide it should have.
[Mike] This is a bit harsh. The reason KDE and Gnome exist is because ppl see the importance of adhering to cross-platform user-interface standards.
There is a standard for word processors/text editors (regarding how they treat the arrow keys and select/cut/paste operations) that was originally set by MacWrite years and years back, because ppl who tried it found it very intuitive to use and remember.
[Ben] <wince> OK, here's a seemingly minor niggle that's got a hidden kicker to it: the definition of the word "standard". As you're using it here, it means "what a lot of folks have been using for a while". What it means to me is "a defined set of specifications." Confuting the two leads to... well, MS Windows is an example. The querent's original assumption is another.
In a way, I find myself agreeing with a minor premise of Jay's: I would like it if there was such a thing as an "editor keystroke standard" - to be exact, if there were several of them, each one a well-thought out, coherent, non-internally-conflicting set of keystrokes. Then, you could have a "flagship" implementation for each - Emacs, vi, MSWord, whatever - and all the other editors could then use, say, a library that simply eliminated the whole bloody job of writing a command parser. Now, throw in a couple of editors like the old "PE3" from DOS (gosh, I loved that thing! I miss it...) where you could actually modify the "keydefs" file any way you wanted to - including building macros to be assigned to specific key combos - and you'd have the world covered.
All that... yeah, sure... BUT.
I'm not a software developer. I don't consider myself as having the right to moan and groan about the issue without being able to make a material contribution - which, again, would only become a contribution in the full sense of the word if it passed the "community acceptance test". The only thing I can do, IM!NSHO, is to put in the time testing the available editors (I've installed and run every editor available with Debian, other than obvious clones, plus a number of others) to see how well they suit me. If they don't, I don't use them - but I don't complain about them, either; they obviously suit other people to a tee.
Had the querent asked STL "I'm looking for an editor that has the same keystrokes as the ETAOINSHRDLU editor - do you folks know of any?", I could have probably found something that would help him - and would have been glad to; I like being able to help people. As it was, I found the fact that he completely ignored my and Dan's original responses, and the attitude of "well, real editors all have this!", irritating.
BTW - I wasn't aware that it was MacWrite that used those keydefs originally. Interesting nybble of info.
[Mike] It has been widely duplicated in MS Word and practically all Mac and Windows word processors and text editors ever since. Even the DOS edit command recognized the sense of this scheme and was compatible with at least part of it (shift-arrow extends the selection, ctrl-arrow moves by words, shift-ctrl-arrow does both). However, part of the paradigm (ctrl-Z/X/C/V for undo/cut/copy/paste) was adopted by everything except DOS edit and MS Works. (Of course, Mac had to use the clover key ["command key"] because there was no ctrl key on the Mac keyboard at the time, a stupid unnecessary attempt to improve on standards without offering anything better, and some programs like Netscape 4 use alt instead of ctrl, but modifier-key exceptions are easy enough to learn.)
[Ben] <grin> Control-Meta-Hyper-Super-Shift-Top-Front-X? According to The Jargon File, all of the above were modifiers - at the same time - on the LISP machines' keyboards at MIT (does it surprise anyone that this influenced the design of Emacs?) "Ten-finger typist", indeed...
[Mike] In the Unix world, applying this standard wholesale is a bit difficult. It's fine for graphical programs that imitate Windows/Mac programs. But vi and emacs have existing standards that conflict with these. Also, ctrl-C is very commonly used in Unix to mean "abort this program".
Also on Unix, you have the problem that when logging in under various circumstances, the terminal type gets out of sync and the non-typewriter keys become inaccessible (insert/delete, pgup/pgdown, and sometimes even backspace). Thus, you must have alphabetic or ctrl-letter keys to perform these actions as an emergency fallback.
Also, vi and emacs typists will say they are more efficient because they never have to take their hands off the typewriter keys.
[Ben] If your editor you write now survives the process of acceptance by the Linux community - i.e., a significant number of folks start using it - then, ta-daa! You've just become one of the folks who decide what "should be". See how easy that was?
<sigh> Pardon me if I sound a bit ascerbic... but, over time, I've grown rather tired of people who are perfectly willing to use the software that other people have spent thousands of hours writing - and complain about it. To me, that smacks of - uh, no, defines - ingratitude.
[Mike] This is certainly correct, not just for the current situation but in general. However, what's really happening here is a clash of worldviews, which cause two topics that don't have anything to do with each other to conflict.
JAY: All programs should stick to the established Windows/Mac standard re the arrow keys, a standard that has proved itself valuable.
BEN: Don't you realize that any change you suggest to a program requires HOURS OF WORK by UNPAID VOLUNTEERS? Why is it their obligation to code things to your specifications?
MIKE: The issue that's falling off the table is, is the Windows/Mac arrow-key standard a good one we should generally adopt, working around conflicts with existing applications as much as feasable? I say yes.
[Ben] If I had any say, my input would be "yes, as one of the standards". One of the reasons I really like using the editor in Midnight Commander is that it follows that set of keydefs pretty closely. Now that I've had to grit my teeth and really learn to work with "vi" ("VIM", actually), I find that I like the functionality - and learning only a small subset of the keystrokes (plus being able to look up all the others via the help facility) is highly feasible. Those are the two that I've settled on, and they cover the entire range of what I need in editors.
Pretty-text editors (word processors) are an entirely different kettle of fish. I've found that 99.9% of the time, I don't need them; in Windows, I used to use them because Notepad was so bad (although GTEdit came very close to Unix functionality), but with Linux, I have choices. The one-in-a-thousand times when I do need that - making up a sign with large lettering, for example[1] - either HTML (yechhh) or KWord suffice. I'll be the first to admit that fancy WP stuff is still not a Known Science under Linux.
[1] This seems like such an obvious lacuna that I wonder: is it me? Am I missing something obvious? There must be some quickie LaTeX thing you can whip up, or something of the sort; I just can't believe that a gap like that would exist in Unix, where a part of the philosophy seems to be "small tools that will roll into and eventually fill every crack". E.g. - I want to print a sign on an 8.5x11 sheet that says "Welcome!" in letters large enough to pretty much cover the sheet. Can anyone think of a simple way, using Unix-native (i.e., not fancy modern GUI) tools?
[K.-H.] This requires you to type everything in vi cut-paste with mouse is surely a fancy GUI method, isn't it?
[Ben] Nope; I've got "gpm" running. Seriously - I meant exactly the type of solution you're suggesting, and I thank you for relieving my sense of frustration. I just knew that there had to be something of the sort - although I could wish that it was easier, something like
echo 'Welcome!'|makebig --pagesize A4 --stretch-percent 90x90|lpr

[K.-H.] Would be nice yes, but even TeX has some idea what a scientific paper should look like. One has to "switch off" lots of things to get something out of the normal scope.
[Ben] I would imagine that a knowledgeable TeXnician could write a macro that could work that way. I don't know that I want to get into TeX in that much detail (my previous forays into it left me covered in cold sweat), but I'll play around with the bits that you've suggested.
[K.-H.] A TeX Macro, even one which chooses the font size automatically is certainly possible. On the other hand this is possible with plain postscript .
Have a look at http://www.red-bean.com/~bwf/software/cdlabelgen
Thats a perl script which uses a postscript template for creating cdlabels. On the backside the postscript itself scales the fontsize down if the lines would be too long otherwise. It should be possible to go that way with lots more direct control -- but I've never learned the programming language postscript, never appealed to me as a convenient one . But it seems to be "turing complete" and I know at least one postscript file which prints a mandelbrot picture -- by calculating it. Takes ages on your stock 66MHz printer if it comes out at all.
[Ben] Thank you again!
[K.-H.] Hmm..... sorry no oneliner. At least not if you would like the comments. Will require any standard TeX installation (like tetex 0.X, 1.X), dvips should be included with tetex, gv would be nice but gs alone will do.
You need file HugeTexttestTeX.tex containing:

See attached HugeTexttestTeX.tex.txt

then run:
  > tex HugeTexttestTeX
This is TeX, Version 3.14159 (C version 6.1)
(HugeTexttestTeX.tex
Babel <v3.6h> and hyphenation patterns for american, german, ngerman,
Output written on HugeTexttestTeX.dvi (1 page, 268 bytes).
Transcript written on HugeTexttestTeX.log.

> dvips -T 11in,8.5in  HugeTexttestTeX
' TeX output 2001.11.20:1824' -> HugeTexttestTeX.ps
<tex.pro><8r.enc><texps.pro>. [1]

>  gv HugeTexttestTeX

The vertical spacing/centering caused me a little trouble there. Whats actually happening in that line starting with the "$" is: • switch to mathematical mode (seems to cancel most of the predefined spacings which we don't want fo a sign • use a vcenter box (only valid in math mode.....) to center vertically • give it "glue" to center with (\vfil) • center the line content horizontally • choose my huge font and put the Text there • ... closing the "brackets" Anyway -- nicely centered "Welcome!" on a landscape letter page. How to get rid of the pagenumber is left as an exercise, I would recommend ther TeXbook by Donal E. Knuth to get the details. One could also increase the letterspacing in TeX so it would exactly fill the line instead of adding space left and right of the text -- that's definitely beyond any M$-word I know of. QuarkExpress has a very good control of things like that though.....
$\vcenter to \vsize{\vfil\hbox to \hsize{\Myfont W e l c o m e !}\vfil}$

The spaces help in word too, but they won't stretch as far as here and adding some more spaces will be necessary and they will never add up to the exactly same linewidth.....

See attached portrait-large-text.tex.txt

this time it's not landscape so you can just use:
tex file[.tex]
dvips -t letter file[.dvi]
gv file[.ps]

One could also become very fancy and write a TeX macro which calculates the width of a given text and scales that to pagewith by increasing the fontsize.
Also in LaTeX there are nice scaling/rotating features which make more sophisticated stuff possible. Using a GUI drawing program to make little eps files which are then scaled comes to my mind.
[Mike] Of course, we'll have to compromise with ctrl-C and ctrl-Z, but emacs (for instance) already makes its own compromises in that regard. (ctrl-Z it emulates; ctrl-C it hijacks for another purpose, but provides a related command "ctrl-X ctrl-C" that does a safe exit).
[Ben] If that sounds like I'm saying that you have to earn the right to complain, you're right. Only the fishermen who bring home the fish get braggin' rights; only those who've put in the effort get to grouse about the results. Anything else is whining.
Here is something you can do to contribute instead of complaining, even if you're not a programmer. Join a list (if one exists) for a given piece of software and put your dearest wish on the "wish list" - there usually is one - and if the author likes your idea, it just might get implemented. If you find an actual bug in the software and report it in detail, most authors would be grateful.
[Mike] Ben is right. Many distributions have the README files in a standard place (/usr/share/doc/PACKAGE/* on Debian, /usr/doc/packages/PACKAGE/* on SuSE). Look at the READMEs for the offending programs and find the place to report wishlist items. It may be a mailing list or a bug tracking system. You can also see whether anybody else has also requested the same thing. If you know enough programming to provide a patch, so much the better. If you don't, do you know enough programming to provide even a few technical details? Those details make the maintainer's job easier, and may even convince them to provide the enhancement if they wouldn't otherwise.

No, I am no programmer. But I know what it takes to write a program. I have some knowledge of programming and wrote a few small programs. Also I am not really complaining, I only thought this thing wouldn't work on my computer whereas it works on other machines which are configured differently.

[Ben] That's why both Dan and I said "application-specific", right off the bat. It's not you, it's not your computer, and your friends can't do it any better.

I really would like to contribute to the development and debugging, enhancing of Linux apps. Unfortunately my wife already complains that I spent too much time in front of the screen and I don't have the time to do better because of my studies.

[Ben] As Mike and I have mentioned, there are many other ways to contribute - some of which take only a little time and effort. Sending in a detailed bug report, or adding your favorite item to a wishlist - which may just be the request that tips the scales - are all good things. Writing up and sending in an article about your battle with the different key-handling mechanisms, even though it was a frustrating and eventually bootless experience, would be another good thing.
[Mike] Yes, that would be a very good article. Would you like to write up your experiences, Jay, and contrast the keystroke handling of various Unix applications with non-Unix ones, and explain how the differences impact the usability of each system?
Let us know if you want to, so we can hold off publishing the Answer Gang thread that's been accumulating. We also can send you a tarball of the existing messages if that would help provide material for the article.

I think however that it would be a good idea to have a standard for keybindings.

[Ben] As I'd said previously, I agree - with the caveat that it should not be _a_ standard, but rather a choice of standards, plus an implementation that lets you build your own.

The people contributing to the Gnome project are discussing about it on their mailing list and I hope that if they find a good compromise that developers will accept that standard (not only for Gnome-Apps) . Thanks again for all of your answers.

[Ben] Yes, you too can participate. Complaints about how things "should be", without a significant contribution of your own, are... tacky.

If you had a clue I would be very thankful.

[Ben] We have lots of clues - for which I'm certainly very thankful. In fact, we often have to employ a clue-by-four to drive them home; there are plenty of times that several of us have found that to be necessary...

oh yes I forgot: the Linux Gazette is by far the best Linux magazine, compared to the magazines I can find in bookshops in lu. I consider downloading every issue automatically with wget from now on.

[Mike] Thanks. You can also use the FTP files; then you only have to download one file per issue (plus the base-new file).

This will also be the last time I will bother you with my word-jumping problem. I solved the problem by trying another window-manager, I now use enlightenment and the ctrl-cursor combo now works in x-emacs, lyx, mozilla, abiword and probably many other apps. You're still right that it of course is application dependent as long as you consider the window-manager as an application.

[Ben] Or even if you don't. All that a WM can do, in that regard, is either intercept keystrokes before they get to the app or not; it cannot make an application accept keystrokes that it was not programmed to accept, or make it perform any functions on those keystrokes that were not programmed in. <Checking several apps> It works for me, in several of the apps that you named, under "icewm" (my usual WM) and "twm" (the "baseline" WM - does the minimum necessary to be a WM and nothing more) - but not in a number of other apps ("xedit", "gvim", "flipbook", etc.) It seems that most widgets and toolkits, especially the newer ones, do indeed support the selection method, but, again, it's a per-application thing.
Obviously, whatever WM you were using before was intercepting your "Ctrl-cursor" keystrokes (which would prevent them from being seen by the application). Clearly, "Enlightenment" doesn't do that, at least not by default - I'm not very familiar with it, but I seem to remember a configuration panel in it which allows you to capture specific key combos.

If you like I will try different WMs and report which ones do that trick. This feels much better now

ciao

[Ben] That would be great - especially if you could dig a little bit into the configuration dialogs and see if the "intercept mechanism" can be enabled or disabled. In "icewm", for example, I can completely disable "keystroke grabbing" by tapping the scroll lock key, even though I have several "Ctrl-Alt-" combos defined in my "keys" file.
[K.-H.] That's neat. I was was just getting used to kde2 (soming along with SuSE per default) when I found out that I can switch off most key-grabs but not one specific key grab -- Ctrl-Tab. It does some win-like switching between app-windows.
[Ben] Yep; that kind of behavior (defaults that can't be disabled, tons of "pre-made decisions" of that sort that are either difficult or impossible to change, etc.), plus the fact that it is a huge resource hog, are the things that completely turned me off KDE/KDE2. I'm sure that some people love it; in my opinion, it comes closest to the feel of the MSWindows GUI, more so with every release. Me, I want a WM to do the basics, give me just a touch of pretty stuff (window ornamentation, toolbar clock, APM display, etc.) with the ability to turn it all off if I want to - and have a reasonably small memory and CPU footprint. Over the years, I've tried pretty much every major WM, and none of the others suit me quite as well. Besides, Marko Macek (the author) has been reading my mind - when I first started using "icewm", I had a few grumbles about some of the features (or the lack of them), and he's fixed every one.
[K.-H.] Now I'm an xemacs user and want that key for switching the buffers in xemacs so fvwm2 is my window manager again There I can define the grabs I want and switch off any of the default ones if necessary.
I'm aware that I could switch xemacs to a different key, but then just the idea that I actually coul find no option to switch that off at all was enough to get me "unfriendly" with kde.
[Ben] Yep. Give'em their due, though: they certainly have quite a large number of people enthralled, and a number of the "K suite" apps are rather nice.
[K.-H.] icewm's feature to toggle them is quite nice. Mybe I'll have a look at that one sometime soon.
[Ben] <rubbing hands> The subversion of the innocents continues apace. My plan for world domination will soon be complete...

##### This page edited and maintained by the Editors of Linux GazetteCopyright © 2002 Published in issue 74 of Linux Gazette January 2002
###### HTML script maintained by Heather Stern of Starshine Technical Services, http://www.starshine.org/

 Meet the Gang   1   2   3   4   5   6   7   8   9