>> Insert header in every page of the document with file path, date
>> last saved, insert page footer with page number and total number of
>> page of the document etc...
>
> And if this header was customisable with TM_* variables (and some new
> vars), etc etc, that would be great.
I second this idea, and I also think that print options should be
relatively simple: use the document font and tabs, and allow a choice
of printing with syntax highlighting on or off (or just use the
greyscale Quartz filter). There should also be an option to print to
PDF, as in the standard MacOS X Print dialog.
Would it also be possible to print from the web preview? I often write
short notes for others in Markdown, so that I can send them a
marginally more pretty version to them as hard copy or PDF, but keep a
simple text file for myself. It would be nice to be able to print it
from the rendered web preview, without having to render it as a
separate HTML file, open that in a browser and print from there.
Jackie
--
Jackie Chappell
jmchappell(a)mac.com
Hello,
I am trying to improve the syntaxe for the Latex bundle. However, I am not familiar with plist.
In addition to structures of the type
\begin{..}
\end{...}
I would like to add a folding of the \section, \chapter, \subsection structure.
For this, I thought of adding in a snipped a line at the end of these structures which would be considered as a comment by Latex:
\section{This is a section}
%\end-section{This is a section}
\section{A new section}
....
I have tried to modified the current Latex.plist to :
<key>foldingStartMarker</key>
<string>(\\begin\{.*\}|\\(((sub)*section)|(chapter)|(paragraph)|(part))(\*?)\{.*\})</string>
<key>foldingStopMarker</key>
<string>(\\end\{.*\}|%\\end-(((sub)*section)|(chapter)|(paragraph)|(part))(\*?)\{.*\})</string>
However, this does not work very well as if there is any substructure in a \section of the type (\end{equation}, for example), the folding occurs from \section to \end{equation}.
Anybody could tell me how to correct that??
I thank you in advance!
Normand Mousseau
I am trying to improve the syntaxe for the Latex bundle. However, I am not familiar with plist.
In addition to structures of the type
\begin{..}
\end{...}
I would like to add a folding of the \section, \chapter, \subsection structure.
For this, I thought of adding in a snipped a line at the end of these structures which would be considered as a comment by Latex:
\section{This is a section}
%\end-section{This is a section}
\section{A new section}
....
I have tried to modified the current Latex.plist to :
<key>foldingStartMarker</key>
<string>(\\begin\{.*\}|\\(((sub)*section)|(chapter)|(paragraph)|(part))(\*?)\{.*\})</string>
<key>foldingStopMarker</key>
<string>(\\end\{.*\}|%\\end-(((sub)*section)|(chapter)|(paragraph)|(part))(\*?)\{.*\})</string>
However, this does not work very well as if there is any substructure in a \section of the type (\end{equation}, for example), the folding occurs from \section to \end{equation}.
Anybody could tell me how to correct that??
I thank you in advance!
Normand Mousseau
Emailed VersionTracker earlier today and just got this reply:
>
> On Oct 23, 2004, at 2:06 AM, Allan Moult wrote:
>
>> How come you haven't got TextMate listed?
>
> Good pointer - just got it. Thanks for keeping us on the ball, and
> have a great weekend!
> --
> Michael Kincaid - Mac Content Editor
> VersionTracker: http://versiontracker.com
Looking forward to the feedback.
Allan [the other one]
Hi All,
In the project drawer, a right-click on a file icon opens a dialog
where one can find :
Treat Files with ".xxx" Extension as Text
Where does TM store this infos afterwards? Did not find anything in
"Application Support" nor in "Preferences"
The point is to have TM consider files with a variable extension as
text, like the ones I have to deal with : the extension is a 8-digit
number representing the date the document was edited (*.20041023 for
instance)
Thanks,
--
Jo <W:00°04'37" ; N:47°15'36">
1....'....12.....'....24.....'....36.....'....48.....'....60.....'....72
Hello all.
I'm not sure why people have seized upon this font-size issue. It is,
as a few people have already noted, a minor point, and anyone who
really cares can change it just like I did. What is *really* important
are the other, functional behaviour changes I suggested:
1. Store the Base URL in the project file. Why must I retype this every
time the Preview disappears, speaking of which:
2. Keep the preview open until *I* close it, don't make it disappear.
If a user opened it, chances are they're doing web design, and they'll
want to use it again. This shouldn't be hard, right?
3. Change the preview to display the contents of the current tab *if
that tab is HTML*. Quick Hint: if you are syntax-highlighting something
as HTML, you should sensibly be able to preview it. Likewise for PHP.
This is a bit trickier, yes.
4. Have an option to update the view if *any* project file changes.
This is probably on a par in implementational difficulty with the
previous suggestion.
---
Justin says:
> Firefox and Safari and pretty much every other browser ship with 16px
> -- I'm 99% certain of this. Eventually a preference is planned for
> you
> to pick your own I think. When the first betas shipped, it was set to
> 12, but people complained about it not being like Safari and Firefox,
> so whatyagonnado?
Set it to the same value as Safari and Firefox - surely the majority of
the mac browser share. Why would you ever set it differently? Why
12pts? ...
> Can't please everyone until there's a font size preview -- and even if
> TM were to preview things EXACTLY the way YOU prefer (14px), it's only
> previewing your Safari/Firefox set-up, not previewing my set-up, or
> some guy down the road surfing the web on his XBox.
... if the font value was the same as the default for other browsers,
you'd please *most* people. If that's 16pts, not 14pts, fine - i was
just guessing as I hacked around. I could be wrong, and in this case,
my eyes were a few pts out :)
My point is, why is TextMate deliberately different from what seems to
be the standard here?
> It's a quick and handy HTML preview, not a full-on browser... and isn't
> that good enough?
For a preview to be useful, it needs to be somewhat accurate,
especially if you are using it for CSS design. I don't ask for a full
on browser (presumably by that you mean history, bookmarks?), just a
quick pane that displays reasonably accurately what the page I'm
hacking up will look like in most browsers.
Timothy says:
> I have to side with Justin here. You
> should leave the Browser default text size alone especially when
> testing design & accessibility.
I'm not suggesting that I'd want to change it as part of my design
process. Just that it be set to a better default value.
I'll repeat - I don't understand why the OakWebPreview sets it's
default to 12pts if the two most popular browsers are different. I'd
love to hear a justification. A preference to change it at some point
would be great, but clearly isn't high-priority, nor do I feel it
should be. Just set the default sensibly - doesn't that better fit the
TextMate philosophy of "no preferences"?
Someone wondered if anyone codes static HTML pages any more. Surely the
answer is YES! Pretty much everyone does. Most design takes place using
placeholder content - a static page - which is the broken up and fed to
the appropriate dynamic parts of Rails, Smarty or whatever. If there
are people designing html using only fragments and relying on dynamic
systems to put them all together without even once just checking that
the html jigsaw pieces they are carving fit together nicely, well kudos
to you :) I must be old school, but I design the whole page first (with
forethought, of course), and then separate the components into
different files/functions.
Kumar said:
> I would also vote to not put too much development
> into WebPreview since Safari is only a command-tab + command-R away....
> unless there was a feature like SubEthaEdit that did WebPreview in
> realtime as you type.
The Web Preview *does* auto-update, like SubEthaEdit, unless I am
imagining things, and that is what makes it most useful. Why hit the
keyboard at all if you don't have to.
---
I've suggested some simple aesthetic changes, and some simple
behavioural changes that AFAIK won't take more than a few hours
consideration, but will surely improve the usefulness of the Web
Preview feature for those of us that do feel it is handy. The font-size
note is tiny compared to these other 'ideas'.
Does anyone else think Web Preview is useful? If you don't use it...
you've not lost anything. If you do, you've gained a lot.
I hope I've made my case more effectively here, thanks for reading guys.
- James
Hello!
I have to get this out of my system: this is possibly my favorite new
mac app. Amazing work!
Anyway, these are my thoughts about how TextMate should respond to
double-clicks on text, based on my preferences and the way other mac
applications like BBedit or TextEdit perform.
When I double click on whitespace, I like for the selection to stop at
the beginning/end of the line, or the nearest adjacent non-whitespace
character, whichcever comes first:
[ ]word word
Textmate selects the white space until the beginning/end of the line,
or the nearest adjacent word, whichever comes first:
[ word] word
When I double click on a word, and then shift click to the right or
left of the selected word, I like the selection to expand to include
the word or whitespace I shift-clicked on:
[word] --> [ word]
Textmate, interestingly, does this when I click to the right of a
selected word, but when I click to the left of one, the selection is
changed to the characters between where I clicked and the beginning of
the old selection:
word [word] --> [word ]word
I'd say it's praise that this is my biggest gripe after switching to
TextMate a little less than 24 hours ago. Yeay textmate!
John
