On 11.08.2009, at 20:29, michael_j_barber wrote:
> There are a couple of modes I use that haven't been updated. By
> looking through the example in the mode SDK, it seems pretty
> straightforward: just add foldable="yes" to appropriate states
> defined in SyntaxDefinition.xml for the mode. The hardest part,
> then, would be adding relevant states for modes that lack them.
>
That's the basic idea.
> Is that really all there is to it? Any other tips to know or
> pitfalls to beware of?
>
As always I'd advice to have a look at the modes we ship for the
"state of the art" in terms of black voodoo mode creation. ;)

C.mode is pretty straight forward, XML.mode is a bit more advanced,
PHP-HTML.mode or ERB.mode are pretty complicated.

I put some advanced features in the engine for fine-tuning and edge
cases, that we haven't yet documented, mainly because I want the dust
to settle a bit before we commit to "public API". So there is some
"headroom" should you run into a wall. In any case, let me know if
have trouble, I'm here to help and to learn how to make this stuff
more approachable for people not sitting in this office. ;)

All the best,
Martin

Thanks for the confirmation. It looks like I will need to define some states for
a couple of modes, so I'm sure I'll be following up soon with some questions
along those lines.

I've already noticed a bit of the modal dark arts in the Python mode. Very
intriguing!

--- In SubEthaEdit@yahoogroups.com, Martin Pittenauer <map@...> wrote:
>
>
> On 11.08.2009, at 20:29, michael_j_barber wrote:
> > There are a couple of modes I use that haven't been updated. By
> > looking through the example in the mode SDK, it seems pretty
> > straightforward: just add foldable="yes" to appropriate states
> > defined in SyntaxDefinition.xml for the mode. The hardest part,
> > then, would be adding relevant states for modes that lack them.
> >
> That's the basic idea.
> > Is that really all there is to it? Any other tips to know or
> > pitfalls to beware of?
> >
> As always I'd advice to have a look at the modes we ship for the
> "state of the art" in terms of black voodoo mode creation. ;)
>
> C.mode is pretty straight forward, XML.mode is a bit more advanced,
> PHP-HTML.mode or ERB.mode are pretty complicated.
>
> I put some advanced features in the engine for fine-tuning and edge
> cases, that we haven't yet documented, mainly because I want the dust
> to settle a bit before we commit to "public API". So there is some
> "headroom" should you run into a wall. In any case, let me know if
> have trouble, I'm here to help and to learn how to make this stuff
> more approachable for people not sitting in this office. ;)
>
> All the best,
> Martin
>

I've begun adding folding support to the Makefile mode, specifically by adding a
Command state to indicate the blocks of build commands for a target. I have a
few questions and observations.

First, the keywords are not colored as I would expect. As a specific example of
the issue, consider the following two lines:
SHELL=/bin/sh
SHELL = /bin/sh
The SHELL in the first line is colored as a keyword, the SHELL in the second is
not. Some keywords don't ever seem to be colored. This happens with the
unmodified Makefile mode as downloaded from the codingmonkeys.de website, before
I make any changes. I really don't have any idea why this is. The definitions
seem consistent with how keywords are given in other modes, so I suspect it may
have something to do with the state definitions.

Second, where should states actually be defined? The C mode has all states as
substates of the default state. The current Makefile mode has a default mode and
two other modes (SingleComment and String) at the same level. What makes more
sense, here?

I relatively arbitrarily decided that I'd put the new state at the same level as
the other three, and not as a substate of the default state. After some
experimentation, I've arrived at this:
<state id="Command" type="block" foldable="yes">
     <begin><regex>(?:^\t)</regex></begin>
     <end><regex>[\n\r](?=[^\t])</regex></end>
     <import keywords-only="yes" />
     <state-link state="SingleComment" />
     <state-link state="String" />
</state>
That is, a command block starts with a tab at the beginning of a line and ends
with a linefeed or carriage return that is not followed by a tab. The keywords
are imported from the default state, and the SingleComment and String states are
linked. Note that a single <import /> wouldn't work, as it would lead to nested
blocks instead of keeping consecutive tab-indented lines in the same block.

As I understand the file format, as described at
<http://codingmonkeys.de/subethaedit/mode.html>, it should have been possible to
use imports instead of the state links, but it did not work. Why is this?

The end regex for the Command state is quite similar to that for the
SingleComment state, which ends with [\n\r].  The similarity produces an edge
case where a command block cannot end with a comment line; in such a case, the
following line is taken as part of the command block. It seems clear enough why
this is: the final linefeed of the command block is taken to close the comment,
so another one is needed to close the command block. That makes sense;
otherwise, it would not be possible to, e.g., nest curly braces. Should I just
accept this edge case, or is there a solution?

Incidentally, I think the definition is wrong. I don't think a carriage return
\r is a valid line ending for a makefile. It is not in GNU Make, at least. I
just followed what was already in the SingleComment state. Can anyone provide an
authoritative answer to this?

On 15.08.2009, at 15:16, michael_j_barber wrote:

> I've begun adding folding support to the Makefile mode, specifically
> by adding a Command state to indicate the blocks of build commands
> for a target. I have a few questions and observations.
>
> First, the keywords are not colored as I would expect. As a specific
> example of the issue, consider the following two lines:
> SHELL=/bin/sh
> SHELL = /bin/sh
> The SHELL in the first line is colored as a keyword, the SHELL in
> the second is not. Some keywords don't ever seem to be colored. This
> happens with the unmodified Makefile mode as downloaded from the
codingmonkeys.de
>  website, before I make any changes. I really don't have any idea
> why this is. The definitions seem consistent with how keywords are
> given in other modes, so I suspect it may have something to do with
> the state definitions.

Is = part of <charsintokens> in your case?


> Second, where should states actually be defined? The C mode has all
> states as substates of the default state. The current Makefile mode
> has a default mode and two other modes (SingleComment and String) at
> the same level. What makes more sense, here?

Usually the default state is a parent to all other states.

> That is, a command block starts with a tab at the beginning of a
> line and ends with a linefeed or carriage return that is not
> followed by a tab. The keywords are imported from the default state,
> and the SingleComment and String states are linked. Note that a
> single <import /> wouldn't work, as it would lead to nested blocks
> instead of keeping consecutive tab-indented lines in the same block.

<import> imports the contents of a state into another. I.e. if you
want to create a state that behave like the default, but with
additional state, import is the way to go. You have to provide a frame
(state/begin/end) to import into.

<state-link> places an existing state as a child into another state.
I.e. if you want to have the string state in another state, with begin/
end conditions intact.


> Should I just accept this edge case, or is there a solution?

I tend to use .(?=[\n\r]) in these cases to have proper state
termination.

Allt the best,
Martin

--- In SubEthaEdit@yahoogroups.com, "michael_j_barber" <michael_j_barber@...>
wrote:
> First, the keywords are not colored as I would expect. As a specific example
of the issue, consider the following two lines:
> SHELL=/bin/sh
> SHELL = /bin/sh
> The SHELL in the first line is colored as a keyword, the SHELL in the second
is not. Some keywords don't ever seem to be colored. This happens with the
unmodified Makefile mode as downloaded from the codingmonkeys.de website, before
I make any changes. I really don't have any idea why this is. The definitions
seem consistent with how keywords are given in other modes, so I suspect it may
have something to do with the state definitions.
>

I noticed similar behavior in the PHP-HTML mode and I filed a bug for it
(SEE-3865).  As excited as I am for the code folding, I had to downgrade to
3.2.1, because the inconsistent and erratic syntax coloring was proving to be a
distraction and decreasing my productivity.

Jeff Groth

On 19.08.2009, at 16:49, jtgroth007 wrote:

> I noticed similar behavior in the PHP-HTML mode and I filed a bug
> for it (SEE-3865). As excited as I am for the code folding, I had to
> downgrade to 3.2.1, because the inconsistent and erratic syntax
> coloring was proving to be a distraction and decreasing my
> productivity.

Not sure these issues are related.
I'm sorry for the bug however. We will try to address it for 3.5.1
which should be due in about 2 weeks.

All the best,
Martin

--- In SubEthaEdit@yahoogroups.com, Martin Pittenauer <map@...> wrote:
>
>
> On 15.08.2009, at 15:16, michael_j_barber wrote:
>
> > First, the keywords are not colored as I would expect. As a specific
> > example of the issue, consider the following two lines:
> > SHELL=/bin/sh
> > SHELL = /bin/sh
> > The SHELL in the first line is colored as a keyword, the SHELL in
> > the second is not. Some keywords don't ever seem to be colored. This
> > happens with the unmodified Makefile mode as downloaded from the
codingmonkeys.de
> >  website, before I make any changes. I really don't have any idea
> > why this is. The definitions seem consistent with how keywords are
> > given in other modes, so I suspect it may have something to do with
> > the state definitions.
>
> Is = part of <charsintokens> in your case?
>
No, it is not. The contents of <charsintokens> is:
<![CDATA[_0987654321abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ@-.]]>

It looks like SHELL should be identified as a separate token in either case.
Looks like it could be a bug, as Jeff Groth suggests.

>
> > Second, where should states actually be defined? The C mode has all
> > states as substates of the default state. The current Makefile mode
> > has a default mode and two other modes (SingleComment and String) at
> > the same level. What makes more sense, here?
>
> Usually the default state is a parent to all other states.
>
Why, though? The makefile mode has them separate, and it doesn't seem to cause
any harm. I'm looking for understanding of the options.

I suppose I should make clear at this point that, even though I'm listed on the
modes page as a contributor for the Makefile mode, I had nothing to do with the
definition of the syntax -- all I did was add the script and triggers for files
with the standard names for makefiles.

> > That is, a command block starts with a tab at the beginning of a
> > line and ends with a linefeed or carriage return that is not
> > followed by a tab. The keywords are imported from the default state,
> > and the SingleComment and String states are linked. Note that a
> > single <import /> wouldn't work, as it would lead to nested blocks
> > instead of keeping consecutive tab-indented lines in the same block.
>
> <import> imports the contents of a state into another. I.e. if you
> want to create a state that behave like the default, but with
> additional state, import is the way to go. You have to provide a frame
> (state/begin/end) to import into.
>
> <state-link> places an existing state as a child into another state.
> I.e. if you want to have the string state in another state, with begin/
> end conditions intact.
>
Thanks for the clarification, that helps a lot.

>
> > Should I just accept this edge case, or is there a solution?
>
> I tend to use .(?=[\n\r]) in these cases to have proper state
> termination.
>
Ah, that does it. I had not properly understood how SEE handles the states. For
others who might have had the same confusion, colorization of the state includes
the begin and end text, while the folding excludes it. Rather a nice solution
for just this case!

On 19.08.2009, at 18:39, michael_j_barber wrote:

> It looks like SHELL should be identified as a separate token in
> either case. Looks like it could be a bug, as Jeff Groth suggests.

Indeed I identified this as a bug we will fix for 3.5.1. It causes
some keyword groups to not highlight consistently currently. Sorry for
that. Took me a while to catch it.

> > Usually the default state is a parent to all other states.
> >
> Why, though? The makefile mode has them separate, and it doesn't
> seem to cause any harm. I'm looking for understanding of the options.

The default mode has no entry conditions and is the starting point for
the parser. Any state with starting conditions that is neither
referenced nor included is only handled correctly because the syntax
definition parser is very liberal to maintain backwards compatibility
with definitions made before we had  nested states.

So, in short, not having states as childs of default works, but should
be avoided.

All the best,
Martin

Does SubEthaEdit or the OS (Snow Leopard) control the double-click selection?

I updated to 3.5 at roughly the same time I installed Snow Leopard so I don't
know which is causing it - but double clicking on a javascript variable is also
selecting the period and function.  So double clicking variableName.function();
selects "variableName.function" whereas previously it would only select
"variableName".

Is this a SubEthaEdit thing? I don't recall it doing it in the past - didn't
want to post this as a bug on BugShelf if it's an OS thing.

(Also, as a note about BugShelf, why don't you use a regular bug tracker that
displays open issues so people don't report already known bugs?)

On 30.08.2009, at 20:26, ocdgeek wrote:

> Does SubEthaEdit or the OS (Snow Leopard) control the double-click
> selection?
>
> I updated to 3.5 at roughly the same time I installed Snow Leopard
> so I don't know which is causing it - but double clicking on a
> javascript variable is also selecting the period and function. So
> double clicking variableName.function(); selects
> "variableName.function" whereas previously it would only select
> "variableName".
>
> Is this a SubEthaEdit thing? I don't recall it doing it in the past
> - didn't want to post this as a bug on BugShelf if it's an OS thing.

It's a change in Snow Leopard, but we are currently contemplating to
make SubEthaEdit behave like 10.5 in that case, as the change strikes
us as odd in general, and especially in a code editor context.

>
> (Also, as a note about BugShelf, why don't you use a regular bug
> tracker that displays open issues so people don't report already
> known bugs?)

We like to have everything in one place and don't split up public/
private bug tracking.
Also, duplicates, if they happen at all, help us to see how often a
issue surfaces, or how many people want a new feature, when it comes
to requests.

All the best,
Martin

Awesome. It does seem like an odd behavior change although I'm sure they have
their reasons.  What are the chances you'll implement the fix and then Apple
will revert their change in the next update?

Should I report syntax highlighting inconsistencies (PHP-HTML) on BugShelf?

On 31.08.2009, at 17:24, ocdgeek wrote:

> Awesome. It does seem like an odd behavior change although I'm sure
> they have their reasons. What are the chances you'll implement the
> fix and then Apple will revert their change in the next update?

We decided to handle selection differently than the standard text
system on 10.6 in that case and maintain 10.5 behavior in 3.5.1. Apple
is welcome to chance their mind, but we should not be affected by them
reverting to 10.5 behavior too.

> Should I report syntax highlighting inconsistencies (PHP-HTML) on
> BugShelf?

Yes please! We are just about to release 3.5.1, anything we can test
our new fixes against is very welcome. If you can upload sample source
files, that would make our work a lot easier.

All the best,
Martin

Is there any way to get either the indentation level or the tab width for
scripting purposes? I don't see anything promising in the AppleScript
dictionary, but hopefully there is some way I'm overlooking.

On 15.09.2009, at 21:10, michael_j_barber wrote:

> Is there any way to get either the indentation level or the tab
> width for scripting purposes? I don't see anything promising in the
> AppleScript dictionary, but hopefully there is some way I'm
> overlooking.

Currently this is not available via AppleScript unfortunately.
But I will file it as a feature enhancement.

All the best,
Martin

I notice that scripts no longer appear in the contextual menus, regardless of
the "inContextMenu" setting. Is this deliberate? Will the feature return?

On 23.09.2009, at 11:33, Michael wrote:

> I notice that scripts no longer appear in the contextual menus,
> regardless of the "inContextMenu" setting. Is this deliberate? Will
> the feature return?

That's a bug we intend to fix.

All the best,
Martin

I wrote some scripts to support Ctags within SEE. They can be downloaded here:
<http://www.box.net/shared/zksls0d28x>. I blogged about the scripts; a summary
and index to the posts are here:
<http://appliedabstraction.blogspot.com/2010/02/exploring-ctags-summary.html>.

The scripts add two menu items: using Ctags for text completion and using Ctags
to find definitions of symbols. This overlaps some with what SEE can already do,
but Ctags has some advantages for projects that consist of a large number of
files.

A word of warning: I'm far from an expert on Ctags, so there may be some
sub-optimal, or outright wrong, choices in how the scripts are implemented. Do
let me know of any bugs found or improvements that could be readily made.

--
Michael

I've written a mode for TaskPaper documents. The main features are syntax
highlighting, scripts for task management, and project navigation using the
function popup menu and Next/Previous Symbol.

More information at
<http://appliedabstraction.blogspot.com/2010/02/taskpaper-mode-for-subethaedit.h\
tml>, or just download at <http://www.box.net/shared/kg3jzb9leh>.

Some tasks in SEE make more sense to be available for all modes, not just a few.
As an example, adding or removing comments is of interest for just about every
mode. I wrote some "modeless scripts" for a few of these tasks: adding and
removing line-oriented comments, adding and removing block comments, and code
indentation. The latter has been mentioned on this list before, and served as a
model for the others.

I think it would be easy enough to add similar modeless scripts for syntax
checking, compilation, and so on -- I just haven't had specific need yet!

Download at <http://www.box.net/shared/ns6jeny3ny>, or see more details at
<http://appliedabstraction.blogspot.com/2010/03/modeless-scripts-for-subethaedit\
.html>.

Here is the meat of the script I'm using.
--It runs my front document in murgaLua, all well and good.
tell application "Terminal"
		 activate
		 set shellscriptString to "/usr/bin/murgalua " & SQ & documentPath & SQ as text
		 --set the contents of the front window to shellscriptString
		 do script shellscriptString
		 set the clipboard to contents of the front window as text
		 set ds to contents of the front window as string
	 end tell

-- Here is where I'm going woefully wrong
	 tell application "SubEthaEdit"
	     set myf to make new document
		 set myf to the front document
		 set contents of the front document to ds
	 end tell
-- from that chunk i'm getting many many 'untitled' documents.

My question is how do I set it up so the same document is always opened and
appended to?

While I'm on that subject how would I set that document to be someplace any old
SubethaEdit user on any machine can access if using the script.

Using "/Users/myaccount/somefolder/murgalog.txt" doesn't seem like the right
solution.

Thanks in advance,
Mr Bill

Hi folks,

Just wanted to let you know that I just released version 2.0 of my SubEthaEdit
scripts.
You can find them over at
http://christoffer.winterkvist.com/groups/christofferwinterkvist/wiki/743d7/SubE\
thaEdit__Scripts.html

It includes basic selections, wrap scripts, snippets and some form of project
solution.

Hope you like it!

Feedback, suggestions and other form of complaints (just kidding :) ) can either
be posted here, yelled on Twitter (@MrStench) or by sending me an email at
christoffer [at] winterkvist [dot] com .

Hi *,

I am currently trying hard to switch from TexShop to SubEthaEdit for my
scientific writing.
I would love to explain you a bit about the work-flow I've set up so far and
would like to get your feedback on "how stupid I've made several things" in case
I've done so.

I write in SubEthaEdit - surprise. Using a little 2-liner script I am polling
the folder all my .tex files are inside and if any of them get changed I call
typeset everything again and open the newly created PDF using Skim. Just in case
anybody is interested in the script I use to poll the folder:
latexmk -pvc -pdf -e '$pdflatex=q/pdflatex --synctex=1 %O %S/;
$pdf_previewer=q/open -a Skim %S/' $1

In Skim I use the 'see' command line tool to be able to go back to SubEtha
directly finding the piece of text I am interested in. It works almost fine...
unfortunately I experience some bugs when I use \input and the TeX code is
distributed over several files.

Currently I struggle a bit with the other direction: so how can I go from
SubEtha and jump to the corresponding point in the PDF???

In total I have 3 Questions:
(1) Does anybody know any workarounds for the bug I've shortly mentioned? Who
has experience similar problems?
(2) Who knows a good way to go forwards from SubEtha to PDF
(3) Does anybody know any further tricks you think are helpful when TeXing with
SubEtha?

Thanks,
Florian

PS: the reason why I do not use the typeset button that comes with SubEtha is
mainly that I get ZERO feedback in case typesetting causes errors.

--- In SubEthaEdit@yahoogroups.com, "jug.florian" <florian.jug@...> wrote:

> In total I have 3 Questions:
> [...]
> (2) Who knows a good way to go forwards from SubEtha to PDF
> (3) Does anybody know any further tricks you think are helpful when TeXing
with SubEtha?
>
> [...]
>
> PS: the reason why I do not use the typeset button that comes with SubEtha is
mainly that I get ZERO feedback in case typesetting causes errors.
>

This is not the whole story. The LaTeX mode is customizable, so you can change
how the document is compiled. This lets you pipe the output of the typesetter
(which you can choose) to another program for viewing the output. There's a
description of how to show the output from latexmk in a SEE window at
<http://appliedabstraction.blogspot.com/search/label/SEEing%20LaTeX>.

That said, I make no recommendation that you actually should take that approach.
Personally, I've come around to using latexmk -pvc in a Terminal window to
continuously compile and update the preview, much like you're doing.

My main use of LaTeX is also scientific writing. Scientific writing is a
significant task, so my main trick is to treat it like any other significant
*programmatic* task -- keep it under version control, use a makefile for the
entire project, and automate what I can using shell scripts. With this approach,
I'll always have Terminal around anyway, so keeping latexmk -pvc going is pretty
natural.

You can save key scripts with a .command ending, which lets you double-click
them in the Finder to run them. One nice use of this is to launch latexmk.
Another is to open up the currently relevant documents for the paper as tabs in
SEE, or another application, depending on the type of document.

Hope that helps.
Michael

Hi,
is it possible in general to make the folding working also for chapters,
section, paragraphs, .. in LaTeX Mode? It works for begin-end-blocks, but the
subdivisions doesn't have that.

I'd like to determine the tab width of SEE documents. There doesn't seem to be
anything relevant in the scripting dictionary, but perhaps I've just missed it.
Is there a way to get the width? (I'm not really willing to resort to UI
scripting.)

I wrote a little AppleScript to open Markdown documents in the Marked previewer,
and thought some others might find it useful. It needs to be saved as a compiled
script in the Scripts folder within the Markdown mode (while you're there, take
advantage and remove the silly rot13 script that's included for some
inexplicable reason).

tell application "SubEthaEdit"
	 if not (exists path of front document) then
		 error "You have to save the document first"
	 end if
	 set docpath to the path of the front document
end tell

set mdFile to POSIX file docpath
tell application "Marked" to open mdFile

on seescriptsettings()
	 return {displayName:"Preview with Marked", shortDisplayName:"Preview",
keyboardShortcut:"@O", toolbarIcon:"ToolbarIconRun", inDefaultToolbar:"yes",
toolbarTooltip:"Preview current document with Marked", inContextMenu:"no"}
end seescriptsettings

For reasons not entirely clear to me, the script will hang on some files
(naturally, none I tested before posting about it!), with SubEthaEdit waiting
for a response from Marked. Adding an <code>ignoring application
responses</code> takes care of that. Sorry for any inconvenience.

Here's the revised script:

tell application "SubEthaEdit"
	 if not (exists path of front document) then
		 error "You have to save the document first"
	 end if
	 set docpath to the path of the front document
end tell

set mdFile to POSIX file docpath
ignoring application responses
	 tell application "Marked" to open mdFile
end ignoring

on seescriptsettings()
	 return {displayName:"Preview with Marked", shortDisplayName:"Preview",
keyboardShortcut:"@O", toolbarIcon:"ToolbarIconRun", inDefaultToolbar:"yes",
toolbarTooltip:"Preview current document with Marked", inContextMenu:"no"}
end seescriptsettings