Hi,

* Jörg Fischer wrote (2008-01-07 21:32):
> 1) In the new release the command shell logic will change: Instead of
>    having a hardcoded default value (ie, /bin/csh), the user's login
>    shell is chosen.  Moreover, the shell setting was moved to the GUI
>    (preference settings), so it's easier to change.
>    
>    Now, if you use or share macros that make use of shell_command(),
>    you can't rely on a fixed default value for the shell. (Although
>    the shell could be changed before via an X resource setting, many
>    users were not aware that nedit was using csh, unless they found
>    out about how to set the shell.)  Since the command syntax differs
>    from shell to shell, macros using the shell need *at least* to
>    know which shell is actually in use, so this calls for a
>    $command_shell variable.  All the other preference settings are
>    also available in macros having a variable and even an action
>    to set them, see Window Preferences Actions (under Action Routines).

I don't think they do. NEdit has two kinds of settings:
- Preferences are those that change behaviour of future documents,
  like 'Make Backup Copy'; these also have a matching local setting.
- Globals are affecting all documents immediately.

The settings with action routines are all preferences, and only the
local option is changed. The command shell is a global option however,
and changing it would affect all windows.


>    Would be even better to have both these things for the shell, too, 
>    so one could write
>        
>        old_shell = $command_shell
>        set_command_shell("/bin/csh")
>        shell_command(...)  # with C shell syntax in this case
>        set_command_shell(old_shell)

Actually it would be better to write
    shell_command("csh -c '...'")


> 2) For 5.4 background coloring was made available for syntax
>    highlighting.  This coloring stops at \n. Then Tony found out how
>    to make the coloring go beyond \n and asked for comments (ie,
>    include into 5.4 or not).  Unfortunately, back then the change was
>    misunderstood as an either-or decision (either stop at \n or go
>    beyond \n always), which is wrong, because now we have "always
>    stop at \n", and with the change we would have both possibilities
>    "go beyond \n" and "stop at \n" (achieved with a subpattern
>    catching the \ns).

Could you point out the discussion about this?


Thorsten
-- 
The privacy of correspondence, posts and telecommunications shall be inviolable.
    - German Grundgesetz, Article 10, Sec. 1 

Attachment: pgpiiCrSFuFVe.pgp
Description: PGP signature

-- 
NEdit Develop mailing list - [email protected]
http://www.nedit.org/mailman/listinfo/develop

Reply via email to