Re: lynx-dev Re: Transport links between bookmark files...

[mattack]

On Mon, 5 Jul 1999, Klaus Weide wrote:
>Ok, some comments..
>
>Your patch also contains the change to LYMain.c (for -nonumber_links)
>which was already determined not to work.  (Did you see my reply to
>your question about that?)

CRAP. Sorry, I forgot I had changes in LYMain.c for this...  I had 
remembered to take out one other change from this.

So this obviously should be taken out since it doesn't work.

>Adding a bookmark entry to another bookmark should already be possible
>with 'a'.  So all your 't' does is replace 'a', 'r' with one key 't'.
>Is that right?  (I haven't really tested this.)

Mostly..  But it actually removes more keypresses than that..  

With your 'a', 'r' combination:
* After the 'a', it would prompt you for the name for the link.. Even if you
        just hit return, it's still another keypress
* After the 'r', it prompts you whether you really want to delete the link.
  Since it has already successfully added the link to the other bookmarks file,
        this prompt seems completely unnecessary to me as there is no loss of 
data
        possible.

>>From a user interface perspective, I would like 't' to remain reserved
>for a use like what it does in dired mode: "tag" some links for future
>action, without doing anything else; and leave it to some other

Well, I definitely didn't break the 'tag' function in dired mode.  I'm
not saying you accuse me of that..

I just thought that this was a useful key to attach it to, because 
't' seems mostly unused (sorry, I had to play around with looking at my home
directory to even figure out what the heck it did)...  and, I will admit, 
't'ransport was a "cute" name, because it transports a link from one file to
another (insert Star Trek Transporter sound mentally).  'm' (for move) was
already taken.

If you can think of a better key, please suggest it..  But I *really* want
the functionality.  I've already used it to add a little bit of sensibility
to my bookmarks files, which I _wouldn't_ have done if I had to edit the
files in an editor.

>The way you are reusing the LYK_TAG_LINK action code for your new
>function isn't good.  LYK_TAG_LINK should remain as a code for only
>what the name indicates.  Instead you should add a new LYK_something
>to LYKeymap.{c,h}.  You could then map that to 't', either by default

Well, I have no idea how to do this.   I admitted I don't really 'get' how
Lynx works.    What I figured so far was:

There's a table in LYKeymap.c (LYKeymap_t keymap), that looks like it 
attaches _each keycode_ (from the comments below each function tag) to
a specific function.

How can I add a new LYK_ code and still map it to 't'? (or whatever other
key is decided upon)   I will slightly defend myself in that LYK_DEL_BOOKMARK
_seems_ to be doing what I did -- it does 'delete bookmark' and 
      } else {  /* behave like REFRESH for backward compatibility */
So it seems to be putting multiple functionalities into the same keypress.

I had thought there was a one to one mapping between keys and functions 
in LYKeymap.c

BTW... Answers to these questions/suppositions of mine would be GREAT to 
put in a "how to begin to add a feature to Lynx" FAQ.  It sounds like I did
it wrong, but I was trying to copy what it looked like was already there.

>In fact your current code makes your function dependent on dired:
>LYKeymap.h has
>
>#ifdef DIRED_SUPPORT
>  , LYK_CREATE
>  , LYK_REMOVE
>  , LYK_MODIFY
>  , LYK_TAG_LINK

Crap, I didn't realize that.  I knew about the DIRED_SUPPORT stuff 
in the _actual tag code_, and I left that in for the actual tag code.


Why is LYK_TAG_LINK defined to LYK_UNKNOWN if DIRED_SUPPORT is off?
The actual code implementing DIRED_SUPPORT won't be compiled, so it
seems redundant.

>That means if someone compiles lynx without dired support it won't
>work.  Either our code would be invoked by any unrecognized key
>(but not 't'), or the compiler would complain about mainloop

So basically I guess this all boils down to how I put a new capability
in LYKeymap.c, and how I can (if at all) still map it to 't'.  I really do
like the 't' keypress since I certainly never used it before, but a logical
alternative (hopefully a mnemonically relevant key) is ok..

Waaaaaait..  I think I have answered my question above -- Can't I still
have it be named LYK_TAG_LINK (or rename all occurrances to something 
better like LYK_TAG_LINK_OR_TRANSPORT), but *take out* that definition
to LYK_UNKNOWN in LYKeymap.h?   That way, 't' would still map to LYK_TAG_LINK,
but the existing checks which already work determine whether you're tagging
(when looking at a local directory) or whether you're transporting (when
looking at any bookmark file).

I'm already starting to feel that I've lost the 't' key fight, so suggestions
are worthwhile (even if we make the default something else, there's existing
functionality to change the keybindings without recompiling right?)...

But I _really_ like the feature, and definitely think it would be useful to 
less sophisticated users, when implemented properly (mostly move the existing
code around to a different case label depending upon answers to above
questions).