Re: Sanest way to make emacs behave on a Solaris OS

Re: Sanest way to make emacs behave on a Solaris OS

[Harry Putnam]

Dan Espen <despen@verizon.net> writes:

> Harry Putnam <reader@newsguy.com> writes:
>
>> I hope there may be a longtime emacs on Solaris user in the house who
>> can tell me the sanest way to make emacs behave on that OS.
>>
>> I'm running a recent install of openindiana (one of the offshoot
>> solaris OS's) and its been a good long while since I've run Solaris. 
>>
>> The biggest problem is that the M (alt) key is not recognized on
>> solaris and so one must use the Esc key which is really awkward.  And
>> it seems I vaguely recall some other problems too, but right now that
>> Esc key thing is such an absolute pain I haven't got that far.
>>
>> I realize I can do some key re-assignments but I seem to remember
>> there being some drawbacks to that too.  So anyway, someone who has
>> run emacs on Solaris will maybe know a comprehensive solution I can
>> try. 
>
> Haven't had my hands on Solaris for a while, so from memory:
>
> Are you running under X or in a terminal?
>
> I'm going to assume you are running under X.
>
> Under X you want the left alt key to emit Alt_L.
> Use xev to see what the key emits.
>
> Alt_L should show up as mod1 when you display modifiers.
> Use the command:
>
> xmodmap -pm

Thanks for the input.
Running X yes, but will also use emacs in terminal mode.

xev reveals Alt is Alt_L:
  KeyRelease event, serial 133, synthetic NO, window 0x4000019,
      root 0x101, subw 0x400001a, time 64504583, (255,507), root:(952,559),
      state 0x8, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
      XLookupString gives 0 bytes: 
      XFilterEvent returns: False

xmodmap -pm reveals that Alt_L is mod1:
  shift       Shift_L (0x32),  Shift_R (0x3e)
  lock        Caps_Lock (0x42)
  control     Control_L (0x25),  Control_R (0x6d)
  mod1        Alt_L (0x40)
  mod2        Num_Lock (0x4d)
  mod3      
  mod4        Meta_L (0x73),  Meta_R (0x74),  Super_L (0x7f),  Hyper_L (0x80)
  mod5        Mode_switch (0x5d),  ISO_Level3_Shift (0x71),  ISO_Level3_Shift (0x7c)

By the way, xev reveals the following for the Esc key on emacs

  KeyRelease event, serial 133, synthetic NO, window 0x4000019,
      root 0x101, subw 0x400001a, time 64689391, (457,441), root:(1154,493),
      state 0x0, keycode 9 (keysym 0xff1b, Escape), same_screen YES,
      XLookupString gives 1 bytes: (1b) "
  FilterEvent returns: False

From your post it appears you are saying if Alt emits Alt_L and Alt_L is
mapped to mod1... I should be good to go.  Is that right?

Because it appears that Alt does emit Alt_L and Alt_l is mapped to mod1
but it is not recognized as M in emacs.. as in such commands as 
M-x whatever RET

What I get when I press the Alt key in emacs is "A-x is not defined." So
have to press Esc x to run M-x. 

I mentioned it is an antique version of emacs:
  GNU Emacs 23.1.1 (x86_64-pc-solaris2.11, X toolkit) of 2012-09-23 on
 oidev0
If that makes a difference.

-------        ---------       ---=---       ---------      -------- 

Gack... I just noticed that the Windows key (Meta_L acts like M (alt)
key to emacs.

xev shows this for Windows key:

  KeyRelease event, serial 134, synthetic NO, window 0x4000019,
      root 0x101, subw 0x400001a, time 66248204, (504,302), root:(1197,383),
      state 0x40, keycode 115 (keysym 0xffe7, Meta_L), same_screen YES,
      XLookupString gives 0 bytes: 
      XFilterEvent returns: False

xmodmap -pm shows it as Mod4
  xmodmap:  up to 4 keys per modifier, (keycodes in parentheses):

  shift       Shift_L (0x32),  Shift_R (0x3e)
  lock        Caps_Lock (0x42)
  control     Control_L (0x25),  Control_R (0x6d)
  mod1        Alt_L (0x40)
  mod2        Num_Lock (0x4d)
  mod3      
  mod4        Meta_L (0x73),  Meta_R (0x74),  Super_L (0x7f),  Hyper_L (0x80)
  mod5        Mode_switch (0x5d),  ISO_Level3_Shift (0x71),  ISO_Level3_Shift (0x7c)

At least that key is way better than the escape key.

Sanest way to make emacs behave on a Solaris OS

[Harry Putnam]

I hope there may be a longtime emacs on Solaris user in the house who
can tell me the sanest way to make emacs behave on that OS.

I'm running a recent install of openindiana (one of the offshoot
solaris OS's) and its been a good long while since I've run Solaris. 

The biggest problem is that the M (alt) key is not recognized on
solaris and so one must use the Esc key which is really awkward.  And
it seems I vaguely recall some other problems too, but right now that
Esc key thing is such an absolute pain I haven't got that far.

I realize I can do some key re-assignments but I seem to remember
there being some drawbacks to that too.  So anyway, someone who has
run emacs on Solaris will maybe know a comprehensive solution I can
try. 

Re: Sanest way to make emacs behave on a Solaris OS

[Dan Espen]

Harry Putnam <reader@newsguy.com> writes:

> I hope there may be a longtime emacs on Solaris user in the house who
> can tell me the sanest way to make emacs behave on that OS.
>
> I'm running a recent install of openindiana (one of the offshoot
> solaris OS's) and its been a good long while since I've run Solaris. 
>
> The biggest problem is that the M (alt) key is not recognized on
> solaris and so one must use the Esc key which is really awkward.  And
> it seems I vaguely recall some other problems too, but right now that
> Esc key thing is such an absolute pain I haven't got that far.
>
> I realize I can do some key re-assignments but I seem to remember
> there being some drawbacks to that too.  So anyway, someone who has
> run emacs on Solaris will maybe know a comprehensive solution I can
> try. 

Haven't had my hands on Solaris for a while, so from memory:

Are you running under X or in a terminal?

I'm going to assume you are running under X.

Under X you want the left alt key to emit Alt_L.
Use xev to see what the key emits.

Alt_L should show up as mod1 when you display modifiers.
Use the command:

xmodmap -pm


-- 
Dan Espen

Re: Sanest way to make emacs behave on a Solaris OS

[Dan Espen]

Harry Putnam <reader@newsguy.com> writes:

> Dan Espen <despen@verizon.net> writes:
>
>> Harry Putnam <reader@newsguy.com> writes:
>>
>>> I hope there may be a longtime emacs on Solaris user in the house who
>>> can tell me the sanest way to make emacs behave on that OS.
>>>
>>> I'm running a recent install of openindiana (one of the offshoot
>>> solaris OS's) and its been a good long while since I've run Solaris. 
>>>
>>> The biggest problem is that the M (alt) key is not recognized on
>>> solaris and so one must use the Esc key which is really awkward.  And
>>> it seems I vaguely recall some other problems too, but right now that
>>> Esc key thing is such an absolute pain I haven't got that far.
>>>
>>> I realize I can do some key re-assignments but I seem to remember
>>> there being some drawbacks to that too.  So anyway, someone who has
>>> run emacs on Solaris will maybe know a comprehensive solution I can
>>> try. 
>>
>> Haven't had my hands on Solaris for a while, so from memory:
>>
>> Are you running under X or in a terminal?
>>
>> I'm going to assume you are running under X.
>>
>> Under X you want the left alt key to emit Alt_L.
>> Use xev to see what the key emits.
>>
>> Alt_L should show up as mod1 when you display modifiers.
>> Use the command:
>>
>> xmodmap -pm
>
> Thanks for the input.
> Running X yes, but will also use emacs in terminal mode.
>
> xev reveals Alt is Alt_L:
>   KeyRelease event, serial 133, synthetic NO, window 0x4000019,
>       root 0x101, subw 0x400001a, time 64504583, (255,507), root:(952,559),
>       state 0x8, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
>       XLookupString gives 0 bytes: 
>       XFilterEvent returns: False
>
> xmodmap -pm reveals that Alt_L is mod1:
>   shift       Shift_L (0x32),  Shift_R (0x3e)
>   lock        Caps_Lock (0x42)
>   control     Control_L (0x25),  Control_R (0x6d)
>   mod1        Alt_L (0x40)
>   mod2        Num_Lock (0x4d)
>   mod3      
>   mod4        Meta_L (0x73),  Meta_R (0x74),  Super_L (0x7f),  Hyper_L (0x80)
>   mod5        Mode_switch (0x5d),  ISO_Level3_Shift (0x71),  ISO_Level3_Shift (0x7c)
>
> By the way, xev reveals the following for the Esc key on emacs
>
>   KeyRelease event, serial 133, synthetic NO, window 0x4000019,
>       root 0x101, subw 0x400001a, time 64689391, (457,441), root:(1154,493),
>       state 0x0, keycode 9 (keysym 0xff1b, Escape), same_screen YES,
>       XLookupString gives 1 bytes: (1b) "
>   FilterEvent returns: False
>
>>From your post it appears you are saying if Alt emits Alt_L and Alt_L is
> mapped to mod1... I should be good to go.  Is that right?
>
> Because it appears that Alt does emit Alt_L and Alt_l is mapped to mod1
> but it is not recognized as M in emacs.. as in such commands as 
> M-x whatever RET
>
> What I get when I press the Alt key in emacs is "A-x is not defined." So
> have to press Esc x to run M-x. 
>
> I mentioned it is an antique version of emacs:
>   GNU Emacs 23.1.1 (x86_64-pc-solaris2.11, X toolkit) of 2012-09-23 on
>  oidev0
> If that makes a difference.
>
> -------        ---------       ---=---       ---------      -------- 
>
> Gack... I just noticed that the Windows key (Meta_L acts like M (alt)
> key to emacs.
>
> xev shows this for Windows key:
>
>   KeyRelease event, serial 134, synthetic NO, window 0x4000019,
>       root 0x101, subw 0x400001a, time 66248204, (504,302), root:(1197,383),
>       state 0x40, keycode 115 (keysym 0xffe7, Meta_L), same_screen YES,
>       XLookupString gives 0 bytes: 
>       XFilterEvent returns: False
>
> xmodmap -pm shows it as Mod4
>   xmodmap:  up to 4 keys per modifier, (keycodes in parentheses):
>
>   shift       Shift_L (0x32),  Shift_R (0x3e)
>   lock        Caps_Lock (0x42)
>   control     Control_L (0x25),  Control_R (0x6d)
>   mod1        Alt_L (0x40)
>   mod2        Num_Lock (0x4d)
>   mod3      
>   mod4        Meta_L (0x73),  Meta_R (0x74),  Super_L (0x7f),  Hyper_L (0x80)
>   mod5        Mode_switch (0x5d),  ISO_Level3_Shift (0x71),  ISO_Level3_Shift (0x7c)
>
> At least that key is way better than the escape key.

Cool, I guess problem solved.
Using xmodmap, you can switch keys around to suit the way you want to
use them.  If I remember Solaris right, they'd switch keys around every
so often driving me nuts.  (Not that Linux hasn't followed the same path.)

-- 
Dan Espen

Re: Sanest way to make emacs behave on a Solaris OS

[Emanuel Berg]

Harry Putnam <reader@newsguy.com> writes:

> I'm running a recent install of openindiana (one of the offshoot
> solaris OS's) and its been a good long while since I've run
> Solaris.

I use Debian, but my school uses Solaris/SunOS, so I've used Emacs
there, and ssh'd to it a lot, and I never had any problems with
Emacs not behaving as it did with my Debian. There shouldn't be
any problems at all.

> The biggest problem is that the M (alt) key is not recognized on
> solaris and so one must use the Esc key which is really awkward.
> And it seems I vaguely recall some other problems too, but right
> now that Esc key thing is such an absolute pain I haven't got
> that far.

I just tried that, and it works for me. Are you running Emacs from
a terminal emulator? In that case, it might be the emulator isn't
tuned to that key. I'm not using Emacs in X, but once I did, and I
recall that some stuff in .Xresources got the Meta key working:

xterm*metaSendsEscape: true
URxvt*altSendsEscape: true

If you use xterm or urxvt, try that. (In .xinitrc, put

xrdb ~/.Xresources

first thing.)

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Sanest way to make emacs behave on a Solaris OS

[Harry Putnam]

Emanuel Berg <embe8573@student.uu.se> writes:

[...]

> I just tried that, and it works for me. Are you running Emacs from
> a terminal emulator?

I'm running emacs in X.

> . . . . . . . . In that case, it might be the emulator isn't
> tuned to that key. I'm not using Emacs in X, but once I did, and I
> recall that some stuff in .Xresources got the Meta key working:
>
> xterm*metaSendsEscape: true
> URxvt*altSendsEscape: true
>
> If you use xterm or urxvt, try that. (In .xinitrc, put
>
> xrdb ~/.Xresources
>
> first thing.)

Thanks.. I'll try that.

Re: Sanest way to make emacs behave on a Solaris OS

[Emanuel Berg]

Harry Putnam <reader@newsguy.com> writes:

>> I just tried that, and it works for me. Are you running Emacs
>> from a terminal emulator?
>
> I'm running emacs in X.

Yeah, but you can run it in a GUI window, and then a titlebar,
menus, etc. are provided by your window manager (WM). The window
manager is not X, it is yet another layer on top of it. In GNOME,
the WM is often Metacity. I sometimes use Openbox. But there are
many. If you type 'emacs', even in a terminal, nowadays this is
what you get.

If the Meta key doesn't work in the above case, I have no idea
why.

But, if you type 'emacs -nw' (for "no window", likely) Emacs runs
within the terminal. You don't even need a WM to do that. It is
only in this case my two suggestions might work and, again, only
for xterm and urxvt. (In GNOME, at least when I used it, the
default terminal was "Gnome Terminal", which is slower.)

I don't know how portable all the stuff I mention is, but if
there's X, anything with an "x" in it should work, as should
.Xresources and .xinit.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Sanest way to make emacs behave on a Solaris OS

[Emanuel Berg]

Emanuel Berg <embe8573@student.uu.se> writes:

> .xinit

Should be: .xinitrc

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Sanest way to make emacs behave on a Solaris OS

[Harry Putnam]

Emanuel Berg <embe8573@student.uu.se> writes:

> Harry Putnam <reader@newsguy.com> writes:
>
>>> I just tried that, and it works for me. Are you running Emacs
>>> from a terminal emulator?
>>
>> I'm running emacs in X.
>
> Yeah, but you can run it in a GUI window, and then a titlebar,
> menus, etc. are provided by your window manager (WM). The window
> manager is not X, it is yet another layer on top of it. In GNOME,
> the WM is often Metacity. I sometimes use Openbox. But there are
> many. If you type 'emacs', even in a terminal, nowadays this is
> what you get.
>
> If the Meta key doesn't work in the above case, I have no idea
> why.

Sorry, the emulator in use when I run emacs in X is xterm-261

> But, if you type 'emacs -nw' (for "no window", likely) Emacs runs
> within the terminal. You don't even need a WM to do that. It is
> only in this case my two suggestions might work and, again, only
> for xterm and urxvt. (In GNOME, at least when I used it, the
> default terminal was "Gnome Terminal", which is slower.)

I only ever use the various WM 'terminals' until I get xterm setup the
way I like it.... so that is not involved.

I always use xterm since it has more options that I know and
understand. Far as I know, the rest of the wannabee wm terminals are
all lessor copies of xterm.
(Many thanks to Thomas Dickey's long standing and expert efforts)

> I don't know how portable all the stuff I mention is, but if
> there's X, anything with an "x" in it should work, as should
> .Xresources and .xinit.

To be clear... the Meta key has worked as ALT does on linux right from
the start.... I just caught it after my OP on this subject, and posted
that I'd 'discovered' a sort of solution.

Its still kind of a pita just because of long habit on the ALT key in
emacs. But much handier than ESC

I still haven't tried your suggestion in .Xdefaults... but will soon.

If I'm not mistaken gnome references .xresources... so I keep
.xresources symlinked to .Xdefaults and have for yrs.  

Just for the information, I'm working the solaris (openindiana) only
intermittently as a vm guest on win7 64bit.  So trying things may
happen rather slowly.

Re: Sanest way to make emacs behave on a Solaris OS

[Harry Putnam]

Emanuel Berg <embe8573@student.uu.se> writes:

[...]

Harry wrote:
>> The biggest problem is that the M (alt) key is not recognized on
>> solaris and so one must use the Esc key which is really awkward.
>> And it seems I vaguely recall some other problems too, but right
>> now that Esc key thing is such an absolute pain I haven't got
>> that far.
>
Emanuel replied:
> I just tried that, and it works for me. Are you running Emacs from
> a terminal emulator? In that case, it might be the emulator isn't
> tuned to that key. I'm not using Emacs in X, but once I did, and I
> recall that some stuff in .Xresources got the Meta key working:

You just tried what?  Do you mean on your solaris in X the Alt key
works as M in emacs, same as linux?

If that is what you are seeing, then mine is different... here the alt
key is not recognized in emacs... only the Meta (windows logo) key or
the ESC key are seen by emacs as M.

But again I have not yet tried your suggestions.

To be clear:
With no attempts at remapping or using .Xdefaults, 'alt' key is not
recognized by emacs.  Meta key (windows logo key) and ESC are
recognized by emacs as M.

Re: Sanest way to make emacs behave on a Solaris OS

[Emanuel Berg]

Harry Putnam <reader@newsguy.com> writes:

>> Harry Putnam <reader@newsguy.com> writes:
>
> Sorry, the emulator in use when I run emacs in X is xterm-261

No, that would be what I would have done, too, if I used X for
Emacs. Is 261 the version number? I have XTerm(278) (on 'xterm
-version') on Debian and on Solaris/SunOS ... hm, that option
doesn't seem exist. Investigating.

> Far as I know, the rest of the wannabee ... terminals are all
> lessor copies of xterm.

I suspect that the GNOME terminal is just a terminal like any
other, with some modifications to make it fit with the GNOME
project. The have a habit of doing that, and (without any insight
other the intuition) to me, it looks like a waste of time.

For example, there is gnome-screenshot. But there is also xwd and
scrot, that do the same. So probably they did gnome-screenshot
just to be able to show a setup window that would be consistent
with the "look and feel" of everything else, when instead, focus
should always be on the purpose of the application (capturing a
screenshot).

Anyway, back to xterm: yes, there is the "lesser copies" rxvt
(reduced X VT: "reduced" as in memory usage), and urxvt (rxvt, but
with Unicode support).

> To be clear... the Meta key has worked as ALT does on linux
> right from the start...

What do you mean, "as ALT does on Linux"?

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Sanest way to make emacs behave on a Solaris OS

[Emanuel Berg]

Harry Putnam <reader@newsguy.com> writes:

> You just tried what?  Do you mean on your solaris in X the Alt
> key works as M in emacs, same as linux?

When I ssh from a Debian Linux VT (a tty) and then run Emacs on
the remote Solaris/SunOS, *yes*.

When I ssh (still, from Linux) with -Y to be able to use X, and
then run xterm, then *no*, the ALT key does not work as
Meta/Escape, not in xterm, and not in Emacs.

Without ssh: I will try this in a couple of minutes. Stay sharp.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Sanest way to make emacs behave on a Solaris OS

[Emanuel Berg]

Harry Putnam <reader@newsguy.com> writes:

> Do you mean on your solaris in X the Alt key works as M in
> emacs, same as linux?

Yes, now I got it to work in X as well, but not with xterm, but
with urxvt.

Put:

URxvt*altSendsEscape: true

in ~/.Xresources and then, 'xrdb ~/.Xresources' in an X terminal.

Note that I still ssh'd (with -Y) from a Linux X terminal (namely,
incidentally, also urxvt).

This is all a bit confusing. I'm trying the real deal, now.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Sanest way to make emacs behave on a Solaris OS

[Emanuel Berg]

Emanuel Berg <embe8573@student.uu.se> writes:

> Without ssh: I will try this in a couple of minutes.

Without Linux & ssh, the ALT key *didn't* work with xterm, and not
for urxvt (regardless, it seemed, of .Xresources & xrdb), and
*not* for a GUI Emacs, but it *did* work for 'emacs -nw' in the
*default Solaris terminal*, in which the ALT key worked as Meta as
well (that is, in the terminal itself, for cursor movements,
etc.).

I don't know what terminal that is, because I didn't invoke it
from the shell, but by clicking on a black squared icon (a
terminal), which had the caption "Terminal". I didn't spend a
fraction of the time with Solaris that I did with Debian, so I
think this is a far as I can help you. I'm (not) on SunOS 5.10, if
that helps.

It worked in the following cases:
- ssh from a Linux VT (tty), run Emacs
- 'ssh -Y' from Linux X & urxvt, then use 'emacs -nw' or the GUI
  Emacs (just 'emacs'), both works (the GUI Emacs also works from
  xterm with this method, as it doesn't matter from where it is
  invoked)
- without ssh, with the default terminal *and* 'emacs -nw'

I take it you don't want to ssh from Linux, so perhaps you should
drop xterm, and use the default terminal? It seems to be good
enough.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Sanest way to make emacs behave on a Solaris OS

[Emanuel Berg]

Emanuel Berg <embe8573@student.uu.se> writes:

> URxvt*altSendsEscape: true
>
> in ~/.Xresources and then, 'xrdb ~/.Xresources' in an X
> terminal.

This method (for Linux, Meta, and xterm) is also described here:

http://unix.stackexchange.com/q/39345/13136

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Sanest way to make emacs behave on a Solaris OS

[Bob Proulx]

I wasn't following this thread until now.  Although there are lots of
good suggestions this message had the most content that I wanted to
comment upon.

Harry Putnam wrote:
> Sorry, the emulator in use when I run emacs in X is xterm-261

I am also using emacs from within xterm-261.

> I always use xterm since it has more options that I know and
> understand. Far as I know, the rest of the wannabee wm terminals are
> all lessor copies of xterm.
> (Many thanks to Thomas Dickey's long standing and expert efforts)

Agreed.

> To be clear... the Meta key has worked as ALT does on linux right from
> the start.... I just caught it after my OP on this subject, and posted
> that I'd 'discovered' a sort of solution.
> 
> Its still kind of a pita just because of long habit on the ALT key in
> emacs. But much handier than ESC

In your Xterm, hold down control and left mouse button.  A menu should
appear.  Keep holding control and left mouse.  Drag down to "Meta
Sends Escape" and tick it so that it now has a checkmark.  As
previously suggested by others that is the same as the following X
resource.

  XTerm*metaSendsEscape:true

Since you say that Alt has the mod1 modifier making it a Meta key I
believe this should be enough.

> I still haven't tried your suggestion in .Xdefaults... but will soon.

Use of .Xdefaults is rather superseded by the .Xresources file.  The
difference between the two is subtle.  But .Xresources tends to be
preferred because of the way that it is applied.  The .Xresources is
applied to the $DISPLAY through xrdb.  The .Xdefaults is applied
through the presence in the $HOME directory, but only if the xrdb is
empty.  So once you have a .Xresources the .Xdefaults is no longer
used.

> If I'm not mistaken gnome references .xresources... so I keep
> .xresources symlinked to .Xdefaults and have for yrs.  

I assume you mean .Xresources with an X rather than .xresources.

> Just for the information, I'm working the solaris (openindiana) only
> intermittently as a vm guest on win7 64bit.  So trying things may
> happen rather slowly.

I am not using Solaris but in the past have been a long time user of
HP-UX.  The environment of yours as a VM under MS-Windows may cause
interactions with Windows.  Things that might "just work" natively
might have interactions with the host Windows system.  Beware.

Bob

Re: Sanest way to make emacs behave on a Solaris OS

[Emanuel Berg]

Bob Proulx <bob@proulx.com> writes:

> Use of .Xdefaults is rather superseded by the .Xresources file.
> The difference between the two is subtle.  But .Xresources tends
> to be preferred because of the way that it is applied.  The
> .Xresources is applied to the $DISPLAY through xrdb.  The
> .Xdefaults is applied through the presence in the $HOME
> directory, but only if the xrdb is empty.  So once you have a
> .Xresources the .Xdefaults is no longer used.

That's interesting. On my school's Solaris/SunOS, in my home
directory, there wasn't any .Xresources to begin with, but there
was an .Xdefaults. It would have been interesting to examine the
the contents of that file, but I was so eager to try the
.Xresources solution that I just deleted the .Xdefaults, to be
sure it didn't influence in any way. And now, you're saying that
was unnecessary, because it is only applied if there isn't a
populated xrdb/.Xresources. You live, you learn.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Sanest way to make emacs behave on a Solaris OS

[Harry Putnam]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Perhaps you should include an example how to do that? xmodmap can
>> be a bit of a jungle.
>
> If you show me the output of "xmodmap" I can tell you what incantation
> to try.

xmodmap:  up to 4 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x32),  Shift_R (0x3e)
lock        Caps_Lock (0x42)
control     Control_L (0x25),  Control_R (0x6d)
mod1        Alt_L (0x40)
mod2        Num_Lock (0x4d)
mod3      
mod4        Meta_L (0x73),  Meta_R (0x74),  Super_L (0x7f),  Hyper_L (0x80)
mod5        Mode_switch (0x5d),  ISO_Level3_Shift (0x71),  ISO_Level3_Shift (0x7c)

Re: Sanest way to make emacs behave on a Solaris OS

[Harry Putnam]

Bob Proulx <bob@proulx.com> writes:

[...]

First off, sorry to both you and Emanuel.  I admit I'm not your basic
quick study... but really asleep at the switch on this. I've allowed
you to put in time and effort and then dropped my end... for that I am
truly sorry.
 
> You are NOT doing what I am suggesting.  As others mentioned if you
> are starting emacs as a graphical application and not a console one
> running in the xterm then Emacs will handle the keyboard itself and
> then it has nothing to do with Xterm at all.  The Meta Sends Escape
> setting only applies to XTerm.  It won't apply to emacs in the
> graphical client mode.  Those are two completely separate and distinct
> cases with different configurations.  Confusing those two cases makes
> talking about it very difficult.

Yes, difficult... so doing my best to clarify now.

> Which do you want to do?  Do you want to run Emacs as a graphical
> client?  Do you want to run Emacs as a text console program within an
> XTerm?  Please pick one or the other and then work through it to
> completion before trying the opposite way.

Actually I want to do both as stated in OP.  But was pinheadedly
focused on the GUI response. (Which will often be my main usage)

> Assuming that you want Emacs as a text client within an Xterm then
> please verify that you have started emacs from the xterm window using
> the 'emacs -nw' with the -nw option.  This should be the simpler case
> to get going.  Then can do the graphical one afterward.  If emacs is
> compiled without X the option is still accepted and therefore never
> hurts to use -nw when debugging the text flavor.

OK, since I DO want both.  But before using the .Xresources approach
I'll report on the the menu technique:

It does cause the key with windows logo to work as M in emacs to bring
up the 'M-x' emacs prompt,

[...]

>> Into my ~/.Xresources file.... but Doggone it, I don't remember how to
>> reread .Xresources so that any changes become effective.... I'll have
>> to restart X  and see how it goes.
>
>   xrdb -m ~/.Xresources
>
> The -m merges.  The -l loads.  I selected merging because you may have
> sevaral files all merged together so this would only change what you
> changed.  Using -l would empty first and then only load that file so
> if you had several files, perhaps a /etc/X11/something, then that
> other would be lost.  But I will use -l when I want only what is in
> that file, nothing more and nothing less, and want to avoid anything
> else that might have been set elsewhere.  Somewhat like the emacs -Q
> of things.

OK thanks for the solid hand holding.  I don't think there will be any
merging unless setup by the install... but using xrdb -m as you
suggested just in case.

It worked as you expected... the Windows Logo key now works like M in
emacs. 

But here's the sort of complicated part.
I want the Alt key to do that.  Having the Meta key work as the alt
key is MUCH MUCH better than stretching for the escape key.  So this
is definitely a working solution.

Now I have an easyish time of it with both Gui and text mode emacs.
Thank you sir... and thanks for being a patient and thorough coach.

Re: Sanest way to make emacs behave on a Solaris OS

[Harry Putnam]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> shift       Shift_L (0x32),  Shift_R (0x3e)
>> lock        Caps_Lock (0x42)
>> control     Control_L (0x25),  Control_R (0x6d)
>> mod1        Alt_L (0x40)
>> mod2        Num_Lock (0x4d)
>> mod3      
>> mod4        Meta_L (0x73),  Meta_R (0x74),  Super_L (0x7f),  Hyper_L (0x80)
>> mod5 Mode_switch (0x5d), ISO_Level3_Shift (0x71), ISO_Level3_Shift
>> (0x7c)
>
> There you go: Alt on `mod1' and Meta on `mod4'.
> So, a possible solution:
>
>    xmodmap -e 'remove mod4 = Meta_L Meta_R'
>    xmodmap -e 'add mod1 = Meta_L Meta_R'
>
> so both your Meta and Alt keys will behave as one and the same modifier
> (probably called "Alt" in most programs and "Meta" in Emacs).
>

Haaa! yup that works..

You are a patient man sir.  Thank you.

Re: Sanest way to make emacs behave on a Solaris OS

[Harry Putnam]

Bob Proulx <bob@proulx.com> writes:

[...]

>> To be clear... the Meta key has worked as ALT does on linux right from
>> the start.... I just caught it after my OP on this subject, and posted
>> that I'd 'discovered' a sort of solution.
>> 
>> Its still kind of a pita just because of long habit on the ALT key in
>> emacs. But much handier than ESC
>
> In your Xterm, hold down control and left mouse button.  A menu should
> appear.  Keep holding control and left mouse.  Drag down to "Meta
> Sends Escape" and tick it so that it now has a checkmark.  As
> previously suggested by others that is the same as the following X
> resource.
>
>   XTerm*metaSendsEscape:true
>
> Since you say that Alt has the mod1 modifier making it a Meta key I
> believe this should be enough.

[...]

Sounds like you are saying that having ticked that item, if I start
emacs in that same command xterm... I should get behavior where the
ALT key just to the right of the key with windows logo (on many
keyboards) Or put another way starting from left with left most key
being 1, it is the 3rd key going to the right... just before the
'space bar'.

OK, that key DOES NOT work in emacs here.  If I press Alt-x (as is how
it works under linux), then emacs responds with 'A-x is not defined'

-------        ---------       ---=---       ---------      -------- 

But, I'm not sure I'm doing what you suggest... once I tick that item,
then at the same xterm command line, typing `emacs <enter>' starts
emacs (In X) in its own new window.

I guess you are saying that in that new emacs window... the ALT key
(same as described above) works in emacs so that pressing Alt-x
displays M-x: prompt in emacs.  If that is what you are saying ...then
That DOES NOT happen here.

Not sure where that leaves things but now going to insert:
   XTerm*metaSendsEscape:true

Into my ~/.Xresources file.... but Doggone it, I don't remember how to
reread .Xresources so that any changes become effective.... I'll have
to restart X  and see how it goes.

Re: Sanest way to make emacs behave on a Solaris OS

[Stefan Monnier]

> OK, that key DOES NOT work in emacs here.  If I press Alt-x (as is how
> it works under linux), then emacs responds with 'A-x is not defined'

IIUC you got this message with Emacs running in GUI mode (not within an
xterm).  Many/most systems don't have a Meta key, so Emacs by default
looks for a Meta key and if it can't find one, it falls back on using
the Alt key as a Meta key.  So the above message indicates that Emacs
did find a Meta key, which is why it treats the Alt key as an actual Alt
key rather than as a Meta key.

So, take a look at the output of "xmodmap".  It probably includes
entries both for Meta and for Alt keys.  Either remap your Alt keys to
be Meta keys, or remap your Meta keys to something else (so that Emacs
will use the Alt keys for its Meta modifier).


        Stefan

Re: Sanest way to make emacs behave on a Solaris OS

[Emanuel Berg]

Harry Putnam <reader@newsguy.com> writes:

> But, I'm not sure I'm doing what you suggest... once I tick that
> item, then at the same xterm command line, typing `emacs
> <enter>' starts emacs (In X) in its own new window.

You need to start Emacs with 'emacs -nw' (for
--no-window-system). They changed the default behaviour a couple
of versions back, so now you get them same from typing 'emacs' in
a terminal, as clicking an Emacs icon in your GNOME, KDE, or
whatever desktop suite: and what you get is a *new* windows with
the Emacs with the WM menus, the buttons, etc.

(Actually, I have already said that, or a variety thereof, several
times in this thread.)

> Not sure where that leaves things but now going to insert:
>    XTerm*metaSendsEscape:true
>
> Into my ~/.Xresources file.... but Doggone it, I don't remember
> how to reread .Xresources so that any changes become
> effective.... I'll have to restart X and see how it goes.

It might not help restarting X. You need 'xrdb ~/.Xresources'. To
automatize things, you can put that in .xinitrc - this I've *also*
mentioned, *and* it is in the link I posted. Are you paying
attention?

That said, I didn't get it to work in xterm in Solaris. In Linux,
the above formula did it.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Sanest way to make emacs behave on a Solaris OS

[Emanuel Berg]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> So, take a look at the output of "xmodmap".  It probably
> includes entries both for Meta and for Alt keys.  Either remap
> your Alt keys to be Meta keys, or remap your Meta keys to
> something else (so that Emacs will use the Alt keys for its Meta
> modifier).

Perhaps you should include an example how to do that? xmodmap can
be a bit of a jungle.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Sanest way to make emacs behave on a Solaris OS

[Stefan Monnier]

> Perhaps you should include an example how to do that? xmodmap can
> be a bit of a jungle.

If you show me the output of "xmodmap" I can tell you what incantation
to try.


        Stefan

Re: Sanest way to make emacs behave on a Solaris OS

[Dan Espen]

Emanuel Berg <embe8573@student.uu.se> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> So, take a look at the output of "xmodmap".  It probably
>> includes entries both for Meta and for Alt keys.  Either remap
>> your Alt keys to be Meta keys, or remap your Meta keys to
>> something else (so that Emacs will use the Alt keys for its Meta
>> modifier).
>
> Perhaps you should include an example how to do that? xmodmap can
> be a bit of a jungle.

xmodmap -pm

shows just the modifier keys:

> xmodmap -pm
xmodmap:  up to 4 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x32),  Shift_R (0x3e)
lock      
control     Control_L (0x25),  Control_L (0x42),  Control_R (0x69)
mod1        Alt_L (0x40),  Alt_R (0x6c),  Meta_L (0xcd)
mod2        Num_Lock (0x4d)
mod3      
mod4        Super_L (0x85),  Super_R (0x86),  Super_L (0xce),  Hyper_L (0xcf)
mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)


This working example for fixing Caps Lock should give you an idea
how to mess with modifiers:

remove Lock = Caps_Lock
keysym Caps_Lock = Control_L
add Control = Control_L


-- 
Dan Espen

Re: Sanest way to make emacs behave on a Solaris OS

[Eli Zaretskii]

> From: Emanuel Berg <embe8573@student.uu.se>
> Date: Mon, 05 Aug 2013 09:58:26 +0200
> 
> You need to start Emacs with 'emacs -nw' (for
> --no-window-system). They changed the default behaviour a couple
> of versions back, so now you get them same from typing 'emacs' in
> a terminal, as clicking an Emacs icon in your GNOME, KDE, or
> whatever desktop suite: and what you get is a *new* windows with
> the Emacs with the WM menus, the buttons, etc.

There was never such a change, not recently anyway.  Emacs always
behaved like what you see now, since it got the GUI frame support on
X.  Perhaps you were used to run an Emacs that was built without X
support, or something else that didn't allow Emacs to create a GUI
frame.

Re: Sanest way to make emacs behave on a Solaris OS

[Dan Espen]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Emanuel Berg <embe8573@student.uu.se>
>> Date: Mon, 05 Aug 2013 09:58:26 +0200
>> 
>> You need to start Emacs with 'emacs -nw' (for
>> --no-window-system). They changed the default behaviour a couple
>> of versions back, so now you get them same from typing 'emacs' in
>> a terminal, as clicking an Emacs icon in your GNOME, KDE, or
>> whatever desktop suite: and what you get is a *new* windows with
>> the Emacs with the WM menus, the buttons, etc.
>
> There was never such a change, not recently anyway.  Emacs always
> behaved like what you see now, since it got the GUI frame support on
> X.  Perhaps you were used to run an Emacs that was built without X
> support, or something else that didn't allow Emacs to create a GUI
> frame.

X enabled Emacs seem to behave like any other tty/x enabled application.
If $DISPLAY is set, you get the GUI.

Type:

DISPLAY=  emacs

and you get text mode.

-- 
Dan Espen

Re: Sanest way to make emacs behave on a Solaris OS

[Eli Zaretskii]

> From: Dan Espen <despen@verizon.net>
> Date: Mon, 05 Aug 2013 11:32:04 -0400
> 
> > There was never such a change, not recently anyway.  Emacs always
> > behaved like what you see now, since it got the GUI frame support on
> > X.  Perhaps you were used to run an Emacs that was built without X
> > support, or something else that didn't allow Emacs to create a GUI
> > frame.
> 
> X enabled Emacs seem to behave like any other tty/x enabled application.
> If $DISPLAY is set, you get the GUI.
> 
> Type:
> 
> DISPLAY=  emacs
> 
> and you get text mode.

Of course, that's what I meant by "something else".  It's rather rare
to see a working X system where DISPLAY is not set correctly.

Re: Sanest way to make emacs behave on a Solaris OS

[Emanuel Berg]

Eli Zaretskii <eliz@gnu.org> writes:

>> You need to start Emacs with 'emacs -nw' (for
>> --no-window-system). They changed the default behaviour a
>> couple of versions back, so now you get them same from typing
>> 'emacs' in a terminal, as clicking an Emacs icon in your GNOME,
>> KDE, or whatever desktop suite: and what you get is a *new*
>> windows with the Emacs with the WM menus, the buttons, etc.
>
> There was never such a change, not recently anyway.

There *was* such a change, I know this, because I read it in a
recent book on Linux and shell programming - a big, white book
with all the tools alphabetically, and with a big section on Emacs
(and one on vim - no bias!). I don't have that book here, and I
don't remember the name of the sole writer (cool guy), but I'll
check it out and get back to you. It doesn't really matter, I
guess, but I like this kind of facts. And perhaps you do, as well.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Sanest way to make emacs behave on a Solaris OS

[Emanuel Berg]

Dan Espen <despen@verizon.net> writes:

> X enabled Emacs seem to behave like any other tty/x enabled
> application.

What do you mean by "tty/x enabled"?

That it behaves differently in a tty and in X?

In X, my display is ":0", in a tty, it isn't set.

With (in a tty)

emacs -d ":0" 2> errors.txt

everything is as predicted - I get the GUI Emacs in X (in the
background, when I switch to X, I see it). Nevertheless, that
command outputs to stderr:

(emacs:3496): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
GConf Error: No D-BUS daemon running

(emacs:3496): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
Unable to autolaunch a dbus-daemon without a $DISPLAY for X11

You have any idea what that is?

Interestingly, again in a tty,

DISPLAY=":0" emacs

did *not* produce those error messages, and the GUI Emacs appeared
just the same in X.

> If $DISPLAY is set, you get the GUI.
>
> Type:
>
> DISPLAY=  emacs
>
> and you get text mode.

Yes, but isn't it better to use -nw - or, did you say that to show
the mechanics, rather than usage?

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Sanest way to make emacs behave on a Solaris OS

[Eli Zaretskii]

> From: Emanuel Berg <embe8573@student.uu.se>
> Date: Mon, 05 Aug 2013 19:51:32 +0200
> 
> > There was never such a change, not recently anyway.
> 
> There *was* such a change, I know this, because I read it in a
> recent book on Linux and shell programming - a big, white book
> with all the tools alphabetically, and with a big section on Emacs
> (and one on vim - no bias!).

Well, if there is such a book, and if it says what you say it says,
then that book is simply wrong.  Emacs behaves like it does today for
a very long time.  "A couple of versions" is definitely wrong.  If
you'd say it was some time when Emacs 19.x was being released, I could
believe you.

Re: Sanest way to make emacs behave on a Solaris OS

[Emanuel Berg]

Eli Zaretskii <eliz@gnu.org> writes:

>> There *was* such a change, I know this, because I read it in a
>> recent book on Linux and shell programming - a big, white book
>> with all the tools alphabetically, and with a big section on
>> Emacs (and one on vim - no bias!).
>
> Well, if there is such a book, and if it says what you say it
> says, then that book is simply wrong.  Emacs behaves like it
> does today for a very long time.  "A couple of versions" is
> definitely wrong.  If you'd say it was some time when Emacs 19.x
> was being released, I could believe you.

Just be patient, I'll get the exact quote.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Sanest way to make emacs behave on a Solaris OS

[Dan Espen]

Emanuel Berg <embe8573@student.uu.se> writes:

> Dan Espen <despen@verizon.net> writes:
>
>> X enabled Emacs seem to behave like any other tty/x enabled
>> application.
>
> What do you mean by "tty/x enabled"?

I meant programs capable of running in text mode (tty), or under X.
There are a few besides Emacs.

> That it behaves differently in a tty and in X?

Yes.

> In X, my display is ":0", in a tty, it isn't set.
>
> With (in a tty)
>
> emacs -d ":0" 2> errors.txt
>
> everything is as predicted - I get the GUI Emacs in X (in the
> background, when I switch to X, I see it). Nevertheless, that
> command outputs to stderr:

Yep, -d is an override or substitute for $DISPLAY.

> (emacs:3496): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
> Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
> GConf Error: No D-BUS daemon running
>
> (emacs:3496): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
> Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
>
> You have any idea what that is?

Yes:

http://www.freedesktop.org/wiki/Software/dbus/

DBUS is not X, it's a way for applications to talk to each other.
I don't run a "desktop" enabled window manager and see those messages
too.  I don't let it bother me.

> Interestingly, again in a tty,
>
> DISPLAY=":0" emacs
>
> did *not* produce those error messages, and the GUI Emacs appeared
> just the same in X.

Yep.

>> If $DISPLAY is set, you get the GUI.
>>
>> Type:
>>
>> DISPLAY=  emacs
>>
>> and you get text mode.
>
> Yes, but isn't it better to use -nw - or, did you say that to show
> the mechanics, rather than usage?

Yes, trying to explain the mechanics.

-- 
Dan Espen

Re: Sanest way to make emacs behave on a Solaris OS

[Eli Zaretskii]

> From: Emanuel Berg <embe8573@student.uu.se>
> Date: Mon, 05 Aug 2013 20:25:55 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> There *was* such a change, I know this, because I read it in a
> >> recent book on Linux and shell programming - a big, white book
> >> with all the tools alphabetically, and with a big section on
> >> Emacs (and one on vim - no bias!).
> >
> > Well, if there is such a book, and if it says what you say it
> > says, then that book is simply wrong.  Emacs behaves like it
> > does today for a very long time.  "A couple of versions" is
> > definitely wrong.  If you'd say it was some time when Emacs 19.x
> > was being released, I could believe you.
> 
> Just be patient, I'll get the exact quote.

FWIW, etc/NEWS.18 has this snippet:

  * New startup command line options.

  [...]

  `-nw' means don't use a window system.  If you are using a terminal
  emulator on the X window system and you want to run Emacs to work through
  the terminal emulator instead of working directly with the window system,
  use this switch.

There's no minor version near this announcement, but the surrounding
text indicates that this was introduced in version 18.41.  According
to this:

   http://www.informatica.co.cr/unix/research/1987/0322.htm

Emacs 18.41 was released in Mar 1987.  (I think the first Emacs
version I used was 19.20 or some such.)

Re: Sanest way to make emacs behave on a Solaris OS

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> There *was* such a change, I know this, because I read it in a
>> recent book on Linux and shell programming - a big, white book
>> with all the tools alphabetically, and with a big section on Emacs
>> (and one on vim - no bias!).
>
> Well, if there is such a book, and if it says what you say it says,
> then that book is simply wrong.  Emacs behaves like it does today for
> a very long time.  "A couple of versions" is definitely wrong.  If
> you'd say it was some time when Emacs 19.x was being released, I could
> believe you.

I suspect that the mentioned book was mostly about stuff you run from
the console, i.e. X is not available. In that context, the `emacs'
command runs on the console. Moreover, at least on Debian distributions
there is an emacsNN-nox package that installs emacs version NN without
graphical support. One of the installed binaries is emacsNN. Then, there
is the package emacsNN which also installs the binary emacsNN, but this
time with graphical support. IIRC, on all cases an `emacs' symlink is
made pointing to `emacsNN'.

So a Debian user might invoke emacs24 on his terminal and obtain a
text-only session or a graphical session, depending on the installed
package and on the availability of an X server.

I'm afraid that what Mr. Berg describes as a change on Emacs behavior is
not something that his book mentions, but a (wrong) conclusion he made.

Re: Sanest way to make emacs behave on a Solaris OS

[Bob Proulx]

Emanuel Berg wrote:
> Bob Proulx writes:
> > Use of .Xdefaults is rather superseded by the .Xresources file.
> > The difference between the two is subtle.  But .Xresources tends
> > to be preferred because of the way that it is applied.  The
> > .Xresources is applied to the $DISPLAY through xrdb.  The
> > .Xdefaults is applied through the presence in the $HOME
> > directory, but only if the xrdb is empty.  So once you have a
> > .Xresources the .Xdefaults is no longer used.
> 
> That's interesting. On my school's Solaris/SunOS, in my home
> directory, there wasn't any .Xresources to begin with, but there
> was an .Xdefaults. It would have been interesting to examine the
> the contents of that file, but I was so eager to try the
> .Xresources solution that I just deleted the .Xdefaults, to be
> sure it didn't influence in any way. And now, you're saying that
> was unnecessary, because it is only applied if there isn't a
> populated xrdb/.Xresources. You live, you learn.

The difference is a little subtle if you are not in a situation to
notice how they are different from each other.  Let me give an
example.

You and I are both working on a server machine for some task using a
shared login.  (Let's not debate the shared login aspect.  Much of
this was set up decades ago.  At one time on local private friendly
networks that was very commonly done.  And this also applies to a
single user with different device displays too.)

You log into the machine and either tunnel X with ssh -X or you set
DISPLAY and allow it to forward raw to your desktop display.  I do the
same.  Say that I like white on black text and you like black on white
text.  However this could be any given customization.  It is only
important that we like different things.  We both start up the same
graphics application for the purposes of the shared task.

An alternative difference could be that you are working on a very
large widescreen monitor and want to set sizes, fonts, dpi, to match
your large screen.  I am working off of a 7 inch tablet and wish to
set sizes, fonts, dpi, to match my more limited work space.  Just for
another example.

Using $HOME/.Xdefaults on the server then we both share the same
customization.  I edit the file and make it my way.  I am happy and
you are unhappy.  You edit the file and make it your way.  You are
happy and I am unhappy.  The use of .Xdefaults works after a fashion
but it is limited and unable to make both of us happy at the same
time.  We can really only keep personalized copies of the .Xdefaults
file and switch by copying or linking it into place when we are
running and hope we are never running at the same time.

Due to this problem it is learned that these types of customization
problems are properties of the display and not of the user.  They
should be attached to the $DISPLAY and not to the $HOME.  Attaching
properties to the $DISPLAY instead of $HOME is the distinction between
using .Xresources and .Xdefaults.

Enter xrdb and the ability to set DISPLAY properties.  You have on
your desktop, not the server, a .Xresources file.  I have the same.
You put your customizations in your file and I put my customizations
in my file.  You load the contents into your $DISPLAY and I load my
contents into my $DISPLAY.  X graphical applications will look for
resources there first.  If that database exists and is available then
those will apply and no $HOME/.Xdefaults will be loaded.  Using this
strategy customization is a property of the $DISPLAY and not $HOME.

This also allows a single user to have a small screen tablet with one
set of customization and a large screen desktop with a different set
of customization because each will have a different $DISPLAY.  So it
applies generically to more than just shared logins between different
users.  It also applies to shared logins of the same user on different
displays.

In the case of a single user on a single device everything is
collapsed into a single case and it would be hard to tell the
difference.  But if you have several devices sharing an account, even
if it is the same user, then the difference allows customization to be
different for each display device.

I hope this explanation makes sense and is useful.

Bob

Re: Sanest way to make emacs behave on a Solaris OS

[Bob Proulx]

Harry Putnam wrote:
> Bob Proulx <bob@proulx.com> writes:
> 
> [...]
> 
> >> To be clear... the Meta key has worked as ALT does on linux right from
> >> the start.... I just caught it after my OP on this subject, and posted
> >> that I'd 'discovered' a sort of solution.
> >> 
> >> Its still kind of a pita just because of long habit on the ALT key in
> >> emacs. But much handier than ESC
> >
> > In your Xterm, hold down control and left mouse button.  A menu should
> > appear.  Keep holding control and left mouse.  Drag down to "Meta
> > Sends Escape" and tick it so that it now has a checkmark.  As
> > previously suggested by others that is the same as the following X
> > resource.
> >
> >   XTerm*metaSendsEscape:true
> >
> > Since you say that Alt has the mod1 modifier making it a Meta key I
> > believe this should be enough.
> 
> [...]
> 
> Sounds like you are saying that having ticked that item, if I start
> emacs in that same command xterm... I should get behavior where the
> ALT key just to the right of the key with windows logo (on many
> keyboards) Or put another way starting from left with left most key
> being 1, it is the 3rd key going to the right... just before the
> 'space bar'.

I do.  On HP-UX as well as on Debian GNU/Linux and on Red Hat
GNU/Linux distributions.

> OK, that key DOES NOT work in emacs here.  If I press Alt-x (as is how
> it works under linux), then emacs responds with 'A-x is not defined'
> ...
> But, I'm not sure I'm doing what you suggest... once I tick that item,
> then at the same xterm command line, typing `emacs <enter>' starts
> emacs (In X) in its own new window.

You are NOT doing what I am suggesting.  As others mentioned if you
are starting emacs as a graphical application and not a console one
running in the xterm then Emacs will handle the keyboard itself and
then it has nothing to do with Xterm at all.  The Meta Sends Escape
setting only applies to XTerm.  It won't apply to emacs in the
graphical client mode.  Those are two completely separate and distinct
cases with different configurations.  Confusing those two cases makes
talking about it very difficult.

Which do you want to do?  Do you want to run Emacs as a graphical
client?  Do you want to run Emacs as a text console program within an
XTerm?  Please pick one or the other and then work through it to
completion before trying the opposite way.

Assuming that you want Emacs as a text client within an Xterm then
please verify that you have started emacs from the xterm window using
the 'emacs -nw' with the -nw option.  This should be the simpler case
to get going.  Then can do the graphical one afterward.  If emacs is
compiled without X the option is still accepted and therefore never
hurts to use -nw when debugging the text flavor.

> Not sure where that leaves things but now going to insert:
>    XTerm*metaSendsEscape:true
> 
> Into my ~/.Xresources file.... but Doggone it, I don't remember how to
> reread .Xresources so that any changes become effective.... I'll have
> to restart X  and see how it goes.

  xrdb -m ~/.Xresources

The -m merges.  The -l loads.  I selected merging because you may have
sevaral files all merged together so this would only change what you
changed.  Using -l would empty first and then only load that file so
if you had several files, perhaps a /etc/X11/something, then that
other would be lost.  But I will use -l when I want only what is in
that file, nothing more and nothing less, and want to avoid anything
else that might have been set elsewhere.  Somewhat like the emacs -Q
of things.

Bob

Re: Sanest way to make emacs behave on a Solaris OS

[Emanuel Berg]

Bob Proulx <bob@proulx.com> writes:

> I hope this explanation makes sense and is useful.

Very helpful. I'll read it one more time (on paper) and get back
to you with questions.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Sanest way to make emacs behave on a Solaris OS

[Emanuel Berg]

Bob Proulx <bob@proulx.com> writes:

>   xrdb -m ~/.Xresources
>
> The -m merges.  The -l loads.  I selected merging because you
> may have sevaral files all merged together so this would only
> change what you changed.  Using -l would empty first and then
> only load that file so if you had several files, perhaps a
> /etc/X11/something, then that other would be lost.  But I will
> use -l when I want only what is in that file, nothing more and
> nothing less, and want to avoid anything else that might have
> been set elsewhere.  Somewhat like the emacs -Q of things.

Interesting. I have

xrdb ~/.Xresources

as the first line of .xinitrc - which is read after 'xinit', in
.zprofile (of zsh).

Without an operation (like -merge or -load, or -m/-l) the default
operation is -all, according to the man page. But what that means,
is not the easiest thing to understand, even with the man page:

> This option indicates that operation should be performed on the
> screen-independent resource property (RESOURCE_MANAGER), as well
> as the screen-specific prop‐ erty (SCREEN_RESOURCES) on every
> screen of the display.  For example, when used in conjunction
> with -query, the contents of all properties are output.  For
> -load, -override and -merge, the input file is processed once
> for each screen.  The resources which occur in common in the
> output for every screen are collected, and these are applied as
> the screen-independent resources.  The remaining resources are
> applied for each individual per- screen property.  This the
> default mode of operation.

I used it the same way when I did my experimentation on Solaris:
that is, without any operation.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Sanest way to make emacs behave on a Solaris OS

[Emanuel Berg]

Óscar Fuentes <ofv@wanadoo.es> writes:

> I'm afraid that what Mr. Berg describes as a change on Emacs
> behavior is not something that his book mentions, but a (wrong)
> conclusion he made.

Drumroll - and now the conclusion:

emacs and the X Window System
tip: Since version 19, GNU emacs has fully embraced the X Window
System environment. If you start emacs from a terminal emulator
window running in a graphical environment, you will bring up the X
interface (GUI) to emacs. This book does not cover the graphical
interface; use the -nw option when you start emacs to bring up the
textual interface in any environment. See "Starting emacs" below.

Mark G. Sobell: "A Practical Guide to Linux Commands, Editors, and
Shell Programming" (third edition, 2012), page 216.

(He spells Emacs with a lowercase "e", perhaps to make it
consistent with the command to invoke it.)

Yes, that was certainly something *ancient*, so there I was dead
wrong. But my memory isn't perfect. I mean, the comparison with
Charles Xavier - I always said that was exaggerated...

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Sanest way to make emacs behave on a Solaris OS

[Bob Proulx]

Emanuel Berg wrote:
> Bob Proulx writes:
> >   xrdb -m ~/.Xresources
> >
> > The -m merges.  The -l loads.  I selected merging because you
> > may have sevaral files all merged together so this would only
> > change what you changed.  Using -l would empty first and then
> > only load that file so if you had several files, perhaps a
> > /etc/X11/something, then that other would be lost.  But I will
> > use -l when I want only what is in that file, nothing more and
> > nothing less, and want to avoid anything else that might have
> > been set elsewhere.  Somewhat like the emacs -Q of things.
> 
> Interesting. I have
> 
> xrdb ~/.Xresources
> 
> as the first line of .xinitrc - which is read after 'xinit', in
> .zprofile (of zsh).
> 
> Without an operation (like -merge or -load, or -m/-l) the default
> operation is -all, according to the man page. But what that means,
> is not the easiest thing to understand, even with the man page:

The -all as I understand it applies to where to apply the properties.
Both to RESOURCE_MANAGER and to SCREEN_RESOURCES.  A different aspect
of things different from what I was talking about.

The -load option is also the default.

       -load   This  option  indicates  that the input should be loaded as the
               new value of the specified properties, replacing  whatever  was
               there  (i.e.   the  old  contents  are  removed).   This is the
               default action.

So these following commands would all be equivalent.

  $ xrdb .Xresources
  $ xrdb -l .Xresources
  $ xrdb -load .Xresources

> I used it the same way when I did my experimentation on Solaris:
> that is, without any operation.

I think that means you were doing the same as 'xrdb -l .Xresources'.
Which is fine.  Probably you only have a single source for everything.

Here is a slightly contrived example of how you might have multiple
files and might want to use both load and merge operations.

  xrdb -load $HOME/.Xresources
  if [ -f $HOME/.Xresources.$(hostname) ]; then
    xrdb -merge $HOME/.Xresources.$(hostname)
  fi

As I recall the KDE 3 desktop environment keeps a set of X resources
in a private location in the .kde/something location.  Then if a
~/.Xresources exists it adds that on top of its own private copy.  Or
something like that.  It has been a while since I used KDE 3.  But
specifically because I remembered it having additional resources is
why I danced around the issue with -merge.

Bob

Re: Sanest way to make emacs behave on a Solaris OS

[Stefan Monnier]

> shift       Shift_L (0x32),  Shift_R (0x3e)
> lock        Caps_Lock (0x42)
> control     Control_L (0x25),  Control_R (0x6d)
> mod1        Alt_L (0x40)
> mod2        Num_Lock (0x4d)
> mod3      
> mod4        Meta_L (0x73),  Meta_R (0x74),  Super_L (0x7f),  Hyper_L (0x80)
> mod5        Mode_switch (0x5d),  ISO_Level3_Shift (0x71),  ISO_Level3_Shift (0x7c)

There you go: Alt on `mod1' and Meta on `mod4'.
So, a possible solution:

   xmodmap -e 'remove mod4 = Meta_L Meta_R'
   xmodmap -e 'add mod1 = Meta_L Meta_R'

so both your Meta and Alt keys will behave as one and the same modifier
(probably called "Alt" in most programs and "Meta" in Emacs).


        Stefan

Re: Sanest way to make emacs behave on a Solaris OS

[Emanuel Berg]

Bob Proulx <bob@proulx.com> writes:

> The -all as I understand it applies to where to apply the
> properties.  Both to RESOURCE_MANAGER and to SCREEN_RESOURCES.
> A different aspect of things different from what I was talking
> about.
>
> The -load option is also the default.

Aha, so -all is unrelated. I just made a search in the man page
for "default", and I didn't consider that many options could be
default.

> As I recall the KDE 3 desktop environment keeps a set of X
> resources in a private location in the .kde/something location.
> Then if a ~/.Xresources exists it adds that on top of its own
> private copy.  Or something like that.  It has been a while
> since I used KDE 3.  But specifically because I remembered it
> having additional resources is why I danced around the issue
> with -merge.

OK. I don't know what I use on my laptop anymore. I got GNOME with
Debian, but then I removed so much stuff. Back then, I had
Metacity as a WM, but now I (seldom) use Openbox, which I invoke
explicitly. I also had gdm (the login screen and that), but now I
have autologin on the ttys, and then automatic invocation of
applications (including X, with 'xinit', as said), in .zprofile,
depending on what tty:

if (( $NORMAL_BOOT )); then
    case $VT in
        (1) emacs ;;
        (2) tinit ;;
        (3) xinit ;;
    esac
fi

(tinit is a script that setups tmux)

So I don't know if this is considered GNOME anymore? Anyway, on my
school's Solaris, I saw (when I did experimentation for this
thread) that *they* had GNOME, and they'd probably had it all this
time, but I never noticed, because I always ssh from my Linux, and
always without GFX. So this problem opened my eyes, or anyway just
a tiny bit, but that's something.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Sanest way to make emacs behave on a Solaris OS

[Emanuel Berg]

Harry Putnam <reader@newsguy.com> writes:

> First off, sorry to both you and Emanuel.  I admit I'm not your
> basic quick study... but really asleep at the switch on
> this. I've allowed you to put in time and effort and then
> dropped my end... for that I am truly sorry.

Ha ha, stop it. I'm totally fine, anyway.

But I give you that, this was probably one of the most confusing
threads *ever* :)

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Sanest way to make emacs behave on a Solaris OS

[Emanuel Berg]

Bob Proulx <bob@proulx.com> writes:

> Due to this problem it is learned that these types of
> customization problems are properties of the display and not of
> the user.  They should be attached to the $DISPLAY and not to
> the $HOME.  Attaching properties to the $DISPLAY instead of
> $HOME is the distinction between using .Xresources and
> .Xdefaults.

This part is clear:

1. You can have a shared login (same $HOME), or

2. you can have a non-shared login (one $HOME), with many monitors,

and you want to have customization that is unique to users A and
B, or to sole user C's L & M monitors.

But - how can you solve this just with another configuration file,
in the same $HOME? Doesn't that end up to just a name change? If
you had files - .monitor-L, .monitor-M, .user-A, .user-B, I dig,
but with just another file? How does that work?

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Sanest way to make emacs behave on a Solaris OS

[Dan Espen]

Bob Proulx <bob@proulx.com> writes:

> Emanuel Berg wrote:
>> Bob Proulx writes:
>> > Use of .Xdefaults is rather superseded by the .Xresources file.
>> > The difference between the two is subtle.  But .Xresources tends
>> > to be preferred because of the way that it is applied.  The
>> > .Xresources is applied to the $DISPLAY through xrdb.  The
>> > .Xdefaults is applied through the presence in the $HOME
>> > directory, but only if the xrdb is empty.  So once you have a
>> > .Xresources the .Xdefaults is no longer used.
>> 
>> That's interesting. On my school's Solaris/SunOS, in my home
>> directory, there wasn't any .Xresources to begin with, but there
>> was an .Xdefaults. It would have been interesting to examine the
>> the contents of that file, but I was so eager to try the
>> .Xresources solution that I just deleted the .Xdefaults, to be
>> sure it didn't influence in any way. And now, you're saying that
>> was unnecessary, because it is only applied if there isn't a
>> populated xrdb/.Xresources. You live, you learn.
>
> The difference is a little subtle if you are not in a situation to
> notice how they are different from each other.  Let me give an
> example.
>
> You and I are both working on a server machine for some task using a
> shared login.  (Let's not debate the shared login aspect.  Much of
> this was set up decades ago.  At one time on local private friendly
> networks that was very commonly done.  And this also applies to a
> single user with different device displays too.)
>
> You log into the machine and either tunnel X with ssh -X or you set
> DISPLAY and allow it to forward raw to your desktop display.  I do the
> same.  Say that I like white on black text and you like black on white
> text.  However this could be any given customization.  It is only
> important that we like different things.  We both start up the same
> graphics application for the purposes of the shared task.
>
> An alternative difference could be that you are working on a very
> large widescreen monitor and want to set sizes, fonts, dpi, to match
> your large screen.  I am working off of a 7 inch tablet and wish to
> set sizes, fonts, dpi, to match my more limited work space.  Just for
> another example.

Shared logins?  Makes no sense to me.
Where is the security in that.



Anyway, since you brought up dealing with different monitor sizes
here's how I deal with rxvt on different terminal sizes using
xrdb and X-resources:

#if ( HEIGHT == 900 )     /* Traditional Sparc */
Rxvt.geometry: 80x55
#elif ( HEIGHT == 1024 )  /* Sparc 21 inch */
Rxvt.geometry: 80x65
#elif ( HEIGHT == 768 )   /* Exceed in 1024x768 mode */
Rxvt.geometry: 80x47
#else                     /* I have no idea... */
Rxvt.geometry: 80x40
#endif

The man page reveals other values you can access besides HEIGHT.

Another person mentioned running xrdb and reading an .Xdefaults file.
A common problem with .Xdefaults is that it can rapidly accumulate
huge amounts of junk.

Here's how I deal with that in my .xinitrc:

  cat $HOME/xdef/*.ad | xrdb -load

The xdef directory contains:

Emacs.ad
exmh.ad
xterm.ad
etc.

Makes it easy to remove things you no longer use.

-- 
Dan Espen

Re: Sanest way to make emacs behave on a Solaris OS

[Bob Proulx]

Harry Putnam wrote:
> Stefan Monnier writes:
> > There you go: Alt on `mod1' and Meta on `mod4'.
> > So, a possible solution:
> >
> >    xmodmap -e 'remove mod4 = Meta_L Meta_R'
> >    xmodmap -e 'add mod1 = Meta_L Meta_R'
> >
> > so both your Meta and Alt keys will behave as one and the same modifier
> > (probably called "Alt" in most programs and "Meta" in Emacs).
> 
> Haaa! yup that works..

Yay!  But for which config?  If you start a new Xterm with the above
does Alt work as Meta in Meta Sends Escape too?  I think it should.

Bob

Re: Sanest way to make emacs behave on a Solaris OS

[Bob Proulx]

Dan Espen wrote:
> Bob Proulx writes:
> > (Let's not debate the shared login aspect.  Much of this was set
> > up decades ago.  At one time on local private friendly networks
> > that was very commonly done.  And this also applies to a single
> > user with different device displays too.)
>
> Shared logins?  Makes no sense to me.
> Where is the security in that.

This used to be very commonly done on local friendly networks back in
the day.  As I said, let's not debate that one.  It is just one of the
explanations for why we arrived where we have today.

> Anyway, since you brought up dealing with different monitor sizes
> here's how I deal with rxvt on different terminal sizes using
> xrdb and X-resources:
> 
> #if ( HEIGHT == 900 )     /* Traditional Sparc */
> Rxvt.geometry: 80x55
> #elif ( HEIGHT == 1024 )  /* Sparc 21 inch */
> Rxvt.geometry: 80x65
> #elif ( HEIGHT == 768 )   /* Exceed in 1024x768 mode */
> Rxvt.geometry: 80x47
> #else                     /* I have no idea... */
> Rxvt.geometry: 80x40
> #endif

A good way to share a single .Xresources across some multiple
situations.

> Another person mentioned running xrdb and reading an .Xdefaults file.

Sure.  That works fine.  But then you can't use any of the extended
features available in the .Xresources such as your cpp processing
example above.

> A common problem with .Xdefaults is that it can rapidly accumulate
> huge amounts of junk.
> 
> Here's how I deal with that in my .xinitrc:
> 
>   cat $HOME/xdef/*.ad | xrdb -load

Very nice.

Bob

Re: Sanest way to make emacs behave on a Solaris OS

[Harry Putnam]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> shift       Shift_L (0x32),  Shift_R (0x3e)
>> lock        Caps_Lock (0x42)
>> control     Control_L (0x25),  Control_R (0x6d)
>> mod1        Alt_L (0x40)
>> mod2        Num_Lock (0x4d)
>> mod3      
>> mod4        Meta_L (0x73),  Meta_R (0x74),  Super_L (0x7f),  Hyper_L (0x80)
>> mod5        Mode_switch (0x5d),  ISO_Level3_Shift (0x71),  ISO_Level3_Shift (0x7c)
>
> There you go: Alt on `mod1' and Meta on `mod4'.
> So, a possible solution:
>
>    xmodmap -e 'remove mod4 = Meta_L Meta_R'
>    xmodmap -e 'add mod1 = Meta_L Meta_R'
>
> so both your Meta and Alt keys will behave as one and the same modifier
> (probably called "Alt" in most programs and "Meta" in Emacs).
>

Is it normal for that change to only be good until next boot up?

I ask because after a reboot, it has gone away.

Re: Sanest way to make emacs behave on a Solaris OS

[Peter Dyballa]

Am 06.08.2013 um 14:52 schrieb Harry Putnam:

> Is it normal for that change to only be good until next boot up?

Yes. Either put the two commands into your xinit startup file or put the instructions into your xmodmap's startup file!

--
Greetings

  Pete

Every instructor assumes that you have nothing else to do except study for that instructor's course. 
				– Fourth Law of Applied Terror

Re: Sanest way to make emacs behave on a Solaris OS

[Emanuel Berg]

Dan Espen <despen@verizon.net> writes:

> Shared logins?  Makes no sense to me.  Where is the security in
> that.

No, probably some ancient way of sharing, when a small group of
people were on a techno-science facility with a huge mainframe,
which they used to estimate the trajectories of Russian nukes...

> Anyway, since you brought up dealing with different monitor
> sizes here's how I deal with rxvt on different terminal sizes
> using xrdb and X-resources:
>
> #if ( HEIGHT == 900 )     /* Traditional Sparc */
> Rxvt.geometry: 80x55
> #elif ( HEIGHT == 1024 )  /* Sparc 21 inch */
> Rxvt.geometry: 80x65
> #elif ( HEIGHT == 768 )   /* Exceed in 1024x768 mode */
> Rxvt.geometry: 80x47
> #else                     /* I have no idea... */
> Rxvt.geometry: 80x40
> #endif

Cool - I didn't know you could branch in .Xresources. What syntax
is that - the C preprocessor?

> The man page reveals other values you can access besides HEIGHT.

What man page?

> Another person mentioned running xrdb and reading an .Xdefaults
> file.  A common problem with .Xdefaults is that it can rapidly
> accumulate huge amounts of junk.
>
> Here's how I deal with that in my .xinitrc:
>
>   cat $HOME/xdef/*.ad | xrdb -load

Doesn't that mean you don't use .Xdefaults?

> The xdef directory contains:
>
> Emacs.ad
> exmh.ad
> xterm.ad
> etc.
>
> Makes it easy to remove things you no longer use.

You mean, you remove it, by not adding it every time X starts?
What extension is .ad?

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Sanest way to make emacs behave on a Solaris OS

[Emanuel Berg]

Peter Dyballa <Peter_Dyballa@Web.DE> writes:

> Am 06.08.2013 um 14:52 schrieb Harry Putnam:
>
>> Is it normal for that change to only be good until next boot up?
>
> Yes. Either put the two commands into your xinit startup file or
> put the instructions into your xmodmap's startup file!

I've done lots of experimentation with the keyboard, and that's
something I load every time.

I paste (last) a file, that is read in

/etc/rc.local

with

loadkeys /etc/console-setup/remap.inc > /dev/null

Because it is read in rc.local, you don't need to provide the
super user password.

The file exemplifies:

- go to a specific tty

- go to X (i.e., tty7, at least on my Debian) - this is extra cool
  if you in X (be it in urxvt or whatever) - setup the same
  shortcut, to go to the console

- iterate the tty's back and forth (I disabled that, instead I
  have one key for Emacs, and one for tmux, and then I do the
  console stuff in tmux)

- insert string - really cool! - but I didn't find a good use case

- scrolling - I removed that since I set it up otherwise in
  tmux. (One of the most annoying limitations of the Linux VTs is
  that if you go from one to another, and then return, you can't
  scroll! For this, those keys won't help, but there is a scroll
  ("copy") mode in tmux.)

- the backtab Emacs hack - to associate some arbitrary Unicode
  char and bind that to some functionality - very impressive! -
  and described in detail in other threads

- the compose key (so I can access those goofy chars - goofy to
  you - but still write and code with the faster and more
  ergonomic US layout)

- the only problem: the keys you setup like this cannot be used in
  for example Emacs to do other things - they take
  precedence. That's why you need to be restrictive. And no, you
  can't setup one map for one tty, and one for another (e.g., the
  one you run Emacs in) - at least not with the loadkeys method.

- is there anything more you could do? Please tell me :)

#### /etc/console-setup/remap.inc

## "ctrll" makes it work even when capslocked
## get keycode with `showkey'
## on-the-fly update: `loadkeys -c -s <keys>' (.zshrc's `lkeys')

# J - Emacs
alt keycode 36       = Console_1 # or Decr_Console
ctrll alt keycode 36 = Console_1 #    Decr_Console
# K - tmux
alt keycode 37       = Console_2 # or Incr_Console
ctrll alt keycode 37 = Console_2 #    Incr_Console

# M-u - X
alt keycode 22        = Console_7
ctrll alt keycode 22  = Console_7

## strings

# M-e M-E
alt keycode 18 = F70
alt shift keycode 18 = F71
string F70 = "embe8573"
string F71 = "@student.uu.se"

### scrolling

## P (up)
# alt keycode 25       = Scroll_Backward
# ctrll alt keycode 25 = Scroll_Backward

## N (down)
# alt keycode 49       = Scroll_Forward
# ctrll alt keycode 49 = Scroll_Forward

### Emacs map to get backtab
shift keycode 15 = U+010E

### compose key
## current state: `dumpkeys --compose-only'
compose 'o' 'a' to U+00E5 # å
compose 'o' 'A' to U+00C5 # Å
compose '0' 'a' to U+00E5 # å
compose '0' 'A' to U+00C5 # Å
compose '"' 'a' to U+00E4 # ä
compose '"' 'A' to U+00C4 # Ä
compose '"' 'o' to U+00F6 # ö
compose '"' 'O' to U+00D6 # Ö
compose '/' 'e' to U+00E9 # é
compose '/' 'E' to U+00C9 # É
compose '/' 'a' to U+00E1 # á
compose '/' 'A' to U+00C1 # Á
compose '/' 'u' to U+00FA # ú
compose '/' 'U' to U+00DA # Ú
compose '/' 'i' to U+00ED # í
compose '/' 'I' to U+00CD # Í

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Sanest way to make emacs behave on a Solaris OS

[Emanuel Berg]

Dan Espen <despen@verizon.net> writes:

> #if ( HEIGHT == 900 )     /* Traditional Sparc */
> Rxvt.geometry: 80x55
> #elif ( HEIGHT == 1024 )  /* Sparc 21 inch */
> Rxvt.geometry: 80x65
> #elif ( HEIGHT == 768 )   /* Exceed in 1024x768 mode */
> Rxvt.geometry: 80x47
> #else                     /* I have no idea... */
> Rxvt.geometry: 80x40
> #endif

I did some research on this, and put it a short article.

I will probably send it to some Linux aficionados and their
publications, so I made an effort to be more pedagogical in tone,
than I usually am. Anyway, suggestions how to improve are welcome.

But this post is also a continuation of this very discussion, so
don't worry!

Xdefaults vs. Xresources

The old solution was: Whenever an X ("Xlib" - ?) application is
invoked, it looks in ~/.Xdefaults for settings, and then
executes. The file had to be on the same filesystem, in the user's
HOME.

The "new" solution is: Whenever an X application is invoked, it
looks for settings in RESOURCE_MANAGER (XA_RESOURCE_MANAGER - ?)
in the root window of screen 0. Settings are there, if xrdb has
been run since the start of X. If not, the *fallback* is to look
for settings in Xdefaults (every time, for every application,
exactly as the old solution).

xrdb doesn't have to read ~/.Xresources, that's a convention. It
can read any file, even ~/.Xdefaults. (Note that xrdb *has* to be
used - some say ~/.Xresources is ignored because of GNOME and GDM
- this is not the case - even with xinit or startx, xrdb has to be
used.)

Xresources makes for flexibility, as any user can use, or not use,
xrdb, and use it on any file.

Xresources makes for mobility, as ~/.Xdefaults has to be in the
user's HOME folder, on the same file system. To test the enhanced
mobility, after reading resources with xrdb, do the following:

1. In X, and a WM (e.g., Openbox), and a terminal (e.g., urxvt),
ssh to a remote system with the -Y option. There, start xterm, or
any other application that you have configured on your local
system, but not on the system, to which you ssh'd. Then, do the
same on you local system: start xterm. They look the same!

2. Now, on your local system, run 'xrdb -remove'. Again, start
xterm on both the remote and the local system - again, they look
the same, only now, they aren't configured.

3. Last, to demonstrate the limited scope of Xdefaults, without
using xrdb since step 2, on you local system, run 'cp
~/.Xresources ~/.Xdefaults' (after salvaging anything of value
from Xdefaults), then run xterm on both remote and local
system. The remote xterm is unconfigured, but the local xterm is -
only, this time, from Xdefaults.

Notes:

The #1 Google hit on this issue recommends making ~/.xinitrc an
executable, with 'chmod +x' - this is not needed.

Also, the same article exemplifies the use of xrdb in .xinitrc
with a trailing '&', making xrdb a background process. This isn't
right, as the next program run from .xinitrc may use the very same
settings, that xrdb is in the process of setting up, and that must
be completed before any application that depends on it can be
run. Simple cure: remove the '&'.

Some xterm settings useful for testing:

xterm*autoWrap:        true
xterm*pointerMode:     2
xterm*geometry:        77x28
xterm*background:      black
xterm*foreground:      green4
xterm*faceName:        default
xterm*metaSendsEscape: true

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Sanest way to make emacs behave on a Solaris OS

[Dan Espen]

Emanuel Berg <embe8573@student.uu.se> writes:

> Dan Espen <despen@verizon.net> writes:
>
>> Shared logins?  Makes no sense to me.  Where is the security in
>> that.
>
> No, probably some ancient way of sharing, when a small group of
> people were on a techno-science facility with a huge mainframe,
> which they used to estimate the trajectories of Russian nukes...
>
>> Anyway, since you brought up dealing with different monitor
>> sizes here's how I deal with rxvt on different terminal sizes
>> using xrdb and X-resources:
>>
>> #if ( HEIGHT == 900 )     /* Traditional Sparc */
>> Rxvt.geometry: 80x55
>> #elif ( HEIGHT == 1024 )  /* Sparc 21 inch */
>> Rxvt.geometry: 80x65
>> #elif ( HEIGHT == 768 )   /* Exceed in 1024x768 mode */
>> Rxvt.geometry: 80x47
>> #else                     /* I have no idea... */
>> Rxvt.geometry: 80x40
>> #endif
>
> Cool - I didn't know you could branch in .Xresources. What syntax
> is that - the C preprocessor?

Yes.

>> The man page reveals other values you can access besides HEIGHT.
>
> What man page?

xrdb

>> Another person mentioned running xrdb and reading an .Xdefaults
>> file.  A common problem with .Xdefaults is that it can rapidly
>> accumulate huge amounts of junk.
>>
>> Here's how I deal with that in my .xinitrc:
>>
>>   cat $HOME/xdef/*.ad | xrdb -load
>
> Doesn't that mean you don't use .Xdefaults?

Yes, as I said, from my point of view, .Xdefaults is a bad idea.
It gets way too big and passing it from person to person
just makes it worse.  Back when I first started working with Solaris,
everyone had huge .Xdefault files with all kinds of junk in them.
This solution was appreciated by lots of people.

>> The xdef directory contains:
>>
>> Emacs.ad
>> exmh.ad
>> xterm.ad
>> etc.
>>
>> Makes it easy to remove things you no longer use.
>
> You mean, you remove it, by not adding it every time X starts?
> What extension is .ad?

.ad is entirely my own invention, along with using the sub-directory
"xdef".

So here's my current xdef directory:

 241  calctool.ad
 512  dtcm.adx
6031  Emacs.ad
  20  exmh.adx
2063  Frame.adx
  25  Gimp.ad
 283  olwm.adx
 499  openwin.adx
2587  x3270.ad
7894  xbiff.ad
3893  XCalc.adx
 168  xcursors.ad
 523  xdefaults.ad
6060  XEmacs.ad
 199  xexit.ad
 132  Xft.ad
1790  xlock.adx
 827  xlogout.ad
 230  xmeter.adx
  32  xperfmon.adx
 225  XPrompt.ad
7521  Xscreensaver.ad
2932  xterm.ad

The files I'm currently not using are just renamed ".adx" so they
get skipped.

-- 
Dan Espen

Re: Sanest way to make emacs behave on a Solaris OS

[Emanuel Berg]

Dan Espen <despen@verizon.net> writes:

> The files I'm currently not using are just renamed ".adx" so
> they get skipped.

Another solution:

Put, in .emacs
  (add-to-list 'magic-mode-alist
    '("! conf-xd" . conf-xdefaults-mode) )

Then, create the file ~/.xterm, that looks like this

! conf-xd

! note: 2 = always hide pointer when typing
xterm*autoWrap:        true
xterm*pointerMode:     2
xterm*geometry:        77x28
xterm*background:      black
xterm*foreground:      green4
xterm*faceName:        default
xterm*metaSendsEscape: true

Then, in ~/.Xresources, put

#include ".xterm"

Note that ~ doesn't work, and $HOME doesn't work - an absolute
path works (with no fancy stuff, just, for example,
/home/user/.xterm), or (as above) a *relative* path: put both
files in $HOME, and don't mention the paths.

To not load the xterm configuration, comment the include line with ! (or M-;).

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Sanest way to make emacs behave on a Solaris OS

[Emanuel Berg]

Emanuel Berg <embe8573@student.uu.se> writes:

> Another solution ...

It wasn't a good idea to call the files (for example) .xterm,
because that is the norm of config files (that are not related to
Xresouces: for example, couldn't be used for Emacs).

So invented the .xr extension for this purpose.

Some "extra material" - haven't tested that much, but seems to
work. Comments are always welcome.

;;; Xresources etc.
(add-to-list 'magic-mode-alist
             '("! conf-xd" . conf-xdefaults-mode))
(add-to-list 'auto-mode-alist
             '("\\.xr\\'"  . conf-xdefaults-mode))

;; get resource file by tool name
(defun x-conf (tool)
  (interactive "s tool: ")
  (find-file (format "~/.%s.xr" tool)) )

;; get resource file by placing the cursor at an #include line;
;;   haven't tested (for that), but could be useful
;;   for C and C++ with some adjustments
(defun follow-x-conf ()
  (interactive)
  (save-excursion ; I was hesitant to add this,
                  ; because `goto-conf' does it, but
                  ; for the possibility of direct invocation
    (beginning-of-line)
    (forward-word 1) ; get by #include
    (forward-char 2) ; get by WS and DQM
    (find-file (thing-at-point 'filename)) ))

;; umbrella function that will invoke one of the above
(defun goto-conf ()
  (interactive)
  (save-excursion
    (beginning-of-line)
    (if (< (point) (point-max)) ; not to break on EOB
                                ; (is there such a predicate?)
        (progn
          (forward-char 1) ; get by hash;
          (if (string= (thing-at-point 'word) "include")
              (follow-x-conf)
            (call-interactively 'x-conf) ))
      (call-interactively 'x-conf) )))

;; shortcut as you see fit
; (define-key (current-global-map) (kbd "...") 'goto-conf)

;; as always, my method to get to config files
;; (not just X config files), fast:
; (global-set-key (kbd "C-j") 'jump-to-register)
; (set-register ?X (cons 'file "~/.Xresources"))

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Sanest way to make emacs behave on a Solaris OS

[Emanuel Berg]

Dan Espen <despen@verizon.net> writes:

> Emacs.ad

I never thought about configuring Emacs with this method.

What is configurable that way?

If you are lazy, but still generous, and not shy, how about
posting that file?

Are there any advantages configuring Emacs like that? Anything
that can't be done in .emacs? Does it all relate to X? If it can
be done in .emacs, is there a speed advantage?

/The Hairdresser

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573

Re: Sanest way to make emacs behave on a Solaris OS

[Dan Espen]

Emanuel Berg <embe8573@student.uu.se> writes:

> Dan Espen <despen@verizon.net> writes:
>
>> Emacs.ad
>
> I never thought about configuring Emacs with this method.
>
> What is configurable that way?
>
> If you are lazy, but still generous, and not shy, how about
> posting that file?
>
> Are there any advantages configuring Emacs like that? Anything
> that can't be done in .emacs? Does it all relate to X? If it can
> be done in .emacs, is there a speed advantage?

X-resources are only for X-windows.
The advantage to using X-resources is that they are all set before
the window is created so you don't get things like the window starting
up 20 lines high and changing as the .emacs is read.
Long ago the help for Emacs recommended using X-resources for this
reason.  It may still do so, I haven't looked in a long time.

What can you set with X-resources?  Lots of things.
My current file is small enough that I guess I can post it here,
but be warned, this is old and may be configuring things long gone
or XEmacs based.

! This is a little funny, but I start XEmacs with 2 frames, one of them
! for mail, and I give it the resource name "xmh".  This makes it start
! iconic:
Emacs*xmh.iconic: true

! Gnus-5 uses this:
Emacs.backgroundMode: dark
! Even though I said it was dark it picked this dark color:
Emacs.custom-face-forestgreen-default-default-nil-t-nil.attributeForeground:pink

Emacs*XlwMenu.selectColor:		ForestGreen
Emacs*XmToggleButton.selectColor:	ForestGreen
! Specify the colors of the various sub-widgets of the dialog boxes.
Emacs*dialog*Foreground:		Black
! #A5C0C1 is a shade of blue
Emacs*dialog*Background:		#A5C0C1
Emacs*dialog*XmTextField*Background:	WhiteSmoke
Emacs*dialog*XmText*Background:		WhiteSmoke
Emacs*dialog*XmList*Background:		WhiteSmoke
! Xlw Scrollbar colors
Emacs*XlwScrollBar.Foreground:		Gray30
Emacs*XlwScrollBar.Background:		Gray75
Emacs*XmScrollBar.Foreground:		Gray30
Emacs*XmScrollBar.Background:		Gray75

! xemacs wants . after Emacs, at least for some things:
Emacs.modeline.attributeBackground:   Wheat
Emacs.modeline.attributeForeground:   Black

! The menubar is 8x13bold (fontlist is if motif widgets are used):
Emacs*menubar*font:     -misc-*-bold-r-normal--13-120-75-75-*-80-iso8859-*
Emacs*menubar*fontlist: -misc-*-bold-r-normal--13-120-75-75-*-80-iso8859-*
Emacs*popup*font: -misc-*-bold-r-normal--15-140-75-75-*-90-iso8859-*

! DJE, 09/28/2009, try to set Emacs menubar colors, not working:
Emacs.menubar*foreground: white
! The "pane" part is for Lucid menus:
Emacs.pane.menubar.background: cornflowerblue
! With LessTif, there are sub-Widgets:
Emacs.pane.menubar.*.background: cornflowerblue

Emacs.menu*.foreground: white
Emacs.menu*.background: cornflowerblue
Emacs.dialog*.foreground: white
Emacs.dialog*.background: blue

! Customize the pointers:
!(default)Emacs*textPointer:	xterm
Emacs*spacePointer:		sailboat
Emacs*modeLinePointer:		spider
Emacs*selectionPointer:		trek
!(default)Emacs*gcPointer:	watch

! Geometry changes based on screen size:
#if ( HEIGHT == 900 )     /* Traditional Sparc */
Emacs.geometry: 81x55+0+0
#elif ( HEIGHT == 1024 )  /* Sparc 21 inch */
Emacs.geometry: 81x63+0+0
#elif ( HEIGHT == 768 )   /* Exceed in 1024x768 mode */
Emacs.geometry: 81x46+0+0
#elif ( HEIGHT == 1200 ) /* My home machine, 1600x1200 use side x side layout */
! No good w. 10x20 Emacs*xmh.geometry: 81x68+757+105
Emacs.geometry: 81x56
#elif ( HEIGHT == 1600 ) /* My home machine rotated 1600x1200 */
Emacs.geometry: 81x70
#else                     /* I have no idea... */
Emacs.geometry: 81x40+0+0
#endif

! This is 10x20:
Emacs.default.attributeFont: -*-*-medium-*-normal--20-200-75-75-*-100-iso8859-*
! Set these, otherwise emacs wont figure out the right size font:
Emacs.italic.attributeFont: -*-*-*-*-normal--*-160-75-75-m-50-iso8859-*
Emacs.bold.attributeFont: -*-*-*-*-normal--*-160-75-75-m-50-iso8859-*
Emacs.bold-italic.attributeFont: -*-*-*-*-normal--*-160-75-75-m-50-iso8859-*

!# 7x13 bold
Emacs.modeline.attributeFont:-misc-*-bold-r-normal--13-120-75-75-*-70-iso8859-*
! This one is a different size, one of the rare cases when it looks OK:
Emacs.man-heading.attributeFont:-adobe-courier-bold-r-normal--*-190-75-75-m-0-iso8859-1
Emacs.man-heading.attributeForeground:pink

! Overall color scheme:
Emacs*Background:  black
Emacs*BackGround:  black
Emacs*background:  black
Emacs*Foreground:  chartreuse
Emacs*ForeGround:  chartreuse
Emacs*foreground:  chartreuse

! Added this to suppress a warning:
Emacs.italic.attributeForeground: pink
Emacs.italic.attributeBackground: black
Emacs.bold-italic.attributeForeground: pink
Emacs.bold-italic.attributeBackground: black
Emacs.bold.attributeBackground: black

#ifdef COLOR
Emacs*XmScrollBar*Foreground:	lavender
Emacs*XmScrollBar*Background:	wheat
Emacs*cursorColor: white
! Defaults for gnus
Emacs.message-highlighted-header-contents.attributeForeground: coral
Emacs.message-cited-text.attributeForeground: lavender
! Defaults for search/selection
Emacs.isearch.attributeBackground: black
Emacs.isearch.attributeForeground: coral
Emacs.highlight.attributeForeground: red
Emacs.bold.attributeForeground: pink
! primary-selection changed to zmacs-region in 19.12
Emacs.zmacs-region.attributeBackground: DarkOrchid3
Emacs.primary-selection.attributeBackground: DarkOrchid3
Emacs.secondary-selection.attributeBackground: DarkOrchid2
! Menubar etc.
Emacs*menubar*Background:  DeepSkyBlue1
Emacs*menubar*Foreground:  black
Emacs*menubar.buttonForeground:		pink
! Dont see this having any effect: dje
Emacs*popup*Background:  lightblue
Emacs*popup*Foreground:  black
Emacs*pointerForeground:              white
Emacs*pointerBackground:              red
! With 19.12, these generated warnings with * after Emacs...dje 6/30/95
Emacs.attributeForeground: green
Emacs.attributeBackground: black
#endif

! For those poor souls without color:
#ifndef COLOR
Emacs*ForeGround:  black
Emacs*Foreground:  black
Emacs*foreground:  black
Emacs*BackGround:  white
Emacs*Background:  white
Emacs*background:  white
Emacs*borderColor: black
Emacs*CursorColor: black
Emacs*cursorColor: black
Emacs*attributeForeground: black
Emacs*attributeBackground: white
Emacs.bold.attributeForeground: white
Emacs.highlight.attributeForeground: white
Emacs.isearch.attributeForeground: white
Emacs.menubar.Foreground: white
Emacs.modeline.Foreground:	white
Emacs.modeline.attributeForeground: white
Emacs.modeline.attributeBackground: black
Emacs.pointerForeground: white
Emacs.popup.foreground: white
Emacs.primary-selection.attributeForeground: white
Emacs.secondary-selection.attributeForeground: white
Emacs.bold.attributeBackground: black
Emacs.highlight.attributeBackground: black
Emacs.isearch.attributeBackground: black
Emacs.menubar.Background: black
Emacs.pointerBackground: black
Emacs.popup.background: black
Emacs.primary-selection.attributeBackground: black
Emacs.secondary-selection.attributeBackground: black
Emacs*pointerColor: black
#endif



-- 
Dan Espen

Re: Sanest way to make emacs behave on a Solaris OS

[Emanuel Berg]

Dan Espen <despen@verizon.net> writes:

> My current file ...

You are a *trooper*!

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573