mactextoolbox-talk Mailing List for Mac TeX Toolbox
Status: Planning
Brought to you by:
jlaurens
Menu
▾
▴
mactextoolbox-talk — Discussion for Macintosh developers for TeX Tools
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(23) |
Jul
(81) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(2) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
|
Feb
(4) |
Mar
(1) |
Apr
(8) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Will R. <ws...@gm...> - 2006-04-30 14:23:22
|
Hi Jerome, Not sure how productive this thread is, but it's good to hash out some consensus. >>> > New LaTeX packages should be able to write their own command >>> > description file (via the dtx mechanism) which would be preparsed >>> > somewhere such that when a \usepackage is recognised, the >>> extra macros >>> > can be added to the current pool of "known" commands that the >>> editor >>> > can prompt for. Ideally, every single user command in LaTeX >>> should be >>> > completely documented in this way, which would then allow true >>> syntax >>> > spell checking of LaTeX code. >>> >>> This is a detail. >> >> And what a detail!! > Sorry Will, for me spell checking was just a detail compared to the > rest of the paragraph... > The problem with latex and other programming languages is "what > command is legal -now-?" Sorry, I thought your "this is a detail" applied to the whole paragraph. I don't see too much difference between "what command is legal -now-" and spelling checking LaTeX code, anyway. I think we're agreed here that the functionality would be nice. >> I disagree with each of these statements. >> 1 - There has never been good coordination between macro writers >> and frontends. > > Because macro and frontends are already 2 difficult things when > managed independently. > People are reluctant to add the complexity of managing both at the > same time... Perhaps I didn't explain myself properly. I mean that frontends haven't tended to take advantage of the structured way LaTeX programmers write their macros. For example, it's easy to parse a .sty file for \DeclareOption and prompt for package options interactively (I wrote an Applescript once). So maybe it's time for the macro writers to take the initiative and provide more hooks for the frontend authors. >> 3 - Supplementary files containing \describemacro can be created. > > And the documentation is no longer in the dtx... > and different localizations can live in different files... This is only for packages who don't want to do this themselves. In an ideal world. this wouldn't be necessary. I know, we don't live in an ideal world. >>> 5 - Caching the result of the parsing is quite like not using >>> the dtx >>> at all. >> >> NO! >> Using the dtx ensures that the completion file remains up-to-date >> with the package, and provides that the author of the package >> specifies how it works. > > Version checking More complexity. > If you define a new dtx scheme, you'll have to write an appropriate > parser too. > Moreover, how will you convince macros developpers to support the > new dtx scheme? Ah, here's the rub. Obviously, it's too late for LaTeX2e. But if the functionality is written into LaTeX3, I predict the advantages would be apparent and the scheme would be followed. >>> That way, many people can contribute, and we just have to designate >>> some moderators to accept contributions, modifications... >> >> Are you volunteering to moderate? This is impractical. > > Not if there are moderator-s- Easier I think to find an enthusiastic volunteer who's willing to trawl through the LaTeX sources and packages adding everything in sight. The problem as always is (wo)manpower. > BTW, what if a package maintainer does not want to adhere to your > new dtx scheme? > What if a package maintainer does not want to manage different > localizations? I agree it's a long shot that this sort of thing will work in the capacity that I imagine. It's clear to me now that something has to be written at the macro level in docstrip to prove the technique before talk of what can be done by the frontend is discussed. Provided the macro solution is sufficiently general, the results can be transformed easily enough to suit whatever purpose. Perhaps I'll bring it up with the LaTeX3 people and see if anyone there has thought about similar things. Will |
|
From: <jer...@u-...> - 2006-04-28 22:27:37
|
Le 26 avr. 06, =E0 03:57, Will Robertson a =E9crit : > Sorry, Mail.app just nuked half of my [toolbox] messages during a=20 > crash. Damn this app. > >> For iTeXMac2, I changed the bullet character to __(ANYTHING)__ >> I adapted the xcode behaviour concerning placeholders. >> Xcode uses something like >> >> [myTextView setSelectedRange:<#NSRange aRange#>]; >> >> The problem with this syntax is that < and > are not allowed in xml >> files... >> This is why I replaced them with __()__ > > XML, meh. Anyway, my characters weren't <>, they were =8B=9B, single=20= > guillemets. An opening/closing syntax is a marked improvement over my=20= > quickly hacked together solution. I was just following from what=20 > TeXShop already provided for. > >> BTW, the actions to select the next and pervious placeholders should=20= >> be >> part of the editor, not an applescript add on. > > Again, whatever. Applescript add-ons provide a good way to "suggest"=20= > new features. It works and has worked well enough for now, but I agree=20= > it would be better to integrate it into the app. There are other good (better) ways to extend an app: plug-ins, perl=20 script, ... > >> If you have some time, see how iTM2 deals with macros at >> http://itexmac.sourceforge.net/wiki/index.php/Macros. > > I'll be investigating iTM2 thoroughly when the final version is=20 > released. I don't have time, I'm sorry to say, to help out with bug=20 > testing. > >> > New LaTeX packages should be able to write their own command >> > description file (via the dtx mechanism) which would be preparsed >> > somewhere such that when a \usepackage is recognised, the extra=20 >> macros >> > can be added to the current pool of "known" commands that the=20 >> editor >> > can prompt for. Ideally, every single user command in LaTeX should=20= >> be >> > completely documented in this way, which would then allow true=20 >> syntax >> > spell checking of LaTeX code. >> >> This is a detail. > > And what a detail!! Sorry Will, for me spell checking was just a detail compared to the=20 rest of the paragraph... The problem with latex and other programming languages is "what command=20= is legal -now-?" > No, this is a core concept to making LaTeX easier to use. It shouldn't=20= > be up to the user to add every single macro defined to their=20 > completions file, nor for a studious individual to hand craft an=20 > all-encompassing list. > >> > I imagine an extension to \newcommand (or the LaTeX3 equivalent,=20= >> more >> > likely) that takes such syntax information for purely metadata >> > reasons. E.g., >> > \newcommand\mycommand[2]{#1: #2} >> > \describemacro\mycommand[1=3Dfirst arg, 2=3Dsecond arg]{This is = a=20 >> macro >> > for not doing much.} I forgot: this is very similar to the management of macros designed for=20= ConTeXt >> >> Here is my pov. >> >> You should not rely on metadata in the dtx: >> 1 - if it were easy people would have implemented/used it for a long >> time. >> 2 - There are some people in the world that would like to see this >> information in their native languages >> 3 - once the documentation is put in the dtx, you cannot improve it >> until the next release... > > I disagree with each of these statements. > 1 - There has never been good coordination between macro writers and=20= > frontends. Because macro and frontends are already 2 difficult things when managed=20= independently. People are reluctant to add the complexity of managing both at the same=20= time... > 2 - \describemacro\mycommand[english][1=3Dfirst, 2=3Dsecond]{...} > \describemacro\mycommand[french][1=3Dune, 2=3Ddeu]{...} see below > 3 - Supplementary files containing \describemacro can be created. And the documentation is no longer in the dtx... and different localizations can live in different files... > >> 4 - it takes time to parse the dtx for just one part of information > > Yes, I envision a caching system when the .dtx file is installed. > >> 5 - Caching the result of the parsing is quite like not using the = dtx >> at all. > > NO! > Using the dtx ensures that the completion file remains up-to-date with=20= > the package, and provides that the author of the package specifies how=20= > it works. Version checking > >> Instead, here is my proposal: >> >> 1 agree on meta markers , I vote for __(*)__ instead of *. The >> former is not mac centric, is xml compliant and of course is a TeX >> error. >> 2 agree on a xml format >> 3 agree on a categorization (to uniquely identify the macro...) >> 4 agree on a context dependency (to ensure that \put is used in=20 >> picture >> environments only...) > > Sure, all these are insignificant details. I don't see what XML gains=20= > you here, but why not. the xml grammar is better than tex's the parser already exists If you define a new dtx scheme, you'll have to write an appropriate=20 parser too. Moreover, how will you convince macros developpers to support the new=20 dtx scheme? > In a good implementation, the metamarkers would never appear in the=20 > TeX source. > >> 5 create a web form where anyone can contribute. when posting, this >> form will just create an xml file containing the appropriate >> information, including language, format, and so on. Some kind of = wiki >> or spip would help. No need to be a programmer to write doc. > > Too hard. Let the package writers deal with it. Docs should only have=20= > to be written once and then everyone can benefit, and the syntax=20 > shouldn't be tricky. You want to waste time with a web form?!? If the docs should only have to be written once, then there is no=20 problem of synchronization with the package. How many macros in how many packages? If there is only one form for each macro of each package, I don't call=20= this a waste of time. > >> 6 Any frontend will just do whatever they want with this material=20 >> (it's >> easy with a bit of perl and xslt.). > > Yes. An agnostic approach is highly desirable. > >> That way, many people can contribute, and we just have to designate >> some moderators to accept contributions, modifications... > > Are you volunteering to moderate? This is impractical. Not if there are moderator-s- > >> Remark: >> Some extensions of this macros/completion design. >> Suppose you have a macro whose parameters only take a finite number=20= >> of >> values, the user interface should only present these possibilities.=20= >> If >> you have a more complex macro, the user interface might need a = better >> approach. >> For example, >> >> \usepackage[__(choose:paper size, a4paper,a5paper,a6paper,letter, >> legal)__]{geometry} >> >> would show a small window with a popup to let the user choose the >> proper paper size. > > This is a good idea, and fits in better with extracting this data from=20= > the .dtx file. Take a look at xkeyval -- it has a structured approach=20= > for defining keyval lists, from which data such as the above can be=20 > extracted. > > A dtx file is supposed to be a self-contained implementation and=20 > documentation of a package. Moving the macro syntax out of here is=20 > madness. Yes, it is certainly a nonsense to move anything out of the dtx archive. But we are talking about adding something new, aren't we? BTW, what if a package maintainer does not want to adhere to your new=20 dtx scheme? What if a package maintainer does not want to manage different=20 localizations? I am afraid your solution is not efficient in practice because it=20 relies on a supplemental work assigned to an already designated person. When someone chose to maintain some package, the localization was not=20 in the contract... It is not fair to add something behind hisback. If you design a new approach and say : okay any one can contribute,=20 then you will have some success. See how things work for cocoa: localization has a minimal binding=20 inside the code such that you can localize the application without=20 knowing any programming language. > > Will > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services,=20 > security? > Get stuff done quickly with pre-integrated technology to make your job=20= > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache=20 > Geronimo > http://sel.as-us.falkag.net/sel?cmd--Mactextoolbox-talk mailing list > Mac...@li... > https://lists.sourceforge.net/lists/listinfo/mactextoolbox-talk > |
|
From: Will R. <ws...@gm...> - 2006-04-27 07:41:09
|
On 27/04/2006, at 13:22 , Adam R. Maxwell wrote: >> XML, meh. Anyway, my characters weren't <>, they were =8B=9B, single =20= >> guillemets. An opening/closing syntax is a marked improvement over =20= >> my quickly hacked together solution. I was just following from =20 >> what TeXShop already provided for. > > Wouldn't this be front-end specific? I don't see anything wrong =20 > with having <#...#>, even, since it's strictly a placeholder. =20 > Xcode uses ctrl-/ to select placeholders as well, so that's a nice =20 > familiar shortcut for some of us. I guess it would be transformed into whichever form the front end =20 preferred. > If anyone's interested in a popup window implementation for =20 > autocomplete, we rewrote Apple's NSTextView autocompletion =20 > mechanism for BibDesk. I wonder how difficult it would be to add =20 > that style (popup child window) of autocomplete for LaTeX? It =20 > could be triggered by something like "\usepackage geom"<hit esc>, =20 > search list of commands and packages with "geom" in them, and then =20 > replacing " geom" with the selected choice. That'd certainly be better than what's available at present. Something to keep in mind; thanks for the tip. Will= |
|
From: Adam R. M. <ama...@ma...> - 2006-04-27 03:51:53
|
On Apr 25, 2006, at 18:57, Will Robertson wrote:
> Sorry, Mail.app just nuked half of my [toolbox] messages during a =20
> crash. Damn this app.
>
>> For iTeXMac2, I changed the bullet character to __(ANYTHING)__
>> I adapted the xcode behaviour concerning placeholders.
>> Xcode uses something like
>>
>> [myTextView setSelectedRange:<#NSRange aRange#>];
>>
>> The problem with this syntax is that < and > are not allowed in xml
>> files...
>> This is why I replaced them with __()__
>
> XML, meh. Anyway, my characters weren't <>, they were =8B=9B, single =20=
> guillemets. An opening/closing syntax is a marked improvement over =20
> my quickly hacked together solution. I was just following from what =20=
> TeXShop already provided for.
Wouldn't this be front-end specific? I don't see anything wrong with =20=
having <#...#>, even, since it's strictly a placeholder. Xcode uses =20
ctrl-/ to select placeholders as well, so that's a nice familiar =20
shortcut for some of us.
>>
>> > New LaTeX packages should be able to write their own command
>> > description file (via the dtx mechanism) which would be preparsed
>> > somewhere such that when a \usepackage is recognised, the extra =20=
>> macros
>> > can be added to the current pool of "known" commands that the =20
>> editor
>> > can prompt for. Ideally, every single user command in LaTeX =20
>> should be
>> > completely documented in this way, which would then allow true =20
>> syntax
>> > spell checking of LaTeX code.
>>
>> This is a detail.
>
> And what a detail!!
> No, this is a core concept to making LaTeX easier to use. It =20
> shouldn't be up to the user to add every single macro defined to =20
> their completions file, nor for a studious individual to hand craft =20=
> an all-encompassing list.
This sounds like a good job for a grad student who can't concentrate =20
on research :). However it's implemented, it would be very handy.
>
>
[...]
>> Instead, here is my proposal:
>>
>> 1 agree on meta markers , I vote for __(*)__ instead of *. The
>> former is not mac centric, is xml compliant and of course is a TeX
>> error.
>> 2 agree on a xml format
>> 3 agree on a categorization (to uniquely identify the macro...)
>> 4 agree on a context dependency (to ensure that \put is used in =20
>> picture
>> environments only...)
>
> Sure, all these are insignificant details. I don't see what XML =20
> gains you here, but why not. In a good implementation, the =20
> metamarkers would never appear in the TeX source.
XML is probably a good choice; it's machine readable and checkable, =20
although (IMHO) it sucks to read/write by hand. I curious as to why =20
the meta markers should be a part of any standard, though; why would =20
they be present in the XML file?
[...]
>
>
>> Remark:
>> Some extensions of this macros/completion design.
>> Suppose you have a macro whose parameters only take a finite =20
>> number of
>> values, the user interface should only present these =20
>> possibilities. If
>> you have a more complex macro, the user interface might need a =20
>> better
>> approach.
>> For example,
>>
>> \usepackage[__(choose:paper size, a4paper,a5paper,a6paper,letter,
>> legal)__]{geometry}
>>
>> would show a small window with a popup to let the user choose the
>> proper paper size.
If anyone's interested in a popup window implementation for =20
autocomplete, we rewrote Apple's NSTextView autocompletion mechanism =20
for BibDesk. I wonder how difficult it would be to add that style =20
(popup child window) of autocomplete for LaTeX? It could be =20
triggered by something like "\usepackage geom"<hit esc>, search list =20
of commands and packages with "geom" in them, and then replacing " =20
geom" with the selected choice.
Adam=
|
|
From: Will R. <ws...@gm...> - 2006-04-26 22:54:02
|
nothing to see here |
|
From: Will R. <ws...@gm...> - 2006-04-26 01:57:56
|
Sorry, Mail.app just nuked half of my [toolbox] messages during a =20 crash. Damn this app. > For iTeXMac2, I changed the bullet character to __(ANYTHING)__ > I adapted the xcode behaviour concerning placeholders. > Xcode uses something like > > [myTextView setSelectedRange:<#NSRange aRange#>]; > > The problem with this syntax is that < and > are not allowed in xml > files... > This is why I replaced them with __()__ XML, meh. Anyway, my characters weren't <>, they were =8B=9B, single =20 guillemets. An opening/closing syntax is a marked improvement over my =20= quickly hacked together solution. I was just following from what =20 TeXShop already provided for. > BTW, the actions to select the next and pervious placeholders =20 > should be > part of the editor, not an applescript add on. Again, whatever. Applescript add-ons provide a good way to "suggest" =20 new features. It works and has worked well enough for now, but I =20 agree it would be better to integrate it into the app. > If you have some time, see how iTM2 deals with macros at > http://itexmac.sourceforge.net/wiki/index.php/Macros. I'll be investigating iTM2 thoroughly when the final version is =20 released. I don't have time, I'm sorry to say, to help out with bug =20 testing. > > New LaTeX packages should be able to write their own command > > description file (via the dtx mechanism) which would be preparsed > > somewhere such that when a \usepackage is recognised, the extra =20 > macros > > can be added to the current pool of "known" commands that the =20 > editor > > can prompt for. Ideally, every single user command in LaTeX =20 > should be > > completely documented in this way, which would then allow true =20 > syntax > > spell checking of LaTeX code. > > This is a detail. And what a detail!! No, this is a core concept to making LaTeX easier to use. It =20 shouldn't be up to the user to add every single macro defined to =20 their completions file, nor for a studious individual to hand craft =20 an all-encompassing list. > > I imagine an extension to \newcommand (or the LaTeX3 equivalent, =20= > more > > likely) that takes such syntax information for purely metadata > > reasons. E.g., > > \newcommand\mycommand[2]{#1: #2} > > \describemacro\mycommand[1=3Dfirst arg, 2=3Dsecond arg]{This is a = =20 > macro > > for not doing much.} > > Here is my pov. > > You should not rely on metadata in the dtx: > 1 - if it were easy people would have implemented/used it for a long > time. > 2 - There are some people in the world that would like to see this > information in their native languages > 3 - once the documentation is put in the dtx, you cannot improve it > until the next release... I disagree with each of these statements. 1 - There has never been good coordination between macro writers and =20 frontends. 2 - \describemacro\mycommand[english][1=3Dfirst, 2=3Dsecond]{...} \describemacro\mycommand[french][1=3Dune, 2=3Ddeu]{...} 3 - Supplementary files containing \describemacro can be created. > 4 - it takes time to parse the dtx for just one part of information Yes, I envision a caching system when the .dtx file is installed. > 5 - Caching the result of the parsing is quite like not using the dtx > at all. NO! Using the dtx ensures that the completion file remains up-to-date =20 with the package, and provides that the author of the package =20 specifies how it works. > Instead, here is my proposal: > > 1 agree on meta markers , I vote for __(*)__ instead of *. The > former is not mac centric, is xml compliant and of course is a TeX > error. > 2 agree on a xml format > 3 agree on a categorization (to uniquely identify the macro...) > 4 agree on a context dependency (to ensure that \put is used in =20 > picture > environments only...) Sure, all these are insignificant details. I don't see what XML gains =20= you here, but why not. In a good implementation, the metamarkers =20 would never appear in the TeX source. > 5 create a web form where anyone can contribute. when posting, this > form will just create an xml file containing the appropriate > information, including language, format, and so on. Some kind of wiki > or spip would help. No need to be a programmer to write doc. Too hard. Let the package writers deal with it. Docs should only have =20= to be written once and then everyone can benefit, and the syntax =20 shouldn't be tricky. You want to waste time with a web form?!? > 6 Any frontend will just do whatever they want with this material =20 > (it's > easy with a bit of perl and xslt.). Yes. An agnostic approach is highly desirable. > That way, many people can contribute, and we just have to designate > some moderators to accept contributions, modifications... Are you volunteering to moderate? This is impractical. > Remark: > Some extensions of this macros/completion design. > Suppose you have a macro whose parameters only take a finite =20 > number of > values, the user interface should only present these =20 > possibilities. If > you have a more complex macro, the user interface might need a better > approach. > For example, > > \usepackage[__(choose:paper size, a4paper,a5paper,a6paper,letter, > legal)__]{geometry} > > would show a small window with a popup to let the user choose the > proper paper size. This is a good idea, and fits in better with extracting this data =20 from the .dtx file. Take a look at xkeyval -- it has a structured =20 approach for defining keyval lists, from which data such as the above =20= can be extracted. A dtx file is supposed to be a self-contained implementation and =20 documentation of a package. Moving the macro syntax out of here is =20 madness. Will |
|
From: <jer...@u-...> - 2006-04-25 19:22:11
|
Le 21 avr. 06, =88 10:43, Will Robertson a =8Ecrit :
> Hello everyone,
>
> I've finally gotten around to taking a more decent look at TeXShop's=20=
> completions, courtesy of some old file of Herb Schulz's I have lying=20=
> around. (Are you here, Herb?)
>
> I've been hacking away at it for a little while now when it occurred=20=
> to me that I should check if it's been improved since I got my hands=20=
> on it. (I don't even know if the file's publicly available any more.)
>
> Anyway, I think you'll like what I've been doing. I always forget what=20=
> the more complex optional arguments are supposed to be in things like=20=
> minipages. I've now got completions like the following:
>
> \framebox[#INS#=F0=DCwidth=DD][=F0=DCpos: c,l,r,s=DD]{=F0}
> \framebox[#INS#]{=F0}
>
> \makebox[#INS#=F0=DCwidth=DD][=F0=DCpos: c,l,r,s=DD]{=F0}
> \makebox[#INS#]{=F0}
>
> \raisebox{#INS#=F0=DCraise=DD}[=F0=DCheight=DD][=F0=DCdepth=DD]{=F0=
}
> \raisebox{#INS#=F0=DCraise=DD}[=F0=DCheight=DD]{=F0}
> \raisebox{#INS#}{=F0}
>
> And I've modified the bullet searching TeXShop macros to select any=20
> matching =DC...=DD text after a bullet as well (see appended, and feel=20=
> free to distribute -- I copied them from Herb).
>
For iTeXMac2, I changed the bullet character to __(ANYTHING)__
I adapted the xcode behaviour concerning placeholders.
Xcode uses something like
[myTextView setSelectedRange:<#NSRange aRange#>];
The problem with this syntax is that < and > are not allowed in xml=20
files...
This is why I replaced them with __()__
__(INS)__ is an end of the selected range
__(SEL)__ is the selected text...
The above syntax becomes
\raisebox{__(INS)____(raise)____(INS)__}{__(height)__}{__(depth)__}
It is pure ascii and works easily with xml. Moreover, '__(' and ')__'=20
are clearly opening and closing tags.
Both leading to TeX errors such that they will not be used (except by=20
super gurus).
BTW, the actions to select the next and pervious placeholders should be=20=
part of the editor, not an applescript add on.
> I'm keen on the idea of expanding the completion file to include as=20
> much of base LaTeX as possible, following conventions something like=20=
> the above. There's no reason it should be TeXShop specific, either. I=20=
> don't know how much time I have or how long my motivation will last,=20=
> but anyone interested in helping out would be great. I guess this file=20=
> would need to be placed in a svn site somewhere if more than one=20
> person were to work on it.
>
> Hypothetically, I would like this file to evolve beyond TeXShop's=20
> current completion engine into a file that can be used for more=20
> flexible purposes; e.g., code prompting as you type.
and macros!
You are addressing a completely different problem here.
One should make a distinction between the macros and the mean to=20
activate theme.
The completion is just a user interface to activate some macro, just=20
like a menu item.
If you have some time, see how iTM2 deals with macros at=20
http://itexmac.sourceforge.net/wiki/index.php/Macros.
> New LaTeX packages should be able to write their own command=20
> description file (via the dtx mechanism) which would be preparsed=20
> somewhere such that when a \usepackage is recognised, the extra macros=20=
> can be added to the current pool of "known" commands that the editor=20=
> can prompt for. Ideally, every single user command in LaTeX should be=20=
> completely documented in this way, which would then allow true syntax=20=
> spell checking of LaTeX code.
This is a detail.
>
> I imagine an extension to \newcommand (or the LaTeX3 equivalent, more=20=
> likely) that takes such syntax information for purely metadata=20
> reasons. E.g.,
> \newcommand\mycommand[2]
> (1: first argument; 2:second argument)
> {#1: #2}
> (I just made that up on the spot. Perhaps it's not such a good idea.)=20=
> Alternatively,
> \newcommand\mycommand[2]{#1: #2}
> \describemacro\mycommand[1=3Dfirst arg, 2=3Dsecond arg]{This is a =
macro=20
> for not doing much.}
>
> I know, I know. It's all easy to say these things, but I'm not the=20
> first to think of them so I believe the idea has merit. (Frank=20
> Mittelbach touches briefly on the subject in the documentation file,=20=
> if I recall correctly, ltxdoc.pdf .)
>
> Just some rambling thoughts for a procrastinating Friday evening. Any=20=
> thoughts?
>
> Will
>
>
Here is my pov.
You should not rely on metadata in the dtx:
1 - if it were easy people would have implemented/used it for a long=20
time.
2 - There are some people in the world that would like to see this=20
information in their native languages
3 - once the documentation is put in the dtx, you cannot improve it=20
until the next release...
4 - it takes time to parse the dtx for just one part of information
5 - Caching the result of the parsing is quite like not using the dtx=20
at all.
Instead, here is my proposal:
1 agree on meta markers , I vote for __(*)__ instead of =F0=DC*=DD. The=20=
former is not mac centric, is xml compliant and of course is a TeX=20
error.
2 agree on a xml format
3 agree on a categorization (to uniquely identify the macro...)
4 agree on a context dependency (to ensure that \put is used in picture=20=
environments only...)
5 create a web form where anyone can contribute. when posting, this=20
form will just create an xml file containing the appropriate=20
information, including language, format, and so on. Some kind of wiki=20
or spip would help. No need to be a programmer to write doc.
6 Any frontend will just do whatever they want with this material (it's=20=
easy with a bit of perl and xslt.).
That way, many people can contribute, and we just have to designate=20
some moderators to accept contributions, modifications...
Remark:
Some extensions of this macros/completion design.
Suppose you have a macro whose parameters only take a finite number of=20=
values, the user interface should only present these possibilities. If=20=
you have a more complex macro, the user interface might need a better=20
approach.
For example,
\usepackage[__(choose:paper size, a4paper,a5paper,a6paper,letter,=20
legal)__]{geometry}
would show a small window with a popup to let the user choose the=20
proper paper size.
|
|
From: Will R. <ws...@gm...> - 2006-04-21 08:44:12
|
Hello everyone,
I've finally gotten around to taking a more decent look at TeXShop's =20
completions, courtesy of some old file of Herb Schulz's I have lying =20
around. (Are you here, Herb?)
I've been hacking away at it for a little while now when it occurred =20
to me that I should check if it's been improved since I got my hands =20
on it. (I don't even know if the file's publicly available any more.)
Anyway, I think you'll like what I've been doing. I always forget =20
what the more complex optional arguments are supposed to be in things =20=
like minipages. I've now got completions like the following:
\framebox[#INS#=F0=DCwidth=DD][=F0=DCpos: c,l,r,s=DD]{=F0}
\framebox[#INS#]{=F0}
\makebox[#INS#=F0=DCwidth=DD][=F0=DCpos: c,l,r,s=DD]{=F0}
\makebox[#INS#]{=F0}
\raisebox{#INS#=F0=DCraise=DD}[=F0=DCheight=DD][=F0=DCdepth=DD]{=F0=
}
\raisebox{#INS#=F0=DCraise=DD}[=F0=DCheight=DD]{=F0}
\raisebox{#INS#}{=F0}
And I've modified the bullet searching TeXShop macros to select any =20
matching =DC...=DD text after a bullet as well (see appended, and feel =20=
free to distribute -- I copied them from Herb).
I'm keen on the idea of expanding the completion file to include as =20
much of base LaTeX as possible, following conventions something like =20
the above. There's no reason it should be TeXShop specific, either. I =20=
don't know how much time I have or how long my motivation will last, =20
but anyone interested in helping out would be great. I guess this =20
file would need to be placed in a svn site somewhere if more than one =20=
person were to work on it.
Hypothetically, I would like this file to evolve beyond TeXShop's =20
current completion engine into a file that can be used for more =20
flexible purposes; e.g., code prompting as you type. New LaTeX =20
packages should be able to write their own command description file =20
(via the dtx mechanism) which would be preparsed somewhere such that =20
when a \usepackage is recognised, the extra macros can be added to =20
the current pool of "known" commands that the editor can prompt for. =20
Ideally, every single user command in LaTeX should be completely =20
documented in this way, which would then allow true syntax spell =20
checking of LaTeX code.
I imagine an extension to \newcommand (or the LaTeX3 equivalent, more =20=
likely) that takes such syntax information for purely metadata =20
reasons. E.g.,
\newcommand\mycommand[2]
(1: first argument; 2:second argument)
{#1: #2}
(I just made that up on the spot. Perhaps it's not such a good idea.) =20=
Alternatively,
\newcommand\mycommand[2]{#1: #2}
\describemacro\mycommand[1=3Dfirst arg, 2=3Dsecond arg]{This is a =20
macro for not doing much.}
I know, I know. It's all easy to say these things, but I'm not the =20
first to think of them so I believe the idea has merit. (Frank =20
Mittelbach touches briefly on the subject in the documentation file, =20
if I recall correctly, ltxdoc.pdf .)
Just some rambling thoughts for a procrastinating Friday evening. Any =20=
thoughts?
Will
--AppleScript direct
--Find Next "Tab"
property bullet : "=F0"
property openDelim : "=DC"
property closeDelim : "=DD"
try
tell application "TeXShop"
activate
set searchOffset to (offset of selection of front =
document)
if (length of selection of front document) > 0 then
set searchOffset to (searchOffset + 1)
end if
tell front document to set bulletMark to (search for =
bullet =20
starting from searchOffset)
if bulletMark > 0 then
set offset of selection of front document to =
(bulletMark - 1)
if character (bulletMark + 1) of the text of the =
front document is =20
openDelim then
tell front document to set delimMark to =
(search for closeDelim =20
starting from bulletMark)
if delimMark > 0 then
set length of selection of front =
document to (delimMark - =20
bulletMark + 1)
else
set length of selection of front =
document to 1
end if
else
set length of selection of front =
document to 1
end if
end if
end tell
end try
--AppleScript direct
--Find Previous "Tab"
property bullet : "=F0"
property openDelim : "=DC"
property closeDelim : "=DD"
try
tell application "TeXShop"
activate
set searchOffset to (offset of selection of front =
document)
tell front document to set bulletMark to (search for =
bullet =20
starting from searchOffset with searching backwards)
if bulletMark > 0 then
set offset of selection of front document to =
(bulletMark - 1)
if character (bulletMark + 1) of the text of the =
front document is =20
openDelim then
tell front document to set delimMark to =
(search for closeDelim =20
starting from bulletMark)
if delimMark > 0 then
set length of selection of front =
document to (delimMark - =20
bulletMark + 1)
else
set length of selection of front =
document to 1
end if
else
set length of selection of front =
document to 1
end if
end if
end tell
end try
|
|
From: Simon S. <si...@si...> - 2006-03-13 22:39:32
|
This could be of interest to some of you: Adobe has released Prerelease 1 of XMP Toolkit Version 4.0. "Version 4.0 of the Adobe XMP Toolkit is planned to significantly =20 extend the capabilities of the current SDK by adding an often-=20 requested feature: the ability to easily find, add, and update XMP in =20= popular image, document, and video file formats. As such, Version 4.0 =20= will contain two distinct components: The XMP Core: a component for parsing, manipulating, and serializing =20 XMP data. This component was historically called the "XMP Toolkit" =20 because it was the only component in the toolkit. It will henceforth =20 be called the XMP Core, whereas the XMP Toolkit refers to the entire =20 SDK. The XMP File Handler: a component for reading, rewriting, and =20 injecting serialized XMP into popular image, document, and video file =20= formats. The XMP File Manager can be thought of as a "file I/O" =20 component for reading and writing the XMP that is manipulated by the =20 XMP Core." "The download contains projects and makefiles for building the XMP =20 Manager on Macintosh and Windows. The Macintosh build is an Xcode 2.2 =20= project, this will create a universal binary for both PowerPC and =20 Intel processors. " Details on: http://labs.macromedia.com/technologies/xmptoolkit/ -- Simon Spiegel Mutschellenstr. 97 8038 Z=FCrich Telephon: ++41 43 535 81 71 Mobophon: ++41 76 459 60 39 http://www.simifilm.ch "I have never been certain that the moral of the Icarus myth is, as =20 is generally accepted, 'don't fly too high', or whether it might also =20= be thought of as: 'forget about the wax and feathers, and do a better =20= job on the wings." Stanley Kubrick |
|
From: <jer...@u-...> - 2006-02-27 09:16:37
|
Le 19 f=E9vr. 06, =E0 18:23, Adam R. Maxwell a =E9crit : > > On Feb 19, 2006, at 03:10, Maarten Sneep wrote: > >> On 19 Feb 2006, at 1:06, Adam R. Maxwell wrote: >> >>> So far, so good. Unfortunately, Mac OS X xattrs aren't supported on=20= >>> other platforms, and setting the PDF attributes via PDFDocument (and=20= >>> then saving the PDFDocument) is /really/ slow, as it needs to=20 >>> re-render the PDF. >>> >>> Question: >>> Does anyone know of a better way to do this? I looked at Adobe's=20 >>> XMP library, but I don't grok C++, and it seems really low-level in=20= >>> any case. >> >> It is. But if you can generate the xml describing the metadata,=20 >> adding it to a pdftex generated file is trivial, and I think it isn't=20= >> too hard either adding the blob to other files as well. > > We have all the metadata available, so writing XML from code is pretty=20= > reasonable (I only object to writing XML by hand). I'm assuming this=20= > is the easy part, anyway. > >> The hardest part is recreating the pointer table at the end of the=20 >> pdf file, but I think you can script this using pdftk as an engine. > > If anyone has pointers to sample code doing this, I'd be interested. =20= > The Adobe sample code is pretty worthless for my purposes. > Maybe I don't get the problem but this might help http://hacks.oreilly.com/pub/h/2407 |
|
From: Adam R. M. <ama...@ma...> - 2006-02-19 17:23:03
|
On Feb 19, 2006, at 03:10, Maarten Sneep wrote: > On 19 Feb 2006, at 1:06, Adam R. Maxwell wrote: > >> So far, so good. Unfortunately, Mac OS X xattrs aren't supported >> on other platforms, and setting the PDF attributes via PDFDocument >> (and then saving the PDFDocument) is /really/ slow, as it needs to >> re-render the PDF. >> >> Question: >> Does anyone know of a better way to do this? I looked at Adobe's >> XMP library, but I don't grok C++, and it seems really low-level >> in any case. > > It is. But if you can generate the xml describing the metadata, > adding it to a pdftex generated file is trivial, and I think it > isn't too hard either adding the blob to other files as well. We have all the metadata available, so writing XML from code is pretty reasonable (I only object to writing XML by hand). I'm assuming this is the easy part, anyway. > The hardest part is recreating the pointer table at the end of the > pdf file, but I think you can script this using pdftk as an engine. If anyone has pointers to sample code doing this, I'd be interested. The Adobe sample code is pretty worthless for my purposes. >> Suggestion: >> It might be nice if the TeX front ends that use PDFDocument could >> write some of that metadata into the file, either by parsing it or >> providing an interface to edit the metadata. > > May I suggest xmpincl? You'll need to generate a separate xmp file > yourself, but after that, including it is easy. > http://www.ctan.org/tex-archive/macros/latex/contrib/xmpincl/ Yeah, you front end people need to pay attention to this :). I was just suggesting more work for someone else here (but it's pretty easy to add limited metadata using PDFDocument; author, title, date(s), keywords, once you work around Apple's bugs). > In any case, a pdfTeX based solution is both portable, and probably > faster anyway. However, I can see that especially for BibDesk, > adding the metadata to an existing file is essential. May I also > suggest you get in contact with Bruce d'Arcus, as he seems to be > working on introducing a standard for this: http:// > netapps.muohio.edu/blogs/darcusb/darcusb/ Thanks, that's a good thought; Bruce has been looking at this for a long time. -- Adam |
|
From: Maarten S. <maa...@xs...> - 2006-02-19 11:10:26
|
On 19 Feb 2006, at 1:06, Adam R. Maxwell wrote:
> So far, so good. Unfortunately, Mac OS X xattrs aren't supported
> on other platforms, and setting the PDF attributes via PDFDocument
> (and then saving the PDFDocument) is /really/ slow, as it needs to
> re-render the PDF.
>
> Question:
> Does anyone know of a better way to do this? I looked at Adobe's
> XMP library, but I don't grok C++, and it seems really low-level in
> any case.
It is. But if you can generate the xml describing the metadata,
adding it to a pdftex generated file is trivial, and I think it isn't
too hard either adding the blob to other files as well. The hardest
part is recreating the pointer table at the end of the pdf file, but
I think you can script this using pdftk as an engine.
> Suggestion:
> It might be nice if the TeX front ends that use PDFDocument could
> write some of that metadata into the file, either by parsing it or
> providing an interface to edit the metadata.
May I suggest xmpincl? You'll need to generate a separate xmp file
yourself, but after that, including it is easy.
http://www.ctan.org/tex-archive/macros/latex/contrib/xmpincl/
In any case, a pdfTeX based solution is both portable, and probably
faster anyway. However, I can see that especially for BibDesk, adding
the metadata to an existing file is essential. May I also suggest you
get in contact with Bruce d'Arcus, as he seems to be working on
introducing a standard for this: http://netapps.muohio.edu/blogs/
darcusb/darcusb/
Maarten
|
|
From: Adam R. M. <ama...@ma...> - 2006-02-19 00:05:41
|
I've been playing around with PDF metadata support in BibDesk, presently implemented as hidden features in the nightly builds. The basic idea is that the PDF file has either full BibTeX associated with it as an extended attribute, or else has the standard Author/ Title/Date/Keywords metadata supported by PDFDocument and Spotlight. With that support, dropping a PDF file on BibDesk fills in much of the needed citation information for you. So far, so good. Unfortunately, Mac OS X xattrs aren't supported on other platforms, and setting the PDF attributes via PDFDocument (and then saving the PDFDocument) is /really/ slow, as it needs to re- render the PDF. Question: Does anyone know of a better way to do this? I looked at Adobe's XMP library, but I don't grok C++, and it seems really low-level in any case. Suggestion: It might be nice if the TeX front ends that use PDFDocument could write some of that metadata into the file, either by parsing it or providing an interface to edit the metadata. thanks, Adam (wondering if the list still works...) |
|
From: Maxwell, A. R <ada...@pn...> - 2005-11-03 22:07:23
|
On Nov 3, 2005, at 13:35, Maarten Sneep wrote: > On 30 Oct 2005, at 11:20, Maarten Sneep wrote: > >> Is anyone aware of the Mac OS X versions that are currently in >> use? And of course especially the distribution of that use in our >> audience. >> >> Does anyone have code to gather this information over the >> internet? I must stress that we should never do this "in secrecy", >> always ask the user whether he/she wants to participate in this >> check or not. > > The omnigroup do this, and have posted some statistics of their > users. take this with as much salt as you need, our users may show > a very different distribution. http://update.omnigroup.com/ > > I think the OmniWebFramework (OWF) can be used for this, but I'm > not sure about that. Another question is whether you want to use > that code, and whether it is easier to use curl or similar. I think this was actually a private framework until the latest version of their frameworks release. It's the OmniSoftwareUpdate framework, and you can get it from <ftp://ftp.omnigroup.com/pub/ software/Source/MacOSX/Frameworks/>. From a quick look, OSU doesn't appear to link with any of the other Omni frameworks, so it's probably a fairly easy addition to most projects. Omni's stuff is pretty nice to work with, in general (BibDesk uses OmniBase/OmniFoundation/OmniAppKit). Adam |
|
From: Maarten S. <maa...@xs...> - 2005-11-03 21:36:18
|
On 30 Oct 2005, at 11:20, Maarten Sneep wrote: > Is anyone aware of the Mac OS X versions that are currently in use? > And of course especially the distribution of that use in our audience. > > Does anyone have code to gather this information over the internet? > I must stress that we should never do this "in secrecy", always ask > the user whether he/she wants to participate in this check or not. The omnigroup do this, and have posted some statistics of their users. take this with as much salt as you need, our users may show a very different distribution. http://update.omnigroup.com/ I think the OmniWebFramework (OWF) can be used for this, but I'm not sure about that. Another question is whether you want to use that code, and whether it is easier to use curl or similar. Maarten |
|
From: Maarten S. <maa...@xs...> - 2005-10-30 10:20:56
|
Hello list, It's been too long, but I've been busy for the mactex portion of the new TeXLive DVD. During testing, we've once again discovered that the rapid change coming from Apple has made it hard to support older releases of the OS, in particular Jaguar (10.2). In a private mail exchange between me and Adam Maxwell, the following arose: >> On a broader note (and perhaps this should be transferred to the >> list): does anyone have any idea about the OS releases BibDesk/ >> TeXShop/i-Installer users are running? How offended would people >> be by an alert asking them to report the OS version, giving a >> proper explanation of why we are interested? > > We don't collect any statistics on that, so I have no idea. Based > on crash reports, I'd estimate 2/3 Tiger and 1/3 Panther for > BibDesk; since no one reported the fact that 1.1.7 was broken on > Jaguar, 10.2 has to be a small minority. If we came up with a > framework that any interested projects could use, that would be > cool (I don't think Omni has open-sourced theirs). Maybe on the > toolbox list? I'm curious as well. So I put it to the list: Is anyone aware of the Mac OS X versions that are currently in use? And of course especially the distribution of that use in our audience. Does anyone have code to gather this information over the internet? I must stress that we should never do this "in secrecy", always ask the user whether he/she wants to participate in this check or not. Maarten |
|
From: <jer...@u-...> - 2005-08-26 14:56:38
|
Le 25 ao=FBt 05, =E0 21:55, Maarten Sneep a =E9crit : > On 29 Jul 2005, at 21:44, Maarten Sneep wrote: > >> Not the list, me that is: I'll be offline for the next three weeks.=20= >> Please keep the list tidy while I'm gone. Adam Maxwell has kindly=20 >> agreed to keep an eye on the list, if things go really wrong, he=20 >> should be able to sort things out. > > What I meant to say was that I was offline, I didn't mean that you=20 > should all keep quiet. In any case, I'm back - let's get the list=20 > rolling again. > > Related: I'm looking for volunteers to write articles. Some=20 > suggestions for subject are already on the site, but other content is=20= > always welcome. > > Kind regards, > Back again too. But I am afraid my body has come back without my head which is still on=20= vacation... However, I am quietly preparing an article on meta data and file=20 attributes... --A+JL= |
|
From: Maarten S. <maa...@xs...> - 2005-08-25 19:56:10
|
On 29 Jul 2005, at 21:44, Maarten Sneep wrote: > Not the list, me that is: I'll be offline for the next three weeks. > Please keep the list tidy while I'm gone. Adam Maxwell has kindly > agreed to keep an eye on the list, if things go really wrong, he > should be able to sort things out. What I meant to say was that I was offline, I didn't mean that you should all keep quiet. In any case, I'm back - let's get the list rolling again. Related: I'm looking for volunteers to write articles. Some suggestions for subject are already on the site, but other content is always welcome. Kind regards, Maarten |
|
From: Maarten S. <maa...@xs...> - 2005-07-29 19:44:48
|
Hi all, Not the list, me that is: I'll be offline for the next three weeks. Please keep the list tidy while I'm gone. Adam Maxwell has kindly agreed to keep an eye on the list, if things go really wrong, he should be able to sort things out. Maarten Sneep |
|
From: Kevin W. <sw...@wo...> - 2005-07-24 01:10:39
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Just writing to introduce myself. I'm a sometimes poster on the regular Mac-TeX mailing list, a regular user of LaTeX for documenting my software projects, and someone who would like to give something back to the Mac-LaTeX community by helping to develop a few useful tools. I have two projects that may be of interest, though I don't know where they would fit in--perhaps others could offer some feedback. 1. AquaTkbibtex, which is designed to be a fully Aquified version of tkbibtex. Last year I released a primitive version of this port, which involved an AppleScript launcher utility and tkbibtex itself. Double-clicking a bib file would launch tkbibtex via the AS launcher. I am not sure how much of a user base this tool got, as it generated a little interest on the Mac-TeX list and then evaporated. More recently I've completed a fully aquified version of this program--I dropped the AppleScript, packaged tkbibtex as a standalone app that responds to drag-and-drop of bib files, and actually refactored a lot of the tkbibtex code to make it more Mac-friendly in appearance and behavior. The announcement of a beta version on Mac-TeX last month about a dozen downloads and no feedback. Still, since the work is done and it seeems to run fine, I'd like to release it anyway, even if the user base isn't huge. (I'm thinking about targeting LyX-Mac users as that program has tight integration wtih tkbibtex.) 2. An as-yet-incomplete tool that I'm tentatively calling latex2applehelp. Basically this involves some basic modifications to latex2html that I've made to provide more attractive output (specifically the navigation icons). When I write user help, I author in LaTeX, output to PDF, then convert to HTML via latex2html, and then use another script to add Apple Help tags to the HTML output. (I prefer latex2html over htlatex because it provides a cleaner navigation structure.) The basic idea is that, after some refinement, I will release my modifications to latex2html as a pkg installer, and then use a GUI to configure the output. If you want to see some sample output from this process, look at the Apple Help for Aquamacs--I developed this ~ tool in the process of creating the Aquamacs help docs. Any suggestions/ideas/feedback about either of these projects are welcome. Looking forward to working with you all! - -- Cheers, Kevin Walzer, PhD WordTech Software--Open Source Applications and Packages for OS X http://www.wordtech-software.com http://www.kevin-walzer.com http://www.smallbizmac.com. mailto:sw...@wo... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC4uqKJmdQs+6YVcoRAhHpAJ9taMN0g2DL0XBOPMWPY+RoPJHR5wCfVIxl +S0/UVC5ECr0PjFm7/p9gaA= =3foc -----END PGP SIGNATURE----- |
|
From: Maarten S. <maa...@xs...> - 2005-07-13 21:57:03
|
On 13 Jul 2005, at 16:25, J=E9r=F4me Laurens wrote: > Le 12 juil. 05, =E0 22:42, Maarten Sneep a =E9crit : > >> Lack of time has kept me from properly starting the project, so =20 >> various minor points will be handled as I find the time. One that =20 >> bugged me for some time: the website. I've hosted on my private =20 >> account at my ISP, but not the site at sourceforge is starting to =20 >> come together. > > I could not read the articles... Fixed. Thanks for the pointer. > The templates are of no use if we do not work with bbedit, am i right? well, they are plain text, and the template variables are pretty easy =20= to follow for the most part. It is useful to have an editor that has =20 something similar to the glossary, to easily insert frequently used =20 snippets (like my html-version of the TeX logo). The least you could =20 do is use them as a starting point. But do whatever suits you, I'm happy to accept most text-based =20 formats (i.e. TeX, LaTeX, ConTeXt, plain-text, html). No word, but =20 that shouldn't come as a surprise. > Can't we have pdf articles too? yes, in due time. I'm not sure right now whether I should make those =20 available as project files, or as part of the normal site contents. I =20= will make pdf-versions (and *TeX sources) available later on, somehow. Maarten= |
|
From: <jer...@u-...> - 2005-07-13 14:26:56
|
Le 12 juil. 05, =E0 22:42, Maarten Sneep a =E9crit : > Hi, > > Lack of time has kept me from properly starting the project, so=20 > various minor points will be handled as I find the time. One that=20 > bugged me for some time: the website. I've hosted on my private=20 > account at my ISP, but not the site at sourceforge is starting to come=20= > together. > > At the moment it is just a copy of the private site, but if you submit=20= > an article, It will now be hosted on=20 > http://mactextoolbox.sourceforge.net, which looks more impressive than=20= > the old one ;-) So keep those articles, standards, and above all:=20 > great applications coming. So far I'm pleased with the most important=20= > part: the mailing list seems to be working, and over time I think=20 > it'll find a place in the developers community. > I could not read the articles... The templates are of no use if we do not work with bbedit, am i right? Can't we have pdf articles too? |
|
From: Maarten S. <maa...@xs...> - 2005-07-12 20:42:56
|
Hi, Lack of time has kept me from properly starting the project, so various minor points will be handled as I find the time. One that bugged me for some time: the website. I've hosted on my private account at my ISP, but not the site at sourceforge is starting to come together. At the moment it is just a copy of the private site, but if you submit an article, It will now be hosted on http:// mactextoolbox.sourceforge.net, which looks more impressive than the old one ;-) So keep those articles, standards, and above all: great applications coming. So far I'm pleased with the most important part: the mailing list seems to be working, and over time I think it'll find a place in the developers community. Maarten Never try to teach a pig to sing. It will only waste your time and annoy the pig. |
|
From: Jan H. <j.h...@tu...> - 2005-07-12 20:17:13
|
Am 12.07.2005 um 17:50 schrieb Maxwell, Adam R: > > On Jul 12, 2005, at 00:45, Jan Hegewald wrote: > > > >> Hello, >> do you know of any LaTeX et al. related projects regarding Spotlight? >> I only know of the DVI importer by Adam Maxwell at >> http://homepage.mac.com/amaxwell/ >> >> > > The next version of BibDesk will ship with an MDImporter, also, =20 > which will have behavior similar to that of Address Book or =20 > Mail...but only if you use BibDesk. > Of course I use it. (-; > > > >> I am thinking about writing one for LaTeX or at least Plain text =20 >> for files that aren=B4t indexed by default. (e.g. because mdimport =20= >> says: type 'public.data' no mdimporter). But mayba there is =20 >> already something like this out there? >> >> > > Norm Gall wrote one for his emacs distro <http://yaced.sf.net/>. =20 > No idea if it works or not; I don't like installing stuff =20 > from .pkgs :). > > Ideally, I think each program should bundle its own MDImporter, =20 > using that program's UTI, even if the importer has identical code. =20= > For instance, iTeXMac and TeXniscope could each bundle a DVI =20 > importer, since each can claim that UTI; however, only the program =20 > that owns DVI on your system would import it (at least, I think =20 > that's how it's supposed to work). My DVI importer is available =20 > under a BSD license, if anyone's interested. > I am interested in your DVI-importer source. Can you send it via email? --Jan-- |
|
From: Michael M. <mic...@gm...> - 2005-07-12 18:40:25
|
Hi Simon, I've been in touch with Richard before about integrating BD and CiteULike. He's the guy behind CiteULike.org, as well as being the person who wrote that wiki page. What he told me was that he started out thinking about the local client as described on that wiki then moved into working on citeulike as his focus changed to collaboration. At any rate, we're both interested in having good support for citeulike in BD 2, and if you'd like to see what we'd probably use as a model to start with, take a look at cocoalicious - the idea would be that bibdesk would be the cocoalicious to citeulike's del.icio.us. -mike On 7/12/05, Simon Spiegel <si...@si...> wrote: > Hi, >=20 > I just stumbled on Richard Cameron's CiteULike project which tries to > some kind of iTunes-like paper managment in combination with > citeUlike.org. I couldn't really figure out what's actually already > here, but it certainly looks interesting: http://dbk.ch.umist.ac.uk/ > wiki/index.php?title=3DCiteULike >=20 > I checked citeULike out today for the first ime and I really like it. > Some kind of integration with BD2 (although I don't really know how) > would be extremely cool. >=20 > Anotther project I already posted once which could be interesting is > the bibconvert project which allows you to do online conversions > between bibtex, Endnote XML and HTML directly on their website: > http://dret.net/bibconvert/ >=20 >=20 > simon >=20 >=20 > -- > Simon Spiegel > Mutschellenstr. 97 > 8038 Z=FCrich >=20 > Telephon: ++41 43 535 81 71 > Mobophon: ++41 76 459 60 39 >=20 > http://www.simifilm.ch >=20 > "I have never been certain that the moral of the Icarus myth is, as > is generally accepted, 'don't fly too high', or whether it might also > be thought of as: 'forget about the wax and feathers, and do a better > job on the wings." Stanley Kubrick >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by the 'Do More With Dual!' webinar happen= ing > July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual > core and dual graphics technology at this free one hour event hosted by H= P, > AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar > -- > Mactextoolbox-talk mailing list > Mac...@li... > https://lists.sourceforge.net/lists/listinfo/mactextoolbox-talk >=20 --=20 Michael McCracken UCSD CSE PhD Student San Diego Supercomputer Center http://www.cse.ucsd.edu/~mmccrack/ |
