[Freehoo-devel] [PATCH: freehoo] increased usability

[Anand Avati]

hi group,
small usability issues i found...

1. the autocompletion feature wasnt working all that great.. (it wasnt
totally context aware)

2. suppose you are talking with someone.. and her/his nick gets auto
'filled' in everyline.. after sending a good bye message to her/him, you
hit an M-<back> to clear the nick and about to type a new nick of
someone else, and before you start typing the new nick, you get a
message from anybody, and that causes the old nick to get auto-insert'ed
.. this happens even when u are simultaneoulsy talking with few people
simultaneously and switching conversations between them ..

<few more.. i'd rather explain the patch>

here's a patch which slightly tunes the user experience...

* the wrongly auto-inserted old nick was due to rl_do_undo() which was
  undo-ing the M-<back> in PRINTF_MESSAGE.. there was no need for
  rl_kill_text/rl_do_undo circus..

* the printf in PRINTF_MESSAGE was statically concatenating "\r" and the
  format string.. in case the format string itself isnt static it gives
  a compile error (ok ok, i hear you talking about security issues.. but
  all it needs is coding without being drunk :D)

* when i got bugged with the 'auto-inserting' of default buddy after a
  ?buzz or ?ping .. i thought an easy way of forcibly removing a default
  buddy was to enter an empty line... (just making sure the
  'auto-insertion' remains a 'feature' and not a 'pita')

  ps: this got to be documented in the user guide?

* the biggest part of the patch.. context specific autocompletion..
  the current autocompletion wasn't doing a good job... in that..
  a. nick autocompletion wasnt been made sure it was at the right 
     position (e.g: ?buzz <tab> works.. but ?buzz abcd <tab> also works
     which shouldnt)
  b. conference rooms weren't autocompleted.
  c. leading spaces before a command were not neglected.
  d. only static string checks could be done and not dynamic.. meaning
     ?conf-add roomaname buddy_name couldnt be done..
  
  the patch removes the string functions and uses regex to find the
  current context for the autocompletion..

  for e.g 

  ?buzz <tab> works, givign only buddies, ?buzz abc <tab> doesnt..

  ?forward <tab>, ?forward abc <tab>, ?forward abc def <tab> all work by
    giving only buddies

  ?conf-add <tab> gives conference list.. and ?conf-add roomname <tab>,
    ?conf-add roomaname abc <tab> gives buddies list

  ?send-file <tab> gives buddy list, ?send-file abc <tab> gives file
   list ..

   etc.. few more things are covered in the patch, and possibly many are
missed.. but adding them should be ease (see the regex strings on top of
interpreter.c)

  The context is decided by the current cursor position.. so if
the current line buffer is

  "?send-file  buddyname /path/to/filename"

  you can arrow back your way to buddyname from the end of string like

  "?send-file <tab> buddyname /path/to/filename" and still it works (it
should be like this i feel)

  the default autocompletion going to filename_completion is changed to
a new NULL returning function (doesnt feel nice if u hit tab in the middle
of typing a sentance and it gives u files in current direcotry)..
  also a line is left commented in command_generator() which when
uncommented makes the default action of <tab> (when not matched by any
other context as discussed above that is) to do buddy completion as
default.. this is particularly useful when u want to mention other
buddies names in middle of a sentance while messaging someone. (i leave
the decision to be taken by group)

ok, that's for now..
hopefully the s/string.h/regex.h/ hasnt introduced new bugs :D
and a check for regcomp() is added to configure.ac

regards,
avati

ps: patch is on the cvs version checked out on 14th feb 2005.

-- 

We will have solar energy as soon as the utility companies solve one
technical problem -- how to run a sunbeam through a meter.

context-autocomplete-misc.diff
Description: Text document