C99 introduced Compound Literals. Seems that c-xref does not handle them as it should. Possibly even not parsing them.

Make c-xrefactory work using the helm interface

After loading, the c-xref menu is always available, which is a bit intrusive.

Although we can't know all possible file patterns people are using, we could at startup just activate the menu for the known patters, or hook into C-mode and Java-mode.

We could also add a c-xref auto-loaded function to activate the menu for specific buffers.

If you select an expression, e.g. inside an if statement, and extract that as a function you get a void function. Either c-xref should recognize the text as in the context of an expression, or give you an option to extracting it as a non-void function with a return statement.

The latter is probably the only choice for C since everything is an expression and you can have expressions everywhere. It seems that in Java the distinction is made since there are both Extract Method and Extract Function, but only the latter is available for C.

Running c-xreafactory on a small Java program with Java 8 gives this error. Java support was "removed" in the "Xrefactory" -> "C-Xrefactory" transition, but is still fully included. Java versions beyond 1.3 was probably never supported.

This can be a starting point in decoding how the Java support is working. E.g. what tag is this, and I have not really understood what the 'constant pool' is either...

Position cursor on a partial identifier and press F8 to start completion. If that was an ambiguous partial string you get a completion list. if you press a letter it should incrementally narrow the search.

In emacs 25 (maybe also emacs 24, I remember seeing this before) you get an emacs error:

Symbol’s value as variable is void: last-command-char

A backtrace on that error reveals

Debugger entered--Lisp error: (void-variable last-command-char)
    (format "%s%c" os last-command-char)
    (setq ns (format "%s%c" os last-command-char))
    (let ((ns) (os) (nns)) (setq os (car c-xref-completion-auto-search-list)) (setq ns (format "%s%c" os last-command-char)) (beginning-of-line) (c-xref-auto-search-search ns) (setq nns (car c-xref-completion-auto-search-list)) (c-xref-completion-source-mod))
    c-xref-completion-auto-search()
    funcall-interactively(c-xref-completion-auto-search)
    call-interactively(c-xref-completion-auto-search nil nil)
    command-execute(c-xref-completion-auto-search)

There are some cases where you want c-xref to analyze all your sources in the directory(ies) except for a few files. One example is if you have generated files, such as yacc grammars. In this case you want c-xref to ignore the .c files because those references will be overwritten anyways.

0002-Make-exactpositionresolve-option-affecting.patch.txt

SCENARIO 1

1. git clone git://anongit.freedesktop.org/systemd/systemd
2. add a new project section to .c-xrefrc:

[/home/litvin/src/systemd]
  /home/litvin/src/systemd
  -refs /home/litvin/CXrefs/src/systemd
  -refnum=100
  -exactpositionresolve

3. Create references:
   c-xref -create -xrefrc /home/litvin/.c-xrefrc -p /home/litvin/src/systemd -user 1 -xrefactory-II -crlfconversion -crconversion -encoding=default -exactpositionresolve -o /tmp/c-xref-test-systemd.log

4. Visit this file in Emacs: /home/litvin/src/systemd/src/network/networkd.c and point cursor to "Manager" here:

int main(int argc, char *argv[]) {
        _cleanup_manager_free_ Manager *m = NULL;

5. Execute "c-xref-push-and-goto-definition" command:
   --->
   Right definition was expecting.
   Wrong definition (but with the same name) happened instead.

6. Point cursor to "manager_new" here:

int main(int argc, char *argv[]) {
...
        r = manager_new(&m);

7. Execute "c-xref-push-and-goto-definition" command:
   --->
   Right definition was expecting.
   Wrong definition (but with the same name) happened instead.

SCENARIO 2

struct S
{
  int i;
};

int main()
{
  struct S
  {
    int j;
  };

  struct S s; // try c-xref-push-and-goto-definition on S here
  s.j = 1; // try c-xref-push-and-goto-definition on j here

  return 0;
}

If you have a grammar with some function declared in the last ("additional C code") section (Outline of a Bison grammar) the symbols inside a function is handled correctly (in that a goto-definition works as expected).

But a static or non-static function defined in that section does not seem to have a symbol table entry ("Definition not found"). This works as expected in the generated C file.

An example is the cgram.y in c-xrefactory itself.

The effect of this is also that renaming such a function will only change the references and not the definition.

Scenario:

1. git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
2. Add a new project section to .c-xrefrc:

[/home/litvin/src/linux]
  -D__KERNEL__
  -D__UM_HOST__
  -D__arch_um__  
  /home/litvin/src/linux/arch/um
  /home/litvin/src/linux/arch/x86/um
  /home/litvin/src/linux/block
  /home/litvin/src/linux/certs
  /home/litvin/src/linux/crypto
  /home/litvin/src/linux/drivers
  /home/litvin/src/linux/fs
  /home/litvin/src/linux/init
  /home/litvin/src/linux/ipc
  /home/litvin/src/linux/kernel
  /home/litvin/src/linux/lib
  /home/litvin/src/linux/mm
  /home/litvin/src/linux/net
  /home/litvin/src/linux/samples
  /home/litvin/src/linux/scripts
  /home/litvin/src/linux/security
  /home/litvin/src/linux/sound
  /home/litvin/src/linux/virt
  -I/home/litvin/src/linux/arch/um/include/uapi 
  -I/home/litvin/src/linux/arch/um/include/generated/uapi 
  -I/home/litvin/src/linux/include/uapi 
  -I/home/litvin/src/linux/include/generated/uapi 
  -I/home/litvin/src/linux/arch/um/include 
  -I/home/litvin/src/linux/arch/um/include/generated 
  -I/home/litvin/src/linux/include
  -I/home/litvin/src/linux/arch/um/include/shared/skas
  -I/home/litvin/src/linux/arch/um/include/shared
  -I/home/litvin/src/linux/arch/x86/um/shared
  -I/home/litvin/src/linux/arch/x86/um
  -I/home/litvin/src/linux/arch/x86/include
  -I/home/litvin/src/linux/arch/x86/include/uapi
  -I/home/litvin/src/linux/arch/x86/include/generated
  -I/home/litvin/src/linux/arch/x86/include/generated/uapi
  -refs /home/litvin/CXrefs/src/linux
  -refnum=1000
  -exactpositionresolve

3. c-xref -create -xrefrc /home/litvin/.c-xrefrc -p /home/litvin/src/linux -user 1 -xrefactory-II -crlfconversion -crconversion -encoding=default -exactpositionresolve -o /tmp/c-xref.log

--->
Program aborts at 16% with message in log file:

<fatalError len=203><A HREF="file:///home/litvin/src/linux/drivers/clk/sunxi/clk-sun9i-core.c#175" len=20>clk-sun9i-core.c:175</A> sorry, memory mbMemory overflowed over borne
	read the TROUBLES section of the README file.
</fatalError>

0001-memory-overflowed-over-borne.patch.txt

Currently .y files are skipped during processing.

0002-Allow-to-process-.y-files.patch.txt

0002-Add.initializer-list.parsing.for.arrays.structs.unions.patch.txt

Try "c-xref-push-and-goto-definition" in "a" and "s" initializers:

enum E {
  E0, E1, E2, E3
};

struct X {
  int a;
};

struct Y {
  int a;
  struct X b;
  struct X c[2];
};

struct Y s = { /* c-xref is able to parse such an initializer from now */
  .a = E0,
  .b.a = E1,
  .c[E0].a = E0,
  .c[E1].a = E1,
};

int a [2][2] = {
  [E0][E0] = E0,
  [E0][E1] = E1,
  [E1][E0] = E2,
  [E1][E1] = E3
};

int main()
{
  return 0;
}

I detect GCC include directories by invoking cpp with -v option:
https://gcc.gnu.org/onlinedocs/cpp/Search-Path.html

This also fixes issue #8

Scenario:

1. Add a new project section to .c-xrefrc:

[/home/litvin/src/c-xrefactory]
  /home/litvin/src/c-xrefactory/src
  -refs /home/litvin/CXrefs/src/c-xrefactory
  -refnum=100
  -exactpositionresolve

2. Execute: c-xref -create -xrefrc /home/litvin/.c-xrefrc -p /home/litvin/src/c-xrefactory -user 1 -xrefactory-II -crlfconversion -crconversion -encoding=default -exactpositionresolve -o /tmp/c-xref.log
   --->
   A lot of warings in /tmp/c-xref.log:

<warning len=92><A HREF="file:///usr/include/unistd.h#229" len=12>unistd.h:229</A> can't open file stddef.h
...
<warning len=90><A HREF="file:///usr/include/zconf.h#427" len=11>zconf.h:427</A> can't open file stdarg.h

0001-Add-GCC-include-directories-detection.patch.txt

In a large source tree there might be duplicate filenames and function names within different modules.

E.g. given

       module1 - void func(int i) {}
     /
src -  module2 - void func(double d) {}
     \
       main - func(3.14);

In this case c-xrefactory, given "sourcedir=src" will misinterpret both func() to be the same definition and navigation will cirlcle over all of them.

This should really be solved by c-xrefactory "knowing" about the compilation and linking structure, but that is probably not feasible.

The solution now is to refrain from using src as the source directory, instead enumerating main and module2. In a large source tree this can be cumbersome and error-prone.

A better option might be to allow "ignored" paths within the source tree, in this case set "sourcedir=src" but ignore module1.

It seems that C Xrefactory won't compile using MYS2/MinGW-64 under Windows 10 x64.

I've tried all the various approaches proposed in INSTALL and none worked:

1. Via el-get — the problem is that el-get won't work under MSYS2 due to incompatibility problems with MinGW-64 install-info tool (from TextInfo).
2. Creation of a binary distribution via CreateXrefDistribution fails with numerous warning and errors (see log below),
3. Simple make failed too, seemingly due to a missing ./c-xref.bs file.
4. Compiling in src/ via make also failed, again due to missing ./c-xref.bs file.

Any ideas? Is Xref supposed to be compiled as 32-bit only?

Failed Auto Create Xrefactory Distribution

Windows 10 x64 | MSYS2 > MinGW64 

Below is the output log from trying to compile c-xrefactory via

sh ./CreateXrefDistribution

Beside various warnings during make byacc, the BOOTSTRAPPING phase fails

P.K.Dick@RANXEROX MINGW64 /d/GitHub/Xref/c-xrefactory
$ sh ./CreateXrefDistribution
make -C ../byacc-1.9
make[1]: ingresso nella directory "/d/GitHub/Xref/c-xrefactory/byacc-1.9"
cc -O -DNDEBUG -std=c89   -c -o closure.o closure.c
In file included from defs.h:4,
                 from closure.c:1:
defs.h:283:12: warning: '_errno' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
  283 | extern int errno;
      |            ^~~~~
cc -O -DNDEBUG -std=c89   -c -o error.o error.c
In file included from defs.h:4,
                 from error.c:3:
defs.h:283:12: warning: '_errno' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
  283 | extern int errno;
      |            ^~~~~
cc -O -DNDEBUG -std=c89   -c -o lalr.o lalr.c
In file included from defs.h:4,
                 from lalr.c:1:
defs.h:283:12: warning: '_errno' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
  283 | extern int errno;
      |            ^~~~~
cc -O -DNDEBUG -std=c89   -c -o lr0.o lr0.c
In file included from defs.h:4,
                 from lr0.c:1:
defs.h:283:12: warning: '_errno' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
  283 | extern int errno;
      |            ^~~~~
cc -O -DNDEBUG -std=c89   -c -o main.o main.c
In file included from defs.h:4,
                 from main.c:3:
defs.h:283:12: warning: '_errno' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
  283 | extern int errno;
      |            ^~~~~
cc -O -DNDEBUG -std=c89   -c -o mkpar.o mkpar.c
In file included from defs.h:4,
                 from mkpar.c:1:
defs.h:283:12: warning: '_errno' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
  283 | extern int errno;
      |            ^~~~~
cc -O -DNDEBUG -std=c89   -c -o output.o output.c
In file included from defs.h:4,
                 from output.c:1:
defs.h:283:12: warning: '_errno' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
  283 | extern int errno;
      |            ^~~~~
cc -O -DNDEBUG -std=c89   -c -o reader.o reader.c
In file included from defs.h:4,
                 from reader.c:1:
defs.h:283:12: warning: '_errno' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
  283 | extern int errno;
      |            ^~~~~
cc -O -DNDEBUG -std=c89   -c -o skeleton.o skeleton.c
In file included from defs.h:4,
                 from skeleton.c:1:
defs.h:283:12: warning: '_errno' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
  283 | extern int errno;
      |            ^~~~~
cc -O -DNDEBUG -std=c89   -c -o symtab.o symtab.c
In file included from defs.h:4,
                 from symtab.c:1:
defs.h:283:12: warning: '_errno' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
  283 | extern int errno;
      |            ^~~~~
cc -O -DNDEBUG -std=c89   -c -o verbose.o verbose.c
In file included from defs.h:4,
                 from verbose.c:1:
defs.h:283:12: warning: '_errno' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
  283 | extern int errno;
      |            ^~~~~
cc -O -DNDEBUG -std=c89   -c -o warshall.o warshall.c
In file included from defs.h:4,
                 from warshall.c:1:
defs.h:283:12: warning: '_errno' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
  283 | extern int errno;
      |            ^~~~~
Loading yacc ... done
make[1]: uscita dalla directory "/d/GitHub/Xref/c-xrefactory/byacc-1.9"
BOOTSTRAPPING...
make ROOTDIR=.. -f Makefile.bs
make[1]: ingresso nella directory "/d/GitHub/Xref/c-xrefactory/src"
cc  -DBOOTSTRAP -o .objects/cgram.o -MMD -c cgram.c
cgram.c:159: warning: "CONST" redefined
  159 | #define CONST 295
      |
In file included from C:/tools/msys64/mingw64/x86_64-w64-mingw32/include/windef.h:8,
                 from C:/tools/msys64/mingw64/x86_64-w64-mingw32/include/windows.h:69,
                 from stdinc.h:17,
                 from proto.h:23,
                 from cgram.x:12,
                 from cgram.y:36:
C:/tools/msys64/mingw64/x86_64-w64-mingw32/include/minwindef.h:122: note: this is the location of the previous definition
  122 | #define CONST const
      |
cgram.c:174: warning: "VOID" redefined
  174 | #define VOID 310
      |
In file included from C:/tools/msys64/mingw64/x86_64-w64-mingw32/include/minwindef.h:163,
                 from C:/tools/msys64/mingw64/x86_64-w64-mingw32/include/windef.h:8,
                 from C:/tools/msys64/mingw64/x86_64-w64-mingw32/include/windows.h:69,
                 from stdinc.h:17,
                 from proto.h:23,
                 from cgram.x:12,
                 from cgram.y:36:
C:/tools/msys64/mingw64/x86_64-w64-mingw32/include/winnt.h:284: note: this is the location of the previous definition
  284 | #define VOID void
      |
cgram.c:204: warning: "INTERFACE" redefined
  204 | #define INTERFACE 340
      |
In file included from C:/tools/msys64/mingw64/x86_64-w64-mingw32/include/windows.h:108,
                 from stdinc.h:17,
                 from proto.h:23,
                 from cgram.x:12,
                 from cgram.y:36:
C:/tools/msys64/mingw64/x86_64-w64-mingw32/include/commdlg.h:587: note: this is the location of the previous definition
  587 | #define INTERFACE IPrintDialogServices
      |
cgram.c:213: warning: "THIS" redefined
  213 | #define THIS 349
      |
In file included from C:/tools/msys64/mingw64/x86_64-w64-mingw32/include/objbase.h:14,
                 from C:/tools/msys64/mingw64/x86_64-w64-mingw32/include/ole2.h:17,
                 from C:/tools/msys64/mingw64/x86_64-w64-mingw32/include/wtypes.h:12,
                 from C:/tools/msys64/mingw64/x86_64-w64-mingw32/include/winscard.h:10,
                 from C:/tools/msys64/mingw64/x86_64-w64-mingw32/include/windows.h:97,
                 from stdinc.h:17,
                 from proto.h:23,
                 from cgram.x:12,
                 from cgram.y:36:
C:/tools/msys64/mingw64/x86_64-w64-mingw32/include/combaseapi.h:106: note: this is the location of the previous definition
  106 | #define THIS INTERFACE *This
      |
cgram.c:227: warning: "DELETE" redefined
  227 | #define DELETE 363
      |
In file included from C:/tools/msys64/mingw64/x86_64-w64-mingw32/include/minwindef.h:163,
                 from C:/tools/msys64/mingw64/x86_64-w64-mingw32/include/windef.h:8,
                 from C:/tools/msys64/mingw64/x86_64-w64-mingw32/include/windows.h:69,
                 from stdinc.h:17,
                 from proto.h:23,
                 from cgram.x:12,
                 from cgram.y:36:
C:/tools/msys64/mingw64/x86_64-w64-mingw32/include/winnt.h:2878: note: this is the location of the previous definition
 2878 | #define DELETE (__MSABI_LONG(0x00010000))
      |
cc  -DBOOTSTRAP -o .objects/main.o -MMD -c main.c
In file included from unigram.h:24,
                 from main.c:20:
cgram.h:84: warning: "INTERFACE" redefined
   84 | #define INTERFACE 340
      |
In file included from C:/tools/msys64/mingw64/x86_64-w64-mingw32/include/windows.h:108,
                 from stdinc.h:17,
                 from proto.h:23,
                 from main.h:4,
                 from main.c:1:
C:/tools/msys64/mingw64/x86_64-w64-mingw32/include/commdlg.h:587: note: this is the location of the previous definition
  587 | #define INTERFACE IPrintDialogServices
      |
cc  -DBOOTSTRAP -o .objects/globals.o -MMD -c globals.c
In file included from unigram.h:24,
                 from globals.c:6:
cgram.h:84: warning: "INTERFACE" redefined
   84 | #define INTERFACE 340
      |
In file included from C:/tools/msys64/mingw64/x86_64-w64-mingw32/include/windows.h:108,
                 from stdinc.h:17,
                 from proto.h:23,
                 from globals.h:5,
                 from globals.c:1:
C:/tools/msys64/mingw64/x86_64-w64-mingw32/include/commdlg.h:587: note: this is the location of the previous definition
  587 | #define INTERFACE IPrintDialogServices
      |
cc  -DBOOTSTRAP -o .objects/misc.o -MMD -c misc.c
misc.c: In function 'concatFNameInTmpMemory':
misc.c:1504:13: error: 's' undeclared (first use in this function)
 1504 |         for(s=tt+1; *s; s++) if (*s=='/') *s=SLASH;
      |             ^
misc.c:1504:13: note: each undeclared identifier is reported only once for each function it appears in
make[1]: *** [Makefile.bs:15: .objects/misc.o] Error 1
make[1]: uscita dalla directory "/d/GitHub/Xref/c-xrefactory/src"
make: *** [Makefile.common:80: c-xref.bs] Error 2
cp: impossibile eseguire stat di 'src/c-xref': No such file or directory
cp: impossibile eseguire stat di 'emacs/c-xrefactory.el'$'\r': No such file or directory
cp: impossibile eseguire stat di 'emacs/c-xref.el'$'\r': No such file or directory
cp: impossibile eseguire stat di 'emacs/c-xrefprotocol.el'$'\r': No such file or directory

Failed Make in Root Folder

Below is the output log from trying to compile c-xrefactory via make inside root folder.

The problem seems to be a missing ./c-xref.bs file.

P.K.Dick@RANXEROX MINGW64 /d/GitHub/Xref/c-xrefactory
$ make
make -C src
BOOTSTRAPPING...
make ROOTDIR=.. -f Makefile.bs
make[2]: ".objects/main.o" è aggiornato.
/bin/sh: ./c-xref.bs: No such file or directory
make[1]: *** [Makefile.common:104: strFill.g.h] Error 127
make: *** [Makefile:6: all] Error 2

Failed Make in src/ Folder

Below is the output log from trying to compile c-xrefactory via make inside src/ folder.

Again, the problem seems to be a missing ./c-xref.bs file.

P.K.Dick@RANXEROX MINGW64 /d/GitHub/Xref/c-xrefactory/src
$ make
BOOTSTRAPPING...
make ROOTDIR=.. -f Makefile.bs
make[1]: ingresso nella directory "/d/GitHub/Xref/c-xrefactory/src"
make[1]: ".objects/main.o" è aggiornato.
make[1]: uscita dalla directory "/d/GitHub/Xref/c-xrefactory/src"
/bin/sh: ./c-xref.bs: No such file or directory
make: *** [Makefile.common:104: strFill.g.h] Error 127

Sometimes when you navigate the usages of a variable you really only want to navigate the assignments to it. When there are many non-assignment usages it becomes harder to see which ones are the interesting ones.

It seems that c-xref can't read paths with spaces in them from the xrefrc file. For example

-refs /cygdrive/c/Program Files (x86)/Jenkins/jobs/c-xrefactory/workspace/tests/process_yacc/CXrefs

does not seem to be interpreted correctly. Instead the CXrefs are stored in /cygdrive/c/Program

@thoni56:

I'm on a long-time quest to resurrect this code to understandable, maintainable and developable standard. This is hard, difficult and time consuming, as it is almost impossible to understand what anything does. At this point I've added a couple of smoke/functional tests, that at least should crash if something basic becomes broken.

I think that a good move would be to reimplement the server part using Language Server Protocol for this would jail-break Xref from being an Emacs only tool and allow using it with any modern editor — which would, in turn, most probably raise awareness on the tool and attract collaborators to it.

There are already numerous LSP Implementations in the wild, and the protocol is supported by an increasing number of editors (including Emacs).

I gather you've looked deeply into Xref source code, so I was wondering if you think that this is doable. Is the server part of the tool coded in a way which would make adapting it to LSP possible?

I'm quite confident that moving Xref to LSP would quickly attract users and contributors from editors like Sublime Text, VSCode, Atom, Vim, and many others, which could really make a big difference in the interest shown for this tool.

As I'm almost dependent on this and refactoring tools for C is sadly lacking, I decided to pick this up and work a bit on it, maybe even make it a bit more visible, by moving it to GitHub.

You're right, there seems to be a serious lack of free refactoring tools for C, which strenghten my convinction that making Xref an LSP-tool would hugely boost its visibility. Once Xref would support LSP, integrating it into other editors via a custom extension/plugins is going to be quite easy, for there are plenty of LSP extension templates available for all the major editors.

It really looks like MicroSoft has come up with a good and successfull idea in regard to LSP, and its VSCode editor is gaining a growing userbase.

See also:

• https://langserver.org/

If you have a structure like

struct S {
    int field;
}

and a static initialization like

S s = {14};

it seems like the "14" is not registered as a reference. It would be very useful to find that when browsing, although it is strictly not a reference. Perhaps this ties into #35 to be able to navigate to only assignments.

According to the documentation the .c-xrefrc option -I adds the extra directory to search for included files at the end. This is not what most compilers do, they add the provided -I directories before the standard ones.

Currently you need to first reset the default with -resetIncludeDirs and then re-add the standard ones.

It would seem more logical to do as compilers do...

A yacc grammar may have the following

%union {
  int integer;
}

%type <integer> rule

The integer is a field in the semantic stack, and the %type indicates that the listed rule "returns" that field.

c-xrefactory doesn't understand the %type declaration so a rename of the field will miss that occurrence.

0002-Add-GCC-predefined-type-macros.patch.txt

These are necessary to parse size_t, int32_t, int64_t, ... correctly.
See https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html#Common-Predefined-Macros

0001-Added-pragma-once-directive-support.patch.txt

It seems that a re-generated file, such as a .c-file generated from a .y, is not detected and does not trigger an update of the tags for that file. At least the navigation with / does not match the actual positions.

Note that this is just a guess about the cause of some symptoms I'm seeing when navigating in a C/Yacc project where the build automatically re-generates the .c-file if required.

As c-xref knows about included files (try F6 when on the file name in an #include statement!) it should be possible to implement "Rename file" or even "Rename module" (assuming the idiomatic x.c/x.h structure).

There is a trick introduced by #11 that automatically discovers the include paths that the compiler is using. This assumes gccand cpp.

This is not sufficient:

• does not work if gcc/cpp is clang as in Darwin
• should not apply for Java (don't understand enough of that code to see if it does or not)

In some cases positions in Emacs get out of sync. It "feels" like c-xref misses to update positions.

I've not yet established a pattern for this, but it often misses a couple of lines, never columns as far as I can remember.

I'm using magit which might sometimes refresh files in the background, e.g. due to command line checkouts and the like. Maybe this is a problem... I don't know enough about the elisp code at this point to start debugging this.

A full, or even fast, update of tags seems to fix the problem.

So possible ideas:

• file updates in the background goes unnoticed
• buffer refreshs goes unnoticed
• mixed line terminations in the file screw this up (not likely since an update fixes it)
• ...

0001-Parsing-ranges-in-case-labeled-statement-fixed.patch.txt

It's a lot easier for most users than el-get.

c-xrefactory requires zlib but currently a build fails if none is available on the target system. This is particularly problematic now with the easy el-get install which basically says that the make command failed.

But c-xrefactory sources includes a very early, but sufficient, version of zlib which could be used in case the system does not provide one. This would lift yet another burdon from the users shoulders.

src\main.c line 2492:
memset(s_yygstate, sizeof(struct yyGlobalState), 0);

should be
memset(s_yygstate, 0, sizeof(struct yyGlobalState));

Is this possible to remedy by package dependencies? Or does the user just have to know that you should have installed?

M-x el-get-remove <ENTER> c-xrefactory <ENTER>

and then at a prompt do something similar to

sudo apt install zlib-devel

and then retry

M-x el-get-install <ENTER> c-xrefactory <ENTER>

Emacs 26 also removed insert-string. Replacing it with insert seems to be the way to go.

See this Stackoverflow answer.

This means that noone using Emacs 26.1 or above can use c-xrefactory unless this is fixed. Fortunately this is an easy fix.

xref-1.6.10.el.diff.txt

This is a patch against the latest non-free version of XRef which fixes some small problems.

I quite understand if it's useless to you, but I thought it worth submitting just in case!

The jedit adapter/plugin is available in the x-refactory 1.6.10 x-refactory distribution.

Line 22:
cat doc/INSTALL doc/readme doc/readme2 > ../c-xref/README

doc/readme not found.
Besides the readme2, I can see only README READMETOP readme.win, but not readme. I do not know which one you intend to copy to the /c-xref/README

0001-Problem-with-restoring-regs-after-longjmp.patch.txt

It would be useful to have better documentation on each feature because at the moment if somebody wants to use the plugin he does not know what function to call.I am talking about emacs function calls.

To simplify initial porting and builds on various platforms, the bootstrapping, that included requiring a pre-build c-xref, was short-circuited.

Some intricate make-ing is required but it should be possible to build a bootstrap c-xref from default sources and then rebuild for the current platform.

See src/Makefile.common, target bootstrap.

0001-Allowing-default-include-directories-searching-for-y.patch.txt

Add missed keywords:
asm, inline, _Noreturn, restrict, _Atomic, _Bool, _Thread_local

0005-Add-missed-C-keywords.patch.txt

A refactoring for C that would be handy is to move a function to another file.

This requires some heuristics that also needs to be checked before doing the move:

• is there a header file with the same name both for source and target module

And what about the clients of the module, should their #includes also be changed? I guess they should, otherwise it is not a true refactoring.

0001-Parsing-asm-statement-fixed.patch.txt

It seems that we you use the refactoring "Delete Parameter" on a macro and you remove parameter nr (meaning the last argument) somewhere there's an out of range thrown.

I have not made extensive investigations on if there are other conditions that are required for this to happen. In the two instanced that I have tried it, it failed.

The current (patched) byacc-1.9 is not a very nice implementation generating a lot of warnings and errors with modern C compilers. We should figure out how to apply the patches to a more modern version of yacc.

This bug prevents browsing in multiple Emacs frames.

0001-c-xref-set-this-frame-dispatch-data.patch.txt