Re: Digest for vim_use@googlegroups.com - 12 updates in 3 topics

[Graham Nicholls]

@Richard Mitchell.

I can't tell you how much I object to this. (I'm not being aggressive, honest!)

There is no "proper extension" for a shell script.  Run "file /usr/bin/* | grep -i shell" to see a list of o/s built in shell scripts.  Then run this:

 file /usr/bin/* | grep -i shell  | awk '$1 ~ /\.sh/'

Exactly 3 of them (on my Ubuntu system) have the extension ".sh".

This is a (silly) windowsism, where file-extensions matter.   Now, Unix does sometimes care.  The C compiler, for instance expects source in .c and headers in .h. But, or course it produces executables with no .exe extension.  For a shell script, it's the #! line which tells the kernel to run it in a shell, and magic numbers for other types (which is all the same thing, and how "file" works).

I do like the idea of copying (I'd link) the .sh version to a bin/<filename> version, but let's not propagate this daft idea of filename extensions mattering to the os.

You can still grep:

If you can't remember how a case statement works:

grep case $(file * | awk '/shell/ 'print (substr($1,length($1)-1)') (# to get rid of the colon - and I've not tested that specific line, but it's something I do occasionally.)  This is proper use of Unix, not demanding file extensions.   Unix is great, but it's expert-friendly, and not as windows claims to be "user" friendly.

Sorry to rant, but it's important to me - and you might guess where I stand on systemd :-)

Graham

On 15 July 2016 at 10:19, <vim...@googlegroups.com> wrote:

vim...@googlegroups.com

Google Groups

Topic digest
View all topics

• Wrong vim color syntax - 3 Updates
• vim function argument - 6 Updates
• pass count to nmap with call - 3 Updates

Wrong vim color syntax

Willem D'Haese <willem...@gmail.com>: Jul 14 08:03AM -0700 On Thursday, 7 July 2016 07:20:22 UTC+2, Christian Brabandt wrote: > It looks like the syntax script does not handle here documents.   > Best, > Christian   Hello Christian,   Thanks for the help. It is actually a Bash script with filename FireTIG (without .sh extension) I made myself. Where can I find the syntax file for Bash?   Grtz

Charles E Campbell <drc...@campbellfamily.biz>: Jul 14 02:56PM -0400 Willem D'Haese wrote: >> Christian > Hello Christian,   > Thanks for the help. It is actually a Bash script with filename FireTIG (without .sh extension) I made myself. Where can I find the syntax file for Bash?   Please try the syntax files for sh.vim available at: http://www.drchip.org/astronaut/vim/index.html#SYNTAX_SH (v154).   Regards, Chip Campbell

Richard Mitchell <rwmit...@gmail.com>: Jul 14 01:24PM -0700 On Thursday, July 14, 2016 at 11:03:47 AM UTC-4, Willem D'Haese wrote:   > Hello Christian,   > Thanks for the help. It is actually a Bash script with filename FireTIG (without .sh extension) I made myself. Where can I find the syntax file for Bash?   > Grtz   As a pointless programming tip, I put the proper extension on my script code files (.sh, .pl, etc) and then use make to copy&strip the extension/chmod them into a bin area. While this seems unnecessary, besides making it easier for vim know how to colorize the code, it also allows the use of find/grep for searching.

Back to top

vim function argument

Yang Luo <youngl...@gmail.com>: Jul 13 11:41PM -0700 I write a function like this: function InsertNumber(start, end, step)   let i = a:start   let curr_line = 0   while i <= a:end if a:step <= 0 echo "Error: step cannot <=0." break endif   call append(curr_line, i)   let i += a:step   let curr_line += 1   endwhile endfunction     when I call this function, I type this: :echo InsertNumber(8,10,1) 8 9 10     1) How can I give arguement "step" a default value(eg: 1) when define the function? like a C function: void C_func(int a, int b_have_default_val = 1) {   ; } 2) I want to print number like this, how to do it? 08 09 10

"Jürgen Krämer" <jott...@googlemail.com>: Jul 14 09:09AM +0200 Hi,   Yang Luo schrieb am 14.07.2016 um 08:41: > {   > ; > }   you can use optional arguments like this   function InsertNumber(start, end, ...) if a:0 == 0 let l:step = 1 else let l:step = a:1 endif ... endfunction   > 08 > 09 > 10   Use the printf() function:   call appendline(curr_line, printf('%02d', i))   Or if your numbers can have more than two digits:   let width = trunc(log10(a:end)) + 1 let format = '%0' . width . 'd' call appendline(curr_line, printf(format, i))     Regards, Jürgen   -- Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us. (Calvin)

Yang Luo <youngl...@gmail.com>: Jul 14 02:01AM -0700 thanks alot

Yang Luo <youngl...@gmail.com>: Jul 14 03:06AM -0700 I complete the function as follow, now I want to add radix option, but I don't know how to get width. Can you help me complement it   function InsertNumber(start, end,...) " step,is_column_first_0_padding,radix(b,d,o,x) let l:i = a:start let l:curr_line = 0 if a:0 == 0 " a:0 extra argument numbers let l:step = 1 else let l:step = a:1 " the first extra argument endif if a:0 == 2 let l:is_padding = 0 else let l:is_padding = 1 "default padding endif if a:0 == 3 let l:radix = a:3 else let l:radix = "" endif if l:radix == "b" elseif l:radix == "o" elseif l:radix == "x" else let l:width = float2nr(trunc(log10(a:end))) + 1 let l:format = '%0'.l:width.'d' endif while l:i <= a:end if l:step <= 0 echo "Error: step cannot <= 0." break endif if l:is_padding == 1 call append(curr_line, printf(l:format, l:i)) else call append(curr_line, l:i) endif let l:i += l:step let l:curr_line += 1 endwhile endfunction

"Jürgen Krämer" <jott...@googlemail.com>: Jul 14 02:52PM +0200 Hi,   Yang Luo schrieb am 14.07.2016 um 12:06: > let l:curr_line += 1 > endwhile > endfunction   there is an simpler way to calculate the necessary width -- just count the number of characters used for the a:end parameter when printed:   let width = strlen(printf('%d', a:end))   This can also be used to calculate the width for other radices than 10:   if l:radix == "b" let width = strlen(printf('%x', a:end)) * 4 elseif l:radix == "o" let width = strlen(printf('%o', a:end)) elseif l:radix == "x" let width = strlen(printf('%x', a:end)) else let width = strlen(printf('%d', a:end)) endif   Note that there is no specification for output as a binary number in printf().   Regards, Jürgen   -- Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us. (Calvin)

Nikolay Aleksandrovich Pavlov <zyx...@gmail.com>: Jul 14 07:00PM +0300 > else > let l:step = a:1 " the first extra argument > endif   let l:step = get(a:000, 0, 1)   Other arguments are to be handled in a similar fashion.   > else > let l:radix = "" > endif   let l:radix = get(a:000, 2, 'd')   (needed for the below suggestion).   > elseif l:radix == "x" > else > let l:width = float2nr(trunc(log10(a:end))) + 1   let l:width = len(a:end)   For other radix variants you will have to use printf indeed.   I could even suggest   let l:format = '%0*' . l:radix let l:width = len(printf('%' . l:radix, a:end))   (note: no if’s at all).   > let l:format = '%0'.l:width.'d'   let l:format = '%0*d'   > echo "Error: step cannot <= 0." > break > endif   This is wrong place to check, l:step does not change, but you check it constantly. Move all arguments checks just below the place where you define arguments.   > if l:is_padding == 1 > call append(curr_line, printf(l:format, l:i))   call append(curr_line, printf(l:format, l:width, l:i))

Back to top

pass count to nmap with call

Bee <beey...@gmail.com>: Jul 13 11:28PM -0700 I tried to pass a count to <F11> but got a range error.   nmap <F11> :call VMA()<bar>:bn<cr>   Can it be done?   nmap <F12> :bn<cr>   4<F12> works   Bill

"Jürgen Krämer" <jott...@googlemail.com>: Jul 14 08:59AM +0200 Hi,   Bee schrieb am 14.07.2016 um 08:28:   > Can it be done?   > nmap <F12> :bn<cr>   > 4<F12> works   in my experience counts and mappings don't work together very well. A preceding count is always used for the first command in the mapping only. So what happens when you enter   4<F11>   is that Vim converts your count to an address for the command-line, which effectively results in   :.,.+3call VMA()|:bn   In your mapping you first have to remove this address and "move" the count to the front of the command :bn. The count is stored in the global variable v:count. There is an example at :help v:count which can be adopted:   :nmap <F11> :<C-U>call VMA()<bar>execute v:count1 . "bn"<cr>   Note that I removed the superfluous second colon and that instead of v:count I used v:count1 which defaults to 1 if no count was given.   Regards, Jürgen   -- Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us. (Calvin)

Bee <beey...@gmail.com>: Jul 14 02:45AM -0700 > -- > Sometimes I think the surest sign that intelligent life exists elsewhere > in the universe is that none of it has tried to contact us. (Calvin)   More reading... a count is not needed. First time I have used bufdo!   function! B_() " field delimiter ';' g/^\d*;\+$/d " remove blank records v/^\d\+;/d " remove non-data records let @4=expand('%:t:r') " remove path, extension let @4=substitute(@4,'\s\+',' ','g') " remove extra whitespace, normalize let @4=substitute(@4,'^ ','','') " remove leading whitespace let @4=substitute(@4,' $','','') " remove trailing whitespace let @4=substitute(@4,'.*\zs ',';','') " replace ' ' ';' before date let @4.=";" " append ';' filename;date g/^\d\+;/:normal "4P " prefix lines filename;date; endfun " example :bufdo call B_()   function! B() " everyone keep quiet silent bufdo call B_() endfun " example :call B()   Bill

Back to top

You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to vim_use+u...@googlegroups.com.

--

Graham Nicholls

Rock Computer Consultancy Limited.

[Richard Mitchell]

I'm fully aware the OS doesn't care about the extension. The extension is there solely for my benefit when writing code. At a glance I can tell which language I used to write something. I could use file or look at the first line myself, but a simple "ls" is all that is needed to view everything. A "find . -name \*.ext" is much easier to find everything written in the same language than anything else you can come up with. It is all about my convenience, not the OS's. 'ls' can even be setup to colorize each file by the different extensions.

When a program goes from being "source" to executable, the script is copied, extension removed, and chmod'd. I know these steps are completely unnecessary to the OS, I could easily be modifying a 775 script directly without having to "make" it, but this is for me. When I want to find something I did in a perl (as an example) script, I can easily search just the perl code across many subdirectories.

I am consistent with the extensions I use, so I have a standard.

I don't link to the executable so that the original is still usable while I'm making changes. If I'm inclined to check it, I can still do a quick diff to make sure I didn't have any accidental editor changes.

When I started out 30+ years ago writing programs, I didn't put the extension on because it wasn't needed for the OS then I realized it was valuable to me. It is only in the source code directories, so only I see it when I'm editing.

I wouldn't expect or want to have the extensions on anything in my PATH.

On Friday, July 15, 2016 at 8:19:58 AM UTC-4, Graham Nicholls wrote:
> @Richard Mitchell.
>
>
> I can't tell you how much I object to this. (I'm not being aggressive, honest!)
>
>
> There is no "proper extension" for a shell script.  Run "file /usr/bin/* | grep -i shell" to see a list of o/s built in shell scripts.  Then run this:
>  file /usr/bin/* | grep -i shell  | awk '$1 ~ /\.sh/'
>
>
>
> Exactly 3 of them (on my Ubuntu system) have the extension ".sh".
>
>
>
>
> This is a (silly) windowsism, where file-extensions matter.   Now, Unix does sometimes care.  The C compiler, for instance expects source in .c and headers in .h. But, or course it produces executables with no .exe extension.  For a shell script, it's the #! line which tells the kernel to run it in a shell, and magic numbers for other types (which is all the same thing, and how "file" works).
>
>
> I do like the idea of copying (I'd link) the .sh version to a bin/<filename> version, but let's not propagate this daft idea of filename extensions mattering to the os.
>
>
> You can still grep:
> If you can't remember how a case statement works:
>
>
> grep case $(file * | awk '/shell/ 'print (substr($1,length($1)-1)') (# to get rid of the colon - and I've not tested that specific line, but it's something I do occasionally.)  This is proper use of Unix, not demanding file extensions.   Unix is great, but it's expert-friendly, and not as windows claims to be "user" friendly.
>
>
> Sorry to rant, but it's important to me - and you might guess where I stand on systemd :-)
>
>
> Graham
>
>
> On 15 July 2016 at 10:19, <vim...@googlegroups.com> wrote:
>
>
>
>
>
>
>
>
>
>
>
> vim...@googlegroups.com
>
>
>
> Google Groups
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

[aro...@vex.net]

Name extension discussion.

I wholeheartedly agree with Graham Nicholls' objection to Windowsisms, but
Richard Mitchell's explanation makes a lot of sense, especially

> I wouldn't expect or want to have the extensions on anything in my PATH.

An alternative approach might be language-specific directories, (e.g.
~/bin/perl, ~/bin/bash, &c.) included in the development environment's
PATH. If it's in ~/bin/perl, you know it's Perl.)

[Christian Brabandt]

Hi Graham!

On Fr, 15 Jul 2016, Graham Nicholls wrote:

> @Richard Mitchell.
>
> I can't tell you how much I object to this. (I'm not being aggressive,
> honest!)
>
> There is no "proper extension" for a shell script. Run "file /usr/bin/* |
> grep -i shell" to see a list of o/s built in shell scripts. Then run this:
> file /usr/bin/* | grep -i shell | awk '$1 ~ /\.sh/'

> This is a (silly) windowsism, where file-extensions matter. Now, Unix
> does sometimes care. The C compiler, for instance expects source in .c and
> headers in .h. But, or course it produces executables with no .exe
> extension. For a shell script, it's the #! line which tells the kernel to
> run it in a shell, and magic numbers for other types (which is all the same
> thing, and how "file" works).

This is true, but using a "proper extension" still is a convention, that
help the user expect certain things and also makes sure, other programs
can guess the filetype easily.

> Sorry to rant, but it's important to me - and you might guess where I stand
> on systemd :-)

While we are at the ranting, can you please make sure, to actually reply
to the correct message and not to the message digest and delete those
long quotes, that do not matter please. Thanks.


Best,
Christian
--
Wer keiner Fliege etwas zuleide tut, kann auch keine Krawatte binden.