Re: M-TAB already used by KDE

[Kai Großjohann]

Fredrik Staxeng <fstx+u@update.uu.se> writes:

> What's the name in Emacs for mod5?

Emacs does not have a name for this.  Emacs looks in the (equivalent
of the) output of "xmodmap -pm" for the modifiers.

So if the mod4 line contains the Meta_L or Meta_R keysym, then mod4
will be considered the meta modifier.
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)
>From help-gnu-emacs-bounces@gnu.org  Fri Dec 20 13:45:30 2002
Path: 
shelby.stanford.edu!newsfeed.stanford.edu!bloom-beacon.mit.edu!news-peer.gip.net!news.gsl.net!gip.net!c03.atl99!cyclone2.usenetserver.com!news.webusenet.com!news01.optonline.net!news4.srv.hcvlny.cv.net.POSTED!53ab2750!not-for-mail
Message-ID: <3E036557.5050106@rcn.com>
From: Tribhuvan <loka@rcn.com>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US;
        rv:1.0.1) Gecko/20020920 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: comp.sys.mac.apps,comp.sys.mac.advocacy,comp.text.tex,gnu.emacs.help
References: <041220020952400758%ajanta@no.spam>
        <slrnav1ed1.ho.smullerin@esb.bbn.com> <m2hedrm4oc.fsf@owlbear.local>
        <84bs3xsyi8.fsf@lucy.cs.uni-dortmund.de> 
<071220021155280606%ajanta@no.spam>
        <5ld6obj8il.fsf@rum.cs.yale.edu> <091220021652087216%ajanta@no.spam>
        <101220021125583826%ajanta@no.spam> <vf3cp5ix2u.fsf@rpc71.cs.man.ac.uk>
        <vf3cp4k92x.fsf@rpc71.cs.man.ac.uk> <111220021101520860%ajanta@no.spam>
        <vfadjcif3n.fsf@rpc71.cs.man.ac.uk> <111220021253524057%ajanta@no.spam>
        <5l65u0i8zj.fsf@rum.cs.yale.edu> <111220022053507599%ajanta@no.spam>
        <84k7ifo3s2.fsf@lucy.cs.uni-dortmund.de> 
<87u1hjdwta.fsf@hurd.crasseux.com>
        <121220021324043990%ajanta@no.spam>
        <m3el8iar9g.fsf@mika.informatik.uni-freiburg.de>
        <171220021132381961%ajanta@no.spam> <3DFFA457.1020103@rcn.com>
        <844r9b3exh.fsf@lucy.cs.uni-dortmund.de>
        <m3bs3gn1f3.fsf@mika.informatik.uni-freiburg.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 43
Date: Fri, 20 Dec 2002 18:44:25 GMT
NNTP-Posting-Host: 24.189.235.22
X-Trace: news4.srv.hcvlny.cv.net 1040409865 24.189.235.22 (Fri, 20 Dec 2002
        13:44:25 EST)
NNTP-Posting-Date: Fri, 20 Dec 2002 13:44:25 EST
Organization: Optimum Online
Xref: shelby.stanford.edu comp.sys.mac.apps:349391
        comp.sys.mac.advocacy:919186 comp.text.tex:238642 gnu.emacs.help:108358
To: help-gnu-emacs@gnu.org
Subject: Re: Software/HD ecology
X-BeenThere: help-gnu-emacs@gnu.org
X-Mailman-Version: 2.1b5
Precedence: list
List-Id: Users list for the GNU Emacs text editor <help-gnu-emacs.gnu.org>
List-Help: <mailto:help-gnu-emacs-request@gnu.org?subject=help>
List-Post: <mailto:help-gnu-emacs@gnu.org>
List-Subscribe: <http://mail.gnu.org/mailman/listinfo/help-gnu-emacs>,
        <mailto:help-gnu-emacs-request@gnu.org?subject=subscribe>
List-Archive: <http://mail.gnu.org/pipermail/help-gnu-emacs>
List-Unsubscribe: <http://mail.gnu.org/mailman/listinfo/help-gnu-emacs>,
        <mailto:help-gnu-emacs-request@gnu.org?subject=unsubscribe>
X-List-Received-Date: Fri, 20 Dec 2002 18:45:30 -0000

Lee wrote:
 > make install 2>&1 >install.log

Redirecting the output to a log file is useful, and
should be a standard practice, but as I indicated in
an earlier post, only a very small portion of this output
indicates the copy operations. In particular, the bin,
lib, man, share portions of an installation. (/etc and
/var stuff I don't think should be removed automatically
during an uninstall because these locations should contain
your custom configuration files and log files which may be
useful later). An install prefix like
--prefix=/usr/local/package
would be problematic for production environments as there
are security and sanity issues that prevent us from mixing
various types of files and directories on any disk partition.

 > ...a "make installed_file_list"...would be very helpful.
 > Or a "make uninstall.sh"...undoing whatever "make install" has done.

I was originally thinking of capturing/filtering the output of
"make install", but you may be on to something much more practical.

After doing "make", all of the instructions are prepared
for "make install". The same set of instructions could be
used for a "make installed" (<- truncated name) to generate
an "installed_file_list". Once this little database is created,
a relatively simple shell script could perform something like:

# make installed > /var/gnu/package-foo.installed_list.log
# sh uninstall.sh < /var/gnu/package-foo.installed_list.log
...removing package-foo
remove all pkg-foo files from /opt/sfw/bin [y|n|?]:
remove all pkg-foo files from /opt/sfw/etc [y|n|?]:
...and so on.

only, if "uninstall.sh" were a standardized item (and) not
something that might inadvertantly get deleted along with
the source tree.