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

[Klaus Weide]

On Mon, 5 Jul 1999 address@hidden wrote:

> I've never done this before (or even used diff much), so please inform me
> about what I'm doing wrong, while hopefully not blowing my idea out of the
> water..
> 
> So, basically:
> 
> When you are viewing a bookmark file, you can hit 't' to transport the
> current link to another bookmark file.  I have covered the error cases
> I could think of, and tried edge cases (first link, last link).  It even 
> allows a lame way to very slowly reorder your links within one bookmark
> file (though you must have multibookmark mode on) by selecting the same 
> file...  It'll move that bookmark to the end.

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

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

>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
mechanism (menu etc.) to decide what do do with them.  There are
various functions for which this could be useful - including
eventually moving bookmark entries in bulk, if someone just
implemented it.  Or bulk uploading, bulk external command invocation,
whatever makes sense for someone to implement.  And the code tracking
which URLs are 'tagged' is already general (i.e not restricted to
local files), it's just that possible actions are only implemented for
local files.

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
or by lynx.cfg, but it would be logically separate from the TAG_LINK
meaning.  This would also take care of showing a more appropriate
description on the 'K'eymap page.  And the key binding in dired mode
can be different from the normal binding, the mechanism for that is
all 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
  , LYK_UPLOAD
  , LYK_INSTALL
#else
#define LYK_TAG_LINK      LYK_UNKNOWN
#endif /* DIRED_SUPPORT */

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
(case LYK_UNKNOWN: effectively appears twice in the same select).


   Klaus