NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/alt/lucidem/help/441

Text File | 1992-09-15 | 5.8 KB | 132 lines

x-gateway: rodan.UU.NET from help-lucid-emacs to alt.lucid-emacs.help; Tue, 15 Sep 1992 18:34:06 EDT
Message-ID: <[e-mail]>
Site:
Subject: New user finds bugs?  Or maybe I'm just confused.
Date: Tue, 15 Sep 1992 18:21:39 EDT
From: [e-mail] (James J Dempsey)
Newsgroups: alt.lucid-emacs.help
Path: sparky!uunet!wendy-fate.uu.net!help-lucid-emacs
Sender: [e-mail]
Lines: 120

I've just started using Lucid Emacs for the first time.  I'm using
v19.3 on a HP9000/720 running HP-UX 8.07 using the modifications for
HP-UX posted to this list by [e-mail] (Henrik B}kman CSD).
Note that this means I have compiled it without floating point support.

I like it a lot, but I have found a series of problems which I will
describe below.  Some of these may indeed be bugs which I will report
to the bug list if I am sure they are bugs.  Others may just be
confusions I have about the way Lucid Emacs works.  Most of them are
incompatibilities between Lucid Emacs and FSF Emacs 18.

I'd love to know whether I should report some of these as bugs, or if
I'm just confused.  Are there workarounds?

Thanks,

        --Jim Dempsey--
        [e-mail]

* You can't have region selected in an other window

    I use mh-e, the mh interface for Emacs.  When replying to a message,
    the draft you are composing is in one buffer and the message you are
    replying to is in another.  There is a command which inserts the
    selected part of the reply-to message in your draft.  It works great
    in Emacs 18.58, but with Lucid Emacs, there is no way to have a
    region in one window while your cursor is in the other.

* ^W^Y^W doesn't work

    In Emacs 18.58, If I kill a region with ^W and then yank it with ^Y
    the pasted region is selected.  I can then do a ^W to delete it again.
    In Lucid, yanked text isn't selected.

* I can't start it up in the background

    When I start lucid emacs in the background, it stops with
     "Stopped (tty output)".  If I then bring it to the foreground (it
    does no output) and then put it back in the background, it continues
    to function fine in the background.

* -geometry on the cmd line doesn't seem to override an Emacs*geometry
  resource in the resource database.

    In general, I thought that command line arguments should always
    override defaults in your resource database.

* When I start lucid emacs on my NCD X terminal at home, I get this message:

    emacs:  Alt_R (0x39) generates Mod1, which is generated by Meta.

        Two distinct modifier keys (such as Meta and Hyper) cannot generate
        the same modifier bit, because Emacs won't be able to tell which
        modifier was actually held down when some other key is pressed.  It
        won't be able to tell Meta-x and Hyper-x apart, for example.  Change
        one of these keys to use some other modifier bit.

        The meanings of the modifier bits Mod1 through Mod5 are determined
        by the keysyms used to control those bits.  Mod1 does NOT always
        mean Meta, although some non-ICCCM-compliant programs assume that.

    Unfortunately, this is exactly the behaviour I want.  I want Meta-x
    and Alt_R-x to be indistinguishable.  Interestingly, I never even
    mention Alt_R in my .xmodmaprc, just Meta_L and Meta_R.  It seems that
    lucid emacs is being too draconian in this regard.  Copies of my
    .xmodmaprc available on request, but the interesting lines are:
        keysym Caps_Lock = Meta_L
        add Mod1 = Meta_L Meta_R

* The mouse cursor changes to a watch on garbage collection and remains so

    On each GC, the mouse changes to a watch cursor, and remains so until
    the next time the mouse is moved.

* The SPACE key terminates an i-search-forward and self-inserts!!!

    When I type ^Sfoo<space> the <space> cancels the isearch and inserts
    itself in the buffer.  This is really annoying.  I mentioned this to
    someone on a Sun who uses Lucid emacs 19.3 and it doesn't happen to
    him, so it may be an HP-UX only bug.

* The visible bell doesn't work well

    I use (setq visible-bell t) in my .emacs file.  This mostly works fine
    in 18.58, but in Lucid Emacs, a subsequent bell appears to have the
    same effect as ^L.  The screen very briefly blanks, perhaps for 1/20th
    of a second, but it is hardly noticable.  I think it should flash some
    color on the screen or reverse video or something similar.

* Line continuation/truncation characters appear too soon

    Using the default font, a line with 79 characters on it in an 80
    character window displays without line continuation/truncation
    characters.  Using font 6x13, a 79 char line in an 80 char window is
    wrapped or truncated.  This is especially annoying when using
    something like mh-e, which specifically truncates message scan lines
    at 79 characters to avoid this problem.

* Autorepeat M-v acts differently than C-v and differently than 18.58

    If I hold C-v down so that it autorepeats, I see each page for a
    fraction of a second as it goes by. If I hold down M-v so it
    autorepeats, the display just freezes until I release the key at which
    time it goes to the place in the file many pages previous to which I
    have scrolled.  It is visually useful to see the pages going by so you
    know how far you have gone.  In any case, one would expect C-v and M-v
    to act similarly in this regard.

* The mh-e.el included with 19.3 is older than the one shipping with 18.58

* When replying to a message in mh-e, v18 can typeahead. V19 no typeahead.

    In emacs 18.58 with mh-e, I can issue a "reply to this message"
    command and start typing the reply even before the new draft buffer
    appears, a second later.  The characters I type appear in the new
    draft buffer.  In Lucid Emacs, there is no typeahead, those characters
    are dropped and don't appear to have gone anywhere.

*** end of report ***