On 13.02.20 09:57, Jürgen Spitzmüller wrote:
> Am Donnerstag, den 13.02.2020, 09:42 +0100 schrieb mn:
>> Problem is reverse search works, now, but neither intuitively by
>> looking
>> through the application, nor by reading the fricking manuals (of
>> which
>> UserGuide will not display, whether compiled by yourself (as Pavel
>> points out to be itself problematic on some Linux version) or
>> downloaded) coming with LyX, nor with the wiki documentation on the
>> web.
> So someone who has a Mac (this excludes me) and can verify the correct
> settings needs to update these places.
> This could also be you, mn.

I know, but that's easier said than done successfully.

As of now, I only see minimal chances of properly updating
Additional.lyx with small modifications.

First I need feedback on my findings regarding Mac setup:

1. Can someone confirm this experience?
2. If: What is my fault in misunderstanding what's written?
3. As: Is 'forward search' *really* not working with Skim?
   (it looks as if it should, and I just failed somehow, but maybe it's
just bug-broken in recent versions?)
4. What are actual bugs (those should not need documentation, as in
workarounds, but need fixing?)
5. etc.

*How should* these be fixed?

In Additional.lyx I see that the pre-conditional of filesystem location
and 'exact name'/'symbolic link' needs either addition to the
documentation; or by far
much better yet: LyX should be made to work regardless of location! I
guess I prefer but cannot force the latter? This can be written into
manual now, but should be removed again, preferably in the near future?

As the logical path in menus of either Tools>Preferences or
AppMenu>Preferences is a general difference between LyX/Mac and other
platforms, should all such occurrences be tackled? (Guessing there to be
a few.)

The critique of the passage containing 'automatic':
who wrote that, what's the rationale behind it, how did that come to be
and evolve? All I don't know, can't retrace now. In what way did it make
sense? Or does it make sense even now, and I just don't get it?

For reverse-search I'd have a preliminary idea on how to improve docs,
based on my current experience, which may be flawed. For forward search,
without feedback, I have no idea on how to start to do anything.

The Preferences workflow, in my opinion/taste, with currently: type
parameter, *then* 'modify', then 'apply'/'save' needs redesign, more
than documentation. Should that be left as is, or documented to
accommodate the complicated evolution of things? Seems again that
re-design of the dialogue would be the proper way?
How should that be redesigned? The actual coders on these parts haven't
said anything, yet.

Second, it seems very ill-advised to start working on huge chunks of
documentation, only to get them rejected or proven wrong. I don't want
to waste my time and yours yet again, as with retina-AppIcons; parsimony
on installed filesizes; or flaws with UserGuide contents preventing
display on certain systems, but demonstrating suboptimal includes on all

Small bits, with a feedback-loop on them: that I might/can do. For the
rest I need more help.

To reiterate:

- Reverse search works for me, but with deviations from documentation.

- Forward search does not work for me, regardless of any documentation.

Neither LyX-docs, LyX-wiki, nor things like the first search engine hits
on this, like:

Users as helpless as me would appreciate not only better documentation
of a too complicated workflow, but a streamlined and working workflow
within LyX to begin with.

If the above is confirmed, and/but that a redesign isn't interesting,
wanted, or possible, at least short-term, I could suggest
improvements/updates to documentation for reverse search in Additional.lyx.

(That is:
If the docs-team could either refrain from using file-format
corresponding to 'latest git' for 'change tracking', or accept a diff
from file-format current stable, or someone provides a working binary
corresponding to latest-git…)

For forward search I just have no idea…

lyx-devel mailing list

Reply via email to