Re: [Nano-devel] Add function to convert leading whitespace to tabs

[Erik Lundin]

> However, two things.  When not assigning a default shortcut to
> whitespace_to_tabs(), then there is no need for most of the
> changes to global.c -- adding an empty "" shortcut to the list
> is pointless.  When adding a short help text for a function,
> then it should really also have a default shortcut.
> 
> The question is: do we want to eat up one of the few remaining
> unassigned key combos for a function that very, very few people
> are ever going to use?  (No one ever asked for it so far.)
> 

Then maybe i should explain the background to why i want this feature in
nano. Many times a day i copy code from one terminal to another and this
messes up the indenting on some of the lines. The original indenting is
usually right but in the copy process it converts tabs to spaces. It's a
very tedious task, manually converting those lines to tabs. Having a
function that can approximately convert a given number of spaces/tabs to
tabs would help massively. Then if the number of spaces isn't directly
matched to the tabsize isn't a big deal. There's a lot less keystrokes
involved in removing or adding a single tab to a line then removing 16
spaces and adding 2 tabs. I bet i'm not the only one working like this.
Since there's no statistical functions in nano we can never really know
how much a feature is used. But i know for a fact that people copy-paste
a lot :)

> You see, there may be still more functions that people may want
> (for an example, see https://savannah.gnu.org/patch/?8208), and
> if we add a help line for each such function, then soon the main
> help text (^G) will show several lines explaining functions that
> are really available because they are not bound to any key.  (Or
> we should decide that any unbound function should not be shown
> in the help text.)  --  Opinions?
> 

I disagree with you on this one. I think all features should be listed
in the help. This way you can find out that such a feature actually
exists and then look it up. I think most people look through the help
and when they don't find the function they are looking for they just
move on. Listing it would at least give people information that the
feature exists. Plus, it would show what key its bound to (if its
bound).

> Oh, the other thing: when the tab size is eight, and I have say
> two leading spaces followed by a tab, then whitespace_to_tabs()
> converts this to two tabs.  This is not correct, because in fact
> two spaces plus a tab take up the same size as a single tab.  You
> cannot simply count the number of tabs and spaces independently,
> you also have to take into account their order: a tab plus two
> spaces converts to two tabs, but two spaces plus a tab to just a
> single tab, in my opinion.
> 

For me this wouldn't be a big deal. Just having the function would help
a lot. But i see your point. I'll look into some better way to calculate
the actual displaying width.

-- 
Erik Lundin <address@hidden>