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

[Vlad Harchev]

On Fri, 15 Oct 1999, Klaus Weide wrote:

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

  Ok, let's forget. But let's hope that such situation won't apear again
some time in the future too.

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

 I tried to say that I don't do boolean expressions optimization in
preprocessor's conditionals yet:)
 
> > 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.

 As you should have noted, a lot of my changes are 'minimalistic' - they
add lines - mostly conditional statements around some code, but don't indent
that code. Sample:

was:

        foo(1); 
        foo(2);

after patch:

#ifndef NO_BAR
        if (bar_flag) {
#endif
        foo(1);
        foo(2);
#ifndef NO_BAR
        };
#endif

instead of properly indented:

#ifndef NO_BAR
        if (bar_flag) {
#endif
            foo(1);
            foo(2);
#ifndef NO_BAR
        };
#endif


 So, I was talking about proper indenting, not about unusual indenting.

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

  You are right.
 
> > And anybody can ask me what something means.
> 
> That's a nice offer.  How long will it be valid?

  You fear that I will leave lynx development some day (I don't say you are 
wrong)... Anyway, I will provide support (consultations).

> But it is irrelevent.  Nobody *should* have to ask you.

  Proper documentation of the code takes a lot of time. 

> And not everybody *can* ask you.

  Why?
 
>[...] 
> 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.

 OK. I didn't think you don't read diffs to lynx.cfg. Just set
STICKY_FIELDS:TRUE in lynx.cfg and you'll get old behaviour. If other
users/developers prefer old behaviour as default (IMO it's more logical to be
backward compatible), replace line in LYMain.c:

PUBLIC BOOL textfield_stop_at_left_edge=TRUE;

with 

PUBLIC BOOL textfield_stop_at_left_edge=FALSE;

  to make old behaviour the default.
My habbit to enclose all changes in cpp conditionals could help you to search
the LYReadCFG.c and find out that there are 2 settings regarding this. You
could also have searched 'textfield_stop_at_left_edge' in sources and discover
its default value... And I finally wonder, why the name 
'textfield_stop_at_left_edge' didn't inspired you about its destiny :)
 
> >  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.

 When that feature was added, there were a lot (2-3) messages from lynx-devers
that told that they prefer that new behaviour. Search the archive for
messages with "[PATCH 2.8.3.dev6] patch that will prevent returning to" in the
subject.

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

 I was a newbie to the lynx sources that time. I was not able to write the
analogous parser similar to SGML.c (I was not able to spent the amount of time
required to write such parser). But IMO SGML.c is not the hottest part of the
sources tree - modifications are done by a very few people, and very seldom. 
So, programmers' efforts (regrading studying SGML.c) are less signtificant
than the features/flexibility users get with syntax highlighter IMO.

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

  I'm glad to hear that you like psrcmode as a user:)
  As for places I chose for inserting new code - I hope you understand that I
don't try to seem clever when I chose places - I chose the places in which
it's more logically to insert the code (without breaking logic of the
original, and allowing the new functionality to mimic the same logic).
Sometimes I don't understand the logic in a whole...

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

  Who else? What for? IMO we shouldn't make the lynx code "a tutorial on
portable C programming" or "tutorial on programming console-based browsers" :)
I prefer to spend less time and produce smaller/faster 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?

 All open-source products are subject to extending and enchancing. IMO
denoting places that responsible for particular feature will help future
developers to understand and enchance lynx code. As you saw, I leave both
branches of conditionals (this is more than just providing marks) - yes, this
can be considered redundant (but this more consistent way of utilizing cpp
conditionals - isn't it?).

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

 I meant that if these marks thierself will be considered redundant, they can
be removed with the use of tools easily (rather than by hand).

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

 After you apply patches, the history of patching is lost (thou' can be
recreated by diffing the source trees). The use of cpp conditionals to mark 
places solves that problem. As You and I said, in most places it's easier to
remove the redundant conditionals with the use of tools.
 
> > 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?

 A sequence of 20 strcmps scared me (it was possible to use already known tag
codes and switch statement in that place). As I remember, there are several 
occurances of such code. May be it will make a difference on 386-SX20.

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

 Yes, this must be done. But I prefer to add more functionality than clean up
the code.

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

 PS: I'll sent the patch that will restore the old behaviour as default wrt 
STICKY_FIELDS - ie it will be possible to leave text field with arrow-left by
default.

 Best regards,
  -Vlad