Re: lynx-dev megapatch to dev.10 - and a rant

[Klaus Weide]

On Thu, 14 Oct 1999, Vlad Harchev wrote:

> On Thu, 14 Oct 1999, Klaus Weide wrote:
> 
>  Very pleased to hear your reply, Klaus (you ignored a lot of my private email
> - thou' their content was the same - 'when do you plan to release TRST?'). 

Ignoring you was the most friendly response to your repetitive nag messages
that I could come up with.

Let's forget that, okay?

>  The description of the algorithm used is supplied with w3m in doc/STORY.html.
> Here is an _entire_ relevant part (note: it was rendered with justification
> and hyphenation enabled :)

Thanks.  I haven't yet tried to ingest and digest it.

> >    ------------
> > 
> > Btw Vlad, while doing that merging of my older changes I found
> > that there are some pieces of code that have become IMO completely
> > unreadable, and some of your changes are foremost...
> 
>  What do you mean by 'foremost'?

'The most glaring examples'.

> > Some examples
> > 
> > (1) in HText_appendCharacter
> [...]
>   I hoped that writing cpp conds that resemble human language (ie without
> boolean expression optimization) will be more understandable.

I don't know what that sentence means.

> Probably indenting could help. 

I don't think so.  If you indent the same thing differently from the style
used in most of the code, it may just get even more confusing.

> And as I remember this way (in this particular case)
> required less changes to source code.

And that is not a good argument for leaving it that way.

I understand how this happens.  I do it too: just throw in some more
preprocessor or other conditions and change the rest as little as
possible.  It's tempting.  I'm pointing out that in this case the
result is an unreadable mess.

In my opinion.  If it's just me, I hope someone else will set me
straight...

> And anybody can ask me what something means.

That's a nice offer.  How long will it be valid?

But it is irrelevent.  Nobody *should* have to ask you.
And not everybody *can* ask you.

> > (2) in form_getstr
> > 
> >             case LTARROW:       /* 1999/04/14 (Wed) 15:01:33 */
> >                 if (MyEdit.pos == 0 && repeat == -1) {
> >                     int c = YES;    /* Go back immediately if no changes */
> > #ifndef NO_NONSTICKY_INPUTS
> >                     if (sticky_inputs
> >                      && !textfield_stop_at_left_edge)
> > #endif
> >                     if (strcmp(MyEdit.buffer, value)) {
> >                         c = HTConfirmDefault(PREV_DOC_QUERY, NO);
> >                     }
> >                     if (c == YES) {
> > #ifndef NO_NONSTICKY_INPUTS
> >                         if (textfield_stop_at_left_edge)
> >                             goto again;
> > #endif
> >                         return(ch);
> >                     } else {
> > 
> > Again, I don't get it.  In fact it seems to be wrong, and seems to
> > have the result that now - with the set of macros I have compiled
> > with *which do not include anything about `STICKY'* - I get *trapped*
> > in form fields without a prompt to escape.  But the logic is too
> > convoluted to see easily what's supposed to happen.
> 
>  What does 'get trapped' mean - does this mean that you are completely locked
> in the field?

It means I can't return to the previous doc with left arrow.

> Here is a background: STICKY_INPUTS - controls whether the text
> inputs should be activated before editing (if is TRUE, then they should be
> activated, if is FALSE, the inputs are already "activated"), STICKY_FIELDS -
> controls whether you can leave the current document by pressing arrow-left in
> already-activated input (if is TRUE, then user will be unable to leave
> activated text input with arrow-left, if false then will be able).

At this point I don't care to criticize all that "sticky stuff", that
would be a whole different mess(age).

*All I want is the previous behavior back*.  That's how I aproached that
section of code.  I was even prepared to define some NO_ macro should
that be imposed now by you.  But I look at the code, and I can't even
figure out without a major study effort what I have to do or whether there
_is_ anything I can to to get the previous behavior back.  *I want to get
the PREV_DOC_QUERY prompt* if necessary, answer with Y or N, and then see
lynx react accordingly.

>  I compiled lss-enabled dev10 with your patch applied and tested all 4
> combinations of settings - all works as expected. You can leave text input by
> pressing ENTER or 'arrow-up|down'. So, the existance of other links on the
> page guarantees the exit from text input (so the user will be trapped on the
> page that contains only one input field and no hyperlinks).

There aren't always other links.  But anyway, I know how I can get out of
that situation.  The point is, I want the old behavior.  It was fine for me.
In fact I don't see your STICKY_FIELDS improve something for *anyone*.

I'd like to see *one* person besides you who finds it useful that you
have taken away the flexibility of a prompt and replaced it by a
configuaration choice between fixed always-yes or always-no behavior.

(But again the original point was I couldn't even see what you had intended.
I'm still not sure.)

   ---------------------------------------------------------------

> > (3) a lot in SGML.c - 'nuff said.
> 
>  I don't see any other way of implementing rather powerfull syntax highlighter
> (that uses that same rules as lynx when parsing) without a lot of
> efforts/pain.

a) Leave 'powerfull' to marketing people please.
b) Did we *need* such a syntax highlighter?
   It's a gimmick.
c) Ok, I find it *is* kinda nice to have.  It's still a gimmick.
d) It does *not* automatically "use the same rules as lynx without
   parsing" without a lot of pain.
   It did take pain and effort to get it as right as now.
   The ifdef-bloated code increases the amount of pain in this world.
   It still doesn't always use the same rules as "lynx when parsing".
e) You could have started with a clone of (the relevant parts of)
   SGML.c, instead of fitting an additional, and quite different, 
   requriement into the existing one.

So, I would not have done it that way.  (If I had wanted a syntax
hightlighter like that, and had had an idea for it.)  I would have
not pursued it, or would have left SGML_character alone.

Just since you were asking...  (well not literally.)

But I was not complaining that we now have a prettysrc mode.
I was complaining that it's hard to parse for the human reader.
And that may be exactly because you try to not change existing
lines, but you try to insert your new lines into to middle of existing
code in some clever way.

> Klaus, you understood how it works, you updated it, so why the
> question? I can explain how it works to any lynx developer.

Vlad, you should know to give better answers than that.

Yes I figured out post-Vlad SGML.c, but it was far from easy.
I know how to use emacs' hide-ifdef mode, and command that move
over structured lists.  And I knew the structure of the code before.

I tend to think that if I find it difficult to keep track of which
ifdef variant is in effect for a gtoup of lines, some other people
will also find it difficult and yet more will find the code completely
unapproachable.

And "I can explain it" is irrelevant.  Why do you think only "any
lynx developer" should be able to understand the code?

> > This proliferation of newe proprocessor macros to control some
> > micro-feature is A Very Bad Thing.  Particularly when they are
> > logiccal negatives and are used in complex logical combinations
> > with other conditions, preprocessor and runtime.
> 
>   I use macro conditions for things like NO_DUMP_WITH_BACKSPACES mostly to
> mark the places of changes (it's much easier to grep for code responsibe for
> that thing, isn't it?).

So your output (as it has ended up in the dev. code) is not a final
product, it is just an intermediate stage?

> As I remember, I posted cpp condition simplifier (as
> awk script, that remove 'conditionals with constant value' - just tell it that
> NO_DUMP_WITH_BACKSPACES is always 0 and pass a code through it - thou' it
> can't handle expressions like x || y).

Why do you bring that up?  I am talking about the code that is distributed
in the dev.N .tar's and .zip's, not about anything one could hypothetically
make out of that with this or that tool.

> As for negatives, Tom is making
> substitutions as I understand (when patches are applied).

Apparently not, in these cases.

(Even if he does, you could save him the work.)
 
[ muchsnipped ] 
>  As I said, I use cpp conditions to denote places with changes. 

And I think what ends up in the lynx code for general distribution should
be reasonably readable C, and conditional code should be used in a logically
straightforward way, not for "denoting places".

I am quite sure Tom doesn't need special macros for denoting where you
made changes.  Diff and so on make that unnecessary.

> And I'm sorry
> for OPT, OPT1 - these was an attempt for optimizations. I hope I will clear
> them one day.

Yes I see they are intended that way.

I don't know why you felt the need to do anything for optimization in
SGML.c - did you have any indication that it was too slow?

But having both versions in the code for a prolonged time is
anti-optimization.

Try it again with OPT defined, maybe it works now.  (I changed something
that may or may not have fixed the 'something wrong' - but didn't try it
at all.)

>  As for psrc mode - did you fixed it to handle XML-like input?

I think I made it act in a resonable way, but better than ask me -
test it.

   Klaus