https://defect.opensolaris.org/bz/show_bug.cgi?id=19110
Jens Elkner <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] | |.de --- Comment #1 from Jens Elkner <[email protected]> 2012-01-17 21:30:10 UTC --- (In reply to comment #0) > The default for tab expansion changed between 0.10 and 0.11-rc. Previously, > the > default was not to expand tabs to spaces. In 0.11-rc, the default is to expand > tabs to spaces with tab stops at every four characters. Yes, this was necessary since many projects don't use the obsolete tab=8 space convention anymore. Actually some projects use different settings depending on the file type, e.g. 2 space for *.xml and 4 spaces for "real" source. So the final goal should be to make it customizable on a per file type base, however, for now "one for all" is the closest thing we can do. > This change might be confusing to users who expect the old behaviour. Also, > since the tab expansion happens before the source is analyzed, it might cause > problems for the analyzers that distinguish between tabs and spaces (example: > bug #19108), so it shouldn't be enabled by default for now. That sounds like the parser/workflow should be fixed (i.e. anaylze before expanding). Probably not that easy to fix it ad hoc... However, if the main wish is to have not tabs expanded, setting TabSize to 0 shouldn't be a problem. Since the implementation follows the Bean contract, it is even possible to set it on a project base using appropriate xml config files. > Disabling it (either by not setting it in Configuration's constructor, or by > running the indexer with -t 0) is not enough to get the exact same behaviour > back, as the width of the line# column has also changed in 0.11-rc. > > Before, it used to be 8 characters wide, padded with characters. This > typically made that column fill the space up to (or slightly past - varying > between the browsers) the first tab stop, so that the first tab on the line > was > close to the right width (sometimes exactly, sometimes one character too > short). > > Now, the line# column is somewhat narrower and not padded (I think its width > is > determined by the style sheets). Since it's narrower, it sometimes doesn't > fill > the space up to the first tab stop, so the first tab on a line might be very > narrow too (like two characters wide, but it varies between the different > layouts since the various style sheets don't agree on the width of the line# > column). I'll need to look into it. Right now the line number column width is set to 8ex (6ex for numbers + 1ex padding on the left and right) to avoid the huge overhead of whitespace data (see style.css:~490). Not sure, how the browsers calculate the tabstop positions and how the alignment is implemented, however, if the issue is "make the column that big, that n tabs < col size < n+1 tabs, than setting the width to 7 or 8 ex acomplishes the same as the overhead (or better said, it is the same lottery). Actually the column has a right margin of 0.5 ex (=> 8.5ex total column width), and since the used font is monospace IMHO a correct implementation should already do that. But this is probably browser dependend and thus cumbersome to find a perfect solution [even with full CSS3 support)... Need an example to further investigate that issue. -- Configure bugmail: https://defect.opensolaris.org/bz/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ opengrok-dev mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opengrok-dev
