Hi Horst, On Dec 2, 2005, at 11:14 AM, Horst Gutmann wrote:

Hi :)

Sorry, if this has already been this discussed, but I couldn't find anything related. I'm looking for a way to alter the appearance of let's say subsection headers in the Symbol Popup. Normally these would appear the same way as would sections. So I want to have subsections be slightly intended as for example class methods are in Python language bundle. My problem now is, I couldn't yet find out how this is achieved there :) I'd really appreciate any help on this matter :)

It seems to me this is set by the symbolTransformation preference in the Preferences part of the Python Bundle. I tried to do something similar for LaTeX and add:

symbolTransformation = 's/^(\s*)\section{(.+)}/$1 $2/; s/^(\s*)\ \subsection{(.+)}/$1 $2/';

in the "Symbol List" preference section of the bundle, but I couldn't get it to work. Maybe someone can explain to us how it is supposed to work, and why the above didn't work as expected? I bet Allan has explained it in great detail somewhere in the blog and I've missed it. Off to do an in depth search...

Best wishes, Horst "zeroK" Gutmann http://weblog.zerokspot.com

Haris

Horst Gutmann wrote:

Charilaos Skiadas wrote:

...

Hi Horst, On Dec 2, 2005, at 11:14 AM, Horst Gutmann wrote:

...

Hi :)

Sorry, if this has already been this discussed, but I couldn't find anything related. I'm looking for a way to alter the appearance of let's say subsection headers in the Symbol Popup. Normally these would appear the same way as would sections. So I want to have subsections be slightly intended as for example class methods are in Python language bundle. My problem now is, I couldn't yet find out how this is achieved there :) I'd really appreciate any help on this matter :)

It seems to me this is set by the symbolTransformation preference in the Preferences part of the Python Bundle. I tried to do something similar for LaTeX and add:

symbolTransformation = 's/^(\s*)\section{(.+)}/$1 $2/; s/^(\s*)\subsection{(.+)}/$1 $2/';

in the "Symbol List" preference section of the bundle, but I couldn't get it to work. Maybe someone can explain to us how it is supposed to work, and why the above didn't work as expected? I bet Allan has explained it in great detail somewhere in the blog and I've missed it. Off to do an in depth search...

Ah, the place I wasn't looking in :) I was only searching in the language definition. While checking the preferences I noticed that this is "Symbol List:Method" preference is bound to the declaration scope. So perhaps we also have to set this symbolTransformation setting for the meta.section scope or something like that :)

Horst

Bingo :) I made a new Preferences' entry and set its scope to "text.latex meta.section" and it seems to work more or less :) Just some minor problems with the regexp as it seems :)

Charilaos Skiadas wrote:

On Dec 2, 2005, at 5:11 PM, Horst Gutmann wrote:

...

Bingo :) I made a new Preferences' entry and set its scope to

"text.latex meta.section" and it seems to work more or less :) Just some

minor problems with the regexp as it seems :)

Did you make any changes to the regexp i posted? because it doesn't work for me. Over here, I just changed the exisitng preferences entry instead of creating a new one, and set its scope to "text.latex meta.section". i also tried to create a new preferences entry and put the info there, but that didn't work either. I mean, the sections and subsections are being shown, but it does not seem that the symbolTransformation is being called, they are just shown the usual way.

Haris

No sorry :S I was way too optimistic after seeing a change in the symbollisting thanks to having also subsubsections in my document :S

Horst

On 3/12/2005, at 1:00, Charilaos Skiadas wrote:

1. First of all, you need to create a new preferences item. WHY?

I'd really like to know that.

You don't. I made the current one: text.latex meta.section.latex and it works. But you have to make one edit to the document, before the symbol list is rebuilt, so maybe that's what threw you off.

2. Second, any changes you make only take effect after you closed

the bundle editor. Again, WHY? That's not the case for commands and snippets and stuff.

I hope it will change real-time in the future, but a preference change affects a lot, so a lot of caches needs to be flushed, things needs to be re-parsed, a.s.o. -- so currently this only happens when you close the window.

Commands, snippets, etc. are special in that when you execute one of these, it “commits” the current changes in the bundle editor. But things like preferences, language grammars etc. are in use all the time, so you (currently) need to manually commit (by closing the window, or for the latter, using the Test button).

3. This is the code I used now [...] two questions on that:

a) Why don't the spaces that $1 catches being shown? They are in the python thing.

Because meta.section match “(sub)*section…” and not “(^\s*)?(sub) *section…”. I.e. the leading spaces are not included in the scope.

b) the \subsubsection rule gives me: \subsubsection{stuff} instead of just "stuff".

You rule had a (closing) ' before the last subst. This works for me:

symbolTransformation = ' s/^(\s*)\section{(.+)}/$1 $2/; s/^(\s*)\subsection{(.+)}/$1\t $2/; s/^(\s*)\subsubsection{(.+)}/$1 \t \t $2/; ';

Of course the “^(\s*)” part has no meaning unless the language grammar gets changed.

Other than that, it works well. The tabs inserted by \t get interpreted, even though spaces seem not to.

As for using \t, I use the em-space in the few transformation I've made (e.g. Markdown headings), this looks a little better. Though you'll have to copy/paste it, and with a fixed width font (bundle editor), it looks just like a regular space -- I'll add support for \x {nnnn} for these things.

On Dec 3, 2005, at 5:02 AM, Allan Odgaard wrote:

On 3/12/2005, at 1:00, Charilaos Skiadas wrote:

...

1. First of all, you need to create a new preferences item. WHY?

I'd really like to know that.

You don't. I made the current one: text.latex meta.section.latex and it works. But you have to make one edit to the document, before the symbol list is rebuilt, so maybe that's what threw you off.

Ah, probably that was it. It works fine now with your latest commit.

...

2. Second, any changes you make only take effect after you closed

the bundle editor. Again, WHY? That's not the case for commands and snippets and stuff.

I hope it will change real-time in the future, but a preference change affects a lot, so a lot of caches needs to be flushed, things needs to be re-parsed, a.s.o. -- so currently this only happens when you close the window.

Commands, snippets, etc. are special in that when you execute one of these, it “commits” the current changes in the bundle editor. But things like preferences, language grammars etc. are in use all the time, so you (currently) need to manually commit (by closing the window, or for the latter, using the Test button).

Yeah, when I thought about it I figured that it would be too messy to have it work real-time, and it is fine as it is, but maybe a little comment on the page would be helpful (to the effect: "Note: This will only take effect if you...), exactly because the behavior is not consistent. Well, the only thing I found irritating is the lack of a shortcut for the Languages editor and for the Preferences editor, or did I miss them? Having to close the bundle editor for effects to show is fine (though a save button as Tim says is even better), but having to press three buttons to get back where you were is not.

...

3. This is the code I used now [...] two questions on that:

a) Why don't the spaces that $1 catches being shown? They are in the python thing.

Because meta.section match “(sub)*section…” and not “(^\s*)?(sub) *section…”. I.e. the leading spaces are not included in the scope.

...

b) the \subsubsection rule gives me: \subsubsection{stuff} instead of just "stuff".

You rule had a (closing) ' before the last subst. This works for me:

symbolTransformation = ' s/^(\s*)\section{(.+)}/$1 $2/; s/^(\s*)\subsection{(.+)}/$1\t $2/; s/^(\s*)\subsubsection{(.+)}/$1 \t \t $2/; ';

ah, the dangers of using the small unpleasant window to edit, rather than a wonderful textmate window :-)

Of course the “^(\s*)” part has no meaning unless the language grammar gets changed.

Oh, we can just remove that, I was using it to try to use that as space, as the Python bundle does, or at least that's what I thought they do.

...

Other than that, it works well. The tabs inserted by \t get interpreted, even though spaces seem not to.

As for using \t, I use the em-space in the few transformation I've made (e.g. Markdown headings), this looks a little better. Though you'll have to copy/paste it, and with a fixed width font (bundle editor), it looks just like a regular space -- I'll add support for \x{nnnn} for these things.

Is that what is being used in the Python code? \x{nnnn} support would be great, as well as explanation of one or two of the choices for nnnn. For instance, I still have no idea what em-space is, guessing some unicode character.

But really, why doesn't plain old space work, both here and in ctags? It seems to be completely ignored if it's at the beginning. Btw, can you make it so that it looks at the number of "sub" in front of section, and puts an equal amount of em-spaces? That would be divine.

Haris

On 3/12/2005, at 15:11, Charilaos Skiadas wrote:

Well, the only thing I found irritating is the lack of a shortcut for the Languages editor and for the Preferences editor, or did I miss them?

There was one in the past, and I do miss it myself. It's a pain for me to do shortcuts “correctly” when there's no menu item for the action. I'll likely put back the status bar stuff in the menus (so they're both places) to get the key.

Though ctrl-opt-cmd B will re-open the bundle editor where you last where (it'll switch the filtering, but that shouldn't matter).

[...] Is that what is being used in the Python code?

The Python code preserves leading whitespace _and_ turns 'def' into an em-space (to have methods indented more than classes).

\x{nnnn} support would be great, as well as explanation of one or two of the choices for nnnn. For instance, I still have no idea what em-space is, guessing some unicode character.

nnnn would just be the character code. An em-space is a space with the width of an M. A normal space is generally to small to be used for indenting items in a list, where a tab gives too much indent. The em-space is generally nice. There's also en-space (for the width of N) and figure-space, which has the width of a digit (digits generally have the same width in proportional fonts) which can be used to right- align numbers. If you open a diff file you can see I spent way too much time aligning up line ranges in the symbol list using the digit space :)

There are half a dozen other space types, all in unicode. Non- breaking space would be known by most, which IIRC is actually used in some languages (French?) to keep multiple words as one unit.

But really, why doesn't plain old space work, both here and in ctags? It seems to be completely ignored if it's at the beginning.

At least for TextMate, it just never sees these because the scope selector does not include them. The Python grammar was specifically modified to also make the declaration.function.* pick up leading spaces (for use in the list).

Btw, can you make it so that it looks at the number of "sub" in front of section, and puts an equal amount of em-spaces? That would be divine.

Sure…

On 4/12/2005, at 8:35, Charilaos Skiadas wrote:

I meant the space in the substitution part of the regexp. Why doesn't something like: s/^\section{(.+)}/ $1/;

Works fine for me. You're on r790, right?

On 4/12/2005, at 8:52, Charilaos Skiadas wrote:

So, does the preferences part support variable regexp substitutions also? Like ${1/^.+$/• $0/g} or something similar.

No, but technically I think it should be possible through a series of regexp substitutions, although not as handy.

Especially for the Markdown headings and (sub)*section I guess recursive regexp substitutions would be nice -- maybe that's actually not so off… I could probably add that to all format strings in TM.