jeff@cjsa.WA.COM (Jeffery Small) (09/24/89)
I discovered a small problem while trying to edit a long To: line using the header editor. When I entered 't' to edit the To line, the text appeared near the bottom of the screen as expected. However, the line was over 80 chars. wide and wrapped around onto the next line with the cursor positioned at the end of the text. Now when I tried to backspace across the text the cursor moved back to column one and then remained in that position as I continued to backspace. It did not jump up to the previous line and track along with the text. Thus, I was erasing characters in the buffer without any visual confirmation of what I was doing. This was on a UNIXPC and is not really a bug - just the net result of the simple editing capability of the header editor. Most of the time when I need to edit a header line, what I want to is trim the front part of a complex return path to make it more direct. The header editor unfortunately makes me write down the path components I need, backspace to erase the entire line and then type in the corrected path from scratch. This is why I would really like to have the headers included in my editing session so that I could perform these editing tasks more efficiently. Also, someone recently mentioned using a utility like "pathto" to determine the path to a site. If the header is in my (vi) editing buffer, I can import a proper path with a command like: :r !pathto <machinename> You can't do anything like this in the header editor. There hasn't been much discussion about this issue recently. I was just wondering what the development team's current thoughts were about incorporating the header in the editor buffer as an option in the next release? Another area which is causing me some problems these days is the lack of command-key binding in Elm. I find myself jumping back and forth between the NN newsreader and Elm (which have a similar visual interface). I have mapped a series of function keys to perform my NN reading functions. When I jump to Elm, I accidentally keep pressing these function keys to perform the same tasks in Elm and instead find I have just issued some strange sequence of Elm commands (depending upon the escape sequence for the key pressed). I would really like to be able to map my keyboard so that I could get Elm to operate similar to NN (and other tools I use). Does this capability seem useful enough to others to warrant the effort of adding it to Elm? If so, I have been impressed with the NN implementation of key binding and Kim Storm (author of NN) might be receptive to allowing this code to be incorporated into Elm. -- Jeffery Small (206) 485-5596 uw-beaver!uw-nsr!uw-warp C. Jeffery Small and Associates !cjsa!jeff 19112 152nd Ave NE - Woodinville, WA 98072 uunet!nwnexus
syd@DSI.COM (Syd Weinstein) (09/24/89)
jeff@cjsa.WA.COM (Jeffery Small) writes: >I was just wondering what the development team's current thoughts >were about incorporating the header in the editor buffer as an option >in the next release? We've thought about it, and have done nothing more. Its not an easy option to integrate the way Elm is written. Without a rewrite of the sending area it is very difficult, so it has been punted for now. If we were to do it, we would base it on the users current mode and only experts would get it, or perhaps those that specifically requested it via their elmrc files. Note, that we still cannot do it, at present. >I would really like to be able to map my keyboard so that I >could get Elm to operate similar to NN (and other tools I use). Does this >capability seem useful enough to others to warrant the effort of adding >it to Elm? If so, I have been impressed with the NN implementation of >key binding and Kim Storm (author of NN) might be receptive to allowing >this code to be incorporated into Elm. We have also considered this when we looked at using a 'real curses' for Elm and punted this also. We could not find a suitable subset of curses that worked on multiple machines. Too many vendors curses broke one feature or another, so we dropped the entire issue. Elm's curses is too dumb for any of this at present, so it would be a complete rewrite of the input fetching code, which also is not necessarily centralized in Elm. -- ===================================================================== Sydney S. Weinstein, CDP, CCP Elm Coordinator Datacomp Systems, Inc. Voice: (215) 947-9900 syd@DSI.COM or {bpa,vu-vlsi}!dsinc!syd FAX: (215) 938-0235