Re: [Geany-devel] Indentation using regex (was [PATCH 14/19] Rewrite tab switching queue)
Nevermind, I need to better RTFM:
`Preferences->Editor->Features->Newline strips trailing spaces` seems to
do exactly what I was talking about (awesome!).
Sorry for the noise
Cheers,
Matthew Brush
On 12/06/2011 06:06 PM, Matthew Brush wrote:
On 12/05/2011 10:30 AM, Colomban Wendling wrote:
Hi,
I know this is a more than one year old discussion, but I was messing
with a very similar thing a few minutes ago when wanting to add
autoindent support for SH.
Sorry I haven't followed/read the whole thread, but I wanted to add a
feature request if someone's going to hack on this.
It would be nice if the auto-indent was "undone" when you leave a blank
line, example (assuming this is all being typed, not loaded from disk):
struct foobar
{
int baz;<--- hit enter here
<--- here's an audo-indented tab
char *bong;<-- auto-indented
};
Would do this (assuming it happens as you type):
struct foobar
{
int baz;<--- hit enter here
<--- indent removed, since the user hit enter again and kept typing
char *bong;<-- re-indented
};
This is the #1 thing I fight against in the auto-indenter, which is why
I usually turn on "Strip trailing spaces and tabs", but that's too
brute-force since it applies to the whole file on save instead of just
the whitespace noise added by the auto-indenter.
Anyway, just a request, feel free to ignore :)
Cheers,
Matthew Brush
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Indentation using regex (was [PATCH 14/19] Rewrite tab switching queue)
On Wed, Dec 7, 2011 at 11:06 AM, Jiří Techet wrote: > On Tue, Dec 6, 2011 at 21:56, Lex Trotman wrote: >> [...] >>> Maybe I don't understand it correctly but does this mean that if you >>> open an existing file, you'd re-indent it completely based on the >>> regexes? I don't think this is a good idea because this could lead to >>> whitespace change in every line when you edit just a single line. >>> >> >> No, thats another reason why I rejected option 1 >> >>> Or does it mean to have these indent numbers just internally and use >>> them only when when auto-indentation is done? I often work with files >>> edited by many people over many years which have inconsistent indents. >>> Imagine the correct indent size is 4 but someone used just 2 indents >>> in the outer "if" block. If I insert new "if" inside this block, the >>> indent size will be 6 because of the incorrect outer indent. This is >>> exactly why I used the "delta" indent solution to be locally correct >>> and have minimal impact on (and be minimally affected by) the rest of >>> the code. >> >> The algorithm will give 6 since it only considers the previous line >> and the line it is indenting which is the line with the cursor. >> >> >>> >>> One more thing - with global indents you have to be sure that the >>> regexes catch all the indentation cases (without false positives) >>> otherwise one error will affect the indentation everywhere in the rest >>> of the file. You can do crazy stuff with some languages so I can >>> imagine such a thing can happen easily (single line with end of >>> multi-line comment followed by end block followed by another comment). >>> With delta indentation it's much less critical - the indent may be >>> incorrect for the next line but this won't affect the rest of the file >>> in any negative way. Moreover, you usually don't do things like the >>> comment example when you write the code and when you need >>> auto-indentation; you usually add them afterwards when no >>> autoindentation is needed. >>> >>> Final remark - better not to auto-indent at all than to indent >>> incorrectly. There's nothing worse than an editor (actually anything) >>> which tries to be smart in an annoying way. >> >> Don't worry there is no intention that auto-indentation does more than >> give a mostly right indent on new lines and mostly correct it when you >> type } on that new line. >> >> I did clearly say it should not change any manual indentation. > > Ah, sorry, after re-reading it again I think I misunderstood your > algorithm originally so please forget what I said. > > What you propose sounds good. Basically the main difference is that > you take the previous line indentation into account which is what my > original algorithm didn't do. This really appears to solve all the > problems in quite an elegant way (much nicer than the flags thing I > suggested). Just a detail that strictly speaking the "N-1 line" should > be previous non-empty line. In fact I also omitted to say that comments should be ignored as well, which means it has to run after scintilla lexing is complete. > > I'm actually not completely against the immediate indent when typing > (without having to press enter). Your algorithm is capable of > indentation "undo" when the regex doesn't match any more. I think it's > quite OK if "fi" unindents the line and subsequent letter returns it > back. Something like that already happens with syntax highlighting > where the keyword becomes blue when you type it but changes back to > black when you add additional letters. Yes, my only objection was having to run the regexes over two lines for each character, but maybe some judicious caching of the results of line N-1 and the start of line N can reduce the work required most of the time. Cheers Lex > > Cheers, > Jiri > ___ > Geany-devel mailing list > Geany-devel@uvena.de > https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Indentation using regex (was [PATCH 14/19] Rewrite tab switching queue)
On 12/05/2011 10:30 AM, Colomban Wendling wrote:
Hi,
I know this is a more than one year old discussion, but I was messing
with a very similar thing a few minutes ago when wanting to add
autoindent support for SH.
Sorry I haven't followed/read the whole thread, but I wanted to add a
feature request if someone's going to hack on this.
It would be nice if the auto-indent was "undone" when you leave a blank
line, example (assuming this is all being typed, not loaded from disk):
struct foobar
{
int baz;<--- hit enter here
<--- here's an audo-indented tab
char *bong;<-- auto-indented
};
Would do this (assuming it happens as you type):
struct foobar
{
int baz;<--- hit enter here
<--- indent removed, since the user hit enter again and kept typing
char *bong;<-- re-indented
};
This is the #1 thing I fight against in the auto-indenter, which is why
I usually turn on "Strip trailing spaces and tabs", but that's too
brute-force since it applies to the whole file on save instead of just
the whitespace noise added by the auto-indenter.
Anyway, just a request, feel free to ignore :)
Cheers,
Matthew Brush
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Default search behavior is irritating
On 12/06/2011 11:34 AM, Colomban Wendling wrote: Le 06/12/2011 03:02, Matthew Brush a écrit : On 12/05/2011 05:52 PM, Lex Trotman wrote: On Tue, Dec 6, 2011 at 12:18 PM, Matthew Brush wrote: On 12/05/2011 01:27 PM, Colomban Wendling wrote: Applied, thanks! Ouch! I wonder how many hours it will take me to convert the old Glade 2 file to GtkBuilder *again*. I say we either delete the gtkbuilder branch or merge it into master. It's basically working fine for along time and I don't think anyone is testing it since it's not in master. I agree, why hasn't it been committed already? Because only a few people have tested it and we don't have a `devel` branch for "unstable" code :) It'd need people to try the "devel" branch too ;) Good point :) Well. I haven't tried the branch that much either -- only tried it once actually I think. My bad. It's hard to use it consistently for day-to-day use since we're always testing stuff from master and whatnot, no worries. However I agree that it should be merged into master. It'd get more testing, we want this change to happen and currently we "fear" changing the UI file, which is not good for development (actually it didn't wanted to change the UI 'til that patch, but still). And IIUC you use the branch, so there shouldn't be *too* annoying bugs. The main thing I can notice is some warnings on the console (I think about some shared menu items), but I couldn't notice any missing functionality and I couldn't figure where the messages were coming from since there's no line number, just process ID. So +1 for you to merge it to master, and we'll handle any problem if there are some. Will do this weekend then. I'm certain there will be some bugs but probably mostly minor and it will help having better programmers than me working on it too :) Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Indentation using regex (was [PATCH 14/19] Rewrite tab switching queue)
On Tue, Dec 6, 2011 at 21:56, Lex Trotman wrote: > [...] >> Maybe I don't understand it correctly but does this mean that if you >> open an existing file, you'd re-indent it completely based on the >> regexes? I don't think this is a good idea because this could lead to >> whitespace change in every line when you edit just a single line. >> > > No, thats another reason why I rejected option 1 > >> Or does it mean to have these indent numbers just internally and use >> them only when when auto-indentation is done? I often work with files >> edited by many people over many years which have inconsistent indents. >> Imagine the correct indent size is 4 but someone used just 2 indents >> in the outer "if" block. If I insert new "if" inside this block, the >> indent size will be 6 because of the incorrect outer indent. This is >> exactly why I used the "delta" indent solution to be locally correct >> and have minimal impact on (and be minimally affected by) the rest of >> the code. > > The algorithm will give 6 since it only considers the previous line > and the line it is indenting which is the line with the cursor. > > >> >> One more thing - with global indents you have to be sure that the >> regexes catch all the indentation cases (without false positives) >> otherwise one error will affect the indentation everywhere in the rest >> of the file. You can do crazy stuff with some languages so I can >> imagine such a thing can happen easily (single line with end of >> multi-line comment followed by end block followed by another comment). >> With delta indentation it's much less critical - the indent may be >> incorrect for the next line but this won't affect the rest of the file >> in any negative way. Moreover, you usually don't do things like the >> comment example when you write the code and when you need >> auto-indentation; you usually add them afterwards when no >> autoindentation is needed. >> >> Final remark - better not to auto-indent at all than to indent >> incorrectly. There's nothing worse than an editor (actually anything) >> which tries to be smart in an annoying way. > > Don't worry there is no intention that auto-indentation does more than > give a mostly right indent on new lines and mostly correct it when you > type } on that new line. > > I did clearly say it should not change any manual indentation. Ah, sorry, after re-reading it again I think I misunderstood your algorithm originally so please forget what I said. What you propose sounds good. Basically the main difference is that you take the previous line indentation into account which is what my original algorithm didn't do. This really appears to solve all the problems in quite an elegant way (much nicer than the flags thing I suggested). Just a detail that strictly speaking the "N-1 line" should be previous non-empty line. I'm actually not completely against the immediate indent when typing (without having to press enter). Your algorithm is capable of indentation "undo" when the regex doesn't match any more. I think it's quite OK if "fi" unindents the line and subsequent letter returns it back. Something like that already happens with syntax highlighting where the keyword becomes blue when you type it but changes back to black when you add additional letters. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Indentation using regex (was [PATCH 14/19] Rewrite tab switching queue)
[...]
> What do you mean here with "the indent" versus a delta? If the new
> indent's value is not count in "current indent + something * indent
> size" (where here "current indent" is previous line's indent) I don't
> see how this would possibly fit with configured indent sizes, nor what's
> the advantage?
Sorry the aside about delta vs indent relates to problems I had with
Jiri's patch and probably doesn't make sense without knowing the whole
of the previous thread, so ignore it.
[Or see very last comment]
[...]
>
> I agree that re-indenting the whole file would just be pointless, but
> not really with the other points.
>
> OK, it may broke a manually tuned indentation, but that'd only be on
> that very line and hopefully the regex would be somewhat OK.
>
> A not-that easy (very) small improvement would be not to change the
> indentation if:
>
> 1) the line has greater indent that the previous line and we would also
> add indent (e.g. if either there's nothing to do or we'd do the same
> thing another way), or
> 2) the line has smaller indent than the previous line and we also would
> remove indent (just the opposite)
>
> So then, we'd no break manual indent if it only change the width of the
> indent to add/remove. Maybe it's overcompliacted for the very small gain.
Several common cases of manual indentation will still break even with
this change so I agree it wouldn't add much.
>
>> Option 4 is rejected because auto new line indent is really the
>> minimum required to be called "auto" indentation
>
> Agreed.
>
>> So that leaves option 3. The upside is that new lines get a sensible
>> indentation automatically, the downside is that lines that should be
>> unindented won't be until enter or user command. I have used another
>> editor that worked this way and after a while I became used to it.
>> Note that editing an existing line won't destroy manual indentation
>> unless you tell it to or create a new line after.
>
> I don't understand why we would change the N-1 line's indent?
It doesn't change line N-1 but when you create a new line (ie type
enter) the line you are on (line N) is checked for things like } or fi
and the indent set for it. Delaying checking till enter/user command
avoids your fi/file problem.
>
>> The settings are two ("indent this line", "indent next line") lists of
>> pairs of a regex and a signed count.
Because pairs are not supported by g_key_file I suggest instead of a
count that only one step is allowed (step size is another parameter)
and we fall back to just having four regexes per language (as per
Jiri's solution) "indent this line one step", "undent this line one
step" "indent next line one step", undent next line one step".
>>
>> These settings are per language so they should come from the filetype files.
>>
>> A final thought, as there is now an "apply auto indent" command, if
>> there is a selection the auto indent should ripple through the whole
>> selection.
>
>
> Well. This does seem to look quite OK at first glance, but what's the
> real difference with Jiří's (and my) solution, but using the previous
> line's indent as the reference?
Well thats the main difference, (idea stolen from Emacs) and the point
that indentation is only triggered on return or an explicit user
command "adjust indentation" (which you should rarely need).
-- which seems quite cool since it'd
> fix most of the problems I see, basically re-unindenting already
> unindented lines.
Well, that is actually what I was meaning by "calculating a stable
indent value" vs "calculating a delta, which we then have to prevent
from being re-applied to an already adjusted line"
Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Indentation using regex (was [PATCH 14/19] Rewrite tab switching queue)
Le 06/12/2011 07:20, Lex Trotman a écrit : > [...] > >> First, note that I wasn't able to find the patch, so I'm only guessing >> from reading the thread and from my own (much less complete) attempt. >> > > I'm afraid that if I had the patch it is on my broken hard drive :-S > > And anyway we never got it to work satisfactorily. > >> >> So. This looks pretty good for line-based indents (but not brace match >> :(), but I ran into a really annoying problem with SH: >> >> SH should indent after "then", "do", etc. and unindent "fi", "esac", >> etc. The problem is that you expect the "fi" line to be unindented >> (e.g. use unindent_this_line), but if you type "file" for example, it'd >> wrongly unindent that line too! >> >> I thought about unindenting the previous line when entering the \n, but >> this isn't a real solution either since re-adding a newline after a well >> indented line would unindent it again. Crap. >> >> So I haven't yet found a sensible solution for this problem -- which >> wouldn't apply for '}' since it's very unlikely it's part of a bigger >> word -- and would like to know it anybody got super clever ideas, or how >> other editors you know handle this. >> >> This said, I really like the idea of configurable indentation rules that >> could handle languages like SH, Pascal, Ruby, Ada, etc. without the need >> to hard-code it. >> > > WARNING, complex topic, big post :) > > Quick summary of ones I know: > > Emacs has language specific elisp, for C: > > "It analyzes the line to determine its syntactic symbol(s) (the kind > of language construct it's looking at) and its anchor position (the > position earlier in the file that CC Mode will indent the line > relative to). The anchor position might be the location of an opening > brace in the previous line, for example. See Syntactic Analysis. > It looks up the syntactic symbol(s) in the configuration to get the > corresponding offset(s). The symbol +, which means “indent this line > one more level” is a typical offset. CC Mode then applies these > offset(s) to the anchor position, giving the indentation for the line. > The different sorts of offsets are described in c-offsets-alist. " > > And it admits that even then it gets it wrong sometimes :( > > Eclipse and Netbeans also use parser results for the indent guidance. > > I don't think parsing the source for indent guidance is in the Geany > light and small spirit, so I reject that. Right, we don't want such a thing. Moreover it'd need one parser for each language, something we don't (or do, if we consider sinctilla/ctags) have and don't want to write. > Instead I propose the following "correct most of the time" but simple > option based on a combination of Jiri's and Emacs' methods: > > 1. Each line N has an initial indentation which is the indentation of > line N-1 plus the increments/decrements for all matches to "indent > next line" regexes that occur in liine N-1. (Note that each regex has > a signed count of columns to indent/exdent) > > 2. The line N final indentation is the initial indentation adjusted by > the increments/decrements for all matches to "indent this line" > regexes that occur in line N > > Note that this is the indent, not a delta like Jiri's algorithm. It > is therefore stable no matter how many times it is calculated. What do you mean here with "the indent" versus a delta? If the new indent's value is not count in "current indent + something * indent size" (where here "current indent" is previous line's indent) I don't see how this would possibly fit with configured indent sizes, nor what's the advantage? > The question is then when to calculate and apply this indent, clearly > when a line is first created by enter the indent should be applied. > > But what about when line content changes? Should we: > > 1. calculate the indent each change, and then ripple that through the file > 2. calculate the indent each change and only apply it to this line > 3. calculate and apply the indent to lines N and N-1 only on new line > or user command > 4. calculate and apply the indent on user command > > Option 1 is rejected because it is expensive and it will destroy > manually adjusted indentation when editing an existing line and > because indentation can change as you type causing distracting effects > (happens with some Emacs indentation styles) > > Option 2 is rejected for the same reasons I agree that re-indenting the whole file would just be pointless, but not really with the other points. OK, it may broke a manually tuned indentation, but that'd only be on that very line and hopefully the regex would be somewhat OK. A not-that easy (very) small improvement would be not to change the indentation if: 1) the line has greater indent that the previous line and we would also add indent (e.g. if either there's nothing to do or we'd do the same thing another way), or 2) the line has smaller indent than the previous line and we also would remove indent (
Re: [Geany-devel] Indentation using regex (was [PATCH 14/19] Rewrite tab switching queue)
[...] > This is exactly what my regex-based indentation did and I assume what > Colomban's experiment does too. The problem Colomban was trying to > resolve was what to do when you have an end-block keyword "fi" which > should unindent and then have an identifier "file" (notice the "fi" > prefix) which shouldn't unindent. In this case there should be some > "undo indent" when you add more letters after "fi". And that is why I chose the option for auto indentation to only be executed on return or when the user said to, then you know the word is finished. Cheers Lex ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Indentation using regex (was [PATCH 14/19] Rewrite tab switching queue)
[...] > Maybe I don't understand it correctly but does this mean that if you > open an existing file, you'd re-indent it completely based on the > regexes? I don't think this is a good idea because this could lead to > whitespace change in every line when you edit just a single line. > No, thats another reason why I rejected option 1 > Or does it mean to have these indent numbers just internally and use > them only when when auto-indentation is done? I often work with files > edited by many people over many years which have inconsistent indents. > Imagine the correct indent size is 4 but someone used just 2 indents > in the outer "if" block. If I insert new "if" inside this block, the > indent size will be 6 because of the incorrect outer indent. This is > exactly why I used the "delta" indent solution to be locally correct > and have minimal impact on (and be minimally affected by) the rest of > the code. The algorithm will give 6 since it only considers the previous line and the line it is indenting which is the line with the cursor. > > One more thing - with global indents you have to be sure that the > regexes catch all the indentation cases (without false positives) > otherwise one error will affect the indentation everywhere in the rest > of the file. You can do crazy stuff with some languages so I can > imagine such a thing can happen easily (single line with end of > multi-line comment followed by end block followed by another comment). > With delta indentation it's much less critical - the indent may be > incorrect for the next line but this won't affect the rest of the file > in any negative way. Moreover, you usually don't do things like the > comment example when you write the code and when you need > auto-indentation; you usually add them afterwards when no > autoindentation is needed. > > Final remark - better not to auto-indent at all than to indent > incorrectly. There's nothing worse than an editor (actually anything) > which tries to be smart in an annoying way. Don't worry there is no intention that auto-indentation does more than give a mostly right indent on new lines and mostly correct it when you type } on that new line. I did clearly say it should not change any manual indentation. Cheers Lex ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Default search behavior is irritating
Le 06/12/2011 03:02, Matthew Brush a écrit : > On 12/05/2011 05:52 PM, Lex Trotman wrote: >> On Tue, Dec 6, 2011 at 12:18 PM, Matthew Brush >> wrote: >>> On 12/05/2011 01:27 PM, Colomban Wendling wrote: >>> Applied, thanks! >>> >>> Ouch! I wonder how many hours it will take me to convert the old >>> Glade 2 >>> file to GtkBuilder *again*. >>> >>> I say we either delete the gtkbuilder branch or merge it into master. >>> It's >>> basically working fine for along time and I don't think anyone is >>> testing it >>> since it's not in master. >> >> I agree, why hasn't it been committed already? >> > > Because only a few people have tested it and we don't have a `devel` > branch for "unstable" code :) It'd need people to try the "devel" branch too ;) Well. I haven't tried the branch that much either -- only tried it once actually I think. My bad. However I agree that it should be merged into master. It'd get more testing, we want this change to happen and currently we "fear" changing the UI file, which is not good for development (actually it didn't wanted to change the UI 'til that patch, but still). And IIUC you use the branch, so there shouldn't be *too* annoying bugs. So +1 for you to merge it to master, and we'll handle any problem if there are some. Regards, Colomban ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Default search behavior is irritating
Le 06/12/2011 06:08, Matthew Brush a écrit : > On 12/05/2011 05:18 PM, Matthew Brush wrote: >> On 12/05/2011 01:27 PM, Colomban Wendling wrote: >> >>> >>> Applied, thanks! >>> >> >> Ouch! I wonder how many hours it will take me to convert the old Glade 2 >> file to GtkBuilder *again*. Yeah, I know, sorry. I tried to ping you the other day on IRC for that, but you seemed AFK, and decided that I/you could "easily" recreate the patch for this in the GtkBuilder format -- it would've need somebody do re-do the thing anyway at some point. > FWIW, it didn't actually take too long to update the gtkbuilder branch. > Instead of re-converting the whole Glade 2 file I just manually added > the changes to the new geany.glade using Glade 3, comparing the changes > in the diff (since I don't have a patched Glade 2 running anymore) and > then I added that in with the merge commit. Great! :) Cheers, Colomban ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Indentation using regex (was [PATCH 14/19] Rewrite tab switching queue)
On Tue, Dec 6, 2011 at 08:27, Nathan Broadbent wrote: >> 1. calculate the indent each change, and then ripple that through the file >> 2. calculate the indent each change and only apply it to this line >> 3. calculate and apply the indent to lines N and N-1 only on new line >> or user command >> 4. calculate and apply the indent on user command >> >> Option 1 is rejected because it is expensive and it will destroy >> manually adjusted indentation when editing an existing line and >> because indentation can change as you type causing distracting effects >> (happens with some Emacs indentation styles) >> >> Option 2 is rejected for the same reasons >> >> Option 4 is rejected because auto new line indent is really the >> minimum required to be called "auto" indentation >> >> So that leaves option 3. The upside is that new lines get a sensible >> indentation automatically, the downside is that lines that should be >> unindented won't be until enter or user command. I have used another >> editor that worked this way and after a while I became used to it. >> Note that editing an existing line won't destroy manual indentation >> unless you tell it to or create a new line after. > > Hello, > > Good auto-indentation is one of the last things I'm missing after my > switch from Gedit to Geany. It was something that was handled really > well by the 'Smart Indent' plugin. I would like to share a short video > (1:24) of the indentation behavior that I grew accustomed to: > > http://vimeo.com/1890098 > > > This style of auto-indentation requires Option 1 or 2 (calculate for > each change), because it unindents the 'end', 'elsif' and 'else' > keywords as soon as their last characters are pressed. > I did find this behavior very useful, even though I admit that it > would sometimes destroy my manual indentation. This is exactly what my regex-based indentation did and I assume what Colomban's experiment does too. The problem Colomban was trying to resolve was what to do when you have an end-block keyword "fi" which should unindent and then have an identifier "file" (notice the "fi" prefix) which shouldn't unindent. In this case there should be some "undo indent" when you add more letters after "fi". Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Indentation using regex (was [PATCH 14/19] Rewrite tab switching queue)
On Tue, Dec 6, 2011 at 07:20, Lex Trotman wrote: > [...] > >> First, note that I wasn't able to find the patch, so I'm only guessing >> from reading the thread and from my own (much less complete) attempt. >> > > I'm afraid that if I had the patch it is on my broken hard drive :-S > > And anyway we never got it to work satisfactorily. > >> >> So. This looks pretty good for line-based indents (but not brace match >> :(), but I ran into a really annoying problem with SH: >> >> SH should indent after "then", "do", etc. and unindent "fi", "esac", >> etc. The problem is that you expect the "fi" line to be unindented >> (e.g. use unindent_this_line), but if you type "file" for example, it'd >> wrongly unindent that line too! >> >> I thought about unindenting the previous line when entering the \n, but >> this isn't a real solution either since re-adding a newline after a well >> indented line would unindent it again. Crap. >> >> So I haven't yet found a sensible solution for this problem -- which >> wouldn't apply for '}' since it's very unlikely it's part of a bigger >> word -- and would like to know it anybody got super clever ideas, or how >> other editors you know handle this. >> >> This said, I really like the idea of configurable indentation rules that >> could handle languages like SH, Pascal, Ruby, Ada, etc. without the need >> to hard-code it. >> > > WARNING, complex topic, big post :) > > Quick summary of ones I know: > > Emacs has language specific elisp, for C: > > "It analyzes the line to determine its syntactic symbol(s) (the kind > of language construct it's looking at) and its anchor position (the > position earlier in the file that CC Mode will indent the line > relative to). The anchor position might be the location of an opening > brace in the previous line, for example. See Syntactic Analysis. > It looks up the syntactic symbol(s) in the configuration to get the > corresponding offset(s). The symbol +, which means “indent this line > one more level” is a typical offset. CC Mode then applies these > offset(s) to the anchor position, giving the indentation for the line. > The different sorts of offsets are described in c-offsets-alist. " > > And it admits that even then it gets it wrong sometimes :( > > Eclipse and Netbeans also use parser results for the indent guidance. > > I don't think parsing the source for indent guidance is in the Geany > light and small spirit, so I reject that. > > Instead I propose the following "correct most of the time" but simple > option based on a combination of Jiri's and Emacs' methods: > > 1. Each line N has an initial indentation which is the indentation of > line N-1 plus the increments/decrements for all matches to "indent > next line" regexes that occur in liine N-1. (Note that each regex has > a signed count of columns to indent/exdent) Maybe I don't understand it correctly but does this mean that if you open an existing file, you'd re-indent it completely based on the regexes? I don't think this is a good idea because this could lead to whitespace change in every line when you edit just a single line. Or does it mean to have these indent numbers just internally and use them only when when auto-indentation is done? I often work with files edited by many people over many years which have inconsistent indents. Imagine the correct indent size is 4 but someone used just 2 indents in the outer "if" block. If I insert new "if" inside this block, the indent size will be 6 because of the incorrect outer indent. This is exactly why I used the "delta" indent solution to be locally correct and have minimal impact on (and be minimally affected by) the rest of the code. One more thing - with global indents you have to be sure that the regexes catch all the indentation cases (without false positives) otherwise one error will affect the indentation everywhere in the rest of the file. You can do crazy stuff with some languages so I can imagine such a thing can happen easily (single line with end of multi-line comment followed by end block followed by another comment). With delta indentation it's much less critical - the indent may be incorrect for the next line but this won't affect the rest of the file in any negative way. Moreover, you usually don't do things like the comment example when you write the code and when you need auto-indentation; you usually add them afterwards when no autoindentation is needed. Final remark - better not to auto-indent at all than to indent incorrectly. There's nothing worse than an editor (actually anything) which tries to be smart in an annoying way. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] junior C developer, interested in learning and helping out with time
Hey there, I'm new to the list, my name is Sean Wolfe and I'm interested in learning more about development for Geany. I've got a Python background, enjoy coding projects in Django and the python game framework Pygame, and also have some C/C++ experience (yay!) and some Java as well (ugh...) I'm really enthusiastic about Geany's small footprint and simplistic design. I personally like to run my Geany completely stripped out, no scrollbars, no line numbers, like a text editor. I'm working on some projects on Python and Android, and I want to improve my C skills. I am thinking learning more about the guts of Geany is a good project. Also there are little bits and tweaks I'd personally like to change just for my own user experience, so I thought I'd hack a bit and see what's what. My longer term goal is to really climb the mountain and help out with the SDL project as well, which if you're not familiar is a game framework in C which is the basis for a lot of interesting games and stuff out there. Some of the tweaks I'm interested in personally for Geany include --> - adding multiple window support with a drag and drop interface ala Eclipse, - learning more about how Geany handles projects - for laptop screens where vertical pixels are at a premium, stripping out the top menu bar and replacing it with a right-click context - again for laptop screens, reducing the size of the title bar (maybe this is an OS issue, but Google Chrome seems to be able to do it well). - color scheme editor ala Code::Blocks or Python's IDLE tool. So! I'm in the process of downloading sources, configuring my build environment (Windows XP and 7, maybe linux one day) and reading documentation like the HACKING file. Just thought I'd say hi ... Thanks! -- A musician must make music, an artist must paint, a poet must write, if he is to be ultimately at peace with himself. - Abraham Maslow ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Indentation using regex (was [PATCH 14/19] Rewrite tab switching queue)
> Actually the plugin is option 3, It is return plus user activated,
> just some activations are normal keys.
Aha, I understand. Thanks for the explanation.
> Maybe it works for Ruby, but
> it doesn't for C, and after looking at the code I don't see how it can
> possibly generate GNU style indentation.
>
> if (blah)
> {
> bletch();
> }
>
> It certainly doesn't as configured, it generates
>
> if (blah)
> {
> bletch();
> }
>
> and doesn't seem to ever lose that indent?
You're right, that plugin seems to generate K&R, 1TBS or BSD KNF style
indentation, and not GNU style by default - see
http://en.wikipedia.org/wiki/Indent_style
However, I think it would be appropriate to support each of these
popular indentation styles, and allow the user to select which style
to use. Even better, perhaps the style could be auto-detected by
parsing the current file.
Regards,
Nathan
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Indentation using regex (was [PATCH 14/19] Rewrite tab switching queue)
[...]
>
> This style of auto-indentation requires Option 1 or 2 (calculate for
> each change), because it unindents the 'end', 'elsif' and 'else'
> keywords as soon as their last characters are pressed.
> I did find this behavior very useful, even though I admit that it
> would sometimes destroy my manual indentation.
>
Actually the plugin is option 3, It is return plus user activated,
just some activations are normal keys. Maybe it works for Ruby, but
it doesn't for C, and after looking at the code I don't see how it can
possibly generate GNU style indentation.
if (blah)
{
bletch();
}
It certainly doesn't as configured, it generates
if (blah)
{
bletch();
}
and doesn't seem to ever lose that indent?
[...]
Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany-Plugins: Git-transition
Am 06.12.2011 09:06, schrieb Frank Lanitz: > Jire and ... It's Jiri... sorry. Cheers, Frank ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Geany-Plugins: Git-transition
Hi developers, Jire and I just finally scheduled git transition of the plugins. This will be done Wednesday evening CET. Please be so kind and stop committing to svn so we can ensure, all changes are going in. Please let me also know you github accounts if available for committing to plugins etc. Cheers, Frank ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
