Texmaker doesn't like filenames with spaces
-
the look of spaces in filename
Yeah, well I dislike the look of air on my lawn. *shakes an onion at the air angrily*
-
-
My guess would be somebody fixed the bug but forgot to tell anyone else about it. Maybe someone should let them know that they don't have to be afraid anymore.
-
Not being able to use a filename with spaces or accents in it?
What I'm surprised about is that you never run into that problem before. Could it mean... that software is getting better?
(no)
-
I'm just here waiting for the standard Blakey
on how LaTeX is an archaic piece of junk.
-
I've run into the issue before, but the fact that it's still a problem is tr
Again, I agree with Blakey about the filename business. Files should be able to have any name. It just sucks.
-
Okay so that's nice and all but what does it matter that such a feature exists in a language with so many other flaws that nobody uses it?
-
There are still shells around without TAB completion for filenames?!
I don't use tab completion much. Still much faster for me to typebscthesis.texthan type a few letters, TAB, are we there yet, TAB, are we there yet, TAB, are we there yet...My guess would be somebody fixed the bug but forgot to tell anyone else about it. Maybe someone should let them know that they don't have to be afraid anymore.
There is only one developer AFAIK.
-
I don't use tab completion much. Still much faster for me to type bscthesis.tex than type a few letters, TAB, are we there yet, TAB, are we there yet, TAB, are we there yet...
If it's a file you use frequently, it shouldn't be too hard to figure out just how many characters you have to type to make the prefix unique. In fact, habit forming should make that almost automatic.
When I am debugging my code at work, I have to launch a webserver (Jetty) so often that typing cd \prTAB\jTAB into a shell happens almost completely from muscle memory and I dare say is a lot faster than spelling out the entire path \Program Files\Jetty. And I know for example that the "prTAB" is neccessary, because just "pTAB" would resolve to something else.
-
I'm just here waiting for the standard Blakey
on how LaTeX is an archaic piece of junk.
Um, well, it is archaic. I remember seeing stuff talking about it when I first touched a machine running Linux, nearly 21 years ago.The "piece of junk" part, I'll leave to other people to evaluate.
-
@marczellm said:
I don't use tab completion much. Still much faster for me to type bscthesis.tex than type a few letters, TAB, are we there yet, TAB, are we there yet, TAB, are we there yet...
If it's a file you use frequently, it shouldn't be too hard to figure out just how many characters you have to type to make the prefix unique. In fact, habit forming should make that almost automatic.
When I am debugging my code at work, I have to launch a webserver (Jetty) so often that typing cd \prTAB\jTAB into a shell happens almost completely from muscle memory and I dare say is a lot faster than spelling out the entire path \Program Files\Jetty. And I know for example that the "prTAB" is neccessary, because just "pTAB" would resolve to something else.
On 64-bit Windows, \prTAB is ambiguous... ("Program Files" and "Program Files (x86)"). On my machine at home, it's also, um, (coins word with no etymological basis) amtriguous, because I also have "projects" in the root of C:...
-
And that's why TAB cycles through the possible completions; just keep pressing it ;)
-
I never said the particular example I made works for everyone; just that it works for me. The point I was trying to make is, that you can figure out (by trial and error perhaps) the minimal prefix that will bring up the desired result on the first press of the TAB key. Especially for often-used files or paths this can be a time-saving investment.
In the case of "Program Files" and "Program Files (x86)" I might instead exploit the fact that "prTAB" resolves the former and "prTABTAB" to the latter (in my specific scenario - you might have to use the prefix "prog" instead) should I ever need that - it's still better than typing it all out by hand.
-
-
On 64-bit Windows, \prTAB is ambiguous
Except that in my experience, it always picks Program Files first, and then a second tab goes to Program Files (x86). If you know your program is in the 64-bit directory, no problem, always one tab, otherwise always two.
-
On 64-bit Windows, \prTAB is ambiguous... ("Program Files" and "Program Files (x86)"). On my machine at home,
Instead of starting from the root of the drive, you could just shift-right-click the folder you want to work in and choose "Open Command Window Here". The GLORIES and WONDERS of a GUI!
Of course you could just also keep the folder open and put a shortcut to the tex-whatever .exe on your desktop and drag-and-drop. But I'm guessing the shitty asshole open source developers who made that tex application fucked-up drag & drop somehow.
it's also, um, (coins word with no etymological basis) amtriguous, because I also have "projects" in the root of C:...
Well don't do that. Don't put shit there. They're YOUR projects, they belong somewhere in your user folders.
-
And that's why TAB cycles through the possible completions; just keep pressing it
In fact I find the cycling through like cmd.exe does it really annoying. I much prefer the "complete up to the first ambiguous letter" approach, like bash does it:
/u TAB ->
/usr/
lo TAB ->/usr/local/
bi TAB ->/usr/local/bin/
py TAB ->/usr/local/bin/python
no space at end so TAB again ->python python2 python2.7 python3 python3.3 python3.4
2. TAB ->/usr/local/bin/python2.7
ENTERAlso, I often use tab completion after having written out most of the name, to just to make sure I got the spelling right.
-
Then you might be interested in this:
How to make Windows tab completion work like on Linux?
In the Windows 7 command line, pressing TAB completes to the first matching item (ie, folder or file). In most Linux shells I am aware of, like bash, TAB completion completes only up to the charact...
Or not; I'm just putting it out there ;)
-
Thanks, looks interesting, will have a look at it!
-
But I'm guessing the shitty asshole open source developers who made that tex application fucked-up drag & drop somehow.
Sort of. The TeΟ tools assume they're running as some sort of pipeline, so although they do take a filename as an argument (which drag-drop passes), by default they write their output tostdout, ready for consumption by the next tool -- or in this case spewed into an instantly-closing console window. One could write a batch file with the appropriate pipes between tools, with a redirect at the end, and use that as the drop target just fine.
-
In fact I find the cycling through like cmd.exe does it really annoying.
The last time I used Unix-style shells, they had the same effect. Oh, they'd tab to the next ambiguous character like you describe, but if you hit tab repeatedly, they'd cycle through all potential matches--only they would do it based on $PATH, so you could get matches to files/programs in other directories.
-
My shell does not exhibit this behaviour. It just displays a list of all files or directories that start with the letters already typed.
-
Sort of. The TeΟ tools assume they're running as some sort of pipeline, ...
What?!? No!
latex filename latex filename latex filename dvips filename.dvi ps2pdf filename.psThe output contains info about what it is doing and any error messages.
One reason that dragging a file into a shortcut may not work, is that latex expects the CWD to be the directory where your latex file/project is, when you include other files into your top-level tex file (and also graphics).
-
The output contains info about what it is doing and any error messages.
But does it print that stuff to stdout or stderr?
-
I went the other way - I made my mac cycle more like windows. In ~/.inputrc:
set completion-ignore-case on
set show-all-if-ambiguous on
TAB: menu-complete
-
But does it print that stuff to stdout or stderr?
I don't have texlive on my Windows machine here, but on Linux it prints all of its information to stdout. So you cannot use stdout to pipe the output dvi to another program directly. i'm going to assume that the Windows version is the same.
-
@Steve_The_Cynic said:
On 64-bit Windows, \prTAB is ambiguous... ("Program Files" and "Program Files (x86)"). On my machine at home,
Instead of starting from the root of the drive, you could just shift-right-click the folder you want to work in and choose "Open Command Window Here". The GLORIES and WONDERS of a GUI!
Even if I already have the command window open, and just change where I am? Well, no. I'd wander through to the parent of the directory I want to be in in Explorer, then drag the folder over the command window having typed cdSPACE, then press ENTER.Of course you could just also keep the folder open and put a shortcut to the tex-whatever .exe on your desktop and drag-and-drop. But I'm guessing the shitty asshole open source developers who made that tex application fucked-up drag & drop somehow.
If they fucked up that particular drag-and-drop, then they fucked up using it in a command-line context, because the shortcut itself will handle the drag and drop and turn the operation into "run texdoodad.exe with the name of the dropped file on the command line"...@Steve_The_Cynic said:
it's also, um, (coins word with no etymological basis) amtriguous, because I also have "projects" in the root of C:...
Well don't do that. Don't put shit there. They're YOUR projects, they belong somewhere in your user folders.
It's my machine. I don't share it with anyone, so I can put them where the fucking fuck I want, like where they were when they were on a machine with Windows 95. You know, so I don't have to fuck about fixing up the location inside VS projects and crap like that. OK?(I expect it to more or less just work, but I've seen enough flaky behaviour from Visual Studio and other IDEs over the years to be not 100% certain of that, and I'd rather not find out that I've done something stupid somewhere either. Call it laziness.)
-
You know, so I don't have to fuck about fixing up the location inside VS projects and crap like that.
It wouldn't be an issue if the .sln and .*proj files used relative paths
-
So you have UAC turned off also. Great.
-
I've got miktex on my Windows machine here, and the CLI tools it comes with write their results to stdout and their messages to stderr. Unless there's a "-o outputfilename.ext" in their arguments list, or the command processor picks up on a "> outputfilename.ext" and does the right thing, that results in console window spam instead of a file.
-
Which means we want to avoid his software at all costs - since it was developed on a machine with essential security features disabled, it probably won't work properly on a machine where they're on as they're supposed to. May not work when installed into a sane path either.
Course that's a moot point if he's not writing end-user application software.
-
The software I write professionally doesn't even run on Windows, and your line of so-called reasoning rests on an invalid assumption anyway, since I didn't deactivate UAC. I'm only six kinds of stupid, and wanting to deactivate UAC for convenience is the seventh... But whatever. Think what you like.
-
It wouldn't be an issue if the .sln and .*proj files used relative paths
They do. At least mine do and I haven't done anything special... (Oh, my .*proj files are all .vcxproj. So at least C++ does it right!)
-
Also, "Open Command Window Here" almost certainly will not work on anything under
Program Files[ (x86)]because it needs to be launched as administrator to do anything. And because there is nosudoor equivalent, you pretty much need to run the shell as admin andcdto wherever you needed to go.
-
Luckily, they've already thought of that
-
That's true, but that was only recently(ish) added.
Also I forgot about it. So. Yeah.
-
Weird because I just tried out drag-n-dropping a .tex file to a pdflatex shortcut. It wrote the PDF and the log and auxiliary files in the D:\Program Files\MiKTeX\miktex\bin\ directory next to the executable. Nice.
One reason that dragging a file into a shortcut may not work, is that latex expects the CWD to be the directory where your latex file/project is, when you include other files into your top-level tex file (and also graphics).
Yep.
