Re: [patch] included files and the load button
Georg == Georg Baum [EMAIL PROTECTED] writes: Georg I think the attached should be safe now and will commit it Georg unless somebody finds other problems. Seems fine to me. JMarc
Re: [patch] included files and the "load" button
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: Georg> I think the attached should be safe now and will commit it Georg> unless somebody finds other problems. Seems fine to me. JMarc
Re: [patch] included files and the load button
Am Dienstag, 14. September 2004 11:22 schrieb Jean-Marc Lasgouttes:
Georg == Georg Baum [EMAIL PROTECTED] writes:
Georg Any sort of files can be inserted with the include inset (at
Georg least if you use the verbatim mode). So it is possible best to
Georg deactivate the load button if the file is not a lyx file.
Georg Unfortunately this requires more code ;-(
In this case the file is a text file and it should be opened with the
editor for ASCII, and should not use getExtFromContents.
Well, there may be a specialized editor e.g. for xml, so the ascii editor
might not be the best solution, but you are right, it should work for
everything that can be inserted verbatim. It is therefore better than the
current state, and this is all what I want.
BTW, my usage of getExtFromContents was wrong anyway: It returns the
extension, and I wanted the format name. Unfortunately they were the same
for the two cases I tested (eps and lyx)!
I think the attached should be safe now and will commit it unless somebody
finds other problems.
Georg
diff -p -r -U 3 -X excl.tmp lyx-1.4-clean/src/frontends/controllers/ChangeLog lyx-1.4-cvs/src/frontends/controllers/ChangeLog
--- lyx-1.4-clean/src/frontends/controllers/ChangeLog 2004-08-29 09:02:25.0 +0200
+++ lyx-1.4-cvs/src/frontends/controllers/ChangeLog 2004-09-15 21:07:56.0 +0200
@@ -1,3 +1,7 @@
+2004-09-15 Georg Baum [EMAIL PROTECTED]
+
+ * ControlInclude.C (load): open nonlyx files via formats.edit()
+
2004-08-15 Lars Gullik Bjonnes [EMAIL PROTECTED]
* pch.h: new file
diff -p -r -U 3 -X excl.tmp lyx-1.4-clean/src/frontends/controllers/ControlInclude.C lyx-1.4-cvs/src/frontends/controllers/ControlInclude.C
--- lyx-1.4-clean/src/frontends/controllers/ControlInclude.C 2004-05-21 08:55:40.0 +0200
+++ lyx-1.4-cvs/src/frontends/controllers/ControlInclude.C 2004-09-15 20:57:34.0 +0200
@@ -17,6 +17,7 @@
#include Kernel.h
#include buffer.h
+#include format.h
#include funcrequest.h
#include gettext.h
#include lyxrc.h
@@ -98,7 +101,12 @@ string const ControlInclude::browse(stri
void ControlInclude::load(string const file)
{
- kernel().dispatch(FuncRequest(LFUN_CHILDOPEN, file));
+ string const ext = support::getExtFromContents(file);
+ if (ext == lyx)
+ kernel().dispatch(FuncRequest(LFUN_CHILDOPEN, file));
+ else
+ // tex file or other text file in verbatim mode
+ formats.edit(kernel().buffer(), file, text);
}
Re: [patch] included files and the "load" button
Am Dienstag, 14. September 2004 11:22 schrieb Jean-Marc Lasgouttes:
> > "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
>
> Georg> Any sort of files can be inserted with the include inset (at
> Georg> least if you use the verbatim mode). So it is possible best to
> Georg> deactivate the load button if the file is not a lyx file.
> Georg> Unfortunately this requires more code ;-(
>
> In this case the file is a text file and it should be opened with the
> editor for ASCII, and should not use getExtFromContents.
Well, there may be a specialized editor e.g. for xml, so the ascii editor
might not be the best solution, but you are right, it should work for
everything that can be inserted verbatim. It is therefore better than the
current state, and this is all what I want.
BTW, my usage of getExtFromContents was wrong anyway: It returns the
extension, and I wanted the format name. Unfortunately they were the same
for the two cases I tested (eps and lyx)!
I think the attached should be safe now and will commit it unless somebody
finds other problems.
Georg
diff -p -r -U 3 -X excl.tmp lyx-1.4-clean/src/frontends/controllers/ChangeLog lyx-1.4-cvs/src/frontends/controllers/ChangeLog
--- lyx-1.4-clean/src/frontends/controllers/ChangeLog 2004-08-29 09:02:25.0 +0200
+++ lyx-1.4-cvs/src/frontends/controllers/ChangeLog 2004-09-15 21:07:56.0 +0200
@@ -1,3 +1,7 @@
+2004-09-15 Georg Baum <[EMAIL PROTECTED]>
+
+ * ControlInclude.C (load): open nonlyx files via formats.edit()
+
2004-08-15 Lars Gullik Bjonnes <[EMAIL PROTECTED]>
* pch.h: new file
diff -p -r -U 3 -X excl.tmp lyx-1.4-clean/src/frontends/controllers/ControlInclude.C lyx-1.4-cvs/src/frontends/controllers/ControlInclude.C
--- lyx-1.4-clean/src/frontends/controllers/ControlInclude.C 2004-05-21 08:55:40.0 +0200
+++ lyx-1.4-cvs/src/frontends/controllers/ControlInclude.C 2004-09-15 20:57:34.0 +0200
@@ -17,6 +17,7 @@
#include "Kernel.h"
#include "buffer.h"
+#include "format.h"
#include "funcrequest.h"
#include "gettext.h"
#include "lyxrc.h"
@@ -98,7 +101,12 @@ string const ControlInclude::browse(stri
void ControlInclude::load(string const & file)
{
- kernel().dispatch(FuncRequest(LFUN_CHILDOPEN, file));
+ string const ext = support::getExtFromContents(file);
+ if (ext == "lyx")
+ kernel().dispatch(FuncRequest(LFUN_CHILDOPEN, file));
+ else
+ // tex file or other text file in verbatim mode
+ formats.edit(kernel().buffer(), file, "text");
}
Re: [patch] included files and the load button
Georg == Georg Baum [EMAIL PROTECTED] writes: Georg Loading an included file results in an error message if it is Georg not a lyx file. This can be fixed easily, see attached. There Georg is still an error message if no editor for the file format is Georg known, but the user can fix that by defining an editor if Georg needed. Is this the correct way to do it, or should I do it Georg like in insetgraphics and insetexternal with an extra lfun? What kind of files do you plan to insert this way? Is that meant for .tex or .txt files? I do not think these ones are well suited for getExtFromContents. JMarc
Re: [patch] included files and the load button
Am Dienstag, 14. September 2004 09:39 schrieb Jean-Marc Lasgouttes: Georg == Georg Baum [EMAIL PROTECTED] writes: Georg Loading an included file results in an error message if it is Georg not a lyx file. This can be fixed easily, see attached. There Georg is still an error message if no editor for the file format is Georg known, but the user can fix that by defining an editor if Georg needed. Is this the correct way to do it, or should I do it Georg like in insetgraphics and insetexternal with an extra lfun? What kind of files do you plan to insert this way? Is that meant for .tex or .txt files? I do not think these ones are well suited for getExtFromContents. Any sort of files can be inserted with the include inset (at least if you use the verbatim mode). So it is possible best to deactivate the load button if the file is not a lyx file. Unfortunately this requires more code ;-( Georg
Re: [patch] included files and the load button
Georg == Georg Baum [EMAIL PROTECTED] writes: What kind of files do you plan to insert this way? Is that meant for .tex or .txt files? I do not think these ones are well suited for getExtFromContents. Georg Any sort of files can be inserted with the include inset (at Georg least if you use the verbatim mode). So it is possible best to Georg deactivate the load button if the file is not a lyx file. Georg Unfortunately this requires more code ;-( In this case the file is a text file and it should be opened with the editor for ASCII, and should not use getExtFromContents. JMarc
Re: [patch] included files and the "load" button
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: Georg> Loading an included file results in an error message if it is Georg> not a lyx file. This can be fixed easily, see attached. There Georg> is still an error message if no editor for the file format is Georg> known, but the user can fix that by defining an editor if Georg> needed. Is this the correct way to do it, or should I do it Georg> like in insetgraphics and insetexternal with an extra lfun? What kind of files do you plan to insert this way? Is that meant for .tex or .txt files? I do not think these ones are well suited for getExtFromContents. JMarc
Re: [patch] included files and the "load" button
Am Dienstag, 14. September 2004 09:39 schrieb Jean-Marc Lasgouttes: > > "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: > > Georg> Loading an included file results in an error message if it is > Georg> not a lyx file. This can be fixed easily, see attached. There > Georg> is still an error message if no editor for the file format is > Georg> known, but the user can fix that by defining an editor if > Georg> needed. Is this the correct way to do it, or should I do it > Georg> like in insetgraphics and insetexternal with an extra lfun? > > What kind of files do you plan to insert this way? Is that meant for > .tex or .txt files? I do not think these ones are well suited for > getExtFromContents. Any sort of files can be inserted with the include inset (at least if you use the verbatim mode). So it is possible best to deactivate the load button if the file is not a lyx file. Unfortunately this requires more code ;-( Georg
Re: [patch] included files and the "load" button
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: >> What kind of files do you plan to insert this way? Is that meant >> for .tex or .txt files? I do not think these ones are well suited >> for getExtFromContents. Georg> Any sort of files can be inserted with the include inset (at Georg> least if you use the verbatim mode). So it is possible best to Georg> deactivate the load button if the file is not a lyx file. Georg> Unfortunately this requires more code ;-( In this case the file is a text file and it should be opened with the editor for ASCII, and should not use getExtFromContents. JMarc
Re: [patch included]
On Sat, 16 Sep 2000, Dekel Tsur wrote: On Fri, Sep 15, 2000 at 07:32:28PM +0300, Marko Vendelin wrote: The following patch adds support for regexp search in FormCitation (Gnome frontend). Why not filter the entries in the citation list (i.e. show only the ones containing the regexp) instead of search? Actually, it is a filter. Marko
Re: [patch included]
On Sat, 16 Sep 2000, Dekel Tsur wrote: > On Fri, Sep 15, 2000 at 07:32:28PM +0300, Marko Vendelin wrote: > > > > The following patch adds support for regexp search in FormCitation (Gnome > > frontend). > > Why not filter the entries in the citation list (i.e. show only the ones > containing the regexp) instead of search? Actually, it is a filter. Marko
Re: [patch included]
On Fri, Sep 15, 2000 at 07:32:28PM +0300, Marko Vendelin wrote: The following patch adds support for regexp search in FormCitation (Gnome frontend). Why not filter the entries in the citation list (i.e. show only the ones containing the regexp) instead of search?
Re: [patch included]
On Fri, Sep 15, 2000 at 07:32:28PM +0300, Marko Vendelin wrote: > > The following patch adds support for regexp search in FormCitation (Gnome > frontend). Why not filter the entries in the citation list (i.e. show only the ones containing the regexp) instead of search?
Re: [patch included] Re: [Jules Bean jmlb2@hermes.cam.ac.uk] Various (math-mode) HMI improvements
Marko Vendelin [EMAIL PROTECTED] writes:
| On 15 Sep 2000, Lars Gullik Bjønnes wrote:
|
| | Any good library (C/C++) which is able to check whether a string matches
| | given regexp. Return value TRUE/FALSE/invalid regexp is expected :)
|
| We already have that included under src/support so it is easy to use.
|
| The following patch adds support for regexp search in FormCitation (Gnome
| frontend).
Ok, I will apply this patch.
One not however: do not use defines, ever!
#define CONF_COLUMN "column"
should be
static string const CONF_COLUMN("column");
similar for the other defines
| PS: BTW, what about my patches submitted earlier (tracking TOC changes and
| adding TOC to Gnome Menubar) ?
I have to dog them up to have a look.
Lgb
Re: [patch included] Re: [Jules Bean jmlb2@hermes.cam.ac.uk]Various (math-mode) HMI improvements
On 15 Sep 2000, Lars Gullik Bjønnes wrote:
One not however: do not use defines, ever!
#define CONF_COLUMN "column"
should be
static string const CONF_COLUMN("column");
I will submit a patch with all these defines removed. But can you tell me
why should we avoid the defines (I presume only with strings) ?
Marko
Re: [patch included] Re: [Jules Bean jmlb2@hermes.cam.ac.uk] Various (math-mode) HMI improvements
Marko Vendelin [EMAIL PROTECTED] writes:
| On 15 Sep 2000, Lars Gullik Bjønnes wrote:
|
| One not however: do not use defines, ever!
|
| #define CONF_COLUMN "column"
|
| should be
|
| static string const CONF_COLUMN("column");
|
| I will submit a patch with all these defines removed. But can you tell me
| why should we avoid the defines (I presume only with strings) ?
with ints enums and other objects too and especially macros.
Defines are bad because:
- untyped
- arg expansion problem with macros
And in C++ we have the needed support for doing this _in_ the language
no need to do it in the preprocessor:
- const
- static
- inline
Lgb
Re: [patch included] Re: [Jules Bean <jmlb2@hermes.cam.ac.uk>] Various (math-mode) HMI improvements
Marko Vendelin <[EMAIL PROTECTED]> writes:
| On 15 Sep 2000, Lars Gullik Bjønnes wrote:
|
| > | Any good library (C/C++) which is able to check whether a string matches
| > | given regexp. Return value TRUE/FALSE/invalid regexp is expected :)
| >
| > We already have that included under src/support so it is easy to use.
|
| The following patch adds support for regexp search in FormCitation (Gnome
| frontend).
Ok, I will apply this patch.
One not however: do not use defines, ever!
#define CONF_COLUMN "column"
should be
static string const CONF_COLUMN("column");
similar for the other defines
| PS: BTW, what about my patches submitted earlier (tracking TOC changes and
| adding TOC to Gnome Menubar) ?
I have to dog them up to have a look.
Lgb
Re: [patch included] Re: [Jules Bean <jmlb2@hermes.cam.ac.uk>]Various (math-mode) HMI improvements
On 15 Sep 2000, Lars Gullik Bjønnes wrote:
> One not however: do not use defines, ever!
>
> #define CONF_COLUMN "column"
>
> should be
>
> static string const CONF_COLUMN("column");
I will submit a patch with all these defines removed. But can you tell me
why should we avoid the defines (I presume only with strings) ?
Marko
Re: [patch included] Re: [Jules Bean <jmlb2@hermes.cam.ac.uk>] Various (math-mode) HMI improvements
Marko Vendelin <[EMAIL PROTECTED]> writes:
| On 15 Sep 2000, Lars Gullik Bjønnes wrote:
|
| > One not however: do not use defines, ever!
| >
| > #define CONF_COLUMN "column"
| >
| > should be
| >
| > static string const CONF_COLUMN("column");
|
| I will submit a patch with all these defines removed. But can you tell me
| why should we avoid the defines (I presume only with strings) ?
with ints enums and other objects too and especially macros.
Defines are bad because:
- untyped
- arg expansion problem with macros
And in C++ we have the needed support for doing this _in_ the language
no need to do it in the preprocessor:
- const
- static
- inline
Lgb
