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

[Klaus Weide]

On Mon, 5 Jul 1999 address@hidden wrote:
> On Mon, 5 Jul 1999, Klaus Weide wrote:
> >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.

Thanks for the clarification.  I suppose it is a useful feature for
some (for you at least :)), although personally I wouldn't mind the
extra keystrokes enough to really want it.

> >>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..

Yes, I didn't say that.  But establishing a binding for 't' that is
completely different (if it becomes canonical) breaks the possibility
to extend the dired 't' to do something beyond dired, with the same
'tagging' function and the same default key.

That has just been my pipe dream for a long time, to one day make
't'agging work beyond dired file URLs.  I think at least the
possibility should be left open.

> 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'm not sure which would be a better key.  But the good thing is that
you can have the functionality, and map it to 't' for yourself, and
also let others have the functionality and map it differently (or
not).  The flexibility is all there, especially if your function gets
more divorced from the dired 't' function.

> 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)

1.a) Invent a new LYK_foo symbol, LYK_TRANSFER_BOOKMARK_LINK or something
     (you'll probably prefer something shorter).  Add it somewhere in the
        typedef enum {
            LYK_UNKNOWN=0
        .....
     in LYKeymap.h. IMO no #ifdefing is needed.
  b) Also invent a user-visible name for this key action, and add it to
     the 'revmap[]' array in LYKeymap.c in the same place.  (Add a brief
     description, too.)  The user-visible name is for lynx.cfg KEYMAP
     and for 'K'eymap page display.  It can be just the LYK_foo symbol
     name stripped of the 'LYK_' prefix, but doesn't have to be.
  c) Change the implementation in mainloop() to be under a 
         case <your LYK_foo symbol>:

That's all that is needed to use your code.  No key is mapped to the
new function by default, but you can do that in lynx.cfg.  You should
also document it by adding a line there.

If you want to have a default binding in the code,

2.) just put it in the table in LYKeymap.c (LYKeymap_t keymap) you
    were referring to.

As long as you did that for 't' and/or 'T' only to the 'keymap' table,
but not to the 'key_override' table that follows it, the binding in
dired directory listings would be unaffected. (ignoring OK_OVERRIDE
here I guess, I never have tried what happens to dired if that symbol
is undefined)

>  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.

Yes, but IMO that is a bad precedent that shouldn't be emulated.
At least things would be clearer without this overloading.

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

It is more flexible than one to one.  Many (or zero) lynxkeycodes
('keys') can be mapped to the same lynxactioncode ('function').  The
same lynxkeycode can be mapped to different funtions in different
situations (either by using the 'key_override' table instead of the
'keymap' table when in dired mode, or by dynamic changes to the table
- see {set,reset}_{vi_keys,emacs_keys,numbers_as_arrows}).

> 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.

You know better than I what is missing (or too hidden) and would be
helpful, since you are just going through it for the first time.
Please write the "how to make a new function and bind it to a key"
section of that FAQ, if you think it should exist. :)

> >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.

Afaics that's just a trick to make the 'keymap' and 'key_override' tables
a bit shorter and more readable.  Without this, they would have to have
alternative versions for the lines with 't' and 'T'.  Other keys that
can be completely disabled could use the same trick but don't, see
for example the lines ifdefd with USE_EXTERNALS.

> >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..

Doing it the way I outlined, you can implement it now without waiting
for agreement on The Right Keybinding.
 
> 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).

Yes, you could do it that way, but why?  It seems less clear and flexible
to me.  And it would do what I would like to see avoided, i.e. preempt
a non-dired LYK_TAG_LINK that really would tag links.

You would also only have one 'K'eymap page description for the LYK_TAG_LINK,
unless special tweak are made to the code that generates the 'K'eymap
page.

> 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).

I hope this helped,

   Klaus