Thread: Re: Cream Tabstop customization
Cream is a free, easy-to-use configuration of the Vim text editor
Brought to you by:
digitect
From: Steve H. <dig...@mi...> - 2004-03-14 22:11:29
|
From: Walter Mundt, Mar 14, 2004 1:03 AM > > I'm an experienced vim user who's been trying out Cream for a few > weeks now. For the most part I like it a lot. > > However, I've run into a few minor issues that bother me. > > First: there's no way to tell Cream to leave tab settings alone! I > personally found the ability to have a different setting for > shiftwidth/softtabstop and tabstop to be one of vim's most useful > and endearing features when I started learning it. I wish more > editors had a similar capability. It lets me maintain a standard > tabstop width that 95% of programs use by default without being > forced to use that width for my indenting as well. Please help me understand this last sentence. Are you saying: 1. You want *your* editing to use different indention depths than the rest of the document (by others)? or 2. Tab characters (dec 9) should be allowed to appear at one interval but selecting text and pressing the Tab key should shove it over at an (optionally) different interval. or something else? > When I installed Cream, I found to my dismay that there's no way for > this to happen. Setting things up in cream-user.vim or > cream-conf.vim doesn't matter because everything will be normalized > to be equal to g:CREAM_TABSTOP anyway. > > My current solutios is simply to comment out all code in cream-lib > that actually propagates the CREAM_TABSTOP setting into the real vim > configuration. If there's any interest I could try and write up a > patch to create some relevant cream-conf setting(s). It wouldn't be too difficult to provide an option for this, but I need to understand why in the first place. It's my opinion that a Tab is a Tab is a Tab, and if one chooses to substitute them with spaces then an option to insert spaces when the Tab key is used is reasonable. But I've never understood why a text/ascii document might use different values for tab and indent, especially if they are not multiples (Tab 8, indent 3). What happens when you give it to someone using Notepad? > My other issue is that the Find/Replace dialogs are worse than > useless. While this doesn't affect me much as I can just do "ctrl-L > /", I would definitely have abandoned vim if it presented me with > something so unfriendly to begin with. We had a thread on this topic just a short while ago. Please read back... I'm not thrilled about them either, but see them as a necessary evil. > I don't know if there's anything you can do about it, but "find" > should _not_ be a multi-step operation. If I were to expect cream to > act like other editors I'm familiar with, typing "ctrl-F searchterms > ENTER" should do it. No having to tab over to the "OK" button or > reach for the mouse. No having approve a second "overview" dialog > every single time I want to do a search. Having a mouse-accessible > GUI interface is great, but (for a text editor more than anything) > not if it gets in the way of keyboard-based operation. You didn't say, but I'm guessing you're using a GTK2 interface, in which case the dialogs (including focus) are horribly broken. (Although recent patches (somewhere around 6.2.300) are improving this.) About the only thing I'd add to our previous arguments about this topic is that if you know C, and want to do our project a *huge* favor (and earn yourself $50US, courtesy of me) write a patch against the current Vim that either: 1. Fixes the :promptfind and :promptrepl dialog to allow preset and return of the checkbox statuses and input strings for manipulation prior to doing the actual find/substitution. A checkbox for regular expressions also needs to be added. 2. Enables more options in dialog boxes via Vim script. The current dialogs option only the display string and the button count and titles. Wouldn't it be great if we could also present multiple input boxes, checkboxes, radio buttons and list boxes? Throw in tabbed leaves and combo boxes and you'd have perfect. I realize both of these are kitchen sink in scope and nearly antithetical to Vim's underlying philosophy, but any good text editor requires decent widgets and we're hamstrung by these limitations. (I won't comment on the existing :promptfind and :promptrepl dialogs since the previous thread pretty much sums up my feelings about the regexp limitation they impose.) > I think you've got a really good idea here, and despite the above > flaws I think I'll find myself transitioning over to Cream from my > current vim/xterm setup. I'm glad you like it. Cream is just a hobby of mine, an effort to get a good, Free text editor for both the operating systems I use daily. While there are plenty of big improvements I'd love to make, life at the moment prevents me from exploring host source code patches, an area we could use to "fix" things... but I'll need help. ;) -- Steve Hall [ dig...@mi... ] Cream... the Vim text editor in sheep's clothing! http://cream.sourceforge.net |
From: Walter M. <em...@sp...> - 2004-03-15 04:40:16
|
I'll try and clarify: > Please help me understand this last sentence. Are you saying: > > 1. You want *your* editing to use different indention depths than the > rest of the document (by others)? > > or > > 2. Tab characters (dec 9) should be allowed to appear at one interval > but selecting text and pressing the Tab key should shove it over at > an (optionally) different interval. I'm referring to your second description. > It wouldn't be too difficult to provide an option for this, but I need > to understand why in the first place. > > It's my opinion that a Tab is a Tab is a Tab, and if one chooses to > substitute them with spaces then an option to insert spaces when the > Tab key is used is reasonable. But I've never understood why a > text/ascii document might use different values for tab and indent, > especially if they are not multiples (Tab 8, indent 3). What happens > when you give it to someone using Notepad? This is exactly the issue. Notepad by default will display tabs as 8 spaces. If I write a document in vim with an indent of three but a tab of 8, then when someone opens it up in notepad (or wordpad, or ...) it will look exactly the way I see it, because vim knows that the tabstops are at 8 spaces and will only use tabs when they will take it where it wants to go. The advantage here is that I can use non-8 indents without having to worry about expanding everything to spaces or retabbing to keep my files the same across editors. >> My other issue is that the Find/Replace dialogs are worse than >> useless. While this doesn't affect me much as I can just do "ctrl-L >> /", I would definitely have abandoned vim if it presented me with >> something so unfriendly to begin with. > > We had a thread on this topic just a short while ago. Please read > back... I'm not thrilled about them either, but see them as a > necessary evil. Sorry, I probably should have looked through the archives a bit before posting. I'll read up in a bit. > You didn't say, but I'm guessing you're using a GTK2 interface, in > which case the dialogs (including focus) are horribly broken. > (Although recent patches (somewhere around 6.2.300) are improving > this.) Yeah, I'd guess that's the case. They definitly look horribly broken to me. I'm running the default gvim in Fedora Core 1; it is most likely GTK2. > About the only thing I'd add to our previous arguments about this > topic is that if you know C, and want to do our project a *huge* favor > (and earn yourself $50US, courtesy of me) write a patch against the > current Vim that either: > > 1. Fixes the :promptfind and :promptrepl dialog to allow preset and > return of the checkbox statuses and input strings for manipulation > prior to doing the actual find/substitution. A checkbox for regular > expressions also needs to be added. > > 2. Enables more options in dialog boxes via Vim script. The current > dialogs option only the display string and the button count and > titles. Wouldn't it be great if we could also present multiple > input boxes, checkboxes, radio buttons and list boxes? Throw in > tabbed leaves and combo boxes and you'd have perfect. > > I realize both of these are kitchen sink in scope and nearly > antithetical to Vim's underlying philosophy, but any good text editor > requires decent widgets and we're hamstrung by these limitations. Well, I *do* know C, but I *don't* know GTK (either version). I have done Win32 GUI code and hacked together a few Java Swing apps. I don't think GTK would be that hard to pick up, especially just what I'd need to do one of the above. Unfortunately, however, I don't have huge piles of free time lying around, waiting for some worthy project. Also, since I tend to just use /searches it's not that big of an issue for me personally. Nonetheless, I'll keep your ideas in mind. Sometime I might grab the vim source and see how hard it'd be to hack up the first, at least. Setting up the second would require more thought. Vim's script syntax is a bit odd; a detailed plan for what the new syntax should look like would need to be drawn up right at the start if things are going to work out at all. And with the scope of your request, it looks as if you want complete GTK bindings for vim-script. ;) > I'm glad you like it. Cream is just a hobby of mine, an effort to get > a good, Free text editor for both the operating systems I use daily. > While there are plenty of big improvements I'd love to make, life at > the moment prevents me from exploring host source code patches, an > area we could use to "fix" things... but I'll need help. ;) Yeah, I definitely understand the nature of spare-time coding efforts. I'm glad you've done it. I've always been fond of vim, and being able to use it in a manner that's vaguely similar to how I'd use other editors makes my transition back and forth between OS's easier. [I'd use it for an editor in Windows as well if its Visual Studio integration wasn't quite so poor (IMHO, of course).] Regards, -- Walter Mundt em...@sp... |
From: Steve H. <dig...@mi...> - 2004-03-16 08:11:46
|
From: "Walter Mundt", Sun, 14 Mar 2004 23:40:10 -0500 (EST) > > > > 2. Tab characters (dec 9) should be allowed to appear at one > > interval but selecting text and pressing the Tab key should shove > > it over at an (optionally) different interval. > > I'm referring to your second description. > > > It wouldn't be too difficult to provide an option for this, but I > > need to understand why in the first place. > > > > It's my opinion that a Tab is a Tab is a Tab, and if one chooses > > to substitute them with spaces then an option to insert spaces > > when the Tab key is used is reasonable. But I've never understood > > why a text/ascii document might use different values for tab and > > indent, especially if they are not multiples (Tab 8, indent 3). > > What happens when you give it to someone using Notepad? > > This is exactly the issue. Notepad by default will display tabs as > 8 spaces. If I write a document in vim with an indent of three but > a tab of 8, then when someone opens it up in notepad (or wordpad, or > ...) it will look exactly the way I see it, because vim knows that > the tabstops are at 8 spaces and will only use tabs when they will > take it where it wants to go. The advantage here is that I can use > non-8 indents without having to worry about expanding everything to > spaces or retabbing to keep my files the same across editors. I'm not trying to be dense here, honest. ;) But is seems that you are advocating that a file should have mixed tabs and spaces, and that your editing is done with a tabstop of x, with spaces, while leaving the remainder of the document in tabs at y. I see only three (really two) possiblities: 1. If the document is completely formatted with tabs, there's not a problem IMO: you just change the tabstop (display only) to what you want. Every user can be different since the display is completely disconnected with the actual bits in the document. |Level one |------->Level two |------->------->Level three |------->------->------->Level four And with the display changed from 8 to 4: |Level one |--->Level two |--->--->Level three |--->--->--->Level four 2. If the document is completely formatted with spaces, it is committed to a particular interval of tabstop. (Short of re-formatting it.) All editors have to use the same settings to avoid a mess. |Level one |....Level two |........Level three |............Level four 3. If the document is formatted with mixed tabs and spaces, well, it's already a mess. Although it may look fine at a particular stop: |Level one |------->Level two |................Level three |------->------->------->Level four Changing the tabstop display to something else no longer coordinates the tabs with hardcoded (spaces) indentions: |Level one |--->Level two |................Level three |--->--->--->Level four I'm obviously missing your (and others) point, since there must have been a good reason why Vim had three options for tabs in the first place. But I've never been able to see it. Perhaps you could draw some pictures to explain as I have. > > You didn't say, but I'm guessing you're using a GTK2 interface, in > > which case the dialogs (including focus) are horribly broken. > > (Although recent patches (somewhere around 6.2.300) are improving > > this.) > > Yeah, I'd guess that's the case. They definitly look horribly > broken to me. I'm running the default gvim in Fedora Core 1; it is > most likely GTK2. Try upgrading to 6.2.327 found here: http://mirrors.kernel.org/fedora/core/development/i386/Fedora/RPMS/ You'll probably also need the libselinux module. > > About the only thing I'd add to our previous arguments about this > > topic is that if you know C, and want to do our project a *huge* > > favor (and earn yourself $50US, courtesy of me) write a patch > > against the current Vim that either: [snip] > Well, I *do* know C, but I *don't* know GTK (either version). I > have done Win32 GUI code and hacked together a few Java Swing apps. > I don't think GTK would be that hard to pick up, especially just > what I'd need to do one of the above. > > Unfortunately, however, I don't have huge piles of free time lying > around, waiting for some worthy project. Also, since I tend to just > use /searches it's not that big of an issue for me personally. > > Nonetheless, I'll keep your ideas in mind. Sometime I might grab > the vim source and see how hard it'd be to hack up the first, at > least. Setting up the second would require more thought. Vim's > script syntax is a bit odd; a detailed plan for what the new syntax > should look like would need to be drawn up right at the start if > things are going to work out at all. And with the scope of your > request, it looks as if you want complete GTK bindings for > vim-script. ;) Actually, Windows, too. ;) But I think the first option (modifying the existing F/R dialogs) would be much simpler. Cream just needs a way to insure that all characters are taken literally. Vim currently has no such option. > > I'm glad you like it. Cream is just a hobby of mine, an effort to > > get a good, Free text editor for both the operating systems I use > > daily. While there are plenty of big improvements I'd love to > > make, life at the moment prevents me from exploring host source > > code patches, an area we could use to "fix" things... but I'll > > need help. ;) > > Yeah, I definitely understand the nature of spare-time coding > efforts. I'm glad you've done it. I've always been fond of vim, and > being able to use it in a manner that's vaguely similar to how I'd > use other editors makes my transition back and forth between OS's > easier. [I'd use it for an editor in Windows as well if its Visual > Studio integration wasn't quite so poor (IMHO, of course).] Yes, Vim definitely suffers from terminal myopia. But I very much appreciate the author's approach to flexibility. How many other text editors around these days can be run across a dialup connection? Anyway, the best strategy is to try and help Vim along: http://vim.sourceforge.net/sponsor/ -- Steve Hall [ dig...@mi... ] Cream... the Vim text editor in sheep's clothing! http://cream.sourceforge.net |
From: Elias P. <el...@us...> - 2004-03-16 11:12:40
|
On Tue, 2004-03-16 at 09:10, Steve Hall wrote: > > This is exactly the issue. Notepad by default will display tabs as > > 8 spaces. If I write a document in vim with an indent of three but > > a tab of 8, then when someone opens it up in notepad (or wordpad, or > > ...) it will look exactly the way I see it, because vim knows that > > the tabstops are at 8 spaces and will only use tabs when they will > > take it where it wants to go. The advantage here is that I can use > > non-8 indents without having to worry about expanding everything to > > spaces or retabbing to keep my files the same across editors. > > I'm not trying to be dense here, honest. ;) But is seems that you are > advocating that a file should have mixed tabs and spaces, and that > your editing is done with a tabstop of x, with spaces, while leaving > the remainder of the document in tabs at y. > > I see only three (really two) possiblities: > > 1. If the document is completely formatted with tabs, there's not a > problem IMO: you just change the tabstop (display only) to what you > want. Every user can be different since the display is completely > disconnected with the actual bits in the document. > > |Level one > |------->Level two > |------->------->Level three > |------->------->------->Level four > > And with the display changed from 8 to 4: > > |Level one > |--->Level two > |--->--->Level three > |--->--->--->Level four > > > 2. If the document is completely formatted with spaces, it is > committed to a particular interval of tabstop. (Short of > re-formatting it.) All editors have to use the same settings to > avoid a mess. > > |Level one > |....Level two > |........Level three > |............Level four > > > 3. If the document is formatted with mixed tabs and spaces, well, it's > already a mess. Although it may look fine at a particular stop: > > |Level one > |------->Level two > |................Level three > |------->------->------->Level four > > Changing the tabstop display to something else no longer > coordinates the tabs with hardcoded (spaces) indentions: > > |Level one > |--->Level two > |................Level three > |--->--->--->Level four > > > I'm obviously missing your (and others) point, since there must have > been a good reason why Vim had three options for tabs in the first > place. But I've never been able to see it. > > Perhaps you could draw some pictures to explain as I have. > No, you are right. Just, your method 3 looks normalyl like: |Level one |...Level two |......Level three |------->.Level four Changing the tab width to anything but 8 results in a complete mess. That's exactly why it is so important for cream to support it. Vim, Anjuta and GEdit all get it right, for example. Hitting <tab> indents with spaces (typically 2,3,4) - but as soon as there are 8 consecutive spaces somewhere, they get replaced by a tab. I completely agree that it is a very bad format. I even suggested once on a quite big project to change the format - but the maintainers were against changing all files in CVS for what they saw as a very minor issue. The reason for the format is purely historical. Ancient editors often had fixed 8-space tabs (DOS edit mabye?) But in text-mode screens, you had not enough room for 8-space indentation in source code. Therefore, source was written with space indentation - but mixed with tabs to save space. -- Elias Pschernig <el...@us...> |
From: Walter M. <em...@sp...> - 2004-03-16 15:40:58
|
> No, you are right. Just, your method 3 looks normalyl like: > > |Level one > |...Level two > |......Level three > |------->.Level four > > Changing the tab width to anything but 8 results in a complete mess. > That's exactly why it is so important for cream to support it. Vim, > Anjuta and GEdit all get it right, for example. Hitting <tab> indents > with spaces (typically 2,3,4) - but as soon as there are 8 consecutive > spaces somewhere, they get replaced by a tab. This is exactly what I'm talking about. Even though nobody uses an editor with fixed tabs anymore, many people still don't bother to customize tab width, and so will indent with all spaces. A large number of editors will then do as Elias described, and automatically substitute tabs wherever they'll fit, also by default. This results in Elias's picture above, and in such wonders as: ....doSomethingComplicated(param, param2, ... ------->------->------->...param8, param9, ...); > I completely agree that it is a very bad format. I even suggested once > on a quite big project to change the format - but the maintainers were > against changing all files in CVS for what they saw as a very minor > issue. I don't necessarily agree that it's such a bad thing. Speaking personally, I rarely if ever find it useful to change the tab width of a piece of code from that in which it was written to begin with. Even when things are all done with tabs, changing tab sizes frequently doesn't work out right; more intricate code will be carefully formatted with internal spaces so that things line up vertically where there are logical connections, and these alignments are frequently lost when tab sizes are changed. Furthermore, while I have a preferred tab-width, my preference isn't that strong, and I will work with whatever tab width the project at hand is using. Finally, extant code in my experience is rarely all-tabs or all-spaces, so one is almost always forced to reconfigure one's editor to whichever tab width the author wrote the code with. That's usually 8, so I personally will just leave my tabs at 8 and write all my code with tabs at 8 just so I don't have to keep adjusting it. Thus, the reasons for this, while they have historical origins, are currently perpetuated by the default settings in various text editors and in vast amounts of existing source code. And, of course, through people (like me) who have to deal with the aforementioned code writing new code in the same manner because reconfiguring their editor is too much trouble. -- Walter Mundt em...@sp... |
From: Steve H. <dig...@mi...> - 2004-03-17 02:56:19
|
From: "Walter Mundt", Tue, 16 Mar 2004 10:40:47 -0500 (EST) > Elias Pschernig > > > > No, you are right. Just, your method 3 looks normalyl like: > > > > |Level one > > |...Level two > > |......Level three > > |------->.Level four > > > > Changing the tab width to anything but 8 results in a complete > > mess. That's exactly why it is so important for cream to support > > it. Vim, Anjuta and GEdit all get it right, for example. Hitting > > <tab> indents with spaces (typically 2,3,4) - but as soon as there > > are 8 consecutive spaces somewhere, they get replaced by a tab. > > This is exactly what I'm talking about. Even though nobody uses an > editor with fixed tabs anymore, many people still don't bother to > customize tab width, and so will indent with all spaces. A large > number of editors will then do as Elias described, and automatically > substitute tabs wherever they'll fit, also by default. This results > in Elias's picture above, and in such wonders as: > > ....doSomethingComplicated(param, param2, ... > ------->------->------->...param8, param9, ...); AH, so with these options you are able to slowly "fix" mixed code. Or at least deal with it. But we all agree that it's not the ideal, right? > > I completely agree that it is a very bad format. I even suggested > > once on a quite big project to change the format - but the > > maintainers were against changing all files in CVS for what they > > saw as a very minor issue. > > I don't necessarily agree that it's such a bad thing. Speaking > personally, I rarely if ever find it useful to change the tab width > of a piece of code from that in which it was written to begin with. > Even when things are all done with tabs, changing tab sizes > frequently doesn't work out right; more intricate code will be > carefully formatted with internal spaces so that things line up > vertically where there are logical connections, and these alignments > are frequently lost when tab sizes are changed. Furthermore, while I > have a preferred tab-width, my preference isn't that strong, and I > will work with whatever tab width the project at hand is using. > > Finally, extant code in my experience is rarely all-tabs or > all-spaces, so one is almost always forced to reconfigure one's > editor to whichever tab width the author wrote the code with. That's > usually 8, so I personally will just leave my tabs at 8 and write > all my code with tabs at 8 just so I don't have to keep adjusting > it. > > Thus, the reasons for this, while they have historical origins, are > currently perpetuated by the default settings in various text > editors and in vast amounts of existing source code. And, of course, > through people (like me) who have to deal with the aforementioned > code writing new code in the same manner because > reconfiguring their editor is too much trouble. Ok, if my assumptions are correct above, I understand the usefulness of having independent control of both tabstop and shiftwidth. Now the question is how Cream could implement this so that it would be out of the way for a less experienced text editor user (a non-programmer). Vim has a number of options related to tabs. These three are linked by Cream: 1. &tabstop 2. &softtabstop 3. &shiftwidth This one can be set independently via menu or Ctrl+T (although it is also linked to AutoWrap): 4. &expandtab and two are unset by Cream: 5. &shiftround 6. &smarttab So if we are proposing de-linking 1, any thoughts on the relationship of the remainder? Can 2 and 3 stay connected? -- Steve Hall [ dig...@mi... ] Cream... the Vim text editor in sheep's clothing! http://cream.sourceforge.net |
From: Walter M. <em...@sp...> - 2004-03-17 08:57:47
|
> Ok, if my assumptions are correct above, I understand the usefulness > of having independent control of both tabstop and shiftwidth. Now the > question is how Cream could implement this so that it would be out of > the way for a less experienced text editor user (a non-programmer). > Vim has a number of options related to tabs. These three are linked by > Cream: > > 1. &tabstop > 2. &softtabstop > 3. &shiftwidth > > So if we are proposing de-linking 1, any thoughts on the relationship > of the remainder? Can 2 and 3 stay connected? I think everything past 1-3 is fine. I also don't see any point in disconnecting 2 and 3. I'd advise adding a setting for locking 1, leaving the CREAM_TABSTOP setting to only affect 2 & 3. You could put it in cream-conf. That way most users (e.g. those who haven't used vim before) won't need to deal with this, but the choice will be there for those of us who want it. Alternately, you could add a checkbox labelled "Use soft tabs" or something to that effect. When checked, it would always set ts=8 regardless of the CREAM_TABSTOP setting. I personally have never had any reason to use a setting for ts that's not one of 8 or the same as shiftwidth. -- Walter Mundt em...@sp... |
From: Steve H. <dig...@mi...> - 2004-03-17 13:13:18
|
From: "Walter Mundt", Wed, 17 Mar 2004 03:57:40 -0500 (EST) > > > Ok, if my assumptions are correct above, I understand the > > usefulness of having independent control of both tabstop and > > shiftwidth. Now the question is how Cream could implement this so > > that it would be out of the way for a less experienced text editor > > user (a non-programmer). Vim has a number of options related to > > tabs. These three are linked by Cream: > > > > 1. &tabstop > > 2. &softtabstop > > 3. &shiftwidth > > > > So if we are proposing de-linking 1, any thoughts on the > > relationship of the remainder? Can 2 and 3 stay connected? > > I think everything past 1-3 is fine. I also don't see any point in > disconnecting 2 and 3. I'd advise adding a setting for locking 1, > leaving the CREAM_TABSTOP setting to only affect 2 & 3. > > You could put it in cream-conf. That way most users (e.g. those who > haven't used vim before) won't need to deal with this, but the > choice will be there for those of us who want it. > > Alternately, you could add a checkbox labelled "Use soft tabs" or > something to that effect. When checked, it would always set ts=8 > regardless of the CREAM_TABSTOP setting. I personally have never > had any reason to use a setting for ts that's not one of 8 or the > same as shiftwidth. If we just add one more menu item "Soft Tabstop Width...", with a dialog that explains it a bit, that should be enough. I like to think that cream-conf is for overrides and Vim-expert type options. But Soft Tab is more of an advanced user option and as long as it can be exposed succinctly, I have no problem with a menu item. Unfortunately, the Vim widget set is limited or a more comprehensive dialog box for all settings could be a one line item. :) -- Steve Hall [ dig...@mi... ] Cream... sheep clothing for the Vim text editor! http://cream.sourceforge.net |
From: Elias P. <el...@us...> - 2004-03-17 14:09:29
|
On Wed, 2004-03-17 at 14:11, Steve Hall wrote: > If we just add one more menu item "Soft Tabstop Width...", with a > dialog that explains it a bit, that should be enough. I like to think > that cream-conf is for overrides and Vim-expert type options. But Soft > Tab is more of an advanced user option and as long as it can be > exposed succinctly, I have no problem with a menu item. > > Unfortunately, the Vim widget set is limited or a more comprehensive > dialog box for all settings could be a one line item. :) I think that would work. Maybe name it "Indentation With" - the different between "shift width" and "soft tab stop width" is probably confusing. So, it would work like this: - "Use Tabstops" disabled -> The "Tabstop With" has no effect at all, "Indentation With" is how many spaces to indent when <tab> is hit. - "Use Tabstops" enabled and *both widths are the same* -> simply tabs are used for indentation, with the specified width. - "Use Tabstops" enabled -> "Tabstop Width" is e.g. 8, and "Indentation Width" e.g. 3, then we get the mixed spaces/tabs behavior. If I understand the vim docs right, "Indentation With" would set both 'shiftwidth' and 'softtabstop'. "Tabstop Width" would be 'tabstop' (I think right now, it also sets 'shiftwith'?). And "Use Tabstops" would effect 'expandtab', like now. -- Elias Pschernig <el...@us...> |
From: Matt W. <mat...@go...> - 2004-03-17 16:53:23
|
Elias Pschernig wrote: > I think that would work. Maybe name it "Indentation With" - the > different between "shift width" and "soft tab stop width" is probably > confusing. Yes very confusing; until this conversation I never understood what all the tab settings were about. Actually I still don't fully know, but at least I now I'm peering around in twilight instead of night. :) Indentation is a better term to use I think. ((Hi Walter, fancy meeting you here...)) -- matt wilkie -------------------------------------------- Geographic Information, Information Management and Technology, Yukon Department of Environment 10 Burns Road * Whitehorse, Yukon * Y1A 4Y9 867-667-8133 Tel * 867-393-7003 Fax -------------------------------------------- |
From: Steve H. <dig...@mi...> - 2004-03-18 02:49:19
|
From: Elias Pschernig, Wed, 17 Mar 2004 15:09:20 +0100 > On Wed, 2004-03-17 at 14:11, Steve Hall wrote: > > > > If we just add one more menu item "Soft Tabstop Width...", with a > > dialog that explains it a bit, that should be enough. > > I think that would work. Maybe name it "Indentation With" - the > different between "shift width" and "soft tab stop width" is > probably confusing. Actually, I meant that Cream's option would include both Vim's &softtabstop and &shiftwidth. What I don't like about naming it with "Indention" is that this conveys something displayed, not just an editing behavior. When I look at a document, I think of how much indention it has, and then realize it is the tabstops that achieve it. "Soft Tab Stop" is a bettor descriptor both because it is Vim's name for the behavior and is also a variation on "Tab Stop". The user is alerted that we're talking about stops, somehow different. One is active, the other passive. Meaning that it should be intuitive that both shiftwidth and softtabstop are connected. (Why on earth would anyone have these two different?) > So, it would work like this: I see it slightly differently: > - "Use Tabstops" disabled -> The "Tabstop With" has no effect at > all, "Indentation With" is how many spaces to indent when <tab> is > hit. Tabstops is never disabled. (A tab character must always be represented by at least 1 space.) > - "Use Tabstops" enabled and *both widths are the same* -> simply > tabs are used for indentation, with the specified width. This is the current behavior. > - "Use Tabstops" enabled -> "Tabstop Width" is e.g. 8, and > "Indentation Width" e.g. 3, then we get the mixed spaces/tabs > behavior. More simply, if the user sets Softtab to a width other than that of Tabstop, &softtabstop and &shiftwidth conform to Softtab. > If I understand the vim docs right, "Indentation With" would set > both 'shiftwidth' and 'softtabstop'. "Tabstop Width" would be > 'tabstop' (I think right now, it also sets 'shiftwith'?). (Also softtabstop, mainly so backspacing deletes a tab worth of spaces.) > And "Use Tabstops" would effect 'expandtab', like now. &expandtab not currently linked to tabstops (it is to Auto Wrap). And I don't see that it need to be under this new setup either. Some may choose to always use tabs, some always spaces. Haven't verified this, but I'm guessing Vim will handle our Soft Tab in either condition. -- Steve Hall [ dig...@mi... ] Cream... sheep clothing for the Vim text editor! http://cream.sourceforge.net |
From: Elias P. <el...@us...> - 2004-03-18 09:41:20
|
On Thu, 2004-03-18 at 03:47, Steve Hall wrote: > Actually, I meant that Cream's option would include both Vim's > &softtabstop and &shiftwidth. What I don't like about naming it with > "Indention" is that this conveys something displayed, not just an > editing behavior. When I look at a document, I think of how much > indention it has, and then realize it is the tabstops that achieve it. > My intention was to name it "Indentation" not "Indention" :) > "Soft Tab Stop" is a bettor descriptor both because it is Vim's name > for the behavior and is also a variation on "Tab Stop". The user is > alerted that we're talking about stops, somehow different. > > One is active, the other passive. Meaning that it should be intuitive > that both shiftwidth and softtabstop are connected. (Why on earth > would anyone have these two different?) > Well, makes sense as well. I just looked in Anjuta, it even names "Expand Tabs" as "Use spaces for indentation", which I also find more descriptive. But since cream is vim, I agree, it should keep the terms as far as possible to avoid confusion. > > So, it would work like this: > > I see it slightly differently: > > > > - "Use Tabstops" disabled -> The "Tabstop With" has no effect at > > all, "Indentation With" is how many spaces to indent when <tab> is > > hit. > > Tabstops is never disabled. (A tab character must always be > represented by at least 1 space.) > Oops, I meant the "Expand Tabs" option (Ctrl-T) - was too lazy to check the menu names. So in that case, the Tabstop-character (ASCII 9 - no idea about other encodings) would never be inserted, just like it already works. > > > - "Use Tabstops" enabled and *both widths are the same* -> simply > > tabs are used for indentation, with the specified width. > > This is the current behavior. > > > > - "Use Tabstops" enabled -> "Tabstop Width" is e.g. 8, and > > "Indentation Width" e.g. 3, then we get the mixed spaces/tabs > > behavior. > > More simply, if the user sets Softtab to a width other than that of > Tabstop, &softtabstop and &shiftwidth conform to Softtab. > Yes, I was thinking about the combination of "Expand Tabs" with differing widths. So if "Expand Tabs" is off - then I think not the "Tabstop Width" should be used for indentation, but the other one. "Tabstop Width" would always be the width of the ASCII character 9. > > > If I understand the vim docs right, "Indentation With" would set > > both 'shiftwidth' and 'softtabstop'. "Tabstop Width" would be > > 'tabstop' (I think right now, it also sets 'shiftwith'?). > > (Also softtabstop, mainly so backspacing deletes a tab worth of > spaces.) > > > > And "Use Tabstops" would effect 'expandtab', like now. > > &expandtab not currently linked to tabstops (it is to Auto Wrap). And > I don't see that it need to be under this new setup either. Some may > choose to always use tabs, some always spaces. Haven't verified this, > but I'm guessing Vim will handle our Soft Tab in either condition. Should actually be very simple, I made another picture of how I see it: EX is the expand tabs, TS the tabstop width, STS the soft tabstop width and shiftwidth. And the result of hitting the <tab> key 3 times and then the <a> key. EX | TS | STS | result n | 3 | 3 | -->-->-->a n | 8 | 3 | ------->.a y | 3 | 3 | .........a y | 8 | 3 | .........a -- Elias Pschernig <el...@us...> |