Re: Jed B0.99-17.111 RPMs for Fedora Core 4

SANGOI DINO LEONARDO wrote:
> But this means changes to every program to link with the right library... It
> can be done, but I feel that SLang 2 should be the only slang around, and
> programs should be ported to it as soon as possibile.
> 

Remember that the license has changed between 1.4 and 2.0. SLang 2.0
can only be used in GPL applications. If someone is using SLang in
an application that is not GPL compatible he would have to use 1.4.

If such cases exist, SLang 2.0 should be in a library called libslang2.

Marko

RE: Jed B0.99-17.111 RPMs for Fedora Core 4

> -----Original Message-----
> From: Marko Mahnic
> Sent: domenica 2 ottobre 2005 13.29
> Subject: Re: Jed B0.99-17.111 RPMs for Fedora Core 4
> 
> Remember that the license has changed between 1.4 and 2.0. SLang 2.0
> can only be used in GPL applications. If someone is using SLang in
> an application that is not GPL compatible he would have to use 1.4.
> 
> If such cases exist, SLang 2.0 should be in a library called 
> libslang2.

Yes, this is a good point I missed.

I looked at debian packages, and those aready use slang2 (and libslang2).

It's not a problem at runtime: a program linked with libslang.so.1 will
never load libslang.so.2 (unless you do something wrong at link time...).
But on a system where the user can compile and link programs freely, this
may still be a problem.

I was hoping to avoid touching the linking of jed and others... well, maybe
is better to change it now and live with it...

Thanks for noticing it!
								Dino

Enable Xft using configure

Well, this is the patch I promised.

I added a function to aclocal.m4 called JD_XFT, that does the test, and used
it in configure.ac.

As it needs the function PKG_CHECK_MODULES, you will need a recent version
of autoconf, but running aclocal will overwrite your aclocal.m4...

so the steps are:
1) patch jed with xft-ac.diff.
2) rename autoconf/aclocal.m4 to acsite.m4.
3) run aclocal on autoconf directory.
   (if this does not work, you can still use the aclocal.m4 attached, it
works for me on Fedora 4, but didn't on SuSE 9.3)
4) autoconf

the new configure will have a new --enable-xft option.
If not given, it will compile Xft support if the libraries are found.
If given '--enable-xft=no' or '--disable-xft' it will not compile Xft
support.

If you have the Xft library, but for some reason configure can't found it,
you can still tweak src/Makefile as before.

Hope this helps,
							Dino

Regexp support for folding

Hi,

Another small hack I did this weekend was adding regexp support to
folding.sl.

as you may remember, mark info is something like 
"<start>\r<end_of_start>\r<end>\r<end_of_end>"

After patching it, regular expression based markers can be defined using 
an empty <start> and <end> (a condition not allowed for string based
markers). 
In <end_of_start> and <end_of_end> must be a string with a context flag 
(first character) followed by the regular expression.
The first character is used to test the context (using parse_to_point()), 
and must be one of:
  - '%': This is a valid marker if context is on a comment.
  - '"': as above for string
  - '#': as above normal code.
  - ' ': Don't test.

For example, you can try this for SLang mode (and almost the same for C).

mode_set_mode_info ("SLang", "fold_info", "\r\r#{[ \t]*$\r#^[ \t]*}");

It will start a fold for every '{' in normal code at the end of line
(skipping whitespaces).
the end of fold are '}' at beginning of line (again skipping whitespaces).

Hope this is useful!
							Dino

C mode parameter offset

Hi.

I am sending the patch for the C_Param_Offset_Max feature for
cmode.sl. This time there is also some documentation.

Marko

--- /cygdrive/s/jed/jed-B0.99-17.95/lib/cmode.sl	2005-04-18 19:02:30.000000000 +0200
+++ /cygdrive/s/localcvs/fljed/jed/lib/cmode.sl	2005-10-04 10:59:24.968750000 +0200
 <at>  <at>  -45,6 +45,22  <at>  <at> 
 %!%-
 custom_variable ("C_Class_Offset", 3);
 
+%!%+
+%\variable{C_Param_Offset_Max}
+%\synopsis{Control indentation of continued parameter list}
+%\usage{Integer C_Param_Offset_Max = 6}
+%\description
+% This variable may be changed to adjust the indentation of parameters
+% in a funcion call that extends over multiple lines.
+% 
+% If the value is less than 0, the feature is off, otherwise
+% it holds the max number of spaces to indent the parameters on
+% the continuation line(s).
+%\seealso{c_mode}
+%\seealso{C_BRA_NEWLINE, C_BRACE, C_INDENT}
+%!%-
+custom_variable ("C_Param_Offset_Max", -1);
+

Re: SuSv3 violation by jed

On Fri, Sep 30, 2005 at 08:57:13PM +0000, Joerg Sommer wrote:
> I looked into the SuSv3 (the Unix standard) and found in section "4.11
> Pathname Resolution", that a path with more than one backslash should be
> treated a the path with one backslash. Ergo the above path must expand to
> /usr/share/jed/compile/jed-common and not /jed-common. Otherwise it is
> not Unix conform.

I think the reason it was implemented like this is that when you get
the filename prompt (like when you try to find a file), it is already
filled with current directory, like:

Find file: /home/alpha/

Now you can open absolute path by just typing the it without the need
to clean the prompt:

Find file: /home/alpha//etc/passwd

will open /etc/passwd. However I don't claim this is compliant in any
way :)

Regards,
Adam

--

-- 
Adam Byrtek
Alpha

Re: SuSv3 violation by jed

On 10/4/05, Adam Byrtek <alpha <at> linux.net.pl> wrote:
> On Fri, Sep 30, 2005 at 08:57:13PM +0000, Joerg Sommer wrote:
> > I looked into the SuSv3 (the Unix standard) and found in section "4.11
> > Pathname Resolution", that a path with more than one backslash should be
> > treated a the path with one backslash. Ergo the above path must expand to
> > /usr/share/jed/compile/jed-common and not /jed-common. Otherwise it is
> > not Unix conform.
>
> I think the reason it was implemented like this is that when you get
> the filename prompt (like when you try to find a file), it is already
> filled with current directory, like:
>
> Find file: /home/alpha/
>
> Now you can open absolute path by just typing the it without the need
> to clean the prompt:
>
> Find file: /home/alpha//etc/passwd
>
> will open /etc/passwd. However I don't claim this is compliant in any
> way :)

You can also use ~ in the same way, at least inside jed.  I quite like
this feature, though perhaps it should only apply to filenames
specified within jed, not filenames on the command-line.

--M.

--
http://beebo.org

Keybindings

Hi.

In C code I need to find out if a key is bound to sth.
I used to use the function jed_get_key_function for the purpose,
but in 99-17.111 it has disappeared from keymap.c (it used to be a
static function in 99-17.95 and I made it public for fljed to
correctly handle Alt-keys).

What can I do?

Marko

Re: Keybindings

Marko Mahnic <marko.mahnic <at> email.si> wrote:
>In C code I need to find out if a key is bound to sth.
>I used to use the function jed_get_key_function for the purpose,
>but in 99-17.111 it has disappeared from keymap.c (it used to be a
>static function in 99-17.95 and I made it public for fljed to
>correctly handle Alt-keys).

The function was removed as part of the cleanup when I added support
for Ref_Type objects to the setkey function.  For example, it is now
possible to do

   private define foo ()
   {
      insert ("foo");
   }
   setkey (&foo, "^Cf");

As a work-around, you can use something like:

   static int is_key_bound (char *keyseq)
   {
      int type;

      if (1 != SLang_run_hooks ("get_key_binding", 1, keyseq))
        return 0;
      /* Two values are returned: type and func. */
      if ((-1 == SLdo_pop ())
          || (-1 == SLang_pop_int (&type)))
	return 0;
	

Re: SuSv3 violation by jed

Hello Adam,

Adam Byrtek <alpha <at> linux.net.pl> wrote:
> On Fri, Sep 30, 2005 at 08:57:13PM +0000, Joerg Sommer wrote:
>> I looked into the SuSv3 (the Unix standard) and found in section "4.11
>> Pathname Resolution", that a path with more than one backslash should be
>> treated a the path with one backslash. Ergo the above path must expand to
>> /usr/share/jed/compile/jed-common and not /jed-common. Otherwise it is
>> not Unix conform.
>
> I think the reason it was implemented like this is that when you get
> the filename prompt (like when you try to find a file), it is already
> filled with current directory, like:
>
> Find file: /home/alpha/
>
> Now you can open absolute path by just typing the it without the need
> to clean the prompt:
>
> Find file: /home/alpha//etc/passwd
>
> will open /etc/passwd. However I don't claim this is compliant in any
> way :)

But jed behaves the same way if you specify a file at the commandline and
it's common practice to concatenate path by simply append one to the
other. This can produce paths like /home/alpha//etc/passwd which jed do
not resolve the way as the unix spec says.

Yes, it is a question if jed would like to be unix conform, but it's a