From: Denis B. <dbi...@wa...> - 2013-01-07 15:45:58
|
Hi, let say I have the following .tex file where I explain how to make use of magic comments in TXS to fix the dictionary: % !TeX spellcheck = fr_FR \documentclass{article} \usepackage{listings} \begin{document} \begin{lstlisting} % !TeX spellcheck = en_GB \end{lstlisting} \end{document} So far, so good, thanks to the lstlisting environment, recognized by TXS as a "verbatim" environment. Suppose now I want to use, instead of lstlisting environment, a personal listings environment, say "foo". In this case, whatever the dictionary I write in either place, it is reproduced in both place: % !TeX spellcheck = fr_FR \documentclass{article} \usepackage{listings} \lstnewenvironment{foo}{}{} \begin{document} \begin{foo} % !TeX spellcheck = fr_FR \end{foo} \end{document} and, during typing the dictionary in one place, as long as it is not a known dictionary, the other one is automatically replaced by "cs_CZ". So, bug or feature? :) -- Denis |
From: Tim H. <tho...@te...> - 2013-01-07 17:25:35
|
Well, spellcheck is currently a per-file setting. It's not really specified what should happen, if you insert two of these comments. Am 07.01.2013 16:45, schrieb Denis Bitouzé: > Hi, > > let say I have the following .tex file where I explain how to make use > of magic comments in TXS to fix the dictionary: > > % !TeX spellcheck = fr_FR > \documentclass{article} > \usepackage{listings} > \begin{document} > \begin{lstlisting} > % !TeX spellcheck = en_GB > \end{lstlisting} > \end{document} > > So far, so good, thanks to the lstlisting environment, recognized by > TXS as a "verbatim" environment. > > Suppose now I want to use, instead of lstlisting environment, a > personal listings environment, say "foo". In this case, whatever the > dictionary I write in either place, it is reproduced in both place: > > % !TeX spellcheck = fr_FR > \documentclass{article} > \usepackage{listings} > \lstnewenvironment{foo}{}{} > \begin{document} > \begin{foo} > % !TeX spellcheck = fr_FR > \end{foo} > \end{document} > > and, during typing the dictionary in one place, as long as it is not > a known dictionary, the other one is automatically replaced by "cs_CZ". > > So, bug or feature? :) |
From: Denis B. <dbi...@wa...> - 2013-01-07 18:25:06
|
Le lundi 07/01/13 à 18h06, Tim Hoffmann <tho...@te...> a écrit : > Well, spellcheck is currently a per-file setting. It's not really > specified what should happen, if you insert two of these comments. OK. Would it be possible nevertheless to neutralize this "feature"? ;) -- Denis |
From: Tim H. <tho...@te...> - 2013-01-07 21:36:06
|
Ok, now I had a proper look and understand what you were trying to achieve. This is one of the cases in which you can use the Config -> Custom Highlighting. Define your personal listings enviroment "foo" as verbatim there. Then the tex comment inside the environement is not parsed any more. Am 07.01.2013 19:24, schrieb Denis Bitouzé: > Le lundi 07/01/13 à 18h06, > Tim Hoffmann <tho...@te...> a écrit : > >> Well, spellcheck is currently a per-file setting. It's not really >> specified what should happen, if you insert two of these comments. > OK. Would it be possible nevertheless to neutralize this "feature"? ;) |
From: Denis B. <dbi...@wa...> - 2013-01-07 21:50:45
|
Le lundi 07/01/13 à 22h36, Tim Hoffmann <tho...@te...> a écrit : > Ok, now I had a proper look and understand what you were trying to > achieve. I probably wasn't that clear. > This is one of the cases in which you can use the Config -> Custom > Highlighting. Define your personal listings enviroment "foo" as > verbatim there. Then the tex comment inside the environement is not > parsed any more. OK, nice. But, as said in another thread, the settings of Config -> Custom Highlighting appear differently in texstudio.ini: 1. for a command, say \foo, it appears as a readable setting: customCommands=\\foo 2. for an environment, say 'bar', it appears as a non really readable setting: customHighlighting=@Variant(\0\0\0\b\0\0\0\x1\0\0\0\x6\0\x62\0\x61\0r\0\0\0\x2\0\0\0\0) Is there a way to make customHighlighting as clear as customCommands? -- Denis |
From: Tim H. <tho...@te...> - 2013-01-07 22:48:01
|
Am 07.01.2013 22:50, schrieb Denis Bitouzé: > Le lundi 07/01/13 à 22h36, > Tim Hoffmann <tho...@te...> a écrit : > >> Ok, now I had a proper look and understand what you were trying to >> achieve. > I probably wasn't that clear. > >> This is one of the cases in which you can use the Config -> Custom >> Highlighting. Define your personal listings enviroment "foo" as >> verbatim there. Then the tex comment inside the environement is not >> parsed any more. > OK, nice. > > But, as said in another thread, the settings of Config -> Custom > Highlighting appear differently in texstudio.ini: > > 1. for a command, say \foo, it appears as a readable setting: > > customCommands=\\foo > > 2. for an environment, say 'bar', it appears as a non really readable > setting: > > customHighlighting=@Variant(\0\0\0\b\0\0\0\x1\0\0\0\x6\0\x62\0\x61\0r\0\0\0\x2\0\0\0\0) > > Is there a way to make customHighlighting as clear as customCommands? Well, you could. But the customHighlighting is more complex than customCommands. While the latter are just the commands themselves, the former are the commands plus the relation to the actual format (e.g. verbatim). And from the programming side it's easier to store this complete structure. In this case, don't worry what is written in the ini. TXS takes care to properly encode and decode it. Use the config dialog to modify it. |
From: Denis B. <dbi...@wa...> - 2013-01-08 07:43:07
|
Le lundi 07/01/13 à 23h48, Tim Hoffmann <tho...@te...> a écrit : > Well, you could. But the customHighlighting is more complex than > customCommands. While the latter are just the commands themselves, > the former are the commands plus the relation to the actual format > (e.g. verbatim). And from the programming side it's easier to store > this complete structure. Yes but in a so human unreadable way :) > In this case, don't worry what is written in the ini. TXS takes care > to properly encode and decode it. Use the config dialog to modify it. OK, thanks. -- Denis |
From: Denis B. <dbi...@wa...> - 2013-01-08 09:31:29
|
Le mardi 08/01/13 à 08h43, Denis Bitouzé <dbi...@wa...> a écrit : > > In this case, don't worry what is written in the ini. TXS takes care > > to properly encode and decode it. Use the config dialog to modify > > it. > > OK, thanks. Well, one more question: AFAICS, if I have custom highlights in my texstudio.ini (an environment 'bar', with verbatim format, and a command \foo): customHighlighting=@Variant(\0\0\0\b\0\0\0\x1\0\0\0\x6\0\x62\0\x61\0r\0\0\0\x2\0\0\0\0) customCommands=\\foo and I load a profile containing another custom highlights (an environment 'anotherbar', with verbatim format, and a command \anotherfoo): customHighlighting=@Variant(\0\0\0\b\0\0\0\x1\0\0\0\x14\0\x61\0n\0o\0t\0h\0\x65\0r\0\x62\0\x61\0r\0\0\0\x2\0\0\0\0) customCommands=\\anotherfoo my previous custom highlights will be overridden. Would it be possible to make the new custom highlights added to the previous ones? This is a similar feature as the one I asked for user macros and user commands that Jan implemented. -- Denis |
From: Benito v. d. Z. <be...@be...> - 2013-01-10 11:29:01
|
> This is a similar feature as the one I asked for user macros and user > commands that Jan implemented. Perhaps we should add a feature to import arbitrary single settings from a file... On 01/08/2013 10:31 AM, Denis Bitouzé wrote: > Le mardi 08/01/13 à 08h43, > Denis Bitouzé<dbi...@wa...> a écrit : > >>> In this case, don't worry what is written in the ini. TXS takes care >>> to properly encode and decode it. Use the config dialog to modify >>> it. >> OK, thanks. > Well, one more question: AFAICS, if I have custom highlights in my > texstudio.ini (an environment 'bar', with verbatim format, and a > command \foo): > > customHighlighting=@Variant(\0\0\0\b\0\0\0\x1\0\0\0\x6\0\x62\0\x61\0r\0\0\0\x2\0\0\0\0) > customCommands=\\foo > > and I load a profile containing another custom highlights (an > environment 'anotherbar', with verbatim format, and a command > \anotherfoo): > > customHighlighting=@Variant(\0\0\0\b\0\0\0\x1\0\0\0\x14\0\x61\0n\0o\0t\0h\0\x65\0r\0\x62\0\x61\0r\0\0\0\x2\0\0\0\0) > customCommands=\\anotherfoo > > my previous custom highlights will be overridden. Would it be possible > to make the new custom highlights added to the previous ones? > > This is a similar feature as the one I asked for user macros and user > commands that Jan implemented. |
From: Denis B. <dbi...@wa...> - 2013-01-10 17:27:20
|
Le jeudi 10/01/13 à 12h35, Benito van der Zander <be...@be...> a écrit : > Perhaps we should add a feature to import arbitrary single settings > from a file... As said by Tim, not the core of this request, but the core of another request I submitted: so, would be very nice! :) -- Denis |
From: Tim H. <tho...@te...> - 2013-01-10 11:59:41
|
Am 10.01.2013 12:35, schrieb Benito van der Zander: >> This is a similar feature as the one I asked for user macros and user >> commands that Jan implemented. > Perhaps we should add a feature to import arbitrary single settings from > a file... That's not not the actual core of the request. For certain features one would have to distinguish between overwrite and merge. This could go as a global option, but it might be worth having this per option (which then requires handling of single settings). Slightly o.t.: Some time ago I already considered the possibility of subgrouping the settings. (e.g. Editor, Highlighting, Commands, ...). This would allow the user importing only the editor settings of someone else without overwriting his build command settings. > > On 01/08/2013 10:31 AM, Denis Bitouzé wrote: >> Le mardi 08/01/13 à 08h43, >> Denis Bitouzé<dbi...@wa...> a écrit : >> >>>> In this case, don't worry what is written in the ini. TXS takes care >>>> to properly encode and decode it. Use the config dialog to modify >>>> it. >>> OK, thanks. >> Well, one more question: AFAICS, if I have custom highlights in my >> texstudio.ini (an environment 'bar', with verbatim format, and a >> command \foo): >> >> customHighlighting=@Variant(\0\0\0\b\0\0\0\x1\0\0\0\x6\0\x62\0\x61\0r\0\0\0\x2\0\0\0\0) >> customCommands=\\foo >> >> and I load a profile containing another custom highlights (an >> environment 'anotherbar', with verbatim format, and a command >> \anotherfoo): >> >> customHighlighting=@Variant(\0\0\0\b\0\0\0\x1\0\0\0\x14\0\x61\0n\0o\0t\0h\0\x65\0r\0\x62\0\x61\0r\0\0\0\x2\0\0\0\0) >> customCommands=\\anotherfoo >> >> my previous custom highlights will be overridden. Would it be possible >> to make the new custom highlights added to the previous ones? >> >> This is a similar feature as the one I asked for user macros and user >> commands that Jan implemented. > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122712 > _______________________________________________ > TeXstudio-list mailing list > TeX...@li... > https://lists.sourceforge.net/lists/listinfo/texstudio-list |
From: Denis B. <dbi...@wa...> - 2013-01-10 17:30:43
|
Le jeudi 10/01/13 à 12h59, Tim Hoffmann <tho...@te...> a écrit : > That's not not the actual core of the request. For certain features > one would have to distinguish between overwrite and merge. Indeed. > This could go as a global option, but it might be worth having this > per option Would be much better. > (which then requires handling of single settings). > > Slightly o.t.: Some time ago I already considered the possibility of > subgrouping the settings. (e.g. Editor, Highlighting, Commands, ...). Do you mean subgrouping in the in the .ini (or txsprofile) file? Could be nice but a UI would be better ;) > This would allow the user importing only the editor settings of > someone else without overwriting his build command settings. Overwriting some of them should be allowed if the user prefers so. -- Denis |
From: Tim H. <tho...@te...> - 2013-01-10 18:50:53
|
Am 10.01.2013 18:30, schrieb Denis Bitouzé: > Le jeudi 10/01/13 à 12h59, > Tim Hoffmann <tho...@te...> a écrit : > >> That's not not the actual core of the request. For certain features >> one would have to distinguish between overwrite and merge. > Indeed. > >> This could go as a global option, but it might be worth having this >> per option > Would be much better. > >> (which then requires handling of single settings). >> >> Slightly o.t.: Some time ago I already considered the possibility of >> subgrouping the settings. (e.g. Editor, Highlighting, Commands, ...). > Do you mean subgrouping in the in the .ini (or txsprofile) file? Could > be nice but a UI would be better ;) Well, maybe sort of both. I think a UI is necessary if this feature should be used by people. One can still decide if we want to make the subgrouping explicitly in the ini or only in the program code. Reflecting the groups in the ini would be nice. However, this means an incompatible change of the format. Then, at least, we'd have to recover backward-compatibility by beeing able to convert the old format to the new format (additional work). >> This would allow the user importing only the editor settings of >> someone else without overwriting his build command settings. > Overwriting some of them should be allowed if the user prefers so. One could organize them in a tree structure so that groups subgroups and single items could be selected. Not sure if users would really use it and if this is worth all the effort. - I don't know any other software allowing for this. So it seems not to be requested much in general. |
From: Denis B. <dbi...@wa...> - 2013-01-11 07:29:28
|
Le jeudi 10/01/13 à 19h50, Tim Hoffmann <tho...@te...> a écrit : > >> Slightly o.t.: Some time ago I already considered the possibility > >> of subgrouping the settings. (e.g. Editor, Highlighting, > >> Commands, ...). > > Do you mean subgrouping in the in the .ini (or txsprofile) file? > > Could be nice but a UI would be better ;) > Well, maybe sort of both. I think a UI is necessary if this feature > should be used by people. One can still decide if we want to make the > subgrouping explicitly in the ini or only in the program code. > Reflecting the groups in the ini would be nice. However, this means > an incompatible change of the format. Then, at least, we'd have to > recover backward-compatibility by beeing able to convert the old > format to the new format (additional work). OK, then maybe not necessary to change the ini structure. > >> This would allow the user importing only the editor settings of > >> someone else without overwriting his build command settings. > > Overwriting some of them should be allowed if the user prefers so. > One could organize them in a tree structure so that groups subgroups > and single items could be selected. > > Not sure if users would really use it and if this is worth all the > effort. - I don't know any other software allowing for this. So it > seems not to be requested much in general. I know at least two persons who'd like it: a researcher working in oriental languages who wants to help colleagues who don't know LaTeX, providing them an IDE (TXS) with ad hoc configuration, and me who want to help PhD students to be as efficient as possible with some thesis class. In Emacs sphere for instance, lot of people put their configuration file on Internet to help others to have a nice customization of their editor. We can imagine same thing for TXS, maybe with a central place to store and provide configuration files (and, as I already suggested it, templates as well that may be easily installed in TXS from TXS). -- Denis |
From: Tim H. <tho...@te...> - 2013-01-11 11:06:08
|
Am 11.01.2013 08:29, schrieb Denis Bitouzé: > Le jeudi 10/01/13 à 19h50, > Tim Hoffmann <tho...@te...> a écrit : > >>>> Slightly o.t.: Some time ago I already considered the possibility >>>> of subgrouping the settings. (e.g. Editor, Highlighting, >>>> Commands, ...). >>> Do you mean subgrouping in the in the .ini (or txsprofile) file? >>> Could be nice but a UI would be better ;) >> Well, maybe sort of both. I think a UI is necessary if this feature >> should be used by people. One can still decide if we want to make the >> subgrouping explicitly in the ini or only in the program code. >> Reflecting the groups in the ini would be nice. However, this means >> an incompatible change of the format. Then, at least, we'd have to >> recover backward-compatibility by beeing able to convert the old >> format to the new format (additional work). > OK, then maybe not necessary to change the ini structure. Well, still not yet decided. Initially it's less work. But in the long run a more modular ini structure may be easier to maintain. >>>> This would allow the user importing only the editor settings of >>>> someone else without overwriting his build command settings. >>> Overwriting some of them should be allowed if the user prefers so. >> One could organize them in a tree structure so that groups subgroups >> and single items could be selected. >> >> Not sure if users would really use it and if this is worth all the >> effort. - I don't know any other software allowing for this. So it >> seems not to be requested much in general. > I know at least two persons who'd like it: a researcher working in > oriental languages who wants to help colleagues who don't know LaTeX, > providing them an IDE (TXS) with ad hoc configuration, and me who want > to help PhD students to be as efficient as possible with some thesis > class. > > In Emacs sphere for instance, lot of people put their configuration > file on Internet to help others to have a nice customization of their > editor. We can imagine same thing for TXS, maybe with a central place > to store and provide configuration files (and, as I already suggested > it, templates as well that may be easily installed in TXS from TXS). It all takes time. You might have noticed that the template system is on its way :) |
From: Denis B. <dbi...@wa...> - 2013-01-11 11:13:24
|
Le vendredi 11/01/13 à 12h06, Tim Hoffmann <tho...@te...> a écrit : > > OK, then maybe not necessary to change the ini structure. > Well, still not yet decided. Initially it's less work. But in the > long run a more modular ini structure may be easier to maintain. OK. > > I know at least two persons who'd like it: a researcher working in > > oriental languages who wants to help colleagues who don't know > > LaTeX, providing them an IDE (TXS) with ad hoc configuration, and > > me who want to help PhD students to be as efficient as possible > > with some thesis class. > > > > In Emacs sphere for instance, lot of people put their configuration > > file on Internet to help others to have a nice customization of > > their editor. We can imagine same thing for TXS, maybe with a > > central place to store and provide configuration files (and, as I > > already suggested it, templates as well that may be easily > > installed in TXS from TXS). > > It all takes time. Of course :) > You might have noticed that the template system is on its way :) Yes, and that's pretty cool: thanks! -- Denis |