Re: [tnt-devel] edit mode

[David G. <da...@da...>]

Neil ''Fred'' Picciotto writes:
 > > 1) The current edit buddy mode is unique (as far as I know) in that
 > >    you can edit the order of the buddies and the groups.  I would like
 > >    to see this capability kept intact, even if a more integrated
 > >    editor is built.
 > 
 > you mean this feature is unique among IM/toc clients?  interesting.  in
 > any case, i agree that this is a useful feature, and should be kept.  

Well, I haven't tried GAIM or TAC, but TiK doesn't do it and I don't
believe Quick Buddy will...  I seem to recall having edited the raw
configuration strings to change the order for TiK...

 > > 2) One thought that occurs is that an initiate editing command is
 > >    logically equivalent to toggle-read-only, and so should probably
 > >    use it's key-binding (C-x C-q).
 > 
 > this makes sense, except that it's not obvious to me that we need to go in
 > and out of "editing" mode.  i think that one nice aspect of the interface
 > that john suggested (and that i talked about in some more detail) is that
 > it doesn't have a notion of editing mode versus not.  the editing commands
 > are always available.  certainly you can switch between seeing all buddies
 > and just those that are online, but i see no reason why you should, for
 > example, only be able to create a new buddy when all buddies are currently
 > showing.  so the "show/hide all buddies" toggle is not an "edit mode"
 > toggle as well.

I hadn't thought back about Emacs enough at the time...  It turns out
when you declare an interactive function, if the parameter string
starts with a "*", then the function is marked as an editing function
and will signal an error before reading any arguments.  Thus, by
correctly marking all the editing functions, the standard
toggle-read-only can be used.  At this point, the only question is if
the buffer defaults to read-only mode, and this could be a
configuration item.  Actually, one must also ensure that all the
normal buffer manipulations deal with the possibility that the buffer
is read-only.  Sample code looks like this:

(defun sample-editing-function () "This is a sample editing function"
(interactive "*") (insert "sample"))

(defun sample-non-editing-function () "This is a sample manipulation
function, that nominally doesn't change the buffer"
(interactive) (let ((buffer-read-only nil)) (insert "sample")))


 > if we find it useful to have an edit mode, then certainly you're right,
 > the standard toggle-read-only command key binding should be used.
 > 
 > > 3) Where possible, matching standard bindings and capabilities as much
 > >    as possible is a good idea.  This means (to me at least) that the
 > >    normal cut and paste functionality should work if possible.
 > >    Additionally, if the concepts of paragraph and page can be defined
 > >    then the paragraph and page moving and manipulation functions
 > >    should work.
 > 
 > again, this makes sense in the abstract, though i'm not entirely sure how
 > to apply it.  i guess a buddy group could be treated as a paragraph.  
 > though i'm not really clear what paragraph-level operations make sense to
 > perform on buddy groups, other than moving the cursor forward and back.

Perhaps kill-paragraph, sort-paragraphs, and transpose-paragraphs?
O.K., to some extent I am just presenting ideas for consideration....

 > oh, i guess transpose-lines and transpose-paragraphs would be a logical
 > interface for modifying the order of buddies and groups.
 > 
 > in any case, while it makes sense to make available the key-bindings for
 > normal editing, i think it also makes sense to make available other
 > bindings for the same commands, since the buddy-list mode does not allow
 > you to simply type words in the buffer...
 > 
 > > 4) One thing I have always wanted was a mechanism that would allow me
 > >    to see the person's real name instead of their buddy name.  Of
 > >    course, this would require my entering their real name, but I am
 > >    willing to do so.  
 > 
 > yes!  i've been thinking about adding this feature too.  
 > 
 > >    This should also include dealing with one person
 > >    having multiple buddy names.  
 > 
 > what's to deal with?  i mean, if you just associate a "real name" with
 > each buddy, then if one person has two screen names, no problem, they just
 > happen to both have the same real name.  i suppose there are questions to
 > be answered, such as whether the buffer name should be based on real name
 > or screen name, and so on.  i'm sure we can come up with solutions which
 > make sense.  but am i missing something more fundamental that needs to be
 > dealt with?

If a person has several buddy names, normally I would only want to see
them listed once.

 > >    Ideally (wish list) this should deal
 > >    with real name to buddy name translations as well.
 > 
 > not sure what you mean by this.

Well, if you do an invite operation, and ask that a person be invited,
a connected buddy name must be chosen for use.

 > > 5) Perhaps tnt should follow tik's lead and add the ability to store a
 > >    local copy of the buddy list that is either the only copy, backup
 > >    copy, or preferred copy.
 > 
 > i don't use tik, so i'm not sure how this works.  but certainly, it sounds
 > reasonable.

It all started with the problem that the server kept losing the stored
information.  Eventually four modes of operation arose.
A) Store the buddy list only on the server.
B) Store the buddy list only on the client, ignore the server.
C) Store the buddy list in both places, ignore the server, but write
it out each time.
D) Store the buddy list in both places, and use the server copy unless
it is empty.  This became the default when it was introduced.



-- 
      David Garfield
MAIL: da...@da..., div...@us...
WWW:  http://home.mgfairfax.rr.com/davidgarfield/
AIM:  divad314 divad31415