Haris: you mentioned that a command using a mouse is unacceptable. I do not understand this and I am intrigued, would you elaborate?
I also hate the mouse and love the keyboard, as any other respectable geek. But this is only because keyboard is much faster and much more accurate. But I have no ideological stance against the mouse. If at some point I find that using a mouse is much more convenient for some purpose, I use it immediately. E.g., I would not draw a picture using the keyboard (neither would you I guess).
So the point with the interface for labels is exactly that I feel the keyboard is not the faster tool for the task; clicking in a nice list is indeed faster. I should also mention that I proposed to the PDFView's brilliant developer (Andrea Bergia) to implement a click-on- the-formula feature (you click on the formula in pdf and the \ref is inserted in the tex file...)
Piero
On Dec 20, 2006, at 2:26 AM, Piero D'Ancona wrote:
Haris: you mentioned that a command using a mouse is unacceptable. I do not understand this and I am intrigued, would you elaborate?
I also hate the mouse and love the keyboard, as any other respectable geek. But this is only because keyboard is much faster and much more accurate. But I have no ideological stance against the mouse. If at some point I find that using a mouse is much more convenient for some purpose, I use it immediately. E.g., I would not draw a picture using the keyboard (neither would you I guess).
So the point with the interface for labels is exactly that I feel the keyboard is not the faster tool for the task; clicking in a nice list is indeed faster.
I guess this is where we disagree. I don't think clicking on the list is faster. If I am in the middle of typing a lot of stuff, I would have to stop that and move my hand to the mouse in order to click at the appropriate label, probably would also have to scroll around a bit.
This of course depends on the list we are talking about, and the way you use the keyboard to select an item. If you just use the arrow keys, and there are 100 items there, then of course it won't be as fast. If you use the first letters to narrow things down first, then it is faster I think. Further, in the context menu you have the option of using either the mouse or the keyboard, to make your selection. With the HTML window, you have no such option.
It's not a question of an ideological stance, I just don't think this labels thing is best accomplished via a mouse-only interface, at least not without an alternative. When writing math, the last thing on my mind is using the mouse.
As far as the HTML view is concerned, I actually think that you should make the entire text, instead of just the \label{..} parts, clickable. The user should be able to just hover over the correct block of text and click, instead of having to track down the small region where the \label part is. That would make it more usable imo.
Another idea would be to have the text, or perhaps more of the text, show up as a tool tip when you hover over an item in the HTML view.
I like the idea of having the HTML view as an optional method, after some polishing (like automatic updating in the background, perhaps different coloring of the equations or something like that), but I don't think it should be the only way, i.e. replace the existing label completion command.
I should also mention that I proposed to the PDFView's brilliant developer (Andrea Bergia) to implement a click-on- the-formula feature (you click on the formula in pdf and the \ref is inserted in the tex file...)
That is an interesting idea indeed. Though this might be a bit more editor-specific than the plain pdfsync. It would probably require some javascript calls. I would actually prefer it if somehow the \ref is passed to the clipboard, instead of being inserted directly into TM. It is probably also easier to implement, though I'm not sure the pdf file has this information at all.
Piero
Haris
Charilaos Skiadas <skiadas@...> writes:
It's not a question of an ideological stance, I just don't think this labels thing is best accomplished via a mouse-only interface, at least not without an alternative. When writing math, the last thing on my mind is using the mouse.
You speak words of wisdom. I guess having both alternatives would the best thing for everybody. I'm not polishing it since I'm waiting to see how much better the click-on-pdf might be.
As far as the HTML view is concerned, I actually think that you should make the entire text, instead of just the \label{..} parts, clickable. The user should be able to just hover over the correct block of text and click, instead of having to track down the small region where the \label part is. That would make it more usable imo.
The whole test underlined? wouldn't it be too ugly?
Another idea would be to have the text, or perhaps more of the text, show up as a tool tip when you hover over an item in the HTML view.
That's a very nice idea: to have only the list of labels to appear in the HTML window, and when I hover with the mouse the formula appears as a tooltip. Advantages: many more labels fit into the window, and cleaner interface. A disadvantage: more difficult to locate the right one without seeing the corresponding formula.
That is an interesting idea indeed. Though this might be a bit more editor-specific than the plain pdfsync. It would probably require some javascript calls. I would actually prefer it if somehow the \ref is passed to the clipboard, instead of being inserted directly into TM. It is probably also easier to implement, though I'm not sure the pdf file has this information at all.
Actually 6 line of code are sufficient to do the trick! If you prefer to have the reference in the clipboard, the lines drop down to 4 :) and it's not even editor specific, and requires no modification to pdfsync. The idea is that when you opt-click the pdf window, a script is executed; the script is accessible by the user anc can be modified (and has access to the internal variables of PDFView). A prototype script is the following (first three lines are just initialization and could be handled by PDFVIEW)
#!/bin/bash linenumber=1442 texeditor="TextMate" texfilepath="$TM_FILEPATH"
reference=$(sed -n "1,$linenumber p" "$texfilepath" | grep -o label{[^}]*} | tail -1 | sed 's/label/\\ref/' | sed 's/ref{(eq)/eqref{\1/')
exec osascript <<END tell app "$texeditor" to insert "$reference" END
Piero
On Dec 20, 2006, at 5:06 PM, Piero D'Ancona wrote:
As far as the HTML view is concerned, I actually think that you should make the entire text, instead of just the \label{..} parts, clickable. The user should be able to just hover over the correct block of text and click, instead of having to track down the small region where the \label part is. That would make it more usable imo.
The whole test underlined? wouldn't it be too ugly?
It doesn't have to be underlined. In fact, it would look just normal, but when the mouse is over it the whole block would be highlighted, and clickable. All it takes is a couple of lines of CSS. It could actually be made to look quite nice. And you can still have the \label part highlighted in some way.
Another idea would be to have the text, or perhaps more of the text, show up as a tool tip when you hover over an item in the HTML view.
That's a very nice idea: to have only the list of labels to appear in the HTML window, and when I hover with the mouse the formula appears as a tooltip. Advantages: many more labels fit into the window, and cleaner interface. A disadvantage: more difficult to locate the right one without seeing the corresponding formula.
Yeah the key advantage of the HTML view is that you can show a bit more of the context, so ideally that should be visible to some extend. Having just the labels would make it lose some of its advantages.
That is an interesting idea indeed. Though this might be a bit more editor-specific than the plain pdfsync. It would probably require some javascript calls. I would actually prefer it if somehow the \ref is passed to the clipboard, instead of being inserted directly into TM. It is probably also easier to implement, though I'm not sure the pdf file has this information at all.
Actually 6 line of code are sufficient to do the trick! If you prefer to have the reference in the clipboard, the lines drop down to 4 :) and it's not even editor specific, and requires no modification to pdfsync. The idea is that when you opt-click the pdf window, a script is executed; the script is accessible by the user anc can be modified (and has access to the internal variables of PDFView). A prototype script is the following (first three lines are just initialization and could be handled by PDFVIEW)
I guess I don't really know exactly what happens with the linenumber information. What is that number, and how does PDFView get that information out? I guess the same way it does for the pdfsync. But what happens if you click on an equation with no label, or if you click somewhere not an equation? And of course it does depend on the editor supporting the applescript insert call. It does look very plausible though. Looking forward to it.
#!/bin/bash linenumber=1442 texeditor="TextMate" texfilepath="$TM_FILEPATH"
reference=$(sed -n "1,$linenumber p" "$texfilepath" | grep -o label{[^}]*} | tail -1 | sed 's/label/\\ref/' | sed 's/ref{(eq)/eqref{\1/')
exec osascript <<END tell app "$texeditor" to insert "$reference" END
Piero
Haris
Charilaos Skiadas <skiadas@...> writes:
I guess I don't really know exactly what happens with the linenumber information. What is that number, and how does PDFView get that information out? I guess the same way it does for the pdfsync. But what happens if you click on an equation with no label, or if you click somewhere not an equation? And of course it does depend on the editor supporting the applescript insert call. It does look very plausible though. Looking forward to it. Haris
Yes, the line number is computed by PDFView using info from pdfsync, and it is already available as an internal variable. The prototype script just locates the first label BEFORE the formula you clicked on. This can be improved and will be if this thing starts working. The idea is that the script is user-modifiable and I guess there are pretty good wizards with script around here...
The applescript call has the advantage to cover a large number of editors in a very simple way, and the editors needs no change. I have another version that copies into clipboard and then pastes using System UI services. That's really universal, and really ugly (and slow).
I only hope Bergia will find the time to do the modification in the next weeks
Piero
P.S. oh, now I understand. I use a Powerbook, so for me using the mouse is very natural. Yes, on a desktop computer that's a different story. Hmm, maybe you're right after all...
On Dec 20, 2006, at 5:09 PM, Piero D'Ancona wrote:
P.S. oh, now I understand. I use a Powerbook, so for me using the mouse is very natural. Yes, on a desktop computer that's a different story. Hmm, maybe you're right after all...
I have an iBook, and even then I can feel the difference. My fingers still need to leave their normal position. And the trackpad really sucks if you have to use it for a long time. ;)
On desktops, the difference is even more clear. Haris
On Dec 20, 2006, at 7:35 AM, Charilaos Skiadas wrote:
My fingers still need to leave their normal position. And the trackpad really sucks if you have to use it for a long time. ;)
That is the one thing I truly hated about switching to the Mac: No pointing sticks on Apple keyboards. With pointing sticks, you can use your mouse without ever leaving the home row, which solves the very problem raised in this thread. I don't know why Apple doesn't understand this.
http://en.wikipedia.org/wiki/Pointing_stick
Trevor
-
Charilaos Skiadas -
Piero D'Ancona -
Trevor Harmon