Opened 22 years ago
Closed 13 years ago
#94 closed enhancement (fixed)
LYX forward DVI search.
Reported by: | levon | Owned by: | |
---|---|---|---|
Priority: | low | Milestone: | 2.0.0 |
Component: | converters | Version: | 1.4.0cvs |
Severity: | minor | Keywords: | |
Cc: | j.spitzmueller@…, mmh@…, christian.ridderstrom@…, georg.baum@…, forenr@… |
Description (last modified by )
From: Stefan Kebekus <stefan.kebekus@…>
I have recently added an inverse search option to the
kdvi program, and
I would like to ask you to support that feature in Lyx.
The current
development version of kdvi (to be found on the KDE
CVS) scans a
dvi-file for specials of the type
"src:<linenumber><filename>". If these
specials are found, the user can click into the dvi
file, and kdvi will
execute a given command line, which -most of the time-
opens an editor
and tells the editor jump to the given line in the
text. Right now, kdvi
interacts very nicely with most of the standard
editors, such as nedit
or xemacs.
It would be very nice indeed, if Lyx could also be
supported. A possible
implementation could look like this: when producing
dvi-files for kdvi,
the TeX-file-generator of Lyx could insert proper
"src:"-specials which
refer to a paragraph (I understand that there is no
concept of a line
number in the Lyx editor). If the user clicks on the
dvi file, kdvi
could start a small program which remote controls the
Lyx editor.
If you prefer, I would also consider to implement a new
class of
TeX-specials exclusively for Lyx.
Attachments (4)
Change History (43)
comment:1 by , 22 years ago
Keywords: | ui added |
---|---|
Summary: | LYX, KDVI and inverse search. → LYX, KDVI and inverse search. |
comment:2 by , 22 years ago
Cc: | added |
---|
comment:3 by , 22 years ago
comment:4 by , 22 years ago
Version: | 1.2.0cvs → 1.2.0 |
---|
Mass move to 1.2.0 - grep out the bugspam with "Dharma ex one+one"
comment:5 by , 22 years ago
This is dependent on a lyxserver shell script or equivalent. I bet it
would be pretty easy to do though, right ?
comment:7 by , 22 years ago
Cc: | added |
---|
comment:10 by , 21 years ago
Keywords: | patch added |
---|---|
Owner: | changed from | to
Version: | 1.2.1 → 1.4.0cvs |
comment:11 by , 18 years ago
Milestone: | → 1.4.1 |
---|
comment:14 by , 18 years ago
Milestone: | 1.4.2 → 1.4.x |
---|
comment:15 by , 17 years ago
Do we really want to have such a feature in LyX?
I am a little bit afraid of the long-term maintenance effort and the missing
genericness of this feature. (How about pdf export, how about yap on Windows,...?)
comment:16 by , 17 years ago
Do we really want to have such a feature in LyX?
Definitely. It would improve editing a lot.
comment:17 by , 17 years ago
I definitely think this functionality is worth maintaining.
Without it, LyX has a big drawback compared to WYSIWYGI
applications when it comes to checking the "print" output.
comment:18 by , 17 years ago
attachments.description: | sef → spam, changed MIME type /Christian |
---|---|
attachments.mimetype: | text/html → application/spam |
comment:19 by , 17 years ago
attachments.description: | sef → spam, changed MIME type /Christian |
---|---|
attachments.mimetype: | text/html → application/spam |
comment:20 by , 17 years ago
attachments.description: | Ups → Spam, changed MIME type /Christian |
---|---|
attachments.mimetype: | application/octet-stream → application/spam |
comment:21 by , 17 years ago
Milestone: | 1.4.x → 1.5.x |
---|
Moving all bugs targeted to before 1.5.0 to 1.5.x.
If these are yours, please check that they have not been fixed and, if so, close
them.
Otherwise, sorry for the spam.
comment:22 by , 16 years ago
Cc: | added |
---|
We had a patch for this. It would be good if someone would finally grab and
apply it (even for 1.5, i.e. after 1.5.4).
comment:23 by , 15 years ago
Milestone: | 1.5.x → 1.6.x |
---|
1.5.x is frozen. Shifting all 1.5.x-targetted bugs to 1.6.x.
If you have reported this bug, please verify if it still occurs in 1.6.0 and
close the report, if not.
comment:24 by , 15 years ago
Georg, what was the problem with your patch that it finally didn't get applied?
comment:25 by , 15 years ago
The patch was not from me, I only tried to make it more consistent with the
formats/converter system :-)
It did not get applied because there was no consensus which approach was best.
Read the thread for details.
comment:26 by , 15 years ago
i already run through the thread and somehow missed there was such a problem.
thanks for explanation.
comment:27 by , 15 years ago
Summary: | LYX, KDVI and inverse search. → LYX forward DVI search. |
---|
inverse search works, this bug is now for forward search part. changing summary.
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg150369.html
comment:30 by , 15 years ago
Priority: | normal → low |
---|
comment:31 by , 14 years ago
Cc: | added |
---|
simplest idea would be to have lfun which get id of current cursor position, translate through TeXRow::getRowFromIdPos into row and then externally launch
xdvi -sourceposition row_line:tmp_tex_file.tex tmp_tex_file.dvi
it maybe not hard for somebody familiar with the rows/id stuff, Enrico?
comment:33 by , 14 years ago
i give it a try, but failed. either i dont know how to correctly use texrow().getRowFromIdPos or this function is broken. see attached.
by , 14 years ago
Attachment: | forward.patch added |
---|
comment:34 by , 14 years ago
Milestone: | 1.6.x → 2.0.0 |
---|
hohoho i replaced the patch with newer version; right paragraph is chosen now, but the column position argument still needs to be fixed.
i believe we can get this into 2.0.
comment:35 by , 14 years ago
It also works on Windows with yap. Of course, some details are still to be addressed, such as making sure that the dvi file was generated, allowing customization for the command to be launched, and so on. Anyway, I like it :)
I don't understand what you mean about the column position argument.
comment:38 by , 13 years ago
Keywords: | fixedintrunk removed |
---|---|
Resolution: | → fixed |
Status: | new → closed |
2.0.0 is ready
comment:39 by , 10 years ago
Component: | export → converters |
---|
* #410 has been marked as a duplicate of this bug. *