[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#24842: 24.5; `help-make-xrefs': False link-type determinations
From: |
Drew Adams |
Subject: |
bug#24842: 24.5; `help-make-xrefs': False link-type determinations |
Date: |
Sun, 5 Feb 2017 11:27:10 -0800 (PST) |
> 1. One possible approach is to improve the behavior. I have not tested
> this generally, but changing the `cond' clauses to include the test
> for type and for documentation as part of the `cond' test, instead of
> being part of the result clause after the test, fixes at least the
> immediate problem of the above example.
>
> For example, instead of:
>
> ((match-string 4) ; `function' &c
> (and (fboundp sym) ; similarly
> (help-xref-button 8 'help-function sym)))
>
> use this:
>
> ((and (match-string 4) ; `function' &c
> (fboundp sym)) ; similarly
> (help-xref-button 8 'help-function sym))
>
> Similarly for the other clauses.
>
> Possibly this does not DTRT generally, since it lets subsequent
> `cond' clauses get tested if the code cannot determine that the
> symbol is a variable, function, etc.
>
> But that's the point of those clauses. If they cannot find that some
> symbol is a variable, etc., then shouldn't the subsequent clauses be
> tried? (The tests might need to be improved. Dunno.)
>
> Again, I have not tested this, so I don't propose an exact code fix.
> I'm reporting the bug.
I've been using this for a while, and it seems to be an improvement.
I have not noticed any bad cases. Can you please consider making
this change? I think the logic is better. Or can you point to a
case where it is not an improvement?
Thx.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- bug#24842: 24.5; `help-make-xrefs': False link-type determinations,
Drew Adams <=