Remember syntax highlighter

[geromueller]

One needs to always change the syntaxhighlighting of a file without extension, e.g. bash scripts. It would be great if ne could rembember this.

[vigna]

Try the defprefs branch. It reloads default preferences when you load a file without extension.

[utoddl]

That defprefs branch does a bit more than that at the moment. This feature is still being tested and is subject to revision before general release. From the updated docs...

For the purposes of automatic preferences and syntax definitions, ne provides a mechanism for determining virtual extensions based on a buffer’s contents. If you create a ̃/.ne/.extensions file, ne will examine this file for certain extensions and corresponding patterns, and if it finds a match with the current buffer it will act as if the buffer’s name had that extension. Here’s an example ̃/.ne/.extensions file:

# Comments and blank lines are allowed. Only lines which match
# this regular expression are used:
#    ˆ[ \t]*(\w+)[ \t]*([0-9]*)[ \t]*(.+)
# These patterns match some common command interpreters.
# Because we don’t specify the optional number between the virtual
# extension and the pattern, they must match on the first line.
sh   ˆ#![\t ]*/.*/(bash|sh|ksh|zsh)\s*
csh  ˆ#![\t ]*/.*/(csh|tcsh)\s*
pl   ˆ#![\t ]*/.*/perl\b
py   ˆ#![\t ]*/.*/python[0-9]*\s*
rb   ˆ#![\t ]*/.*/ruby\s*
# These must match in the first 30 and 10 lines respectively to work.
yaml  30  ˆ\+\+\+$
ini   10  ˆ\[\w+\]$

There may also be a ‘ .extensions ’ file in the global directory. If so, and your ̃/.ne/.extensions file fails to map a virtual extension, then the one in the global directory will be consulted.

[geromueller]

Hi! At least python ist often startet with "/usr/bin/env python".

…

On 15.02.2017 05:16, Todd Lewis wrote: That |defprefs| branch does a bit more than that at the moment. This feature is still being tested and is subject to revision before general release. From the updated docs... For the purposes of automatic preferences and syntax definitions, ne provides a mechanism for determining virtual extensions based on a buffer’s contents. If you create a |̃/.ne/.extensions| file, ne will examine this file for certain extensions and corresponding patterns, and if it finds a match with the current buffer it will act as if the buffer’s name had that extension. Here’s an example |̃/.ne/.extensions| file: |# Comments and blank lines are allowed. Only lines which match # this regular expression are used: # ˆ[ \t]*(\w+)[ \t]*([0-9]*)[ \t]*(.+) # These patterns match some common command interpreters. # Because we don’t specify the optional number between the virtual # extension and the pattern, they must match on the first line. sh ˆ#![\t ]*/.*/(bash|sh|ksh|zsh)\s* csh ˆ#![\t ]*/.*/(csh|tcsh)\s* pl ˆ#![\t ]*/.*/perl\b py ˆ#![\t ]*/.*/python[0-9]*\s* rb ˆ#![\t ]*/.*/ruby\s* # These must match in the first 30 and 10 lines respectively to work. yaml 30 ˆ\+\+\+$ ini 10 ˆ\[\w+\]$ | There may also be a ‘ .extensions ’ file in the global directory. If so, and your |̃/.ne/.extensions| file fails to map a virtual extension, then the one in the global directory will be consulted. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#26 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABQq2cEGQMH5t1dHx8DbjAZNC0GkrGOlks5rcnwPgaJpZM4L2TFC>.

[pepa65]

This would be a great addition!
I have found if you remove the slash before python (or bash etc.) it also detects /usr/bin/env style first lines.
Remark: the character used in your example code for ^ doesn't yield any results!!

[utoddl]

Thanks for trying it out @pepa65. There have been a few changes if you're willing to test some more. The number is now required between the extension and the regex, but zero allows matching all the lines.

The updated docs have better examples and should match invocations via the "env" command.

The ^ in regex anchors the match to the beginning of the line, so ^# will only match "#" if it's the first character on the line.

[pepa65]

:-) With that bit I meant to say I ran into problems copying your code, because my grep recognizes ^ but it ignores ˆ as a normal character.
Now waiting for it to be pulled into master.

[pepa65]

I just built master, thinking it had been merged, but it doesn't work. I have the line sh 1 ^#![\t ]*/.*sh\s* in ~/.ne/.extensions and the first line of the file I'm editing is #!/bin/bash.

Also no colors when files have an extension .sh so there must be some compile option that is wrong. I tried all permutations of make NE_ANSI=1 NE_TERMCAP=1 but none of them give me any color...

I've found that NEWS talks about 3.0.2 but the opening screen after ne still says 3.0.1 and the status line has ne, the nice editor 3.0.1. (2017-02-23).

[utoddl]

Sounds like you don't have your syntax directory installed correctly. Go to the File menu and select About, or to the command line (^K) and enter About. The last line there should say something like Global Directory: /usr/local/share/ne/. Inside that directory should be a syntax directory with a bunch of .jsf files. My guess is that your About screen will say Global directory "/usr/local/share/ne" not found!.

The NEWS file has been updated with items as they've been added, but the version number in the makefile has not been changed because 3.0.2 (or whatever we eventually call the next release) has not yet been released.

[pepa65]

The last 2 lines are:

ne home page: http://ne.di.unimi.it/
Discuss ne at http://groups.google.com/group/niceeditor/

I didn't properly install, I just ran the binary at src/ne (using the files from the package install on Ubuntu). But after make docs; sudo make install there were still no colors on the extension-less file, but colors on the .sh file now work. But the point was to get the extensionless files to be recognized.

[utoddl]

Can you make your window a little taller?

[pepa65]

I did that when my last line was ne home page: http://ne.di.unimi.it/ and then I found the "Discuss" line, and after that a blank line (status line at the bottom)... But now even longer, I have another line: Global Directory: /usr/local/share/ne/. It does contain the syntax directory with the .jsf files.

[pepa65]

It seems just unable to use the ~/.ne/.extensions file...

[utoddl]

Is your HOME environment variable set? through echo $HOME on the command line should insert the path to your HOME directory into the current document. If HOME isn't set, then that would explain what you're (not) seeing.

[pepa65]

Yes, through echo $HOME works.
I've tried another fetch & pull. The only branch is master. I'm having this repo.

I'm wondering, is there a way to run with DEBUG that would be helpful?

[utoddl]

You could try strace -o /tmp/ne.strace ne and do whatever you're doing in ne. When you exit, you can the look in /tmp/ne.strace to see all the system calls ne made. Look particularly for lines that start with open and stat so you can see what files ne is looking for.

Just curious: what OS and distribution are you running?

[pepa65]

Ubuntu 16.04

stat("/home/pp/.ne/.extensions", {st_mode=S_IFREG|0664, st_size=587, ...}) = 0
stat("/home/pp/.ne/.extensions", {st_mode=S_IFREG|0664, st_size=587, ...}) = 0
open("/home/pp/.ne/.extensions", O_RDONLY) = 3
lseek(3, 0, SEEK_END)                   = 587
lseek(3, 0, SEEK_SET)                   = 0
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], NULL, 8) = 0
brk(0x17dd000)                          = 0x17dd000
read(3, "# Comments and blank lines are a"..., 587) = 587
rt_sigprocmask(SIG_UNBLOCK, ~[RTMIN RT_1], NULL, 8) = 0
close(3)                                = 0
stat("/home/pp/.ne/.extensions", {st_mode=S_IFREG|0664, st_size=587, ...}) = 0
access("/home/pp/.ne/.extensions", W_OK) = 0
brk(0x17fe000)                          = 0x17fe000
brk(0x181f000)                          = 0x181f000
brk(0x181c000)                          = 0x181c000
brk(0x183d000)                          = 0x183d000

[pepa65]

And my complete /home/pp/.ne/.extensions:

# Comments and blank lines are allowed, or any line that doesn't match:
#  ^[ \t]*(\w+)[ \t]*([0-9]*)[ \t]*(.+)
# Canonical format: <file> <n> <regex>
# (space delimited; when <regex> matches the first <n> lines, <file>.jsf applies

# These patterns match some common command interpreters:
#sh 1 ˆ#![\t ]*/.*/(bash|sh|ksh|zsh)\s*
 sh 1 ^#![\t ]*/.*sh\s* 
 csh 1 ^#![\t ]*/.*(csh|tcsh)\s* 
 pl 1 ^#![\t ]*/.*perl\b 
 py 1 ^#![\t ]*/.*python[0-9]*\s* 
 rb 1 ^#![\t ]*/.*ruby\s* 
# These must match in the first 30 and 10 lines respectively to work.
 yaml 30 ^\+\+\+$ 
 ini 10 ^\[\w+\]$ 

[utoddl]

The problem wasn't obvious until I selected the above text of your .extensions file to copy-n-paste it.

You have a trailing space after each of your patterns. Or rather, you have a space as the last character of each of your patterns. With your .extensions file loaded, invoke the tabs syntax (^k<enter>sy tabs<enter>). The new tabs.jsf will highlight trailing spaces, because they are almost always wrong. (They're almost always irrelevant, too, but not in this case.)

[pepa65]

Thanks for persisting with this! I had put them in when I read that the arguments had to be space-delimited, so I thought I'd make sure every part was surrounded by spaces... How silly.

[utoddl]

I've updated the master branch with this new .extensions code. It also now ignores trailing white space in .extensions. If you really want a pattern with space at the end, use [ ] or \s.

By the way, in the .extensions above (ignoring the trailing space issue), the sh line will match before the csh line, so the csh line will never trigger.

[pepa65]

Good call. I've never even seen a .csh file, but I'll swap the lines. :-)